I think MCP is awesome, mainly because it forces devs to design the simplest possible tools/APIs/functions so even an average-performance LLM can use them correctly to get things done.
As developers, we often want everything to be rich, verbose, and customizable — but the reality is that for most users (and now for AIs acting on their behalf), simplicity wins every time. It’s like designing a great UI: the fewer ways you can get lost, the more people (or models) can actually use it productively.
If MCP ends up nudging the ecosystem toward small, well-defined, composable capabilities, that’s a win far beyond just “AI integration.”
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.
I’m just getting into MCP (building my own server and trying some canned ones), and one thing I’ve noticed — some servers seem to devour your context window before you’ve even typed a single token / question.
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.
> 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
I think they'll have a while where they can get away with this approach too. For a good while, most people will probably blame the AI or the model if it doesn't use Atlassian tools well. It'll probably be quite some time before people start to notice that Atlassian specifically doesn't work well, but the almost all their other tools do.
(More technical users might notice sooner—obviously, given the context of this thread—but I mean enough of a broader user base noticing to have reputational impact)
They’re trained in using tools that take actions (like sending an email) and tools that retrieve information (like pulling down a Wikipedia article), yes. The specific pattern I see in a lot of SaaS MCPs though is tools for traversing a database which is not really either of those things.
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.
> 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.
That's a toolchain design approach that is independent of MCPs. A toolchain using MCP could do that and there would be no need for any special support in the protocol.
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.
We've been thinking that an intermediate (virtual) server layer might be helpful here. Actively working on something to solve that now and looking for feedback, please reach out if interested.
The way the function is described to the LLM matter. Even when the parameters are the same and the effect is the same the title and description can fundamentally influence how the task is performed.
The other issue is that you cannot think of MCP servers as universal pluggable systems that can fit into every use-case with minimal wrapping. Real world scenarios require pulling a lot of tricks. Caching can be done at higher or lower level depending on the use-case. Communication of different information from the MCP server also is different depending on the use-case (should we replace these long IDs for shorter IDs that are automatically translated to longer ones). Should we automatically tinyurl all the links to reduce hallucination? Which operations can be effectively solved with pure algorithms (compress 2-3 operations into one) because doing this with LLMs is not only error-prone but also not optimal (imagine using LLM to grep for strings in many files one by one using tool calls rather than using grep to search for strings - not the same)
There are so many things to consider. MCP is nice abstraction but it is not a silver bullet.
Speaking from experience with actual customers and real use-case.
This is Web 2.0. You're in the process of rediscovering mashups. Before it was SOAP and REST/HTTP and now it's...well, it's still kind of REST/HTTP because MCP is JSON-RPC. There was this brief, beautiful period where every "learn to code" book ended with a couple of chapters of how to make your app do google searches and throw the results into a word graph or something before all the big tech companies locked that sort of access down.
Weirdly, I'm a little optimistic that it might work this time. AI is hot, which means that suddenly we don't care about IP anymore, and if AIs are the ones that are mostly using this protocol, providers will perhaps be in less of a rush to block everybody from doing cool things.
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.
ads really aren’t all that lucrative, though, they’re just simple. I worked for a company that was trying to figure out an alternative to ad revenue (we failed) and our people did some research and the average internet user ends up being shown (if I remember correctly) like $60/month of ads, total.
That’s not surprising and is also so depressing. Imagine what the Internet would be like if there were zero ads and zero of the dark patterns that they essentially force every web site operator to engage in. And all for sixty measly bucks a month that we’d spend in microtransactions or subscriptions or whatever. :(
It’s an average, you can’t just charge everyone in the world and have an ad-free worldwide internet. About 2 billion of internet users are probably worth 0.60$ pm while 200m are worth 600$ of ads pm.
Maybe lucrative isn’t the right word but it’s more profitable than the alternative. Call it simple but there’s only so many ways to monetize people that feel entitled to digital works and refuse to open their wallet.
In practice it'll just mean that each MCP provider will have API tokens and it'll be even harder to lock down spending than AWS. Maybe companies will need to have a company wide system prompt to pretty please don't use the expensive APIs too much.
Obviously it’s possible. And just like the early internet ad networks…
You can’t guarantee they’ll be shown and interpreted correct by the downstream LLM, you can’t guarantee attribution later when a user makes a purchase, you can’t collect (as much) data on users for targeting, etc
The biggest ad networks today (Google, Meta) have strong first party data operations, strong first party attribution techniques, and strong targeting, either through intent (search) or profiles (meta).
MCP originated ads really only threaten Google (via intent based ads), and they’re quickly moving I to owning the UX of LLMs, securing their place in this value chain.
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
I think 3.0 as a term was taken over by those weird crypto guys with their alternative dns roots and suffixes, that literally no one uses. “Own your domain forever!!*”
* Disclaimer: domain not usable for any purposes except on computers where you have root to install their alternative resolver
Yes, but not in intent. Semantic Web (which was web 3.0 before it got meshed into web3 apparently) was meant to open up internet data for new/novel applications and uses. The article appears to be alluding to that very thing via MCP.
While it does fall short of the implementation of the Semantic Web, in a way it makes it a possibility to fulfill its intent without the full buy-in of site owners. There still has to be some buy-in or allowance, otherwise it will be locked down in the near future as some comments are expecting.
The more I look into MCP, the less I understand the hype. It's an OK API that describes how to fetch list of tools and resources and retrieve them, somehow this is supposed to be the standard for AI and environment communication, and...that's it? Am I missing something vital there?
Yep, it's like 5 json schemas in a trench coat. Not not useful but also not some revolution. The biggest win seems to be just convincing rando 3rd parties to go along with it.
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.
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.
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.
> "Your car doesn't care if you're charging a phone or running a personal pizza oven. The hole is the same size. The power is there."
This is an inadvertently great and amusing analogy, because it shows how people can assume something about an API's capabilities without actually trying it.
A 12V battery car battery can't power a pizza oven. It can barely boil water in a special rice cooker - very very slowly. And it risks depleting the battery and not being able to start your car.
Like a new API, people get excited about what it can do, but the reality is very different.
I have a portable fan with a power bank that charges over USB with a USB-micro plug. For some reason I can't fathom, it's an absolute power hog. I've killed my van's battery using it for just a few hours. (In theory it should be using at max 2.5W, but that's not the point).
Again, that shows how trying to extend an APIs design can have unexpected side effects which tax the system in ways that are hard to predict.
MCP has a lot of excitement around it now, but it will inevitably reach its limits. The lesson is to test your system under load before assuming anything.
First of all I think this kind of localhost/stdio MCP is kind of not 'The Way' besides for playing around. I've been working on SSE/remote/cloud-based MCP
("my landing page is in a text editor with iframe preview. I ask Claude to edit it—the doc gets transcluded into the AI chat, gets surgically edited. I reload. (All on mobile!)")
I'm working on a starter template like a DevTools MCP that people can deploy on Cloudflare and oAuth with their github account and it provides tools like url_fetch for people to use privately in their AI chats/tools. First I have to figure out the oAuth stuff myself but will make it a public repo after that and post on here
PS. I also think tool use is really underrated and stuff like MCP unlocks a kind of agentic behavior 99% of AI users have never seen.
> MCP thinks it's for giving context to AI models. But really? It's just a really good protocol for making things talk to other things.
MCP has very little utility outside of LLMs. The article begins by saying "but what if we remove the AI", then goes back on that thesis by saying "but if there was an AI between these things, then it becomes a universal plugin system". Which is true, but its missing the critical bit: The AI itself is the universal plugin system, not MCP. And, beyond that, its not even the AI: Its natural language. Language is the universal plugin system.
Its not unbelievable that there exists an alternate reality where the Anthropic researchers that invented MCP instead simply leveraged a slightly extended form of OpenAPI specs. The only functional difference is that MCP was a stdin/stdout format first, and added HTTPS later, but sister problems in this domain like LSP just skipped stdin/stdout and went straight to locally-hosted HTTPS anyway. What matters isn't MCP, OpenAPI, or anything like that; what matters is the LLM itself, its tool calling capability, and the tool calling harness. The catalogue of available tools can be in any format; and, truly, the LLM does not care what format its in.
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?
I think that's an extreme characterization. Existing AIs are intelligent enough to be able to form immediately executable API requests based on the content of an OpenAPI schema. OpenAPI defines everything they need; endpoint names, human descriptions, arguments, authorization, etc. With proper prompting and a well designed harness, which MCP also needs, it would have solved the problem. Conversely: MCP doesn't really have much over OpenAPI in the domain of helping LLMs identify which tools to call; it has tool names, tool descriptions, input parameters, and that's basically it. OpenAPI has all that.
The reason why MCP was invented is hard to reverse-engineer, but from what I've seen I suspect its mostly: it was stdio/stdout first, and there isn't really a great standard like OpenAPI in the local-first stdio/stdout world. Interesting, LSP (Microsoft) took the opposite approach; despite having far less reason to be hosted on the web, LSP is just localhost http calls. MCP could have done that, but they didn't, without good reason, which leads me to the second reason why I suspect it was invented: they didn't know, and thus couldn't learn from prior art that they didn't know. Most of these AI labs are not rigorous engineering shops, they're better characterized as: a bunch of kids with infinite money trying to reignite the spirit of the early internet startup boom. Many believe that what they're building will replace everything, so why even try to build on what already exists?
But why it was invented doesn't matter, because anyone can invent anything. The reason why MCP has gotten popular is because its AI. That's it. Its a marketing and SEO system that enables companies who are otherwise struggling to find a way to prioritize AI use-cases for their apps to say "look, we're AI now". You don't get the same market impact if all you need is that boring old OpenAPI schema you already have.
And again: I like MCP. What I stated sounds pessimistic, but its only intended to be realistic. There is almost zero technical reason for MCP to exist beyond that.
> 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.
I agree, the article does explicitly say that; the thesis of the article and the information it presents to support that thesis are entirely at odds. That's what I'd argue this is a poor article, just an advertisement for the world's eighty-sixth todo app; yet it keeps getting re-posted here.
I honestly feel like we're not even reading the same article. His contention is that MCP, while created for AI, can serve as a universal plugin system. He's writing software that... does that. Not seeing the contradiction.
> 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.
I really don't know where you're coming from with that statement.
1. No one asserted that MCP's key innovation was its format. In fact, what I strongly, almost explicitly implied with my previous comment is that MCP has made no key innovations beyond its marketing system (which does matter and has forced a lot of companies who would never have operated in this space to make an MCP system, and that is good. I like MCP.).
2. MCP is fundamentally bidirectional, not unidirectional. Its a schematized request-response protocol that defines a ton of the same primitives that OpenAPI defines, like available RPC methods, authorization, request parameters, and response schemas [1]. Of course, OpenAPI goes beyond that into HTTP-specific characteristics like status codes, and MCP goes beyond that into LLM-specific characteristics like a prompt catalogue.
3. I'm not aware of any problem domain outside of LLMs that is adopting MCP. In fact, its adoption even within the world of LLMs has been lackluster at best [2].
MCP "universal plugin system" claims are oversold. It is really just a standardized tool calling for AI agents. If you are not building agents that need to dynamically discover and choose tools, traditional APIs are simpler and better.
The "system integration" benefits only matter when you have an LLM in the loop making decisions about which tools to use.
I love that MCP servers are rediscovering the old idea of public web APIs mash-ups from the early days of Web 2.0. Of course we don't need any icky XML with its namespace and schemas. Just some vibe-heavy JSON.
Snark aside it's, autonomous agents were one of the more interesting justifications for web APIs back in the day. I don't think people necessarily envisioned LLMs but some sort of agent you could send off to grab data or book flights or whatever. Specs like WSDL do what MCP does today letting the autonomous system figure out how to use a service.
Oh well, schemas and the ability to do browser-native style transforms were lame! Lets transition to YAML so no one can say "no" to Norway.
This is not a novel take, but what's arguably even more universal is cli access to a service.
I have a lot more luck integrating service specific cli's with Claude than trying to use MCPs. As an additional bonus, AI tools instantly know how to troubleshoot issues with them, filter or transform the output and compose them into bigger workflows with scripting.
This community has no ability to separate researched information from conjecture, and especially on this topic since neural nets are a black box where we can never know if any behavior is fully intentional or not.
Is it just me who absolutely hates this much hype around AI while still getting value from AI models? I get it, MCP is useful, but it's neither new nor safe and well thought-out. It feels like everyone now has to write a mandatory MCP article...
It's done a good job for me with the tools I've written and connected to LM Studio. I suspect the issue with whether you get satisfactory results is less about MCP qua MCP and more about particular servers and tools.
The “model context” in MCP refers to the motivating application domain (the resources, tool responses, and prompts it provides all, in that use case, are used to populate the model’s context), not the content of the protocol.
I'll be honest i read your repository's README.md and still have no idea what this is supposed to be. The tagline sounds like it's for implementing MCP servers, but the endpoints specified further down aren't part of MCP but something more specific (to MCPs serving a language model? Why would we serve them like that?)
Also doesn't really seem to relate to the OP beside the term 'MCP' in the title
Then the "Examples" section should include a "How to build a simple MCP server using this framework" section. Instead, it contains an example for an "MCP client" (however the implementation has little to do with what the MCP spec says a client does), and an "example of a custom module for the MCP server" (which MCP server? we haven't built one yet), which (after checking implementation) does not conform to the MCP spec for tools (see https://modelcontextprotocol.io/specification/2025-06-18/ser...).
Unless I'm missing something, this has very little to nothing to do with MCP.
I think MCP is awesome, mainly because it forces devs to design the simplest possible tools/APIs/functions so even an average-performance LLM can use them correctly to get things done.
As developers, we often want everything to be rich, verbose, and customizable — but the reality is that for most users (and now for AIs acting on their behalf), simplicity wins every time. It’s like designing a great UI: the fewer ways you can get lost, the more people (or models) can actually use it productively.
If MCP ends up nudging the ecosystem toward small, well-defined, composable capabilities, that’s a win far beyond just “AI integration.”
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
I’m just getting into MCP (building my own server and trying some canned ones), and one thing I’ve noticed — some servers seem to devour your context window before you’ve even typed a single token / question.
My favorite example is the public Atlassian one — https://www.atlassian.com/blog/announcements/remote-mcp-serv...
Even with Claude or Gemini CLI (both with generous limits), I run out of context and resources fast.
With local LLMs via LM Studio? Forget it — almost any model will tap out before I can get even a simple question in.
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.
> 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
I think they'll have a while where they can get away with this approach too. For a good while, most people will probably blame the AI or the model if it doesn't use Atlassian tools well. It'll probably be quite some time before people start to notice that Atlassian specifically doesn't work well, but the almost all their other tools do.
(More technical users might notice sooner—obviously, given the context of this thread—but I mean enough of a broader user base noticing to have reputational impact)
All new models are probably trained to understand the tool use paradigm
They’re trained in using tools that take actions (like sending an email) and tools that retrieve information (like pulling down a Wikipedia article), yes. The specific pattern I see in a lot of SaaS MCPs though is tools for traversing a database which is not really either of those things.
The only one I've had any use for like that was the sqlite mcp they let's it pull the database index and structure
Seems to help it during database coding. But this could also be done easily with a file.
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.
> 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.
That's a toolchain design approach that is independent of MCPs. A toolchain using MCP could do that and there would be no need for any special support in the protocol.
Love how the MCPs mimic the company they represent in that sense.
Heh.. this comment made my day.
Conway’s law in action?
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...
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.
Vscode let's you go tool by tool. It's great
We've been thinking that an intermediate (virtual) server layer might be helpful here. Actively working on something to solve that now and looking for feedback, please reach out if interested.
There other ways to get the data & do the interactions you need.
Eg. give the model your login token/cookies so it can curl the pages and interact with them - or have it log in as you with Playwright MCP.
The way the function is described to the LLM matter. Even when the parameters are the same and the effect is the same the title and description can fundamentally influence how the task is performed.
The other issue is that you cannot think of MCP servers as universal pluggable systems that can fit into every use-case with minimal wrapping. Real world scenarios require pulling a lot of tricks. Caching can be done at higher or lower level depending on the use-case. Communication of different information from the MCP server also is different depending on the use-case (should we replace these long IDs for shorter IDs that are automatically translated to longer ones). Should we automatically tinyurl all the links to reduce hallucination? Which operations can be effectively solved with pure algorithms (compress 2-3 operations into one) because doing this with LLMs is not only error-prone but also not optimal (imagine using LLM to grep for strings in many files one by one using tool calls rather than using grep to search for strings - not the same)
There are so many things to consider. MCP is nice abstraction but it is not a silver bullet.
Speaking from experience with actual customers and real use-case.
Everyone keeps rediscovering OS IPC extensions via RPC.
Not only that, apparently we finally got Jini and Agent Tcl back!
https://www.usenix.org/conference/fourth-annual-usenix-tcltk...
https://www.eetimes.com/jini-basics-interrelating-with-java/
MCP is just JSON rpc with one useful command (list-tools). Turns out that's probably all we ever needed.
WSDL has entered the chat
This is Web 2.0. You're in the process of rediscovering mashups. Before it was SOAP and REST/HTTP and now it's...well, it's still kind of REST/HTTP because MCP is JSON-RPC. There was this brief, beautiful period where every "learn to code" book ended with a couple of chapters of how to make your app do google searches and throw the results into a word graph or something before all the big tech companies locked that sort of access down.
Weirdly, I'm a little optimistic that it might work this time. AI is hot, which means that suddenly we don't care about IP anymore, and if AIs are the ones that are mostly using this protocol, providers will perhaps be in less of a rush to block everybody from doing cool things.
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.
ads really aren’t all that lucrative, though, they’re just simple. I worked for a company that was trying to figure out an alternative to ad revenue (we failed) and our people did some research and the average internet user ends up being shown (if I remember correctly) like $60/month of ads, total.
That’s not surprising and is also so depressing. Imagine what the Internet would be like if there were zero ads and zero of the dark patterns that they essentially force every web site operator to engage in. And all for sixty measly bucks a month that we’d spend in microtransactions or subscriptions or whatever. :(
It’s an average, you can’t just charge everyone in the world and have an ad-free worldwide internet. About 2 billion of internet users are probably worth 0.60$ pm while 200m are worth 600$ of ads pm.
Maybe lucrative isn’t the right word but it’s more profitable than the alternative. Call it simple but there’s only so many ways to monetize people that feel entitled to digital works and refuse to open their wallet.
People are willing to pay for AI. Some of this money flow could be diverted to the MCP provider.
In practice it'll just mean that each MCP provider will have API tokens and it'll be even harder to lock down spending than AWS. Maybe companies will need to have a company wide system prompt to pretty please don't use the expensive APIs too much.
why cant i serve ads thru my mcp?
Obviously it’s possible. And just like the early internet ad networks…
You can’t guarantee they’ll be shown and interpreted correct by the downstream LLM, you can’t guarantee attribution later when a user makes a purchase, you can’t collect (as much) data on users for targeting, etc
The biggest ad networks today (Google, Meta) have strong first party data operations, strong first party attribution techniques, and strong targeting, either through intent (search) or profiles (meta).
MCP originated ads really only threaten Google (via intent based ads), and they’re quickly moving I to owning the UX of LLMs, securing their place in this value chain.
Because then you'd be serving ads to an LLM?
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
I think 3.0 as a term was taken over by those weird crypto guys with their alternative dns roots and suffixes, that literally no one uses. “Own your domain forever!!*”
* Disclaimer: domain not usable for any purposes except on computers where you have root to install their alternative resolver
> I think 3.0 as a term was taken over by those weird crypto guys
that is certainly what I think of when web 3 is mentioned.
Unfortunately (?) there are no real semantics in MCP so it falls short of Semantic Web.
Yes, but not in intent. Semantic Web (which was web 3.0 before it got meshed into web3 apparently) was meant to open up internet data for new/novel applications and uses. The article appears to be alluding to that very thing via MCP.
While it does fall short of the implementation of the Semantic Web, in a way it makes it a possibility to fulfill its intent without the full buy-in of site owners. There still has to be some buy-in or allowance, otherwise it will be locked down in the near future as some comments are expecting.
Web 2.0 was also hot.
The more I look into MCP, the less I understand the hype. It's an OK API that describes how to fetch list of tools and resources and retrieve them, somehow this is supposed to be the standard for AI and environment communication, and...that's it? Am I missing something vital there?
Yep, it's like 5 json schemas in a trench coat. Not not useful but also not some revolution. The biggest win seems to be just convincing rando 3rd parties to go along with it.
The emperor is indeed naked.
How long before companies start closing this "loophole"?
And with the cynicism out of the way, what an insightful and refreshing article!
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.
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.
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.
Previous discussion (43 days ago, 355 comments):
https://news.ycombinator.com/item?id=44404905
> "Your car doesn't care if you're charging a phone or running a personal pizza oven. The hole is the same size. The power is there."
This is an inadvertently great and amusing analogy, because it shows how people can assume something about an API's capabilities without actually trying it.
A 12V battery car battery can't power a pizza oven. It can barely boil water in a special rice cooker - very very slowly. And it risks depleting the battery and not being able to start your car.
Like a new API, people get excited about what it can do, but the reality is very different.
I have a portable fan with a power bank that charges over USB with a USB-micro plug. For some reason I can't fathom, it's an absolute power hog. I've killed my van's battery using it for just a few hours. (In theory it should be using at max 2.5W, but that's not the point).
Again, that shows how trying to extend an APIs design can have unexpected side effects which tax the system in ways that are hard to predict.
MCP has a lot of excitement around it now, but it will inevitably reach its limits. The lesson is to test your system under load before assuming anything.
Relevant: https://news.ycombinator.com/item?id=44846871
I've been doing some really fun things with MCP
First of all I think this kind of localhost/stdio MCP is kind of not 'The Way' besides for playing around. I've been working on SSE/remote/cloud-based MCP
Here's a fun example: https://x.com/firasd/status/1945233853414826060
("my landing page is in a text editor with iframe preview. I ask Claude to edit it—the doc gets transcluded into the AI chat, gets surgically edited. I reload. (All on mobile!)")
I'm working on a starter template like a DevTools MCP that people can deploy on Cloudflare and oAuth with their github account and it provides tools like url_fetch for people to use privately in their AI chats/tools. First I have to figure out the oAuth stuff myself but will make it a public repo after that and post on here
PS. I also think tool use is really underrated and stuff like MCP unlocks a kind of agentic behavior 99% of AI users have never seen.
> MCP thinks it's for giving context to AI models. But really? It's just a really good protocol for making things talk to other things.
MCP has very little utility outside of LLMs. The article begins by saying "but what if we remove the AI", then goes back on that thesis by saying "but if there was an AI between these things, then it becomes a universal plugin system". Which is true, but its missing the critical bit: The AI itself is the universal plugin system, not MCP. And, beyond that, its not even the AI: Its natural language. Language is the universal plugin system.
Its not unbelievable that there exists an alternate reality where the Anthropic researchers that invented MCP instead simply leveraged a slightly extended form of OpenAPI specs. The only functional difference is that MCP was a stdin/stdout format first, and added HTTPS later, but sister problems in this domain like LSP just skipped stdin/stdout and went straight to locally-hosted HTTPS anyway. What matters isn't MCP, OpenAPI, or anything like that; what matters is the LLM itself, its tool calling capability, and the tool calling harness. The catalogue of available tools can be in any format; and, truly, the LLM does not care what format its in.
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?
I think that's an extreme characterization. Existing AIs are intelligent enough to be able to form immediately executable API requests based on the content of an OpenAPI schema. OpenAPI defines everything they need; endpoint names, human descriptions, arguments, authorization, etc. With proper prompting and a well designed harness, which MCP also needs, it would have solved the problem. Conversely: MCP doesn't really have much over OpenAPI in the domain of helping LLMs identify which tools to call; it has tool names, tool descriptions, input parameters, and that's basically it. OpenAPI has all that.
The reason why MCP was invented is hard to reverse-engineer, but from what I've seen I suspect its mostly: it was stdio/stdout first, and there isn't really a great standard like OpenAPI in the local-first stdio/stdout world. Interesting, LSP (Microsoft) took the opposite approach; despite having far less reason to be hosted on the web, LSP is just localhost http calls. MCP could have done that, but they didn't, without good reason, which leads me to the second reason why I suspect it was invented: they didn't know, and thus couldn't learn from prior art that they didn't know. Most of these AI labs are not rigorous engineering shops, they're better characterized as: a bunch of kids with infinite money trying to reignite the spirit of the early internet startup boom. Many believe that what they're building will replace everything, so why even try to build on what already exists?
But why it was invented doesn't matter, because anyone can invent anything. The reason why MCP has gotten popular is because its AI. That's it. Its a marketing and SEO system that enables companies who are otherwise struggling to find a way to prioritize AI use-cases for their apps to say "look, we're AI now". You don't get the same market impact if all you need is that boring old OpenAPI schema you already have.
And again: I like MCP. What I stated sounds pessimistic, but its only intended to be realistic. There is almost zero technical reason for MCP to exist beyond that.
> 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.
I agree, the article does explicitly say that; the thesis of the article and the information it presents to support that thesis are entirely at odds. That's what I'd argue this is a poor article, just an advertisement for the world's eighty-sixth todo app; yet it keeps getting re-posted here.
I honestly feel like we're not even reading the same article. His contention is that MCP, while created for AI, can serve as a universal plugin system. He's writing software that... does that. Not seeing the contradiction.
> 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.
I really don't know where you're coming from with that statement.
1. No one asserted that MCP's key innovation was its format. In fact, what I strongly, almost explicitly implied with my previous comment is that MCP has made no key innovations beyond its marketing system (which does matter and has forced a lot of companies who would never have operated in this space to make an MCP system, and that is good. I like MCP.).
2. MCP is fundamentally bidirectional, not unidirectional. Its a schematized request-response protocol that defines a ton of the same primitives that OpenAPI defines, like available RPC methods, authorization, request parameters, and response schemas [1]. Of course, OpenAPI goes beyond that into HTTP-specific characteristics like status codes, and MCP goes beyond that into LLM-specific characteristics like a prompt catalogue.
3. I'm not aware of any problem domain outside of LLMs that is adopting MCP. In fact, its adoption even within the world of LLMs has been lackluster at best [2].
[1] https://modelcontextprotocol.io/docs/learn/architecture#data...
[2] https://modelcontextprotocol.io/clients
MCP "universal plugin system" claims are oversold. It is really just a standardized tool calling for AI agents. If you are not building agents that need to dynamically discover and choose tools, traditional APIs are simpler and better.
The "system integration" benefits only matter when you have an LLM in the loop making decisions about which tools to use.
I love that MCP servers are rediscovering the old idea of public web APIs mash-ups from the early days of Web 2.0. Of course we don't need any icky XML with its namespace and schemas. Just some vibe-heavy JSON.
Snark aside it's, autonomous agents were one of the more interesting justifications for web APIs back in the day. I don't think people necessarily envisioned LLMs but some sort of agent you could send off to grab data or book flights or whatever. Specs like WSDL do what MCP does today letting the autonomous system figure out how to use a service.
Oh well, schemas and the ability to do browser-native style transforms were lame! Lets transition to YAML so no one can say "no" to Norway.
Has anyone tried Basement's typed xmcp framework [1]? I rolled my own mcp server implementation earlier this summer and it works but it's very basic.
I'm considering migrating, but time is limited and I'd love to avoid a dead-end if I can :p
[1] https://github.com/basementstudio/xmcp
This is not a novel take, but what's arguably even more universal is cli access to a service.
I have a lot more luck integrating service specific cli's with Claude than trying to use MCPs. As an additional bonus, AI tools instantly know how to troubleshoot issues with them, filter or transform the output and compose them into bigger workflows with scripting.
how does this hypeblog spam keep getting to the top?
This community has no ability to separate researched information from conjecture, and especially on this topic since neural nets are a black box where we can never know if any behavior is fully intentional or not.
People don't read the article, they just comment based on the title. In that respect HN is no different from Reddit.
Made a similar comment [1] a while back. Universal, open APIs might be one of the best things to come out of this AI wave.
[1] https://news.ycombinator.com/item?id=44405187
Is it just me who absolutely hates this much hype around AI while still getting value from AI models? I get it, MCP is useful, but it's neither new nor safe and well thought-out. It feels like everyone now has to write a mandatory MCP article...
> It feels like everyone now has to write a mandatory MCP article...
Like this one you can bet every blogspam article is also trying to push something...
> The Part Where I Tell You I'm Building Something
Would be great if we don’t repeat the same mistake over and over again by making security a subsequent feature
MCP has barely given me satisfactory results. LLMs just keep fighting with it and fill up a lot of their context.
> MCP has barely given me satisfactory results.
It's done a good job for me with the tools I've written and connected to LM Studio. I suspect the issue with whether you get satisfactory results is less about MCP qua MCP and more about particular servers and tools.
Accidentally? Generic interoperability was the whole point of mcp, it was not an accident.
There's nothing about "model" in MCP at all, they're just json rpc ?
The “model context” in MCP refers to the motivating application domain (the resources, tool responses, and prompts it provides all, in that use case, are used to populate the model’s context), not the content of the protocol.
Yep, and the primary transport method is json rpc over stdio
Tools like this have existed for between years and decades.
From IFTT/Zapier to N8N to ETLs
I'm a well-designed hole. Put something here.
You asked for it.
checkout my MCP server platform: https://github.com/profullstack/mcp-server
I built it and have added several modules, but I'm always looking for people to add more modules. See ./mcp_modules in the root folder.
I'll be honest i read your repository's README.md and still have no idea what this is supposed to be. The tagline sounds like it's for implementing MCP servers, but the endpoints specified further down aren't part of MCP but something more specific (to MCPs serving a language model? Why would we serve them like that?)
Also doesn't really seem to relate to the OP beside the term 'MCP' in the title
It’s a framework for building mcp servers.
Then the "Examples" section should include a "How to build a simple MCP server using this framework" section. Instead, it contains an example for an "MCP client" (however the implementation has little to do with what the MCP spec says a client does), and an "example of a custom module for the MCP server" (which MCP server? we haven't built one yet), which (after checking implementation) does not conform to the MCP spec for tools (see https://modelcontextprotocol.io/specification/2025-06-18/ser...).
Unless I'm missing something, this has very little to nothing to do with MCP.
I implemented some changes, it works now. you can test it out at https://mcp.profullstack.com
[dead]
[dead]