The Future of MCPs
iamcharliegraham.substack.com
iamcharliegraham.substack.com
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.
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).
TBH, it's quite surprising (and reassuring) that they have standardised as MCPs so soon. It normally takes a decade of walled gardens and proprietary formats before any open standards emerge.
I don't think most of those are granular enough.
But maybe the companies would actually like to at least pipe the communication throught the cloud to get all the usage data. Here's one possible architecture:
local chat client
- talks to cloud LLM
- talks to local MCP servers
- connects to company cloud (this lets the company collect usage data)
- forwards tasks to the cloud
- connects to company cloud to get a users tasks
- executes the tasks (this lets the company use the users hardware, saving cloud costs)Nefariously, I guess since these things would be running in the background continuously, that would provide another avenue for companies to spy on you, so that may be a reason companies create local mcps even if there's no other reason to.
That may make more sense than having a separate "wallet MCP server" running locally and having the LLM coordinate the transaction. While the premise of MCP is to allow LLMs to do such things, idk if I want an LLM to be hallucinating with my credit card.
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.
Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called Linux, and many of its users are not aware that it is basically the GNU system, developed by the GNU Project.
There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine’s resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called Linux distributions are really distributions of GNU/Linux!
And that’s how you get them.
The author explicitly states he built 2 MCP servers, not 2 MCPs, so I don’t know where your beef is coming from
I agree that it sounds stupid and incorrect, but that doesn’t necessarily mean using MCP as a metonym for MCP server.
Words that climb the Zipf curve get squeezed for maximum compression, even at the cost of technical correctness. Entropy > pedantry. Resisting it only Streisands the shorthand.
It is like the ERC20 era all over again.
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.
For example, when I search for flights, there might be situational things (like, "can you please find me a flight that has at least a 2 hour layover at <X> airport because last time i had a hard time finding the new terminal" etc.
Or an agent that will actually even READ that information from the airport website to see notices like "expect long delays in the next 3 months as we renovate Terminal 3"
Right?
The agent could have this information, and then actually look at the flight arrival/departure times and actually filter them through.
Other things like, "I can do a tuesday if cheaper, or, look through my calendar to see if i have any important meetings that day and then decide if i can pick that day to save $400"
These are all things that synthesize multiple pieces of data to ultimately arrive at something as simple as a date filter.
But definitely web mashups all over again.
Who knows what MCP looks like in a decade?
Extending this thought: why would there be any difference between offering data behind an API, and offering data behind a "MCP api"? At the end of the day, the underlying data will be the same (weather, stock market info, logs, whatever), it seems LLMs just needs this to be "standardized", otherwise it doesn't get it (?).
Furthermore..! LLMs can already crawl web pages just fine using (true) restful technologies. So why would there be need for other, new, special APIs when it's enough to expose the same data on a normal website?
I don't get it.
Bespoke MCP's right now are a convenience.
Look at it this way. You have to get some work done - maybe book a flight ticket. So you go to two sites - first you go to flight fare comparison, then you book the ticket on the airline website. And you have to do it in code.
There are two ways you can do it.
First Way 1. Understand the API of the flight comparison portal. 2. Understand the API for the airline website. 3. Write code which combines both these API and does the task.
Second Way 1. Message a coder friend who knows the API of the flight comparison portal and ask him to write code to get the cheapest flight. 2. Message another coder friend who knows the API of the airline portal and ask him to book a flight.
Both ways are possible, but which one do you think is Less Work ? Which one is 'cognitively' easier ? Which one can you do while driving a car with one hand ?
It should be clear that the second way is easier. Not only is the second way easier, but if the task requires multiple providers and a lot of context, it might be the only way possible.
The first way is analogous to LLM's doing API calls. The second way is analogous to LLM's doing MCP Servers. MCP servers reduce the cognitive cost to do a task to the LLM - which dramatically increases their power.
LLM's _can't_ just call APIs, because all they can do is generate text. The LLM can _ask_ you to run some code, but it has no ability to run code directly. MCPs are basically a way for LLMs to signal intent to make an API call, along with a list of white listed APIs, and documentation for using them, and preloaded credentials with whatever permissions you want to give them.
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.
And how exactly will they do that?
Though to be honest not sure why you would need so much info - if I need lettuce or tomatoes for example, I know theyre gonna be at essentially every supermarket in my area....
I was hoping that an LLM would do the heavy lifting of working out who can get your shopping cheapest from various supermarkets.
Probably not worth it if you're buying lettuce and tomatoes, but if you have a large family with a £100+ grocery bill per week it might be worth it?
I thought it might be "managed cloud providers", but perhaps I'm too optimistic for a change
Btw, one of my favorite MCPs is a Whois MCP so I can ask Claude Desktop to brainstorm domain names and then immediately check if they are available :).
It’s clunky but I am still using it :)
What I will say is I agree there should be an option to get rid of the chat confirmations of every single new tool call in a chat - as well as building a set of "profiles" of different tools depending what I'm working on. Also strongly agree there needs to be an internal prompt possibility to explicitely tell the LLM what tool(s) to favor and how to use them (even in addition to the descriptions / schemas of the tools themselves) I opened an issue on the anthropic repo exactly about this: https://github.com/modelcontextprotocol/typescript-sdk/issue...
On that note, the various agents libraries will let you create that same setup.
How does discovery work with MCP? Is there a way to make it fairly seamless?
But any self-hosted npm registry backend (e.g. github npm registry) should serve as a private MCP Server registry?
OCI registry is available every where and probably already presented in your infrastructure. You get to use all the OCI tools/security controls you already have with it.
To add new tools, you just have to update the config file to include new plugins and restart.
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.