MCP: An (Accidentally) Universal Plugin System

You’re totally right, and that’s why I think this era will fail.

Web 2.0 failed because eventually people realized to make money they needed to serve ads, and to do that they needed to own the UI. Making it easy to exfiltrate data meant switching cost was low, too. Can’t have that when you’re trying to squeeze value out of users. Look at the evolution of the twitter API over the 2.0 era. That was entirely motivated by Twitter’s desperate need to make money through ads.

Only way we avoid that future is if we figure out new business models, but I doubt that will happen. Ads are too lucrative and people too resistant to pay for things.

They don't care about using your IP rights, I doubt it also works the other way around.

Did you mean this is Web 3.0? (semantic web)

Where the goal was to have a site's data as machine readable so that could be mashed up into something new? Instead of making it easier to gather the big sites locked the bulk of their data down so it never gained widespread adoption

Web 2.0 is what we mostly have now -- social, user generated content and interaction

Web 2.0 was also hot.

There’s very little actual engineering going in to designing MCP interfaces to actually efficiently work with the way LLM workflows actually operate. Many MCPs offer tools that allow an LLM to retrieve a list of ‘things that exist’ with the expectation the LLM will then pick something out of that list for further action with a different tool. There’s very little evidence that LLMs are actually good at using tools that work like that, and massive lists of ‘things that exist’ eat tokens and context.

Many businesses are rushing to put out something that fits the MCP standard but not taking the time to produce something that lets an LLM achieve things with their tool.

MCPs are the most basic solution possible. Shoving the tool definitions into a vector store and having a subagent search for relevant tools, then another subagent to run the tools would greatly reduce impact on context. I think it’d work in theory, but it’s so annoying to have to do something like this. We’re still in a world where we have some building blocks rather than full fledged toolboxes.

I discovered the "Layered Tool Pattern" a few days ago which exposes three tools to discover and execute an arbitrary number of service endpoints. https://engineering.block.xyz/blog/build-mcp-tools-like-ogre...

Love how the MCPs mimic the company they represent in that sense.

Most UIs currently are unsophisticated and let you turn on or off the tools on server-by-server basis. For some large servers (especially if they act as aggrgeators) this approach isn't going to be desirable and you are going to want to select individual tools to activate, not servers. But that's a UI issue more than a protocol issue.

I don’t like MCP because it relies on good faith from the plugin provider. It works great in closed, trusted environments but it cannot scale across trust boundaries.

It just begs for spam and fraud, with badly-behaving services advertising lowest-cost, highest-quality, totally amazing services. It feels like the web circa 1995… lots of implicit trust that isn’t sustainable.

Totally agree - the true source of all of the value here is the new incentive to write very simple services with very simple documentation and to make that documentation easily discoverable.

It fills a gap that exists in most service documentation: an easily discoverable page for developers (specifically, those who already know how to use their ecosystem of choice's HTTP APIs) that has a very short list of the service's most fundamental functionality with a simplified specification so they can go and play around with it.

Too bad that the S in MCP stands for security

WSDL has entered the chat

The emperor is indeed naked.

I wouldn't call it cynicism.

Web services started as the same open utopia. Once everyone was in they jacked up the prices so high it killed the initial consumer apps (eg. Google Maps and Reddit)

Nobody is giving access to their walled garden for the good of open-anything. It's what the VCs and stockholders demand and they're the ones putting up the cash to keep this AI hype funded in spite of it running at a loss.

Given they haven't put security into MCP yet, I guess they'll need to do that first before they move on reinventing API keys so they can charge for access and hailing that as the next reason the line will go up.

Some remote MCPs will get locked down to know client endpoints, same as any other HTTP service, so if companies are really concerned about them being AI-use-only and don't mind cutting off some AI use to preserve that exclusivity, they’ll lock it down to the big known hosted AI frontends (assuming those end up supporting MCP; the only one I know of that does currently is ChatGPT Deep Research, and only for very limited shapes of servers.)

OTOH, that only effects those services, it won't stop people from leveraging MCP as, say, a generic local plugin model for non-AI apps.

If MPC develops as an open standard and this "loophole" gains enough popularity, then companies can only really limit access to their services. This seems like a generally good thing that will enhance automation. In some cases it doesn't really matter if the automation comes from agents, hard coded software or a combination of the two.

And even then: the key value of MCP is that it's "simplified." Few servers are implementing anything you couldn't already do for years with their REST APIs.

And why? Because it dumbs it down to the point that the LLM can understand it (often, in part, by removing security concerns). But these are LLMs! They're supposed to be smart! Isn't it a supposedly temporary failure that I can't just point the LLM at an OpenAPI spec (or use HATEOAS) and be good to go?

Will this be doable in the next few months with better models? If so, why bother with MCP? If this won't be doable in the next few months / years, then how smart do we really expect these LLMs to be?

> but if there was an AI between these things, then it becomes a universal plugin system

I've reread the article a couple times and I can't see where it says that you need to use an LLM to make it universal. I'm going to go so far as to say that it doesn't say that.

> then goes back on that thesis by saying "but if there was an AI between these things, then it becomes a universal plugin system".

This is neither an accurate quote of the article, nor an accurate paraphrase of something the article says, nor an accurate description of something subtly implied by the article without directly being said.

The article, in fact, gives an example without AI in the middle.

MCP's key innovation isn't the format but its unidirectional, stateless design pattern that makes it fundamentally easier to implement than bidirectional protocols like OpenAPI, which is why it's gaining traction as a universal connector beyond just LLM contexts.