People routinely mistake "protocol specification uploaded to GitHub, PRs welcome" as open standards. They are not. Calling them "open protocols" because they are open source, not open standards (no standards body was involved in the making of this protocol!) is essentially a form of openwashing.
This has been happening way too frequently lately (see also: ATProto), and it really needs to be called out.
Is a standards body being involved relevant? Many standards ratified by standards bodies are "pay to access" and seem much less open than many de facto standards where no standards body was involved.
I believe it is. Taking the example of ATproto, it boils down to a managed platform as a service but they seem to do a #BuildInPublic thing where we can experience early developer previews. That’s not really open and it isn’t a standard.
The organizations that create "standards" are much less open than this, requiring in person lobbying, schmoozing, travel, and company affiliations.
A big mistake in the first place to start it without proper security.
That not Web 2.0 2.0, that‘s Web 1.0
Anything that’s connected to the web has to consider security at step one.
How often are we repeating the same mistakes over and over again?
But this is solved by sandboxes such as mcp.run .
What would you call these projects? Open protocols?
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.
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.
What you want to do is offer resources that make you money when they're "exploited".
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").
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.
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).
"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.
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.
In that sense, it is probably the building block for the next user interface, which is conversational.
Maybe the mention of web 2.0 is triggering all negative responses here, but on it's own, it is useful and could disrupt (not MCP itself, but the overall field) how we interact with software and systems
In the negative vein, I see a lot of VCs and business leaders talking about making AI for companies that directly interface with customers.
Those agents will be used to manipulate and make painful existings services exactly like today. Enshitified transactional websites engineered for maximum pain.
A different direction can happen if we choose instead to use our ai agents to interact with business services. This is actually what's currently happening.
I use gemini/chatgpt to find things on the web for me without being manipulated and marketed at. Maybe one day soon, I can buy airline tickets without the minefield of dark patterns employed to maximize A/B tested revenue.
The only thing that needs to happen to keep us on this path is to bite the heels of the major companies with great agent systems that put the user at the center and not a brand. That means selling AI agents as a SaaS or open source projects - not ad-supported models.
This community is probably the group that has, collectively, the most say in where this future goes. Let's choose optimism.
And don’t forget when you use an AI agent today to buy something it’s using “marketing” information to make its decisions. It’s influenced by SEO in its search results, indeed there’s no shortage of marketers busy working out how to do this.
I do agree there’s much to be optimistic about but the fundamental dynamics of the consumer market won’t change.
And that's great.
In that world, those agents will sift through the noise. And the one that does that the best will win.
The end user experience then becomes uniform and pleasant.
It's the difference between talking to a personal secretary and a customer service representative. No one should have to endure the latter.
The existence of agents capable of learning to cut through the enshittification also implies the existence of agents capable of learning to enshittify all the more effectively. It's an arms race, and there's no reason to suspect that the pro-consumer side will win over the pro-exploitation side.
i would rephrase as "incumbents don't usually make more money if things are opened up".
if consumer gets materially better value, then challenger ecosystem around MCP will evolve. it will be open at first - great for startups and challengers, innovator's dilemma for market leaders.
and then it will close as the new wave establishes their moats. but, similar to web, even though the current web leaders are now much more closed than we would like, the overall ecosystem is more open than it was.
Whoever coined it as HATEOAS basically set it up to fail though.
I could never understand making the term "hate" so prominent.
I dunno, HTTP/1.1, the motivating use case for REST and HATEOAS, seems to have been moderately successful.
Manual or even semi-automated cataloguing of websites (and further curating) of websites wasn't the answer to "how do I find stuff on the web" — Google was. Having standardized metadata format for menus is undoubtedly nice — but good luck making people to use it. You just can't. It really is both cheaper and easier for everyone involved to have website with arbitrary information layout scraped and fed into an LLM to extract relevant data: because what is "relevant" is different for everyone. You can't pre-ordain the full list of possible relevant metadata, and, again, good luck forcing everyone to fill out those 500 items-long forms. Ain't nobody got time for that.
> It's also because nobody ain't got no time for generating infinite amount of metadata
There's also a lot of tooling problems too, that the semantic web doesn't integrate gracefully with POJO of the programming worlds.)
The tooling distance between users/devs and semantic web remains. But all that metadata? There being an interesting rich world of information, associated & well described & meticulous? Uh we actually seem like we just invented a really powerful tool at doing all this immense catalogization (LLM's).
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.
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.)
Is there a way to handle "locking down" things with MCP? It seems like a potential opportunity for freemium services if they have a mechanism for authentication and telling the MCP caller "this user has access to these tools, but not _these_ yet".
The difference for the user is instead of them having to make (or use) a special-purpose client to call your rest api, the llm (or llm powered application) can just call the api for them, meaning your rest service can be integrated into other llm-powered workflows.
You've described most white-collar jobs :)
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?
>There is a chance, though, that younger developers, and those who weren't around to build back during that last era a generation ago, are going to get inspired by MCP to push for the web to go back towards its natural architecture. It was never meant to be proprietary.
Alas, the reason APIs started closing and being metered is because, after all, there's someone owning and paying for the hardware upon which you are making calls and requests.
As long as there's no way to agree upon how to have a bunch of servers providing computation for anyone and at the same time ensuring their upkeep without the need for a central authority, I don't think such vision is sustainable long term. The current state of the Internet is proof of it.
All the mistakes of "hey everything has an API now" that we learned from we're back to repeating.
I feel like that meme from Watchmen with the blue guy sitting on Mars.
Blah. Bay Area Tech regularly goes through these bursts of baseless enthusiasm for rehashes of existing technology. Is MCP useful? Yeah, probably. Is the current froth based on anything but SF-scene self-licking-ice-cream-code social cred? No.
Thank you. You said what I was going to say. Another goose chase for something that's valuable, certainly, but being frothed up into some mythical sword in the stone.
It's ultimately just a way to say "hey, here's some extra context including some functions we have defined on our server that you can ask us to call."
One thing different from APIs is the LLM makers get tokens for every MCP call so they have incentives to hype this up significantly.
MCP is useful - i use it quite a bit internally for some testing/QA workflows. However, the hype level is disproportionate to utility.
But there doesn't seem to be any standardization or method in how to describe the tool to the AI so that it can utilize it well. And I guess part of the power of AI is that you shouldn't need to standardize that? But shouldn't there at least be some way to describe the tool's functionality in natural language or give some context to the tool?
https://modelcontextprotocol.io/specification/2025-03-26/ser...
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.
Imagine it, everything is open, servers are as simple as a pip install ... You have full control of what servers you install. What functions you turn on, what access you allow.
Now everyone and their blog is sticking MCPs on their servers and locking them down behind subscriptions and paywalls.
What a wasted opportunity.
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.
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"
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.
I think of logic puzzles I used to do as a kid. The whole idea of the puzzle is that all of the information you need is provided, the fun is in solving using deduction. Sudoku scratches the same itch.
At the least, I would argue there are many problems that don't fit the mold you are suggesting and MCP is not the correct method for addressing them.
Wow, you must have worked in some really mature shops then if you knew instantly which of [Google Drive, Confluence, Airtable, GitHub wiki, ${that one deprecated thing that Alice was using}, ...] contained the reference to Project Frazlebaz mentioned in Slack last.. day? week? Maybe it was today but time is a blur?
This idea that if you don't know where the data is, magically the LLM will, is very confusing to me.
Here's a real example from my job as a BI dev. I needed to figure out how to get counts of incoming products from an ERP with a 1000+ table database schema in a data lake with 0 actual foreign keys. I sorta knew the data would need to come from the large set of "stock movements" tables, which I didn't know how to join, and I had no idea which rows from that table would be relevant to incoming product or even which fields to look at to even begin to determine that. I simultaneously asked a consultant for the ERP how to do it and asked Cursor a very basic "add the count of incoming units to this query" request.
Cursor gave me a plausible answer instantly, but I wasn't sure it was correct. When the consultant got back to be a few days later, the answer he gave was identical to Cursor's code. Cursor even thought of an edge case that the consultant hadn't.
It blew my mind! I don't know if Cursor just knows about this ERP's code or what, or if it ran enough research queries to figure it out. But it got it right. The only context I provided was the query I wanted to add the count to and the name of the ERP.
So, I 100% believe that, especially with something like MCP, the pull model is the right way. Let the LLM do the hard work of finding all the context.
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.
In my view, we hand craft the context and then the LLM makes the deductions.
I guess it will come down to how important crafting the relevant context is for making useful deductions. In my experience with writing code using LLMs, the effectiveness increases when I very carefully select the context and the effectiveness goes down when I let the agent framework (e.g. Cursor) figure out the context. The ideal case is the entire project fits in the context window obviously, but that won't always be possible.
What I've found is that LLMs struggle to ask the right questions. I will often ask the LLM "what other information can I provide you to help solve this problem" and I rarely get a good answer. However, if I know the information that will help it solve the problem and I provide it to the agent then it often does a good job.
We (as in users) provide the source material and our questions, the LLM provides the answers. The entire concept of a context is incidental complexity resulting from technical constraints, it's not anything that users should need to care about, and certainly not something they should need to craft themselves.
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.
It failed because they couldn't figure out how to stuff ads in.
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.
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.
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.
MCP is an attempt to make that easy, but the issue here is that a lot of the companies offering integration could be disintermediated entirely by LLMs. Hard to say what that means.
I've seen a lot of talk around here, and everywhere, about MCP. A lot of enthusiasm and a lot of criticism. I've written a few MCP servers and plan to write some more. It isn't how I would design a protocol, but it works, and everyone is using it, so hooray for interoperability.
I think the hype represents the wider enthusiasm that people have about this moment in time, and the transformative power of these new tools. It's easy to look at MCP and say there it is, now it's easy to connect these tools to the things that I care about, it feels accessible, and there's community.
MCP is NOT the new TCP for AI. It is, essentially, an RPC layer for chat. And while it could be extended to a wider variety of use cases, I expect that it will remain primarily a method for wiring up tool calls for user-facing use cases. We recognize the power of these tools and anticipate deep changes to workflows and systems, but we don't know how that will shake out. If I am writing a classifier for a backend system, I am not going to use MCP, even if I could. Because it's inefficient. Every additional tool we offer the model consumes tokens and increases latency. I expect that the primary user of LLMs is going to be business automation of all kinds, and I don't expect them to reach for MCP to wire things up. Yeah, it's really cool to hook tools up to the chat, for that to feel accessible, to know how to do things in an idiomatic and standards-compliant way, that feels good! And yeah, the hype is overblown.
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.
-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.
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 :-)
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.
That allows already for self discovery etc.
Everyone who will offer mcp offers a good API anyway.
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.
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.
Vaguely seems like a Visa-Mastercard duopoly.
https://techcrunch.com/2025/05/19/github-microsoft-embrace-a...
lxgr•7h ago