11 ms·

Everything wrong with MCP

516 points by sshh12 2y ago

cratermoon 2y ago
"Authentication is tricky and so it was very fair that the designers chose not to include it in the first version of the protocol." No, it's not fair at all. You can't add security afterwards like spreading icing on baked cake. If you forgot to add sugar to the cake batter, there's not enough buttercream in the world to fix it.
- sshh12 2y ago
  I haven't read a good justification from them on this but it did seem reasonable to me that if the protocol allows auth to be added on top then it's less critical to be in the spec v1 itself. It's not no security vs security but not standardized vs standardized. Agree though that's it's not ideal and there will definitely be non zero harm from that decision.
- chrisweekly 2y ago
  great analogy
- mickael-kerjean 2y ago
  I made a MCP server to access remote storage using any kind of protocols (S3, SFTP, FTP, .... ), and authentication was not as much of a problem that most people would make you think. Is it technically pure and beautiful? No. Does it work? Yes and you can check by yourself by pointing the mcp inspector to "https://demo.filestash.app/sse https://demo.filestash.app/sse" and play around
- fnordpiglet 2y ago
  I’ll admit I’m a total dunce with respect to using MCP but given it uses TLS why not just use mutual TLS and validate the client certificate for authentication? You don’t need to use higher level protocols for authentication if your transport protocol supports it already. I would think authZ is the trickier unhandled part of MCP as I don’t remember any primitives for authorization denial or granularity, but, again, HTTP provides a coarse authZ exchange protocol.
  - throw1290381290 2y ago
    There are 2 transports, HTTP and STDIO. You can use whatever authN/authZ you want for the HTTP transport. It's entirely up to the client and server implementers.
    - fnordpiglet 2y ago
      Presumably STDIO depends on the local AuthN/PAM that enabled the user space IO to begin with? I suspect what people are concerned about is the authorization of the LLM to the agent and its data rather than authN. AuthN in stdio would be the user that started the processes, or went through some AuthN chain allowing stdio to forward (I.e., ssh, sudo, etc). Am I missing something?
      - mehdibl 2y ago
        No they are concerne with SSE/HTTP as some made some MCP server over HTTP without auth in 2025. Then call it MCP issue.
        fnordpiglet 2y ago
        Right - that’s my point. It’s janky to put AuthN into a high level protocol like MCP when low level protocols do a better job that’s more reliable and thoroughly vetted. You can do full on SAML etc and go hog wild without ever touching MCP while inheriting all the thorough analysis and implementation pressure testing down stack. Doing something unsafe because you don’t know what safe looks like isn’t application protocols fault.
      - jacobr1 2y ago
        The bigger issue is that we need a good why to authenticate more dynamically. In the context of a desktop app (desktop claude, claude code) where you are running an application locally, for your own purposes it can run as your own user. But when you are running things in any kind of multi-user/multi-tenant scenario, this is much harder and the protocol doesn't really address this (though also doesn't prevent us from layering something on top). As a dumb (but real) example, I don't want a web-enabled version of of an MCP plugin to have access to my company's google drive and expose that to all our chat users. That would bypass the RBAC we have. Also I don't want to bake that in at the level of the tool calls, as that can be injected. I need some side channel information on the session to have the client and server to manage that.
- throw1290381290 2y ago
  MCP can use HTTP or STDIO as transports. There is no need to implement a new form of authentication that's specific to the protocol because you already have a myriad of options available with HTTP. Any form of auth used to secure a web service can be used with MCP. It's no different than adding authN to a REST API. Please just read the spec. It just builds on top of JSON-RPC, there's nothing special or inherently new about this protocol. https://modelcontextprotocol.io/specification/2025-03-26 https://modelcontextprotocol.io/specification/2025-03-26 There are way too many commentators like yourself that have no idea what they are talking about because they couldn't be bothered to RTFM.
  - RamblingCTO 2y ago
    Exactly, lots of people without any idea on what's going on. I implemented an authenticated MCP that uses the context bearer token and passes it on to the backend. Fully authenticated and authorized.
seuros 2y ago
Did you read the spec ? Everything you said is already a recommendation.
- sshh12 2y ago
  I think recommendation != being enforceably part of it or being implemented. There are a lot of great recs in the docs but I wrote this based on what I actually saw in the wild. I definitely don't think it's all on the spec to solve these.
  - mehdibl 2y ago
    You didn't read the spec. And you didn't mention Stdio. Stdio is secure and that's what is used by Claude Desktop the first MCP client and they don't support SSE yet. Since the start, SSE was set a draft and there was a long discussion over the authentification implementation first round already got defined and second is defined again. I saw a lot of articles since MCP was buzzing same claims copy & paste. And the post show a lot of confusion for what MCP is and MCP do.
    - sshh12 2y ago
      A lot of servers don't use the stdio transport.
klntsky 2y ago
MCP is a dead end for chatbots. Building valuable workflows requires more than tool calling, most importantly, understanding the context of a conversation to adjust the tools dynamically.
- simonw 2y ago
  What does that have to do with MCP? Those sound like things you would build on a separate layer from MCP.
  - klntsky 2y ago
    MCP tools are completely static. If you have to expose some APIs bypassing MCP, then you don't need MCP in the first place, because you don't have the tools abstracted anymore. I believe it is possible to build nuanced workflows with well abstracted / reusable / pluggable tools, it's just not as simple as implementing a static discovery / call dispatch layer.
    - chipgap98 2y ago
      Static in what sense?
      - mdaniel 2y ago
        I'm not the person you asked, but it does jam me up that Claude Desktop currently makes you edit a .json file and restart the app to add new MCP servers[1], so that's at least one static thing. I'm sure someone will show up with a github link of awesome-org/mcp-mcp-server 1: https://modelcontextprotocol.info/docs/quickstart/user/#3-restart-claude https://modelcontextprotocol.info/docs/quickstart/user/#3-re...
    - cmsparks 2y ago
      MCP isn't static. It explicitly includes support for dynamically modifying tools, resources, etc via it's client notifications[0]. Sure, context is usually opaque to the server itself (unless you use the sampling feature[1]), but there's nothing preventing MCP clients/hosts from adjusting or filtering tools on their own. [0] https://modelcontextprotocol.io/specification/2025-03-26/server/tools#list-changed-notification https://modelcontextprotocol.io/specification/2025-03-26/ser... [1] https://modelcontextprotocol.io/specification/2025-03-26/client/sampling https://modelcontextprotocol.io/specification/2025-03-26/cli...
totaldude87 2y ago
isnt langchain doing the exact same thing? (sorry ai noob here)
- simonw 2y ago
  Langchain is one of many frameworks that implement the "tool calling" pattern, where LLM applications can request that a tool is run (eg "search the web for X" or "execute this Python code") and see the result of that. MCP is a standard for describing and exposing tools to LLM applications. So they're not the same category of thing. Langchain could implement aspects of the MCP specification, in fact it looks like they're doing that already: https://github.com/langchain-ai/langchain-mcp-adapters https://github.com/langchain-ai/langchain-mcp-adapters
  - the_arun 2y ago
    So, is MCP a spec for tool calling API?
    - simonw 2y ago
      There's a MCP "server" spec for writing code that exposes tool definitions and the ability to execute them, and an MCP "client" spec for building systems that can make use of those servers.
    - tuananh 2y ago
      it's more than just tools. there're prompts & resources too
    - pizza 2y ago
      It's a spec for how external info can get into a language model's context window. Part of that is tool calling, but there's also templated input, cancellation, progress tracking, recursive generation sampling, statefulness of tool servers, etc.
- sshh12 2y ago
  It's a common question! Related: > Tool-Calling - If you’re like me, when you first saw MCP you were wondering “isn’t that just tool-calling?”... Not everyone uses langchain nor does langchain cover some of the lower level aspects of actually connecting things up. MCP just helps standardize some of those details so any assistant/integration combo is compatible. Edit: +1 simonw above
behnamoh 2y ago
Yeah, I don't feel comfortable downloading tiny server programs from random devs on the internet to give my LLM client apps extra "tools". I can LuLu or LittleSnitch regular apps but not these ones.
- deleted 1y ago
  [deleted]
jwpapi 2y ago
I have read 30 MCP articles now and I still don’t understand why we not just use API?
- jasondigitized 2y ago
  I played around with MCP this weekend and I agree. I just want to get a users X and then send X to my endpoint so I can do something with it. I don't need any higher level abstraction than that.
  - deleted 2y ago
    [deleted]
  - deleted 2y ago
    [deleted]
- cnych 2y ago
  [dead]
- pcarolan 2y ago
  Right. And if you use OpenAPI the agent can get the api spec context it needs from /openapi.json.
- kristoff200512 2y ago
  I think it's fine if you only need a standalone API or know exactly which APIs to call. But when users ask questions or you're unsure which APIs to use, MCP can solve this issue—and it can process requests based on your previous messages.
- pizza 2y ago
  I just want to mention something in a chat in 5 seconds instead of preparing the input data, sending it to the API, parsing the output for the answer, and then doing it all again for every subsequent message.
- mehdibl 2y ago
  Because you need mainly a bridge between the Function calling schema defined that you expose to the AI model so you can leverage them. The model need a gateway as API can't be used directly. MCP core power is the TOOLS and tools need to translate to function calls and that's mainly what MCP do under the hood. Your tool can be an API, but you need this translation layer function call ==> Tool and MCP sits in the middle https://platform.openai.com/docs/guides/function-calling https://platform.openai.com/docs/guides/function-calling
dend 2y ago
Coordinator of the authorization RFC linked in this post[1]. The protocol is in very, very early stages and there are a lot of things that still need to be figured out. That being said, I can commend Anthropic on being very open to listening to the community and acting on the feedback. The authorization spec RFC, for example, is a coordinated effort between security experts at Microsoft (my employer), Arcade, Hellō, Auth0/Okta, Stytch, Descope, and quite a few others. The folks at Anthropic set the foundation and welcomed others to help build on it. It will mature and get better. [1]: https://github.com/modelcontextprotocol/modelcontextprotocol/pull/284 https://github.com/modelcontextprotocol/modelcontextprotocol...
- sshh12 2y ago
  Awesome! Thanks for your work on this.
  - dend 2y ago
    Can't take any credit - it's a massive effort across many folks much smarter than me.
