MCP is the coming of Web 2.0 2.0
219 comments
·May 23, 2025phillipcarter
Karrot_Kream
MCP is just RPC over a long-lived connection, most cases being a Websocket. IMO RPC is easier to setup because:
1. There's less bikeshedding for the authors about whether modifying a field in a user object should be a PUT or a POST replacing the original user object. I've spent a non-trivial amount of time bikeshedding over REST verbs.
2. LLMs don't need to understand the REST semantics of the API. It can just look at available RPC methods and make the RPC call it thinks will work.
I think that's really it.
HarHarVeryFunny
MPC is more than just a standard way to access remote functionality - it also provides discoverability so the client (LLM) can ask the server what functionality it offers, and understand how to use it.
Karrot_Kream
Sure but there are established alternatives for that also. The internet supports looking up DNS records (A, MX, SRV, TXT, etc), the web offers /.well-known as a place to store things like API endpoint specs, etc. The main difference with MCP is that the discoverability comes with the stream-oriented communication semantics.
masklinn
That’s far from unheard of in RPC protocols? E.g. the system namespace of xml-rpc.
phillipcarter
Right, our MCP server we’ve productionized supports this. It’s really fantastic when it works well. Lotta work to do to make it work well more often though!
EE84M3i
>MCP is just RPC over a long-lived connection, most cases being a Websocket.
My impression was that MCP used SSE and that not using websockets was one of the main reasons it isn't enterprise ready - because it requires maintaining server side state which makes it difficult to deploy at scale. Did they change it to websockets?
mdaniel
Not "change" but it does seem to be an option https://modelcontextprotocol.io/specification/2025-03-26/bas...
As for the stateless part, they heard you and made sure to bring sessions back to SSE: https://modelcontextprotocol.io/specification/2025-03-26/bas...
lsaferite
It isn't "just RPC". The response from an MCP Server Tool is supposed to be LLM-Ready Context. Normal API or RPC calls are responses designed for other software to ingest. If you simply attach an existing API you get a context flooded with detail it likely doesn't need.
exiguus
I use RPC in combination with vector search and a embedded model to get AI ready content. Would you define this as MCP?
cyanydeez
Isn't it just an extension of Swagger, ensuring the API is well documented so the LLM can properly use it?
Doesn't seem to have any other real magic. It could be replaced by an additional field which acts as the LLM equivelent of a doc string in python.
Animats
It's a great money maker. Each data request involves a paid trip through an LLM. It's not like the endpoints negotiate a schema they can use to make cheap queries in future.
Flemlo
We have rest and openapi.
That allows already for self discovery etc.
Everyone who will offer mcp offers a good API anyway.
hirsin
We don't need SDKs, they publish API docs.
We don't need packages or functions, we can just write the code ourselves, every time it's needed.
We don't need compilers, the computer understands assembly already.
It's a mismatch of use - MCP isn't about telling the LLM about the APIs. It's also about encapsulating and simplifying them so the LLM isn't manually figuring them out every single time from scratch.
9dev
OpenAPI specs provide everything the LLM needs to understand an API. And if it can be simplified for the LLM while retaining functionality, why not simplify the API altogether, instead of implementing yet another entry point into the application? Just so nobody has to sit down for longer than the duration of a TikTok and design their API properly?
yeahbruh
[dead]
eddythompson80
> That allows already for self discovery etc.
The problem is usually not with listing the APIs. Almost all services have OpenAPI specs, and you can (often too) complain about lack of documentation.
Orchestrating these APIs is the annoying "fuzzy" challenge. Imagine you have a VM service, and you provide a set of APIs. Someone comes asking "How do I create a copy of a VM we have in the US region to EU region but with half the CPU/RAM?"
You might point to your OpenAPI spec and say you can:
var s1 = takeSnapshot(vm1);
var s2 = copySnapshot(s1, 'EU');
var vm2 = createVmFromSnapShopt(s2, sizeOverride).
If this were an MCP, then it would either orchestrate these APIs "correctly" for me checking as corner cases as possible as (presumably from examples it saw on github). When it misses, it's "oh well, even AI couldn't get it. We can all blame AI everybody" As oppose to when a Human misses and someone is like "how amateurish is the implementation that you're not checking if the vm is `snapshotable` or not?
8note
the value is being able to extend the internal website mcp, so it can grab the data i need.
i can script across a billion systems that i would never go through the work of getting auth/setting up all the service calls and workflows for.
the mcp doesnt need any new permissions, its just what ive got website access to
broost3r
completely agree. huge enterprises are full of engineers who want to do amazing things from 9-5 and then sign off and forget about work until the next day. what kind of business wouldn't want to make sure they're getting the most out of their employees during business hours?
null
zoogeny
> Compared to the olden days, when specs were written by pedantic old Unix dudes
I think that is one of the reasons (among many others) that the semantic web failed (which doesn't contradict the author, whose point is literally the worse-is-better mantra).
People really leaned into the eXtensible part of XML and I think a certain amount of fatigue set it. XSL, XHTML, XSD, WSDL, XSLT, RDF, RSS, et al. just became a bit too much. It was architecture astronautics for data formats when what the world at the time needed was simple interchange formats (and JSON fit the bill).
But I actually believe XML's time has come. I've noticed that XML appears a lot in leaked system prompts from places like Anthropic. LLMs appear to work very well with structured text formats (Markdown and XML specifically).
I believe that MCP is the wrong model, though. I believe we should be "pushing" context to the models rather than giving them directions on how to "pull" the context themselves.
jazzyjackson
Interesting observation. I've been kinda hyped about XML/XSLT lately because I was working on a JSON macro expansion language (just four different macro tags that replace themselves with the macro's expansion, #= #& #? #! assignment, substitution, conditional branch like cond, and call for custom functions) and realised I was re-inventing XSLT, but what I really wanted was xpath, a way to describe traversal over graphs, back and forth along different axes, it's actually an amazing spec. Then I found basex [0] which pulls arbitrary XML documents into a queryable database that can be have queries described in XPATH or XQUERY.
In my mind the best way to create a reliable natural language interface to a dataset without hallucination would be to hand over XML schemas to the system prompt and have it write the queries to retrieve the data.
zoogeny
What I miss is E4X [1]. The ability to grab collections of child elements and collections of descendent elements made working with XML bearable.
mdaniel
> I believe we should be "pushing" context to the models rather than giving them directions on how to "pull" the context themselves.
How could that possibly work for the cases that people want the intern to solve for them? If they knew the information ahead of time, presumably they'd just solve the problem by themselves
I get the impression that the value folks get from MCP is "run some query for me, don't make me learn how to glue together 15 sources"
zoogeny
I'm not sure I understand your objection. You seem to imply that knowing the context is the same as knowing the solution to the problem the context provides?
Let me think of an example here. Context needed to determine if there is cancer in a radiology scan would be the contents of the scan. So there are two modes here, one I say "LLM please tell me if there is cancer in this patients scan" and the LLM makes an MCP call to load the patients report. The second mode is I say "LLM, here is the patients radiology scan, can you tell me if it has signs of cancer".
The first example is what I was calling a "pull" model and the second example is what I am calling a "push" model.
hirsin
The point above about enterprise glue is why this is a pull model.
In your push model, the onus is on you to go find the scan from one of five backends, traverse whatever hoops of access are needed, and actually handle the files manually.
In the pull model, each backend implements the server once, the LLM gets connected to each one once, and you have one single flow to interact with all of them.
goncalo-r
For a lot of office jobs, knowing the context is almost the same as knowing the solution to the problem at hand.
ryeguy
MCP is just function calls with parameters. Whether or not it's push or pull can be decided by the author. A push model takes the scan as an input to the mcp call. A pull model does the pulling within the mcp call. Neither is right or wrong, it's situational.
ranguna
I'm not sure if it's productive to give a full database worth of context to an LLM. There'd be a lot of data that could potentially pollute the LLM's reasoning with information that it doesn't need to answer your prompts. This can be specially troublesome for small models.
wongarsu
XML tags work well for LLMs. But notably the vast majority are just xml tags. Nobody™ is feeding LLMs well-formed XML with an xml declaration (the <?xml version="1.0" encoding="UTF-8"?> at the start) and we aren't using namespaces, XSLT, XML Schemas etc. It's just some ad-hoc collection of sgml-style tags
zoogeny
I've noticed that as well, but I doubt those additional tokens hurt.
You can make an unholy mess with namespaces and all of the bells-and-whistles that XML provides, or you can not. But even if you just structure using <tag></tag> without any of the fancy stuff, you still can create pipelines that operate on that structured format in ways that are more powerful than plain text.
jazzyjackson
still its a format that allows for lossy transmission which I think meshes well with the fuzzy ingestion of llms, the closing tags' redundancy is a feature that helps the llm stay focused
null
selfselfgo
[dead]
crq-yml
I occasionally dally with XML in hobby code as a document source format, but I think what drives me away at the end is silly stuff with syntax, because it is a big spec well beyond the angle-bracket stuff, it wants to cover all the bases, do security right and do character encoding right - which means that "plain text editing" in it is some really unintuitive stuff where you can type in something like this paragraph and it might be parsed in a compatibility mode, but it won't be valid. As an interchange format or something loaded into application software tailored for it, it has more legs - and LLMs definitely wouldn't have any trouble making sense of it, which is good. A lot of yesteryear's challenges came from programmers short on time and eager to hack in features taking a heavily structured spec and wielding it like a blunt instrument. "XML? Sure, I can write a regex for that." Repeat that across three different programs and three different authors and you have a mess.
There is a format that I've hit upon that actually does get at what I want for myself, and that's BBCode. That's a great source format for a lot of stuff - still basically an angle-bracket, but with the right amount of structure and flexibility to serve as a general-purpose frontend syntax. Early implementations were "write a regex for that" but after decades of battle-testing, there are more graceful parsers around these days as well.
blitzar
> the semantic web failed
It failed because they couldn't figure out how to stuff ads in.
bastawhiz
It failed because nobody wanted to use it. Nobody built a compelling product from it, nobody wanted to author the data, nobody cared to use it when anyone did. It wasn't killed, it never got started because it never had a useful purpose.
phatskat
I remember learning XML and XSLT from library books in the late 90’s and found it interesting, but couldn’t find a use for it - I wasn’t really handling data in any meaningful way back then, it was all just hobby learning, but in the decades since I’ve touched XML _at all_ maybe three times? Once was a Salesforce integration I wish I could fully forget, the other times were client one-offs when they had a few things stored in XML that we needed to pipe into WordPress.
MarkMarine
I found this talk really interesting at conj, argues that RDF and the semantic web may have finally found its niche.
cube2222
> I believe we should be "pushing" context to the models rather than giving them directions on how to "pull" the context themselves.
I believe MCP "Resources"[0] are what you're looking for.
[0]: https://modelcontextprotocol.io/docs/concepts/resources#reso...
kiitos
> I believe we should be "pushing" context to the models rather than giving them directions on how to "pull" the context themselves.
Models have very very very limited capacity for context, it's one of their primary bottlenecks, therefore it's important to optimize (minimize) that information as much as possible, allowing the model to pull what it decides it needs makes that constraint much easier to satisfy.
zoogeny
>what it decides it needs
This is what I am suggesting: relying on the model to decide what it needs is maybe not the best use of the available context. It might be better for us to give it the information we are certain it will need.
kiitos
I'm talking about situations where the user wants to ask questions about data that's many orders of magnitude larger than what can be included in any LLM request context. I just provide access to the data (via MCP server, RAG server, whatever) and my question/prompt, it's the LLM's responsibility to do everything else.
bad_haircut72
"The rise of MCP gives hope that the popularity of AI amongst coders might pry open all these other platforms to make them programmable for any purpose, not just so that LLMs can control them."
I think the opposite, MCP is destined to fail for the exact same reason the semantic web failed, nobody makes money when things aren't locked down.
It makes me wonder how much functionality of things like AI searching the web for us (sorry, doing "deep-research") might have been solved in better ways. We could have had restaurants publish their menus in a metadata format and anyone could write a python script to say find the cheapest tacos in Texas, but no, the left hand locks down data behind artificial barriers and then the right hand builds AI (datacenters and all) to get around it. On a macro level its just plain stupid.
fidotron
> I think the opposite, MCP is destined to fail for the exact same reason the semantic web failed, nobody makes money when things aren't locked down.
I think this is right. MCP resembles robots.txt evolved into some higher lifeform, but it's still very much "describe your resources for us to exploit them".
The reason the previous agent wave died (it was a Java thing in the 90s) was eventually everyone realized they couldn't trust their code once it was running on a machine it's supposed to be negotiating with. Fundamentally there is an information assymetry problem between interacting agents, entirely by design. Take that away and huge swathes of society will stop functioning.
arbuge
"describe your resources for us to exploit them"
What you want to do is offer resources that make you money when they're "exploited".
fidotron
I would agree with that if there were no distinction between clients and servers. i.e. agents and LLMs are resources that should be discovered and exploited in the same exact way as anything else, and switchable in the same ways.
The whole thing reminds me of stuff like Alan Kay's legendary OOPSLA talk in 1997 ( https://www.youtube.com/watch?v=oKg1hTOQXoY ) "Every object should have an IP" (Also "Arrogance in computer science is measured in nano Dijkstras").
renatovico
i think the problem is in business process, it´s created for no work automatic, the people need be on control OR need have block because well if all people try cancel your subscription and can go in one step with a simple prompt, this is a huge revenue loss.
look how all companies have super system for crm/sales but when you go to backoffice all run in sheets and sometimes in real paper.
jsnell
It's not just that nobody makes money providing a free and open API. It's that to operate such an API you'll basically need unlimited resources. No matter how many resources you throw at the problem, somebody will still figure out a way of exhausting those resources for marginal gains. MCP will just make the problem worse as AI agents descend on any open MCP servers like locusts.
The only stable option, I think, is going to be pay-per-call RPC pricing. It's at least more viable to do then it was for Web 2.0 APIs, since at least the entity operating the model / agent will act as a clearinghouse for all the payments. (And I guess their most likely billing model is to fold these costs into their subscription plans? That seems like the best way to align incentives.)
noodletheworld
This is correct imo.
...and just like no one is prepared to pay 500 different vendors for micro-transactions, no one is prepared to pay 500 different websites for their MCP services.
Much much more likely is that a few big players (like google and AWS) will have paid-tier 'mega-MCP' servers, that offer 90% of what people need and fit in with existing payment/auth solutions (like your AWS account) and...
...everyone else with an MCP server will be left out in the cold.
That's what's going to happen.
These MCP servers will be cute for a very very short amount of time until people try to monetize them, and then they will consolidate very very quickly into a much smaller set of servers that people are already paying. Mostly cloud providers.
ljm
HATEOAS was the dream in the early 2010s and that basically went nowhere beyond generating swagger yaml, despite the fact it intended to make API consumption trivial.
Whoever coined it as HATEOAS basically set it up to fail though.
johnmaguire
> Whoever coined it as HATEOAS basically set it up to fail though.
I could never understand making the term "hate" so prominent.
dragonwriter
> HATEOAS was the dream in the early 2010s and that basically went nowhere
I dunno, HTTP/1.1, the motivating use case for REST and HATEOAS, seems to have been moderately successful.
badgersnake
MCP is just that again, but less well thought out. Everything new is old.
isodev
I think MCP’s popularity is a side effect of the hype bubble driving AI atm - one of the fancy things one can do with AI.
If there was any “easy” value in making one’s data available in a standard form, we would’ve seen a lot more adoption of interoperable endpoints (e.g. using schema.org or generally common ontologies as opposed to custom formats that always need a special magic SDK).
doug_durham
There is an easy way to make your data available. It's existed for several hundred years, it's called plain text. We now have tools that allow computers to work with plain text. Outside of specific niches ontologies are vanity projects.
doug_durham
Plain human readable text is not an "artificial barrier". It the nature of our our world. Requiring that a restaurant publish menus in a metadata format is an artificial barrier. That the beauty of these new NLP tools. I don't need to have a restaurant owner learn JSON, or buy a software package that generates JSON. We can use data as it is. The cost of building useful tools goes to near zero. It will be imprecise, but that's what human language is.
Y_Y
Plain text menus would have been fine
a1j9o94
How do you do things like compare prices in plain text?
thunderfork
[dead]
lucideer
> It the nature of our our world.
It's the nature of capitalism.
Some forms of capitalism may have roots in the natural world - natural selection as both a destructive & wasteful competitive process certainly has a lot of parallels in idealised markets - but there's nothing inherent about your menu example when it comes to the modern human world, beyond restrictions placed upon us by capitalism.
> Requiring that a restaurant publish menus in a metadata format is an artificial barrier
This is oddly phrased as noone would need to require anyone to do anything - it's obviously beneficial to a restaurant to publish their menus in formats that are as broadly usable as they can. The only barrier to them doing that is access to tools.
The various hurdles you're describing ("buying" software, the "cost" of building tools) are not natural phenomena.
jjfoooo4
MCP is described as a means to make the web open, but it’s actually it’s a means to make demos of neat things you could do if the web were actually open.
AlienRobot
I still don't know who uses this semantic web. Like you have all these semantics marked up... for whom? What are actual applications using this?
Google has a small subset of schema.org it supports, but rather than "semantic web" it feels more like "here's my API." Its own schema tester often complains about things that should be valid schemas, simply because it doesn't conform to its API. How would any web developer mark up (and test the validity of said mark up) for applications that don't even exist?
pphysch
xAI is a concrete example of this. During the initial LLM explosion, X locked down its previously public APIs and data sources. Simultaneously, xAI is investing massively in building its private data hoard and compute infrastructure. Probably a similar case with Meta.
"Data for me but not for thee"
MCP is only getting the light of day, arguably, because of LLM "one trick ponies" like OpenAI and Anthropic, who do benefit from MCP amplifying their value proposition. As that business model continues to fizzle out and lose/subordinate to the AI integrators (Google, Microsoft, xAI?), MCP will probably fizzle out as well.
klabb3
> "Data for me but not for thee"
Exactly. Consumer tech has been locking down APIs and actively working against interop since the advertising business model became dominant. Web 2.0 is the most obvious example, but there are plenty more.
Look, you don’t even own your own contacts on social media sites. If you access Google from an atypical browser you will get fingerprinted, captchad and rejected. Anti-scraping, anti fraud, paywalls, even lawsuits because you’re using ”our” APIs (see oracle).
It’s not the tech, it’s the business model. It’s adversarial, it’s a Mexican standoff. Doesn’t matter how good the MCP spec is, it’s not gonna go anywhere with consumer apps. As long as the economy is based on ads, your B2C company needs a sidebar to show ads (or in rare cases, subscriptions). You’re not gonna make money from providing a free API.
1oooqooq
I pitty the fools thinking they will have access to anything because there's a MCP.
those things will be hidden behind a dozen layers of payment validation and authentication. And whitelisted IPs (v4, of course).
ERR 402; is all that will be visible to yall.
vasusen
What worries me most about MCP isn't that the protocol is so poorly created, but that fixing/improving it is only at the mercy of internal teams at Anthropic and OpenAI. It doesn't seem like the folks who are coming up with the protocol are actual engineers trying to implement it as well.
Vaguely seems like a Visa-Mastercard duopoly.
TOMDM
Microsoft has joined the steering committee as well
https://techcrunch.com/2025/05/19/github-microsoft-embrace-a...
timwis
Isn’t conformance to a standard API arguably less necessary now that LLMs can read API docs and adapt? For me, the win is the expectation that sites _have_ an API, whether it conforms to the MCP spec or not.
bilbo0s
-API documentation may have been poorly written.
-Even with good documentation, the LLM may generate incorrect code to interact with API. (If you fix the generated code and just have the LLM call that code to interact with the API, then you're on your way to an intermediary in any case. You're basically building an "MCP-like" server.)
-Security or resource allocation issues when giving LLMs direct access to APIs. (LLM has limited knowledge of when API was last called. It could call too often and, if each call is expensive, generate surprise infrastructure bills.)
-So on and so forth. Lots of other potential pain points solved by having something intermediate.
Should that "something" be MCP? Reasonable people can disagree on that. Works well enough right now to get done what people need done I suppose.
what
Don’t all of these arguments apply to MCP as well?
quantadev
We can now build the Semantic Web. All we have to do is create a tiny protocol (as an optional extension to MCP) for how organizations can share their SQL Table Create DDL as a static file that MCP apps can read, to understand data, and then, using the already-existing tools for AI/LLM function calling to SQL, that would become a Semantic Web.
That would fill the missing link that always held back the Semantic Web which was the lack of any incentive for companies to bother to use a standard "Data Type" rather than all proprietary data types. Once we have an MCPQ (MCP with Queries), suddenly there's an incentive for organizations to collaborate at the data structure layer.
lxgr
Turns out the “Semantic Web” was a syntactic web all along, and maybe this is the real deal?
justinclift
Wonder how long it's going to be until someone makes an MCP server for controlling a cockroach (or similar)?
For reference:
* https://www.technologynetworks.com/informatics/news/robo-roa...
* https://www.sciencealert.com/scientists-turned-cockroaches-i...
And many other examples going back more than a decade...
foobarian
> when specs were written by pedantic old Unix dudes
I'm tickled pink that this generation imagines "old Unix dudes" as pedantic, when Unix was the ultimate "move fast and break things" rebellion against the MIT school. Some things never change :-)
devrandoom
Won't this be used to spam AI with ads and "search engine optimization" equivalent?
null
The thing that a lot of people miss with MCP is that it's the right fit for enterprise software. LLMs, being universal translators, are the ideal glue between many disconnected systems that are extremely hard to connect without some fuzzy layer in between. And so that's why you see so much of the B2B SaaS world rolling out MCP servers, and internally at these companies, they're talking about how to re-jigger their APIs and restrictions for those APIs given different usage patterns.
Yes, the protocol is not necessarily "enterprise ready" by various definitions, but as the author points out, this is not terribly important, and the history of standards shows us that even messy and "bad" things get widespread adoption because they hit the right notes at the right time for the right people.