Interesting thoughts regarding MCPs being the future App Store/Platform. I don't know that I agree but I don't necessarily disagree either. Time will certainly tell.
To me, MCP feels more like an implementation detail, not something that most people would ever use directly. I would expect that the future would be some app distributed through existing channels, which bundles the MCP client into it, then uses a server-side component (run by the vendor of course) to get the real work done. As much as I like the idea of people installing the servers locally, that future seems like a Linux nerd/self hosted type of activity. I just can't imagine a typical mac or windows non-power-user installing one directly. Just the idea that they would need to install "two apps" is enough to confuse them immensely. It's possible some might bundle the server too and run it locally as needed, but even in that case I think MCP is completely invisible to the user.
Agree that for mainstream use it needs to be and will be hidden from the user entirely.
Will be much more like an app store where you can see a catalog of the "LLM Apps" and click to enable the "Gmail" plugin or "Shopping.com" plugin. The MCP protocol makes this easier and lets the servers write it once to appear in multiple clients (with some caveats I'm sure).
MCP's will be run by the service providers, and you'll have the ability to "link" them, just like today you can link a Google account to give access to Calendar, GDrive, ... in the future you'll be able to give a model access to the Google MCP for your account.
I don't feel that way. Maybe the first examples have all been related to what software people do, but I think an MCP for a travel site would be a game changer.
There are so many things I want to tell a travel site that just doesn't fit into filters, so then end up spending more time searching all kinds of permutations.
It's a matter of organizing developer effort around a set of standards. Good architecture makes it easy to contribute to the ecosystem, and currently agentic tooling is the wild west, with little in terms of standardization. Now we are seeing more developer momentum around making our everyday tools accessible to agents.
> Think of MCPs as standardized APIs—connectors between external data sources or applications and large language models (LLMs) like ChatGPT or Claude.
This is incorrect.
MCP is Model Context Protocol.
You didn't "build an MCP", you implemented an MCP server. Lighttpd is not "an HTTP", it's an HTTP server. wget is also not "An HTTP", it's an HTTP client. Lighttpd and wget are different enough that it's useful to make that distinction clear when labeling them.
dnsmasq is not "a DHCP", it's a DHCP server.
This distinction also matters because it is certain that we will see further protocol iterations so we will indeed have multiple different MCPs that may or may not be compatible.
As someone else once said, I want a Grocery Shopping Engine. "Here's my shopping list, taking into consideration delivery times and costs, please buy this for the lowest cost from any combination of supermarkets and deliver by day after tomorrow at the latest."
If MCPs gave the LLMs a window into all the major supermarkets home shopping sites that looks like it's a step closer.
My prediction: there will be no standard protocol, clients will do whatever works for them, and devs will do whatever it takes to be installable on those clients. Just like mobile.
Are there any open-source MCP 'app stores' currently available? I am considering building one for my employer. A place to host internally built MCPs. It would be useful to know if there is something already out there.
we’ve been building most of what OP has written about with https://mcp.run
We started doing this the day Anthropic released MCP in November last year. Our company has always been devoted to secure plug-in system technology having built Extism, a WebAssembly plugin framework.
We immediately saw MCP as the plugin system for AI and knew it would be significant, but were concerned about the security implications of running MCP servers from untrusted parties and using the STDIO transport which makes user systems vulnerable in ways we weren’t ok with.
So we built mcp.run which is a secure implementation of the protocol, running servers in fully isolated & portable wasm modules. They must be allow-listed to access files & network hosts, and cannot access any part of your system without your explicit permission.
They also run everywhere. Each server (we call them servlets) on mcp.run is automatically available via SSE (soon HTTP streaming) as well as STDIO, but can also be embedded directly into your AI apps, no transport needed, and can run natively on mobile!
We are excited about MCP and glad so many are too - but we really need more security-oriented implementations before it’s too late and someone suffers a seriously bad exploit - which could tarnish the ecosystem for everyone.
Interesting thoughts regarding MCPs being the future App Store/Platform. I don't know that I agree but I don't necessarily disagree either. Time will certainly tell.
To me, MCP feels more like an implementation detail, not something that most people would ever use directly. I would expect that the future would be some app distributed through existing channels, which bundles the MCP client into it, then uses a server-side component (run by the vendor of course) to get the real work done. As much as I like the idea of people installing the servers locally, that future seems like a Linux nerd/self hosted type of activity. I just can't imagine a typical mac or windows non-power-user installing one directly. Just the idea that they would need to install "two apps" is enough to confuse them immensely. It's possible some might bundle the server too and run it locally as needed, but even in that case I think MCP is completely invisible to the user.
Agree that for mainstream use it needs to be and will be hidden from the user entirely.
Will be much more like an app store where you can see a catalog of the "LLM Apps" and click to enable the "Gmail" plugin or "Shopping.com" plugin. The MCP protocol makes this easier and lets the servers write it once to appear in multiple clients (with some caveats I'm sure).
MCP's will be run by the service providers, and you'll have the ability to "link" them, just like today you can link a Google account to give access to Calendar, GDrive, ... in the future you'll be able to give a model access to the Google MCP for your account.
MCP might be one of the few technology pieces where more articles have been written about it than the actual use-cases being built.
It is like the ERC20 era all over again.
I don't feel that way. Maybe the first examples have all been related to what software people do, but I think an MCP for a travel site would be a game changer.
There are so many things I want to tell a travel site that just doesn't fit into filters, so then end up spending more time searching all kinds of permutations.
These could be done with an MCP-augmented agent.
There is no saying that they will expose more functionality through the MCP API than their web site. I imagine the API will be more limited.
ERC20 stood the test of time and is ubiquitous today.
Who knows what MCP looks like in a decade?
It's very funny to see people talking about an extremely thin protocol like this.
It's a matter of organizing developer effort around a set of standards. Good architecture makes it easy to contribute to the ecosystem, and currently agentic tooling is the wild west, with little in terms of standardization. Now we are seeing more developer momentum around making our everyday tools accessible to agents.
[dead]
> Think of MCPs as standardized APIs—connectors between external data sources or applications and large language models (LLMs) like ChatGPT or Claude.
This is incorrect.
MCP is Model Context Protocol.
You didn't "build an MCP", you implemented an MCP server. Lighttpd is not "an HTTP", it's an HTTP server. wget is also not "An HTTP", it's an HTTP client. Lighttpd and wget are different enough that it's useful to make that distinction clear when labeling them.
dnsmasq is not "a DHCP", it's a DHCP server.
This distinction also matters because it is certain that we will see further protocol iterations so we will indeed have multiple different MCPs that may or may not be compatible.
>>MCP Affiliate Shopping Engines
As someone else once said, I want a Grocery Shopping Engine. "Here's my shopping list, taking into consideration delivery times and costs, please buy this for the lowest cost from any combination of supermarkets and deliver by day after tomorrow at the latest."
If MCPs gave the LLMs a window into all the major supermarkets home shopping sites that looks like it's a step closer.
My prediction: there will be no standard protocol, clients will do whatever works for them, and devs will do whatever it takes to be installable on those clients. Just like mobile.
Are there any open-source MCP 'app stores' currently available? I am considering building one for my employer. A place to host internally built MCPs. It would be useful to know if there is something already out there.
MCP in this context means "Model Context Protocol"
I thought it might be "managed cloud providers", but perhaps I'm too optimistic for a change
Or: Master Control Program
we’ve been building most of what OP has written about with https://mcp.run
We started doing this the day Anthropic released MCP in November last year. Our company has always been devoted to secure plug-in system technology having built Extism, a WebAssembly plugin framework.
We immediately saw MCP as the plugin system for AI and knew it would be significant, but were concerned about the security implications of running MCP servers from untrusted parties and using the STDIO transport which makes user systems vulnerable in ways we weren’t ok with.
So we built mcp.run which is a secure implementation of the protocol, running servers in fully isolated & portable wasm modules. They must be allow-listed to access files & network hosts, and cannot access any part of your system without your explicit permission.
They also run everywhere. Each server (we call them servlets) on mcp.run is automatically available via SSE (soon HTTP streaming) as well as STDIO, but can also be embedded directly into your AI apps, no transport needed, and can run natively on mobile!
We are excited about MCP and glad so many are too - but we really need more security-oriented implementations before it’s too late and someone suffers a seriously bad exploit - which could tarnish the ecosystem for everyone.