- magicalhippo 2y ago
  A nice, comprehensive yet accessible blog post about it can be found here[1], got submitted earlier[2] but didn't gain traction. [1]: https://aaronparecki.com/2025/04/03/15/oauth-for-model-context-protocol https://aaronparecki.com/2025/04/03/15/oauth-for-model-conte... [2]: https://news.ycombinator.com/item?id=43620496 https://news.ycombinator.com/item?id=43620496
  - dend 2y ago
    Great news - Aaron has been a core reviewer and contributor to the aforementioned RFC.
    - magicalhippo 2y ago
      Yeah figured he had to be involved and saw his name on the pull request after I posted. Really enjoyed the article he wrote, just wanted to promote it some more. I learned of several things that will be useful to me beyond MCP.
rglover 2y ago
Yet another piece of rushed technology that's being heralded as "the way" which will most certainly be discarded when the next hype-able acronym comes along. The only upside to these technologies being shotgun implemented and promoted is that they'll inevitably lead to a failure that can't be pushed under the rug (and will irreversibly damage the credibility of AI usage in business).
- deleted 2y ago
  [deleted]
- pizza 2y ago
  To paraphrase the Bjarne Stroustrop quote: There are only two kinds of language model tool calling protocols: the ones people complain about and the ones nobody uses
  - rglover 2y ago
    Okay and now what? Throwing out empty platitudes like this in the face of legitimate criticism is only going to expedite what I said above.
    - pizza 2y ago
      What do you want it to do differently? There's still the option of making a PR or a fork or sharing an alternative you've built with others.
- rvz 2y ago
  Totally agree. It appears Anthropic developed this "standard" in a vacuum with no scrutiny or review and it turns out it's riddled with horrific security issues, ignored by those hyping up the "standard" for more VC money. Reminds me of the micro-services hype, which that helps the big cloud providers more than it helps startups with less money even with some over-doing it and being left with enormous amount of technical debt and complex diagrams costing them millions to run.
mehdibl 2y ago
MCP have a BAD UI? MCP is not a UI. Seem someone here quite confused about what is MCP. MCP have no security? Someone don't know that stdio is secure and over SSE/HTTP there was already specs: https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization https://modelcontextprotocol.io/specification/2025-03-26/bas.... MCP can run malicious code? Apply to any app you download. How this is the MCP issue? Happen in vscode extensions. NPM libs. But blame MCP. MCP transmits unstructured text by design? This is totally funny. It's the tool that decide what to respond. Annd the dialogue is quite I start feeling this post is a troll. I stopped reading and even worth continuing over prompt injection and so on.
- throw1290381290 2y ago
  > Someone don't know that stdio is secure I'm sure someone in the comments will say that inter-process communication requires auth (－‸ლ.
  - frogsRnice 2y ago
    It absolutely does
- ramesh31 2y ago
  MCP is absolutely a UI. It's just that the "user" is an LLM agent. Properly defining that interface is the main crucial piece of developing any tool.
  - mehdibl 2y ago
    OK the HTTP is a UI. Seriously, these comment are trolling.
    - dang 2y ago
      Please don't resort to accusing others of trolling, or of telling them they didn't read something (https://news.ycombinator.com/item?id=43677540 https://news.ycombinator.com/item?id=43677540). These are swipes, which the HN guidelines ask you to edit out of your posts here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. If people are posting bad information or bad arguments, it's enough to respond with good information and good arguments. It's in your interests to do this too, because if you make them without swipes, your arguments will be more credible.
sunpazed 2y ago
Let’s remind ourselves that MCP was announced to the world in November 2024, only 4 short months ago. The RFC is actively being worked on and evolving.
- sealeck 2y ago
  It's April 2025
  - marcellus23 2y ago
    Yes, and it's been about 4 and a half months since Nov 25, 2024.
rvz 2y ago
Another article accurately critiquing the short-comings of this terrible "spec". This is exactly why MCP is hardly a mature standard and was not designed to be secure at all making it acceptable for AI agents to claim to execute commands but could also be stealing your credentials or running a totally different command such or could download malware. The spec appears to to be designed by 6 month-old vibe-coding developers learning Javascript with zero scrutiny rather than members of the IETF at leading companies with maximum scrutiny. Next time, Anthropic should consult professionals that have developed mature standards for decades and learn from bad standards such as JWT and Oauth.
EigenLord 2y ago
The author makes good general points but seems to be overloading MCP's responsibilities imo. My understanding of MCP is that it just provides a ready-made "doorway" for LLMs to enter and interact with externally managed resources. It's a bridge or gateway. So is it really MCP's fault that it: >makes it easier to accidentally expose sensitive data. So does the "forward" button on emails. Maybe be more careful about how your system handles sensitive data. How about: >MCP allows for more powerful prompt injections. This just touches on wider topic of only working with trusted service providers that developers should abide by generally. As for: >MCP has no concept or controls for costs. Rate limit and monitor your own usage. You should anyway. It's not the road's job to make you follow the speed limit. Finally, many of the other issues seem to be more about coming to terms with delegating to AI agents generally. In any case it's the developer's responsibility to manage all these problems within the boundaries they control. No API should have that many responsibilities.
- Spivak 2y ago
  I think the author's point is that the architecture of MCP is fundamentally extremely high trust between not only your agent software and the integrations, but the (n choose 2) relationships between all of them. We're doing the LLM equivalent of loading code directly into our address space and executing it. This isn't a bad thing, dlopen is incredibly powerful with this power, but the problem being solved with MCP just isn't that level of trust. The real level of trust is on the order OAuth flows where the data provider has a gun sighted on every integration. Unless something about this protocol and it's implementations change I expect every MCP server to start doing side-channel verification like getting an email "hey your LLM is asking to do thing, click the link to approve." Where in this future it severely inhibits the usefulness of agents in the same vein as Apple's "click the notification to run this automation."
  - zoogeny 2y ago
    Sure, at first, until the users demand a "always allow this ..." kind of prompt and we are back in the same place. A lot of these issues seem trivial when we consider having a dozen agents running on tens of thousands of tokens of context. You can envision UIs that take these security concerns into account. I think a lot of the UI solutions will break down if we have hundreds of agents each injecting 10k+ tokens into a 1m+ context. The problems we are solving for today won't hold as LLMs continue to increase in size and complexity.
ezyang 2y ago
I quite liked this article, actually, and I'm quite an MCP stan. These all seem like legitimate problems that the burgeoning ecosystem needs to figure out. Some of them will be logically solved inside the MCP spec, but I also think some won't.
jeswin 2y ago
> MCP servers can run (malicious code) locally. I wrote an MCP Server (called Codebox[1]) which starts a Docker container with your project code mounted. It works quite well, and I've been using it with LibreChat and vscode. In my experience, Agents save 2x the time (over using an LLM traditionally) and is less typing, but at roughly 3x the cost. The idea is to make the entire Unix toolset available to the LLM (such as ls, find), along with project specific tooling (such as typescript, linters, treesitter). Basically you can load whatever you want into the container, and let the LLM work on your project inside it. This can be done with a VM as well. I've found this workflow (agentic, driven through a Chat based interface) to be more effective compared to something like Cursor. Will do a Show HN some time next week. [1]: https://github.com/codespin-ai/codebox-js https://github.com/codespin-ai/codebox-js
- jillesvangurp 2y ago
  Any interpreter can run malicious code. Mostly the guidance is: don't run malicious code if you don't want it to run. The problem isn't the interpreter/tool but the entity that's using it. Because that's the thing that you should be (mis)-trusting. The issue is two fold: - models aren't quite trustworthy yet. - people put a lot of trust in them anyway. This friction always exist with security. It's not a technical problem that can or should be solved on the MCP side. Part of the solution is indeed going to come from containerization. Give MCP agents access to what they need but not more. And part of it is going to come from some common sense and the tool UX providing better transparency into what is happening. Some of the better examples I've seen of Agentic tools work like you outline. I don't worry too much about the cost. This stuff is getting useful enough that paying a chunk of what normally would go into somebody's salary actually isn't that bad of a deal. And of course cost will come down. My main worry is actually speed. I seem to spend a lot of time waiting for these tools to do their thing. I'd love this stuff to be a bit zippier.
  - jeswin 2y ago
    > Give MCP agents access to what they need but not more. My view is that you should give them (Agents) a computer, with a complete but minimal Linux installation - as a VM or Containerized. This has given me better results, because now it can say fetch information from the internet, or do whatever it wants (but still in the sandbox). Of course, depending on what you're working on, you might decide that internet access is a bad idea, or that it should just see the working copy, or allow only certain websites.
lacker 2y ago
Is anyone successfully using Claude Code along with MCP? I feel like I hear very many stories of some company integrating with MCP, many fewer stories from users about how it helps them.
- zoogeny 2y ago
  I've heard the opposite, stories from users that MCP has been a flop. One of my acquaintances works in marketing and is a heavy LLM user. He got swept up in the hype of MCPs and tried a bunch of them out. He was expressing his disappointment and frustration. It is a drawback of hype and early adoption. I think highly technical users can get value out of it for now and can keep their expectations in line. If I am building my own MCP server and it is a bit flaky, I manage that responsibility myself. If I am wiring up a MCP server that makes some claims of automating some workflow and it doesn't work, then I negatively associate that with the very idea of MCP.
israrkhan 2y ago
I feel MCP emerged too quickly. It will take some time and further protocol versions/enhancements for it to mature, and address stuff like security. Also it was not vetted by a conventional standards body, but just made public by a company. Lots of hype around it, everyone seems to be talking MCP these days.
- sgt101 2y ago
  This is a key point - where are the applications? Normally we have a standard when we have applications, but I am not seeing these yet... perhaps I am blind and mad!
  - jacobr1 2y ago
    Three big places: 1 - Claude Desktop (and some more niche AI chat apps) - you can use MCPs to extend these chat systems today. I use a small number daily. 2 - Code Automation tools - they pretty much all have added MCP. Cursor, Claude Code, Cline, VSCode GH Codepilot, etc ... 3 - Agent/LLM automation frameworks. There are a ton of tools to build agentic apps and many support using MCP to to integrate third party APIs with limited to no boilerplate. And if there are are large libraries of every third party system you can imagine (like npm - but for APIs) then these are going to get used. Still early days - but tons of real use, at least by the early adopter crowd. It isn't just a spec sitting on a shelf for all the many faults.
    - sgt101 2y ago
      These examples seem to be tools built on this tool - which is cool and all, but it's not the equivalent of "a mail order catalogue you can access through your computer", or "a replacement for a travel agent". What are the applications at the level of Amazon.com, Expedia, or Hacker News?
  - cruffle_duffle 2y ago
    They are little things like “hey I want to get the LLM to fetch logs from elasticsearch” or “hey I want to create a way for the LLM to query my database in a more structured way”. And yeah in theory openapi can do it but not nearly as token efficient or user efficient. OpenAPI doesn’t help actually “connect” the LLM to anything, it’s not a tool itself but a spec. To use an OpenAPI compliant server you’d still need to tell the LLM how to authenticate, what the server address is, what tool needs to be used to call out (curl?) and even then you’d still need an affordance for the LLM to even make that call to curl. That “afforance” is exactly what MCP defines. It provides a structured way for the LLM to make tool calls.
seinecle 2y ago
A natural follow up: is Google's newly launched a2a better equipped to handle these security issues?
krige 2y ago
Does it at least say "END OF LINE" and banish wannabe hackers to the game grid?
otabdeveloper4 2y ago
> It's so over > We are so back
sixhobbits 2y ago
I'm sure MCP does have legitimate problems and some might even be covered in this article but the author would benefit by spending more time refining their criticisms. There's a whole section on how people can do things like analyse a combination of slack messages, and how they might use that information. This is more of an argument suggesting agents are dangerous. You can think MCP is a good spec that lets you create dangerous things but conflating these arguments under "mcp bad" is disingenuous. Id rather have more details and examples on the problem with the spec itself. "You can use it to do bad things" doesn't cut it. I can use http and ssh to bad things too, so it's more interesting to show how Eve might use MCP to do malicious things to Alice or Bob who are trying to use MCP as intended.
lbeurerkellner 2y ago
I think what is not to be overlooked in these discussions, is the user base of MCP. In my experience, many less-technical folks started using MCP, and that makes security issues all the more relevant. This audience often lacks intuition around security best-practices. So it’s definitely important to raise awareness around this.
madrox 2y ago
Nothing the author said is wrong, but I don’t know how much it matters or if it would’ve been better if it handled all this out of the gate. I think if MCP were more complicated no one would’ve adopted it. Being pretty close to OAuth 1.0 and the group that shaped it I’ve seen how new standards emerge, and I think it’s been so long since new standards mattered that people forgot how they happen. I was one of the first people to criticize MCP when it launched (my comment on the HN announcement specifically mentioned auth) but I respect the groundswell of support it got, and at the end of the day the standard that matters is the one people follow, even if it isn’t the best.
a3w 2y ago
BetaMax is better than VHS, the latter won. Rkt is better than Docker, later won. ${TBD} is better than MCP, my bet is on MCP.
- mdaniel 2y ago
  > Rkt is better than Docker, later won. Your experience with rkt is way different from mine. I would gladly accept "podman is..." or even "nerdctl is..." but I hate rkt so much and was thrilled when it disappeared from my life
- idonotknowwhy 2y ago
  BetaMax had better fidelity than VHS, but initially could only hold 60 minutes of A/V while VHS could do 120m (ie, almost a full movie without swapping tapes)
rcarmo 2y ago
There is one thing I pointed out in https://taoofmac.com/space/notes/2025/03/22/1900 https://taoofmac.com/space/notes/2025/03/22/1900 and seems to be missing from the article: "... MCP tends to crowd the model context with too many options. There doesn’t seem to be a clear way to set priorities or a set of good examples to expose MCP server metadata–so your model API calls will just pack all the stuff an MCP server can do and shove it into the context, which is both wasteful of tokens and leads to erratic behavior from models."
- sshh12 2y ago
  It's in there briefly in the llm limitations section.
jascha_eng 2y ago
Something that I struggle with in regards to MCP and no-ones really touches on: We don't even know if this "general" Chatbot paradigm will persist. So far I got the feeling that we end up building specialized apps for specialized use-cases (e.g. cursor or claude code for coding) These then bring their own set of tools (for file writing, reading, running bash commands, etc.) and don't really need MCP (except for very niche use-cases maybe). I don't really see the point yet where LLMs become so good that I throw my specialized LLM tools out and do everything in one claude desktop window. It simply doesn't work generic enough. Also... if you end up building something custom, you end up having to reimplement the tool calling again anyways. MCP really is just for the user facing chat agents, which is just one section of AI applications. It's not as generically applicable as implied.
- fragmede 2y ago
  If you have a better idea you could get millions in VC funding to pursue that. Chat is where it's at. It's fine to think that it's not gonna be the be-all and end-all of AI, but it's pretty fundamentally how we interact with each other, so I don't see it going away any time soon. There's also a thing as being too generic. So really they just hit this sweet spot.
  - skydhash 2y ago
    > If you have a better idea you could get millions in VC funding to pursue that. I would like to see: - Some Smalltalk-like IWE (Integrated Work Environment), creating prompt snippets and chaining them together. - A spreadsheet like environment. Prompt's result are always tables and you have the usual cell reference available.
    - fragmede 1y ago
      Fascinating idea. Though I will note that prompt results aren't usually tables when I ask ChatGPT to ask me questions to help me figure out where I personally stand on, say, hot button political issues.
torginus 2y ago
Is it just me, or is this thing really, really stupid? I mean the whole AI personal assistant shebang from all possible angles. Imagine, for example if booking.com built an MCP server allowing you to book a hotel room, query all offers in an area in a given time, quickly, effortlessly, with a rate limit of 100 requests/caller/second, full featured, no hiding or limiting data. That would essentially be asking them to just offer you their internal databases, remove their ability to show you ads, remove the possibility to sell advertisers better search rankings, etc. It would be essentially asking them to keel over and die, and voluntarily surrender all their moat. But imagine for a second they did do that. You get the API, all the info is there. Why do you need AI then? Let's say you want to plan a trip to Thailand with your family. You could use the fancy AI to do it for you, or you could build a stupid frontend with minimal natural language understanding. It would be essentially a smart search box, where you could type in 'book trip to Thailand for 4 people, 1 week, from July 5th', and then it would parse your query, call out to MCP, and display the listings directly to you, where you could book with a click. The AI value add here is minimal, even non-existent. This applies to every service under the sun, you're essentially creating a second Internet just for AIs, without all the BS advertising, fluff, clout chasing and time wasting. I, as a human am dying to get access to that internet. Edit: I'm quite sure this AI MCP future is going to be enshittified in some way.
- FirmwareBurner 2y ago
  "What is Hooli? Excellent question. Hooli isn't just another high tech company. Hooli isn't just about software. Hooli...Hooli is about people. Hooli is about innovative technology that makes a difference, transforming the world as we know it. Making the world a better place, through minimal message oriented transport layers. I firmly believe we can only achieve greatness if first we achieve goodness."
- bob1029 2y ago
  It's not just you. However, I would say that I've grown to accept that most people prefer these more constrained models of thinking. Constraints can help free the mind up in other ways. If you do not perceive MCP as constraining, then you should definitely use it. Wait until you can feel the pain of its complexity and become familiar with it. This will be an excellent learning experience. Also consider the downstream opportunities that this will generate. Why not plan a few steps ahead and start thinking about a consultancy for resolving AI microservices clusterfucks.
novoreorx 2y ago
How well the protocol is designed doesn't matter, the most popular choice is not necessarily the best one. Sometimes "worse is better."
- _pdp_ 2y ago
  Like IE6?
jtrn 2y ago
What do we gain by using MCP that cloud not be achieved worth OpenAPI standard. It feels extremely redundant to me.
- emilsedgh 2y ago
  The biggest advantage of this is for the llm providers like OAI not application developers. LLM's are brains with no tools (no hands, legs, etc). When we use tool calling we use them to empower the brain. But using normal API's the language model providers like OpenAI have no access to those tools. With MCP they do. The brain they create can now have access to a lot of tools that the community builds directly _from_ llm, not through the apps. This is here to make ChatGPT/Claude/etc _the gateway_ to AI rather than them just being API providers for other apps.
- cruffle_duffle 2y ago
  What will the LLM use to call out to an OpenAPI system? Will it use a shell command like curl? How will it bind to the shell? How will the LLM’s host orchestrate that on the LLM’s behalf? And who will define the credentials? And what is the URL? Oh, those are in the environment variables? How will the LLM get that info? Do I need to prompt the LLM all that info, wasting context window on minutia that has nothing to do with my task? …if only there was a standard for that… I know! Maybe it can provide a structured way for the LLM to call curl and handle all the messy auth stuff and smooth over the edges between operating systems and stuff. Perhaps it can even think ahead and load the OpenAPI schema and provide a structured way to navigate such a large “context blowing” document so the LLM doesn’t have to use precious context window figuring it out? But at that point why not just provide the LLM with pre-built wrappers on top specifically for whatever problem domain the rest api is dealing with? Maybe we can call this protocol MCP? Because think about it. OpenAPI doesn’t help the LLM actually reach out and talk to the API. It still needs a way to do that. Which is precisely what MCP does.
  - jtrn 2y ago
    So why do I have to make an MCP server? Could it not just hook into the OpenAPI JSON spec? And who will define the credentials? The OpenAPI spec defines the credentials. MCP doesn't even allow for credentials, it seems, for now. But I don't think deleting a requirement is a good thing in this instance. I would like to have an API that I could reach from anywhere on the net and could secure with, for instance, an API key. And what is the URL? You have to define this for MCP also. For instance, in Cursor, you have to manually enter the endpoint with a key named "url." How will the LLM get that info? This was shown to be easily 1.5 years ago with GPT's easy understanding of the OpenAPI spec and its ability to use any endpoint on the net as a tool. I don't disagree that there needs to be a framework for using endpoints. But why can't it reach out to an OpenAPI endpoint? What do we gain from using a new "protocol"? I created a couple of MCP servers, and it just feels like going back 10 years in progress for creating and documenting web APIs. Let me ask you this in reverse then: Have you created a basic API and used it as a tool in a GPT? And have you created an MCP server and added it to applications on your computer? If you have done both and still feel that there is something better with MCP, please tell, because I found MCP to be solving an issue that didn't need solving. Create an awesome framework for reaching out to Web APIs and read the OpenAPI definition of the endpoint? GREAT! Enforce a new Web API standard that is much less capable than what we already have? Not so great. You seem to miss that an MCP server IS an HTTP server already. It's not just safe to expose it to the net and contains a new and limited spec for how to document and set it up.
serbuvlad 2y ago
This article reads less like a criticism of MCP, the internal technical details of which I don't know that much about, and they make the subject of but a part of the srticle, but a general criticism of the general aspect of "protocol to allow LLM to run actions on services" A large problem in this article stems from the fact that the LLM may take actions I do not want it to take. But there are clearly 2 types of actions the LLM can take: those I want it to take on it's own, and those I want it to take only after prompting me. There may come a time when I want the LLM to run a business for me, but that time is not yet upon us. For now I do not even want to send an e-mail generated by AI without vetting it first. But the author rejects the solution of simply prompting the user because "it’s easy to see why a user might fall into a pattern of auto-confirmation (or ‘YOLO-mode’) when most of their tools are harmless". Sure, and people spend more on cards than they do with cash and more on credit cards than they do on debit cards. But this is a psychological problem, not a technological one!
angusturner 2y ago
I have been developing with MCP for a few weeks now, making some small python and javascript servers to integrate with Claude Desktop. I am yet to see a use case that wouldn't be better served with an HTTP API. I understand the need to standardize some conventions around this, but at the heart of it, all "tool" use boils down to: 1. an API endpoint to expose capabilities / report the API schema 2. other endpoints ("tools") to expose functionality Want state? ("resources") - put a database or some random in-memory data structure behind an API endpoint. Want "prompts"? This is just a special case of a tool. Fundamentally (like most everyone else experimenting with this tech), I need an API that returns some text and maybe images. So why did I just lose two days trying to debug the Python MCP SDK, and the fact that its stdio transport can't send more than a few KB without crashing the server? If only there was a stateless way to communicate data between a client and a server, that could easily recover from and handle errors...
- crabmusket 2y ago
  APIs aren't self describing by default, but it feels like a missed opportunity for REST and HATEOAS proponents to show the value in those approaches. I've always said REST is for human clients, and LLMs seem like they should be human enough for this kind of thing.
  - ikiris 2y ago
    Rest is for people who thought xml was a good idea.
    - crabmusket 2y ago
      XML was a good idea ¯\_(ツ)_/¯
  - Xelynega 2y ago
    MCP is not self describing by default either. I can implement a tool and not add it to the definitions, much like you can implement an API endpoint and not add it to the spec. This is a documentation/code synchronization problem that is solved the same way for both MCP and REST, generate documentation from code.
codydkdc 2y ago
the only one of these points I personally care about is: > The protocol has a very LLM-friendly interface, but not always a human friendly one. similar to the people asking "why not just use the API directly", I have another question: why not just use the CLI directly? LLMs are trained on natural language. CLIs are an extremely common solution for client/server interactions in a human-readable, human-writeable way (that can be easily traversed down subcommands) for instance, instead of using the GitHub MCP server, why not just use the `gh` CLI? it's super easy to generate the help and feed it into the LLM, super easy to allow the user to inspect the command before running it, and already provides a sane exposure of the REST APIs. the human and the LLM can work in the same way, using the exact same interface
- jacobr1 2y ago
  FWIW - that is what claude code does, at least how I use it. It uses the BashTool to call `gh`
jappgar 2y ago
Amazing to see so many comments out here in support of a very new and very boring protocol. I have to think the enthusiasm is coming mostly from the vibe-coding snakeoil salespeople that seem to be infecting every software company right now.
- cruffle_duffle 2y ago
  Alternatively it’s actually pretty cool and useful and you just personally don’t have a use for it?
  - otabdeveloper4 2y ago
    It's not "pretty cool", it's a shitty reimplementation of the OpenAPI spec made by NIH syndrome idiots.
mlenhard 2y ago
One of the biggest issues I see, briefly discussed here, is how one MCP server tool's output can affect other tools later in the same message thread. To prevent this, there really needs to be sandboxing between tools. Invariant labs did this with tool descriptions [1], but I also achieved the same via MCP resource attachments[2]. It's a pretty major flaw exacerbated by the type of privilege and systems people are giving MCP servers access to. This isn't necessarily the fault of the spec itself, but how most clients have implemented it allows for some pretty major prompt injections. [1] https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks https://invariantlabs.ai/blog/mcp-security-notification-tool... [2] https://www.bernardiq.com/blog/resource-poisoning/ https://www.bernardiq.com/blog/resource-poisoning/
- cyanydeez 2y ago
  Isn't this basically a lot of hand waving that ends up being isomorphic to SQL injection? Thats what we're talking about? A bunch of systems cobbled together where one could SQL inject at any point and there's basically zero observability?
  - mlenhard 2y ago
    Yeah, you aren't far off with SQL injection comparison. That being said it's not really a fault of the MCP spec, more so with current client implementations of it.
  - seanhunter 2y ago
    Yes, and the people involved in all this stuff have also reinvented SQL injection in a different way in the prompt interface, since it's impossible[1] for the model to tell what parts of the prompt are trustworthy and what parts are tainted by user input, no matter what delimeters etc you try to use. This is because what the model sees is just a bunch of token numbers. You'd need to change how the encoding and decoding steps work and change how models are trained to introduce something akin to the placeholders that solve the sql injection problem. Therefore it's possible to prompt inject and tool inject. So you could for example prompt inject to get a model to call your tool which then does an injection to get the user to run some untrustworthy code of your own devising. [1] See the excellent series by Simon Willison on this https://simonwillison.net/series/prompt-injection/ https://simonwillison.net/series/prompt-injection/
superfreek 2y ago
Great point in the article about tools lacking output schemas. Makes reliable multi-step planning tough. We based Xops (https://xops.net https://xops.net) on OpenRPC for this exact reason (disclosure: we are the OpenRPC founders). It requires defining the result schema, not just params, which helps plan how outputs connect to the any step's inputs. Feels necessary for building complex workflows and agents reliably.
Havoc 2y ago
Much like the early days of JS and APIs in general this is presumably going to need time to evolve and settle.
cynicalpeace 2y ago
MCP has a LangChain smell. Doesn't solve a pressing problem that can't be solved via a few lines of code. Overly abstract. Tons of articles trying to explain its advantages, yet all somehow fail.
kordlessagain 2y ago
MCP is built on JSON-RPC 2.0. JSON-RPC 2.0 is a super lightweight, stateless protocol that lets a client and a server talk to each other using plain old JSON. It’s not tied to HTTP, but it often rides on it. It’s like the chill cousin of REST: no verbs, no URL gymnastics—just methods and parameters, passed as structured JSON. MCP calls itself a “protocol,” but let’s be honest—it’s a framework description wrapped in protocol cosplay. Real protocols define message formats and transmission semantics across transport layers. JSON-RPC, for example, is dead simple, dead portable, and works no matter who implements it. MCP, on the other hand, bundles prompt templates, session logic, SDK-specific behaviors, and application conventions—all under the same umbrella. As an example, I evidently need to install something called "uv", using a piped script pulled in from the Internet, to "run" the tool, which is done by putting this into a config file for Claude Desktop (which then completely hosed my Claude Desktop): { "mcpServers": { "weather": { "command": "uv", "args": [ "run", "--with", "fastmcp", "fastmcp", "run", "C:\\Users\\kord\\Code\\mcptest\\weather.py" ] } } } They (the exuberant authors) do mention transport—stdio and HTTP with SSE—but that just highlights the confusion here we are seeing. A real protocol doesn’t care how it’s transported, or it defines the transport clearly. MCP tries to do both and ends up muddying the boundaries. And the auth situation? It waves toward OAuth2.1, but offers almost zero clarity on implementation, trust delegation, or actual enforcement. It’s a rats nest waiting to unravel once people start pushing for real-world deployments that involve state, identity, or external APIs with rate limits and abuse vectors. This feels like yet another centralized spec written for one ecosystem (TypeScript AI crap), claiming universality without earning it. And let’s talk about streaming vs formatting while we’re at it. MCP handwaves over the reality that content coming in from a stream (like SSE) has totally different requirements than a local response. When you’re streaming partials from a model and interleaving tool calls, you need a very well-defined contract for how to chunk, format, and parse responses—especially when tools return mid-stream or you’re trying to do anything interactive. Right now, only a few clients are actually supported (Anthropic’s Claude, Copilot, OpenAI, and a couple local LLM projects). But that’s not a bug—it’s the feature. The clients are where the value capture is. If you can enforce that tools, prompts, and context management only work smoothly inside your shell, you keep devs and users corralled inside your experience. This isn’t open protocol territory; it’s marketing. Dev marketing dressed up as protocol design. Give them a “standard” so they don’t ask questions, then upsell them on hosted toolchains, orchestrators, and AI-native IDEs later. The LLM is the bait. The client is the business. And yes, Claude helped write this, but it's exactly what I would say if I had an hour to type it out clearly.
pgt 2y ago
MCP is just a transport + wire format with request/response lifecycle and most importantly: tool-level authorization. The essay misses the biggest problem with MCP: 1. it does not enable AI agents to functionally compose tools. 2. MCP should not exist in the first place. LLMs already know how to talk to every API that documents itself with OpenAPI specs, but the missing piece is authorization. Why not just let the AI make HTTP requests but apply authorization to endpoints? And indeed, people are wrapping existing APIs with thin MCP tools. Personally, the most annoying part of MCP is the lack of support for streaming tool call results. Tool calls have a single request/response pair, which means long-running tool calls can't emit data as it becomes available – the client has to repeat a tool call multiple times to paginate. IMO, MCP could have used gRPC which is designed for streaming. Need an onComplete trigger. I'm the author of Modex[^1], a Clojure MCP library, which is used by Datomic MCP[^2]. [^1]: Modex: Clojure MCP Library – https://github.com/theronic/modex https://github.com/theronic/modex [^2]: Datomic MCP: Datomic MCP Server – https://github.com/theronic/datomic-mcp/ https://github.com/theronic/datomic-mcp/
- keithwhor 2y ago
  I mean you don’t need gRPC. You can just treat all tool calls as SSEs themselves and you have streaming. HTTP is pretty robust.
  - pgt 2y ago
    HTTP Server-Sent Events (SSE) does not natively support batched streaming with explicit completion notifications in its core specification.
- cruffle_duffle 2y ago
  There are plenty of things out there that don’t use OpenAPI. In fact most things aren’t. Even if the universe was all OpenAPI, you’d still need a lower level protocol to define exactly how the LLM reaches out of the box and makes the OpenAPI call in the first place. That is what MCP does. It’s the protocol for calling tools. It’s not perfect but it’s a start.
RKFADU_UOFCCLEL 2y ago
I don't see the problem. I've just been using services with 3 - 10 verbs that the agent can use without adding any that can do harmful things. Even when they have no auth mechanism I can just put a temporary token in the URL.
K7mR2vZq 2y ago
[dead]
emorning3 2y ago
Anybody remember OSGi? I can imagine a plugin-based server where the plugins are applications and AIs that all use MCP to interact. The server would add a discovery protocol. That seems like the perfect use for MCP.
CamperBob2 2y ago
TL,DR: "MCP is powerful enough to do useful things. That's not OK. Somebody might get hacked."

516 points by sshh12 2y ago

"Authentication is tricky and so it was very fair that the designers chose not to include it in the first version of the protocol." No, it's not fair at all. You can't add security afterwards like spreading icing on baked cake. If you forgot to add sugar to the cake batter, there's not enough buttercream in the world to fix it.

sshh12 2y ago
I haven't read a good justification from them on this but it did seem reasonable to me that if the protocol allows auth to be added on top then it's less critical to be in the spec v1 itself. It's not no security vs security but not standardized vs standardized. Agree though that's it's not ideal and there will definitely be non zero harm from that decision.
chrisweekly 2y ago
great analogy
mickael-kerjean 2y ago
I made a MCP server to access remote storage using any kind of protocols (S3, SFTP, FTP, .... ), and authentication was not as much of a problem that most people would make you think. Is it technically pure and beautiful? No. Does it work? Yes and you can check by yourself by pointing the mcp inspector to "https://demo.filestash.app/sse https://demo.filestash.app/sse" and play around
fnordpiglet 2y ago
I’ll admit I’m a total dunce with respect to using MCP but given it uses TLS why not just use mutual TLS and validate the client certificate for authentication? You don’t need to use higher level protocols for authentication if your transport protocol supports it already. I would think authZ is the trickier unhandled part of MCP as I don’t remember any primitives for authorization denial or granularity, but, again, HTTP provides a coarse authZ exchange protocol.
- throw1290381290 2y ago
  There are 2 transports, HTTP and STDIO. You can use whatever authN/authZ you want for the HTTP transport. It's entirely up to the client and server implementers.
  - fnordpiglet 2y ago
    Presumably STDIO depends on the local AuthN/PAM that enabled the user space IO to begin with? I suspect what people are concerned about is the authorization of the LLM to the agent and its data rather than authN. AuthN in stdio would be the user that started the processes, or went through some AuthN chain allowing stdio to forward (I.e., ssh, sudo, etc). Am I missing something?
    - mehdibl 2y ago
      No they are concerne with SSE/HTTP as some made some MCP server over HTTP without auth in 2025. Then call it MCP issue.
      - fnordpiglet 2y ago
        Right - that’s my point. It’s janky to put AuthN into a high level protocol like MCP when low level protocols do a better job that’s more reliable and thoroughly vetted. You can do full on SAML etc and go hog wild without ever touching MCP while inheriting all the thorough analysis and implementation pressure testing down stack. Doing something unsafe because you don’t know what safe looks like isn’t application protocols fault.
    - jacobr1 2y ago
      The bigger issue is that we need a good why to authenticate more dynamically. In the context of a desktop app (desktop claude, claude code) where you are running an application locally, for your own purposes it can run as your own user. But when you are running things in any kind of multi-user/multi-tenant scenario, this is much harder and the protocol doesn't really address this (though also doesn't prevent us from layering something on top). As a dumb (but real) example, I don't want a web-enabled version of of an MCP plugin to have access to my company's google drive and expose that to all our chat users. That would bypass the RBAC we have. Also I don't want to bake that in at the level of the tool calls, as that can be injected. I need some side channel information on the session to have the client and server to manage that.
throw1290381290 2y ago
MCP can use HTTP or STDIO as transports. There is no need to implement a new form of authentication that's specific to the protocol because you already have a myriad of options available with HTTP. Any form of auth used to secure a web service can be used with MCP. It's no different than adding authN to a REST API. Please just read the spec. It just builds on top of JSON-RPC, there's nothing special or inherently new about this protocol. https://modelcontextprotocol.io/specification/2025-03-26 https://modelcontextprotocol.io/specification/2025-03-26 There are way too many commentators like yourself that have no idea what they are talking about because they couldn't be bothered to RTFM.
- RamblingCTO 2y ago
  Exactly, lots of people without any idea on what's going on. I implemented an authenticated MCP that uses the context bearer token and passes it on to the backend. Fully authenticated and authorized.

seuros 2y ago

Did you read the spec ? Everything you said is already a recommendation.

sshh12 2y ago
I think recommendation != being enforceably part of it or being implemented. There are a lot of great recs in the docs but I wrote this based on what I actually saw in the wild. I definitely don't think it's all on the spec to solve these.
- mehdibl 2y ago
  You didn't read the spec. And you didn't mention Stdio. Stdio is secure and that's what is used by Claude Desktop the first MCP client and they don't support SSE yet. Since the start, SSE was set a draft and there was a long discussion over the authentification implementation first round already got defined and second is defined again. I saw a lot of articles since MCP was buzzing same claims copy & paste. And the post show a lot of confusion for what MCP is and MCP do.
  - sshh12 2y ago
    A lot of servers don't use the stdio transport.

klntsky 2y ago

MCP is a dead end for chatbots. Building valuable workflows requires more than tool calling, most importantly, understanding the context of a conversation to adjust the tools dynamically.

simonw 2y ago
What does that have to do with MCP? Those sound like things you would build on a separate layer from MCP.
- klntsky 2y ago
  MCP tools are completely static. If you have to expose some APIs bypassing MCP, then you don't need MCP in the first place, because you don't have the tools abstracted anymore. I believe it is possible to build nuanced workflows with well abstracted / reusable / pluggable tools, it's just not as simple as implementing a static discovery / call dispatch layer.
  - chipgap98 2y ago
    Static in what sense?
    - mdaniel 2y ago
      I'm not the person you asked, but it does jam me up that Claude Desktop currently makes you edit a .json file and restart the app to add new MCP servers[1], so that's at least one static thing. I'm sure someone will show up with a github link of awesome-org/mcp-mcp-server 1: https://modelcontextprotocol.info/docs/quickstart/user/#3-restart-claude https://modelcontextprotocol.info/docs/quickstart/user/#3-re...
  - cmsparks 2y ago
    MCP isn't static. It explicitly includes support for dynamically modifying tools, resources, etc via it's client notifications[0]. Sure, context is usually opaque to the server itself (unless you use the sampling feature[1]), but there's nothing preventing MCP clients/hosts from adjusting or filtering tools on their own. [0] https://modelcontextprotocol.io/specification/2025-03-26/server/tools#list-changed-notification https://modelcontextprotocol.io/specification/2025-03-26/ser... [1] https://modelcontextprotocol.io/specification/2025-03-26/client/sampling https://modelcontextprotocol.io/specification/2025-03-26/cli...

totaldude87 2y ago

isnt langchain doing the exact same thing? (sorry ai noob here)

simonw 2y ago
Langchain is one of many frameworks that implement the "tool calling" pattern, where LLM applications can request that a tool is run (eg "search the web for X" or "execute this Python code") and see the result of that. MCP is a standard for describing and exposing tools to LLM applications. So they're not the same category of thing. Langchain could implement aspects of the MCP specification, in fact it looks like they're doing that already: https://github.com/langchain-ai/langchain-mcp-adapters https://github.com/langchain-ai/langchain-mcp-adapters
- the_arun 2y ago
  So, is MCP a spec for tool calling API?
  - simonw 2y ago
    There's a MCP "server" spec for writing code that exposes tool definitions and the ability to execute them, and an MCP "client" spec for building systems that can make use of those servers.
  - tuananh 2y ago
    it's more than just tools. there're prompts & resources too
  - pizza 2y ago
    It's a spec for how external info can get into a language model's context window. Part of that is tool calling, but there's also templated input, cancellation, progress tracking, recursive generation sampling, statefulness of tool servers, etc.
sshh12 2y ago
It's a common question! Related: > Tool-Calling - If you’re like me, when you first saw MCP you were wondering “isn’t that just tool-calling?”... Not everyone uses langchain nor does langchain cover some of the lower level aspects of actually connecting things up. MCP just helps standardize some of those details so any assistant/integration combo is compatible. Edit: +1 simonw above

behnamoh 2y ago

Yeah, I don't feel comfortable downloading tiny server programs from random devs on the internet to give my LLM client apps extra "tools". I can LuLu or LittleSnitch regular apps but not these ones.

deleted 1y ago
[deleted]

jwpapi 2y ago

I have read 30 MCP articles now and I still don’t understand why we not just use API?

jasondigitized 2y ago
I played around with MCP this weekend and I agree. I just want to get a users X and then send X to my endpoint so I can do something with it. I don't need any higher level abstraction than that.
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
cnych 2y ago
[dead]
pcarolan 2y ago
Right. And if you use OpenAPI the agent can get the api spec context it needs from /openapi.json.
kristoff200512 2y ago
I think it's fine if you only need a standalone API or know exactly which APIs to call. But when users ask questions or you're unsure which APIs to use, MCP can solve this issue—and it can process requests based on your previous messages.
pizza 2y ago
I just want to mention something in a chat in 5 seconds instead of preparing the input data, sending it to the API, parsing the output for the answer, and then doing it all again for every subsequent message.
mehdibl 2y ago
Because you need mainly a bridge between the Function calling schema defined that you expose to the AI model so you can leverage them. The model need a gateway as API can't be used directly. MCP core power is the TOOLS and tools need to translate to function calls and that's mainly what MCP do under the hood. Your tool can be an API, but you need this translation layer function call ==> Tool and MCP sits in the middle https://platform.openai.com/docs/guides/function-calling https://platform.openai.com/docs/guides/function-calling

dend 2y ago

Coordinator of the authorization RFC linked in this post[1]. The protocol is in very, very early stages and there are a lot of things that still need to be figured out. That being said, I can commend Anthropic on being very open to listening to the community and acting on the feedback. The authorization spec RFC, for example, is a coordinated effort between security experts at Microsoft (my employer), Arcade, Hellō, Auth0/Okta, Stytch, Descope, and quite a few others. The folks at Anthropic set the foundation and welcomed others to help build on it. It will mature and get better. [1]: https://github.com/modelcontextprotocol/modelcontextprotocol/pull/284 https://github.com/modelcontextprotocol/modelcontextprotocol...

sshh12 2y ago
Awesome! Thanks for your work on this.
- dend 2y ago
  Can't take any credit - it's a massive effort across many folks much smarter than me.
magicalhippo 2y ago
A nice, comprehensive yet accessible blog post about it can be found here[1], got submitted earlier[2] but didn't gain traction. [1]: https://aaronparecki.com/2025/04/03/15/oauth-for-model-context-protocol https://aaronparecki.com/2025/04/03/15/oauth-for-model-conte... [2]: https://news.ycombinator.com/item?id=43620496 https://news.ycombinator.com/item?id=43620496
- dend 2y ago
  Great news - Aaron has been a core reviewer and contributor to the aforementioned RFC.
  - magicalhippo 2y ago
    Yeah figured he had to be involved and saw his name on the pull request after I posted. Really enjoyed the article he wrote, just wanted to promote it some more. I learned of several things that will be useful to me beyond MCP.

rglover 2y ago

Yet another piece of rushed technology that's being heralded as "the way" which will most certainly be discarded when the next hype-able acronym comes along. The only upside to these technologies being shotgun implemented and promoted is that they'll inevitably lead to a failure that can't be pushed under the rug (and will irreversibly damage the credibility of AI usage in business).

deleted 2y ago
[deleted]
pizza 2y ago
To paraphrase the Bjarne Stroustrop quote: There are only two kinds of language model tool calling protocols: the ones people complain about and the ones nobody uses
- rglover 2y ago
  Okay and now what? Throwing out empty platitudes like this in the face of legitimate criticism is only going to expedite what I said above.
  - pizza 2y ago
    What do you want it to do differently? There's still the option of making a PR or a fork or sharing an alternative you've built with others.
rvz 2y ago
Totally agree. It appears Anthropic developed this "standard" in a vacuum with no scrutiny or review and it turns out it's riddled with horrific security issues, ignored by those hyping up the "standard" for more VC money. Reminds me of the micro-services hype, which that helps the big cloud providers more than it helps startups with less money even with some over-doing it and being left with enormous amount of technical debt and complex diagrams costing them millions to run.

mehdibl 2y ago

MCP have a BAD UI? MCP is not a UI. Seem someone here quite confused about what is MCP. MCP have no security? Someone don't know that stdio is secure and over SSE/HTTP there was already specs: https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization https://modelcontextprotocol.io/specification/2025-03-26/bas.... MCP can run malicious code? Apply to any app you download. How this is the MCP issue? Happen in vscode extensions. NPM libs. But blame MCP. MCP transmits unstructured text by design? This is totally funny. It's the tool that decide what to respond. Annd the dialogue is quite I start feeling this post is a troll. I stopped reading and even worth continuing over prompt injection and so on.

throw1290381290 2y ago
> Someone don't know that stdio is secure I'm sure someone in the comments will say that inter-process communication requires auth (－‸ლ.
- frogsRnice 2y ago
  It absolutely does
ramesh31 2y ago
MCP is absolutely a UI. It's just that the "user" is an LLM agent. Properly defining that interface is the main crucial piece of developing any tool.
- mehdibl 2y ago
  OK the HTTP is a UI. Seriously, these comment are trolling.
  - dang 2y ago
    Please don't resort to accusing others of trolling, or of telling them they didn't read something (https://news.ycombinator.com/item?id=43677540 https://news.ycombinator.com/item?id=43677540). These are swipes, which the HN guidelines ask you to edit out of your posts here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. If people are posting bad information or bad arguments, it's enough to respond with good information and good arguments. It's in your interests to do this too, because if you make them without swipes, your arguments will be more credible.

sunpazed 2y ago

Let’s remind ourselves that MCP was announced to the world in November 2024, only 4 short months ago. The RFC is actively being worked on and evolving.

sealeck 2y ago
It's April 2025
- marcellus23 2y ago
  Yes, and it's been about 4 and a half months since Nov 25, 2024.

rvz 2y ago

Another article accurately critiquing the short-comings of this terrible "spec". This is exactly why MCP is hardly a mature standard and was not designed to be secure at all making it acceptable for AI agents to claim to execute commands but could also be stealing your credentials or running a totally different command such or could download malware. The spec appears to to be designed by 6 month-old vibe-coding developers learning Javascript with zero scrutiny rather than members of the IETF at leading companies with maximum scrutiny. Next time, Anthropic should consult professionals that have developed mature standards for decades and learn from bad standards such as JWT and Oauth.

EigenLord 2y ago

The author makes good general points but seems to be overloading MCP's responsibilities imo. My understanding of MCP is that it just provides a ready-made "doorway" for LLMs to enter and interact with externally managed resources. It's a bridge or gateway. So is it really MCP's fault that it: >makes it easier to accidentally expose sensitive data. So does the "forward" button on emails. Maybe be more careful about how your system handles sensitive data. How about: >MCP allows for more powerful prompt injections. This just touches on wider topic of only working with trusted service providers that developers should abide by generally. As for: >MCP has no concept or controls for costs. Rate limit and monitor your own usage. You should anyway. It's not the road's job to make you follow the speed limit. Finally, many of the other issues seem to be more about coming to terms with delegating to AI agents generally. In any case it's the developer's responsibility to manage all these problems within the boundaries they control. No API should have that many responsibilities.

Spivak 2y ago
I think the author's point is that the architecture of MCP is fundamentally extremely high trust between not only your agent software and the integrations, but the (n choose 2) relationships between all of them. We're doing the LLM equivalent of loading code directly into our address space and executing it. This isn't a bad thing, dlopen is incredibly powerful with this power, but the problem being solved with MCP just isn't that level of trust. The real level of trust is on the order OAuth flows where the data provider has a gun sighted on every integration. Unless something about this protocol and it's implementations change I expect every MCP server to start doing side-channel verification like getting an email "hey your LLM is asking to do thing, click the link to approve." Where in this future it severely inhibits the usefulness of agents in the same vein as Apple's "click the notification to run this automation."
- zoogeny 2y ago
  Sure, at first, until the users demand a "always allow this ..." kind of prompt and we are back in the same place. A lot of these issues seem trivial when we consider having a dozen agents running on tens of thousands of tokens of context. You can envision UIs that take these security concerns into account. I think a lot of the UI solutions will break down if we have hundreds of agents each injecting 10k+ tokens into a 1m+ context. The problems we are solving for today won't hold as LLMs continue to increase in size and complexity.

ezyang 2y ago

I quite liked this article, actually, and I'm quite an MCP stan. These all seem like legitimate problems that the burgeoning ecosystem needs to figure out. Some of them will be logically solved inside the MCP spec, but I also think some won't.

jeswin 2y ago

> MCP servers can run (malicious code) locally. I wrote an MCP Server (called Codebox[1]) which starts a Docker container with your project code mounted. It works quite well, and I've been using it with LibreChat and vscode. In my experience, Agents save 2x the time (over using an LLM traditionally) and is less typing, but at roughly 3x the cost. The idea is to make the entire Unix toolset available to the LLM (such as ls, find), along with project specific tooling (such as typescript, linters, treesitter). Basically you can load whatever you want into the container, and let the LLM work on your project inside it. This can be done with a VM as well. I've found this workflow (agentic, driven through a Chat based interface) to be more effective compared to something like Cursor. Will do a Show HN some time next week. [1]: https://github.com/codespin-ai/codebox-js https://github.com/codespin-ai/codebox-js

jillesvangurp 2y ago
Any interpreter can run malicious code. Mostly the guidance is: don't run malicious code if you don't want it to run. The problem isn't the interpreter/tool but the entity that's using it. Because that's the thing that you should be (mis)-trusting. The issue is two fold: - models aren't quite trustworthy yet. - people put a lot of trust in them anyway. This friction always exist with security. It's not a technical problem that can or should be solved on the MCP side. Part of the solution is indeed going to come from containerization. Give MCP agents access to what they need but not more. And part of it is going to come from some common sense and the tool UX providing better transparency into what is happening. Some of the better examples I've seen of Agentic tools work like you outline. I don't worry too much about the cost. This stuff is getting useful enough that paying a chunk of what normally would go into somebody's salary actually isn't that bad of a deal. And of course cost will come down. My main worry is actually speed. I seem to spend a lot of time waiting for these tools to do their thing. I'd love this stuff to be a bit zippier.
- jeswin 2y ago
  > Give MCP agents access to what they need but not more. My view is that you should give them (Agents) a computer, with a complete but minimal Linux installation - as a VM or Containerized. This has given me better results, because now it can say fetch information from the internet, or do whatever it wants (but still in the sandbox). Of course, depending on what you're working on, you might decide that internet access is a bad idea, or that it should just see the working copy, or allow only certain websites.

lacker 2y ago

Is anyone successfully using Claude Code along with MCP? I feel like I hear very many stories of some company integrating with MCP, many fewer stories from users about how it helps them.

zoogeny 2y ago
I've heard the opposite, stories from users that MCP has been a flop. One of my acquaintances works in marketing and is a heavy LLM user. He got swept up in the hype of MCPs and tried a bunch of them out. He was expressing his disappointment and frustration. It is a drawback of hype and early adoption. I think highly technical users can get value out of it for now and can keep their expectations in line. If I am building my own MCP server and it is a bit flaky, I manage that responsibility myself. If I am wiring up a MCP server that makes some claims of automating some workflow and it doesn't work, then I negatively associate that with the very idea of MCP.

israrkhan 2y ago

I feel MCP emerged too quickly. It will take some time and further protocol versions/enhancements for it to mature, and address stuff like security. Also it was not vetted by a conventional standards body, but just made public by a company. Lots of hype around it, everyone seems to be talking MCP these days.

sgt101 2y ago
This is a key point - where are the applications? Normally we have a standard when we have applications, but I am not seeing these yet... perhaps I am blind and mad!
- jacobr1 2y ago
  Three big places: 1 - Claude Desktop (and some more niche AI chat apps) - you can use MCPs to extend these chat systems today. I use a small number daily. 2 - Code Automation tools - they pretty much all have added MCP. Cursor, Claude Code, Cline, VSCode GH Codepilot, etc ... 3 - Agent/LLM automation frameworks. There are a ton of tools to build agentic apps and many support using MCP to to integrate third party APIs with limited to no boilerplate. And if there are are large libraries of every third party system you can imagine (like npm - but for APIs) then these are going to get used. Still early days - but tons of real use, at least by the early adopter crowd. It isn't just a spec sitting on a shelf for all the many faults.
  - sgt101 2y ago
    These examples seem to be tools built on this tool - which is cool and all, but it's not the equivalent of "a mail order catalogue you can access through your computer", or "a replacement for a travel agent". What are the applications at the level of Amazon.com, Expedia, or Hacker News?
- cruffle_duffle 2y ago
  They are little things like “hey I want to get the LLM to fetch logs from elasticsearch” or “hey I want to create a way for the LLM to query my database in a more structured way”. And yeah in theory openapi can do it but not nearly as token efficient or user efficient. OpenAPI doesn’t help actually “connect” the LLM to anything, it’s not a tool itself but a spec. To use an OpenAPI compliant server you’d still need to tell the LLM how to authenticate, what the server address is, what tool needs to be used to call out (curl?) and even then you’d still need an affordance for the LLM to even make that call to curl. That “afforance” is exactly what MCP defines. It provides a structured way for the LLM to make tool calls.

seinecle 2y ago

A natural follow up: is Google's newly launched a2a better equipped to handle these security issues?

krige 2y ago

Does it at least say "END OF LINE" and banish wannabe hackers to the game grid?

otabdeveloper4 2y ago

> It's so over > We are so back

sixhobbits 2y ago

I'm sure MCP does have legitimate problems and some might even be covered in this article but the author would benefit by spending more time refining their criticisms. There's a whole section on how people can do things like analyse a combination of slack messages, and how they might use that information. This is more of an argument suggesting agents are dangerous. You can think MCP is a good spec that lets you create dangerous things but conflating these arguments under "mcp bad" is disingenuous. Id rather have more details and examples on the problem with the spec itself. "You can use it to do bad things" doesn't cut it. I can use http and ssh to bad things too, so it's more interesting to show how Eve might use MCP to do malicious things to Alice or Bob who are trying to use MCP as intended.

lbeurerkellner 2y ago

I think what is not to be overlooked in these discussions, is the user base of MCP. In my experience, many less-technical folks started using MCP, and that makes security issues all the more relevant. This audience often lacks intuition around security best-practices. So it’s definitely important to raise awareness around this.

madrox 2y ago

Nothing the author said is wrong, but I don’t know how much it matters or if it would’ve been better if it handled all this out of the gate. I think if MCP were more complicated no one would’ve adopted it. Being pretty close to OAuth 1.0 and the group that shaped it I’ve seen how new standards emerge, and I think it’s been so long since new standards mattered that people forgot how they happen. I was one of the first people to criticize MCP when it launched (my comment on the HN announcement specifically mentioned auth) but I respect the groundswell of support it got, and at the end of the day the standard that matters is the one people follow, even if it isn’t the best.

a3w 2y ago

BetaMax is better than VHS, the latter won. Rkt is better than Docker, later won. ${TBD} is better than MCP, my bet is on MCP.

mdaniel 2y ago
> Rkt is better than Docker, later won. Your experience with rkt is way different from mine. I would gladly accept "podman is..." or even "nerdctl is..." but I hate rkt so much and was thrilled when it disappeared from my life
idonotknowwhy 2y ago
BetaMax had better fidelity than VHS, but initially could only hold 60 minutes of A/V while VHS could do 120m (ie, almost a full movie without swapping tapes)

rcarmo 2y ago

There is one thing I pointed out in https://taoofmac.com/space/notes/2025/03/22/1900 https://taoofmac.com/space/notes/2025/03/22/1900 and seems to be missing from the article: "... MCP tends to crowd the model context with too many options. There doesn’t seem to be a clear way to set priorities or a set of good examples to expose MCP server metadata–so your model API calls will just pack all the stuff an MCP server can do and shove it into the context, which is both wasteful of tokens and leads to erratic behavior from models."

sshh12 2y ago
It's in there briefly in the llm limitations section.

jascha_eng 2y ago

Something that I struggle with in regards to MCP and no-ones really touches on: We don't even know if this "general" Chatbot paradigm will persist. So far I got the feeling that we end up building specialized apps for specialized use-cases (e.g. cursor or claude code for coding) These then bring their own set of tools (for file writing, reading, running bash commands, etc.) and don't really need MCP (except for very niche use-cases maybe). I don't really see the point yet where LLMs become so good that I throw my specialized LLM tools out and do everything in one claude desktop window. It simply doesn't work generic enough. Also... if you end up building something custom, you end up having to reimplement the tool calling again anyways. MCP really is just for the user facing chat agents, which is just one section of AI applications. It's not as generically applicable as implied.

fragmede 2y ago
If you have a better idea you could get millions in VC funding to pursue that. Chat is where it's at. It's fine to think that it's not gonna be the be-all and end-all of AI, but it's pretty fundamentally how we interact with each other, so I don't see it going away any time soon. There's also a thing as being too generic. So really they just hit this sweet spot.
- skydhash 2y ago
  > If you have a better idea you could get millions in VC funding to pursue that. I would like to see: - Some Smalltalk-like IWE (Integrated Work Environment), creating prompt snippets and chaining them together. - A spreadsheet like environment. Prompt's result are always tables and you have the usual cell reference available.
  - fragmede 1y ago
    Fascinating idea. Though I will note that prompt results aren't usually tables when I ask ChatGPT to ask me questions to help me figure out where I personally stand on, say, hot button political issues.

torginus 2y ago

Is it just me, or is this thing really, really stupid? I mean the whole AI personal assistant shebang from all possible angles. Imagine, for example if booking.com built an MCP server allowing you to book a hotel room, query all offers in an area in a given time, quickly, effortlessly, with a rate limit of 100 requests/caller/second, full featured, no hiding or limiting data. That would essentially be asking them to just offer you their internal databases, remove their ability to show you ads, remove the possibility to sell advertisers better search rankings, etc. It would be essentially asking them to keel over and die, and voluntarily surrender all their moat. But imagine for a second they did do that. You get the API, all the info is there. Why do you need AI then? Let's say you want to plan a trip to Thailand with your family. You could use the fancy AI to do it for you, or you could build a stupid frontend with minimal natural language understanding. It would be essentially a smart search box, where you could type in 'book trip to Thailand for 4 people, 1 week, from July 5th', and then it would parse your query, call out to MCP, and display the listings directly to you, where you could book with a click. The AI value add here is minimal, even non-existent. This applies to every service under the sun, you're essentially creating a second Internet just for AIs, without all the BS advertising, fluff, clout chasing and time wasting. I, as a human am dying to get access to that internet. Edit: I'm quite sure this AI MCP future is going to be enshittified in some way.

FirmwareBurner 2y ago
"What is Hooli? Excellent question. Hooli isn't just another high tech company. Hooli isn't just about software. Hooli...Hooli is about people. Hooli is about innovative technology that makes a difference, transforming the world as we know it. Making the world a better place, through minimal message oriented transport layers. I firmly believe we can only achieve greatness if first we achieve goodness."
bob1029 2y ago
It's not just you. However, I would say that I've grown to accept that most people prefer these more constrained models of thinking. Constraints can help free the mind up in other ways. If you do not perceive MCP as constraining, then you should definitely use it. Wait until you can feel the pain of its complexity and become familiar with it. This will be an excellent learning experience. Also consider the downstream opportunities that this will generate. Why not plan a few steps ahead and start thinking about a consultancy for resolving AI microservices clusterfucks.

novoreorx 2y ago

How well the protocol is designed doesn't matter, the most popular choice is not necessarily the best one. Sometimes "worse is better."

_pdp_ 2y ago
Like IE6?

jtrn 2y ago

What do we gain by using MCP that cloud not be achieved worth OpenAPI standard. It feels extremely redundant to me.

emilsedgh 2y ago
The biggest advantage of this is for the llm providers like OAI not application developers. LLM's are brains with no tools (no hands, legs, etc). When we use tool calling we use them to empower the brain. But using normal API's the language model providers like OpenAI have no access to those tools. With MCP they do. The brain they create can now have access to a lot of tools that the community builds directly _from_ llm, not through the apps. This is here to make ChatGPT/Claude/etc _the gateway_ to AI rather than them just being API providers for other apps.
cruffle_duffle 2y ago
What will the LLM use to call out to an OpenAPI system? Will it use a shell command like curl? How will it bind to the shell? How will the LLM’s host orchestrate that on the LLM’s behalf? And who will define the credentials? And what is the URL? Oh, those are in the environment variables? How will the LLM get that info? Do I need to prompt the LLM all that info, wasting context window on minutia that has nothing to do with my task? …if only there was a standard for that… I know! Maybe it can provide a structured way for the LLM to call curl and handle all the messy auth stuff and smooth over the edges between operating systems and stuff. Perhaps it can even think ahead and load the OpenAPI schema and provide a structured way to navigate such a large “context blowing” document so the LLM doesn’t have to use precious context window figuring it out? But at that point why not just provide the LLM with pre-built wrappers on top specifically for whatever problem domain the rest api is dealing with? Maybe we can call this protocol MCP? Because think about it. OpenAPI doesn’t help the LLM actually reach out and talk to the API. It still needs a way to do that. Which is precisely what MCP does.
- jtrn 2y ago
  So why do I have to make an MCP server? Could it not just hook into the OpenAPI JSON spec? And who will define the credentials? The OpenAPI spec defines the credentials. MCP doesn't even allow for credentials, it seems, for now. But I don't think deleting a requirement is a good thing in this instance. I would like to have an API that I could reach from anywhere on the net and could secure with, for instance, an API key. And what is the URL? You have to define this for MCP also. For instance, in Cursor, you have to manually enter the endpoint with a key named "url." How will the LLM get that info? This was shown to be easily 1.5 years ago with GPT's easy understanding of the OpenAPI spec and its ability to use any endpoint on the net as a tool. I don't disagree that there needs to be a framework for using endpoints. But why can't it reach out to an OpenAPI endpoint? What do we gain from using a new "protocol"? I created a couple of MCP servers, and it just feels like going back 10 years in progress for creating and documenting web APIs. Let me ask you this in reverse then: Have you created a basic API and used it as a tool in a GPT? And have you created an MCP server and added it to applications on your computer? If you have done both and still feel that there is something better with MCP, please tell, because I found MCP to be solving an issue that didn't need solving. Create an awesome framework for reaching out to Web APIs and read the OpenAPI definition of the endpoint? GREAT! Enforce a new Web API standard that is much less capable than what we already have? Not so great. You seem to miss that an MCP server IS an HTTP server already. It's not just safe to expose it to the net and contains a new and limited spec for how to document and set it up.

serbuvlad 2y ago

This article reads less like a criticism of MCP, the internal technical details of which I don't know that much about, and they make the subject of but a part of the srticle, but a general criticism of the general aspect of "protocol to allow LLM to run actions on services" A large problem in this article stems from the fact that the LLM may take actions I do not want it to take. But there are clearly 2 types of actions the LLM can take: those I want it to take on it's own, and those I want it to take only after prompting me. There may come a time when I want the LLM to run a business for me, but that time is not yet upon us. For now I do not even want to send an e-mail generated by AI without vetting it first. But the author rejects the solution of simply prompting the user because "it’s easy to see why a user might fall into a pattern of auto-confirmation (or ‘YOLO-mode’) when most of their tools are harmless". Sure, and people spend more on cards than they do with cash and more on credit cards than they do on debit cards. But this is a psychological problem, not a technological one!

angusturner 2y ago

I have been developing with MCP for a few weeks now, making some small python and javascript servers to integrate with Claude Desktop. I am yet to see a use case that wouldn't be better served with an HTTP API. I understand the need to standardize some conventions around this, but at the heart of it, all "tool" use boils down to: 1. an API endpoint to expose capabilities / report the API schema 2. other endpoints ("tools") to expose functionality Want state? ("resources") - put a database or some random in-memory data structure behind an API endpoint. Want "prompts"? This is just a special case of a tool. Fundamentally (like most everyone else experimenting with this tech), I need an API that returns some text and maybe images. So why did I just lose two days trying to debug the Python MCP SDK, and the fact that its stdio transport can't send more than a few KB without crashing the server? If only there was a stateless way to communicate data between a client and a server, that could easily recover from and handle errors...

crabmusket 2y ago
APIs aren't self describing by default, but it feels like a missed opportunity for REST and HATEOAS proponents to show the value in those approaches. I've always said REST is for human clients, and LLMs seem like they should be human enough for this kind of thing.
- ikiris 2y ago
  Rest is for people who thought xml was a good idea.
  - crabmusket 2y ago
    XML was a good idea ¯\_(ツ)_/¯
- Xelynega 2y ago
  MCP is not self describing by default either. I can implement a tool and not add it to the definitions, much like you can implement an API endpoint and not add it to the spec. This is a documentation/code synchronization problem that is solved the same way for both MCP and REST, generate documentation from code.

codydkdc 2y ago

the only one of these points I personally care about is: > The protocol has a very LLM-friendly interface, but not always a human friendly one. similar to the people asking "why not just use the API directly", I have another question: why not just use the CLI directly? LLMs are trained on natural language. CLIs are an extremely common solution for client/server interactions in a human-readable, human-writeable way (that can be easily traversed down subcommands) for instance, instead of using the GitHub MCP server, why not just use the `gh` CLI? it's super easy to generate the help and feed it into the LLM, super easy to allow the user to inspect the command before running it, and already provides a sane exposure of the REST APIs. the human and the LLM can work in the same way, using the exact same interface

jacobr1 2y ago
FWIW - that is what claude code does, at least how I use it. It uses the BashTool to call `gh`

jappgar 2y ago

Amazing to see so many comments out here in support of a very new and very boring protocol. I have to think the enthusiasm is coming mostly from the vibe-coding snakeoil salespeople that seem to be infecting every software company right now.

cruffle_duffle 2y ago
Alternatively it’s actually pretty cool and useful and you just personally don’t have a use for it?
- otabdeveloper4 2y ago
  It's not "pretty cool", it's a shitty reimplementation of the OpenAPI spec made by NIH syndrome idiots.

mlenhard 2y ago

One of the biggest issues I see, briefly discussed here, is how one MCP server tool's output can affect other tools later in the same message thread. To prevent this, there really needs to be sandboxing between tools. Invariant labs did this with tool descriptions [1], but I also achieved the same via MCP resource attachments[2]. It's a pretty major flaw exacerbated by the type of privilege and systems people are giving MCP servers access to. This isn't necessarily the fault of the spec itself, but how most clients have implemented it allows for some pretty major prompt injections. [1] https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks https://invariantlabs.ai/blog/mcp-security-notification-tool... [2] https://www.bernardiq.com/blog/resource-poisoning/ https://www.bernardiq.com/blog/resource-poisoning/

cyanydeez 2y ago
Isn't this basically a lot of hand waving that ends up being isomorphic to SQL injection? Thats what we're talking about? A bunch of systems cobbled together where one could SQL inject at any point and there's basically zero observability?
- mlenhard 2y ago
  Yeah, you aren't far off with SQL injection comparison. That being said it's not really a fault of the MCP spec, more so with current client implementations of it.
- seanhunter 2y ago
  Yes, and the people involved in all this stuff have also reinvented SQL injection in a different way in the prompt interface, since it's impossible[1] for the model to tell what parts of the prompt are trustworthy and what parts are tainted by user input, no matter what delimeters etc you try to use. This is because what the model sees is just a bunch of token numbers. You'd need to change how the encoding and decoding steps work and change how models are trained to introduce something akin to the placeholders that solve the sql injection problem. Therefore it's possible to prompt inject and tool inject. So you could for example prompt inject to get a model to call your tool which then does an injection to get the user to run some untrustworthy code of your own devising. [1] See the excellent series by Simon Willison on this https://simonwillison.net/series/prompt-injection/ https://simonwillison.net/series/prompt-injection/

superfreek 2y ago

Great point in the article about tools lacking output schemas. Makes reliable multi-step planning tough. We based Xops (https://xops.net https://xops.net) on OpenRPC for this exact reason (disclosure: we are the OpenRPC founders). It requires defining the result schema, not just params, which helps plan how outputs connect to the any step's inputs. Feels necessary for building complex workflows and agents reliably.

Havoc 2y ago

Much like the early days of JS and APIs in general this is presumably going to need time to evolve and settle.

cynicalpeace 2y ago

MCP has a LangChain smell. Doesn't solve a pressing problem that can't be solved via a few lines of code. Overly abstract. Tons of articles trying to explain its advantages, yet all somehow fail.

kordlessagain 2y ago

MCP is built on JSON-RPC 2.0. JSON-RPC 2.0 is a super lightweight, stateless protocol that lets a client and a server talk to each other using plain old JSON. It’s not tied to HTTP, but it often rides on it. It’s like the chill cousin of REST: no verbs, no URL gymnastics—just methods and parameters, passed as structured JSON. MCP calls itself a “protocol,” but let’s be honest—it’s a framework description wrapped in protocol cosplay. Real protocols define message formats and transmission semantics across transport layers. JSON-RPC, for example, is dead simple, dead portable, and works no matter who implements it. MCP, on the other hand, bundles prompt templates, session logic, SDK-specific behaviors, and application conventions—all under the same umbrella. As an example, I evidently need to install something called "uv", using a piped script pulled in from the Internet, to "run" the tool, which is done by putting this into a config file for Claude Desktop (which then completely hosed my Claude Desktop): { "mcpServers": { "weather": { "command": "uv", "args": [ "run", "--with", "fastmcp", "fastmcp", "run", "C:\\Users\\kord\\Code\\mcptest\\weather.py" ] } } } They (the exuberant authors) do mention transport—stdio and HTTP with SSE—but that just highlights the confusion here we are seeing. A real protocol doesn’t care how it’s transported, or it defines the transport clearly. MCP tries to do both and ends up muddying the boundaries. And the auth situation? It waves toward OAuth2.1, but offers almost zero clarity on implementation, trust delegation, or actual enforcement. It’s a rats nest waiting to unravel once people start pushing for real-world deployments that involve state, identity, or external APIs with rate limits and abuse vectors. This feels like yet another centralized spec written for one ecosystem (TypeScript AI crap), claiming universality without earning it. And let’s talk about streaming vs formatting while we’re at it. MCP handwaves over the reality that content coming in from a stream (like SSE) has totally different requirements than a local response. When you’re streaming partials from a model and interleaving tool calls, you need a very well-defined contract for how to chunk, format, and parse responses—especially when tools return mid-stream or you’re trying to do anything interactive. Right now, only a few clients are actually supported (Anthropic’s Claude, Copilot, OpenAI, and a couple local LLM projects). But that’s not a bug—it’s the feature. The clients are where the value capture is. If you can enforce that tools, prompts, and context management only work smoothly inside your shell, you keep devs and users corralled inside your experience. This isn’t open protocol territory; it’s marketing. Dev marketing dressed up as protocol design. Give them a “standard” so they don’t ask questions, then upsell them on hosted toolchains, orchestrators, and AI-native IDEs later. The LLM is the bait. The client is the business. And yes, Claude helped write this, but it's exactly what I would say if I had an hour to type it out clearly.

pgt 2y ago

MCP is just a transport + wire format with request/response lifecycle and most importantly: tool-level authorization. The essay misses the biggest problem with MCP: 1. it does not enable AI agents to functionally compose tools. 2. MCP should not exist in the first place. LLMs already know how to talk to every API that documents itself with OpenAPI specs, but the missing piece is authorization. Why not just let the AI make HTTP requests but apply authorization to endpoints? And indeed, people are wrapping existing APIs with thin MCP tools. Personally, the most annoying part of MCP is the lack of support for streaming tool call results. Tool calls have a single request/response pair, which means long-running tool calls can't emit data as it becomes available – the client has to repeat a tool call multiple times to paginate. IMO, MCP could have used gRPC which is designed for streaming. Need an onComplete trigger. I'm the author of Modex[^1], a Clojure MCP library, which is used by Datomic MCP[^2]. [^1]: Modex: Clojure MCP Library – https://github.com/theronic/modex https://github.com/theronic/modex [^2]: Datomic MCP: Datomic MCP Server – https://github.com/theronic/datomic-mcp/ https://github.com/theronic/datomic-mcp/

keithwhor 2y ago
I mean you don’t need gRPC. You can just treat all tool calls as SSEs themselves and you have streaming. HTTP is pretty robust.
- pgt 2y ago
  HTTP Server-Sent Events (SSE) does not natively support batched streaming with explicit completion notifications in its core specification.
cruffle_duffle 2y ago
There are plenty of things out there that don’t use OpenAPI. In fact most things aren’t. Even if the universe was all OpenAPI, you’d still need a lower level protocol to define exactly how the LLM reaches out of the box and makes the OpenAPI call in the first place. That is what MCP does. It’s the protocol for calling tools. It’s not perfect but it’s a start.

RKFADU_UOFCCLEL 2y ago

I don't see the problem. I've just been using services with 3 - 10 verbs that the agent can use without adding any that can do harmful things. Even when they have no auth mechanism I can just put a temporary token in the URL.

K7mR2vZq 2y ago

[dead]

emorning3 2y ago

Anybody remember OSGi? I can imagine a plugin-based server where the plugins are applications and AIs that all use MCP to interact. The server would add a discovery protocol. That seems like the perfect use for MCP.

CamperBob2 2y ago

TL,DR: "MCP is powerful enough to do useful things. That's not OK. Somebody might get hacked."