Everything wrong with MCP

Posted by sshh12 4/13/2025

516 points | 223 commentspage 4

novoreorx 4/14/2025|

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

_pdp_ 4/14/2025|

Like IE6?

seinecle 4/14/2025||

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

seuros 4/14/2025||

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

sshh12 4/14/2025|

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 4/14/2025||

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 4/14/2025||

A lot of servers don't use the stdio transport.

totaldude87 4/14/2025||

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

simonw 4/14/2025||

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

the_arun 4/14/2025||

So, is MCP a spec for tool calling API?

pizza 4/14/2025|||

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.

simonw 4/14/2025||||

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 4/14/2025|||

it's more than just tools. there're prompts & resources too

sshh12 4/14/2025||

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

sixhobbits 4/14/2025||

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.

cratermoon 4/14/2025||

"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.

throw1290381290 4/14/2025||

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

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 4/14/2025||

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.

sshh12 4/14/2025|||

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.

mickael-kerjean 4/14/2025|||

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" and play around

fnordpiglet 4/14/2025|||

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 4/14/2025||

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 4/14/2025||

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?

jacobr1 4/14/2025|||

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.

fnordpiglet 4/15/2025||

Ok fair enough - effectively there needs to be an authorization propagation channel that is systematic and bypasses the LLM and probabilistic layers through to each endpoint through the server. The issue isn’t the MCP server and client themselves but that there’s no clear and defined way to pass authZ through to the other side. AuthN should be handled at the interface and the AuthZ propagation is the crucial missing piece. Right?

jacobr1 4/15/2025||

Yep - that is my take. It isn't a weakness of MCP as such, but it a gap for which no good tooling exists afaik.

mehdibl 4/14/2025|||

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 4/14/2025||

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.

chrisweekly 4/14/2025||

great analogy

rglover 4/14/2025||

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).

pizza 4/14/2025||

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 4/14/2025||

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 4/15/2025||

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 4/14/2025|||

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.

otabdeveloper4 4/14/2025||

> It's so over

> We are so back

kordlessagain 4/14/2025||

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.

K7mR2vZq 4/14/2025|

[dead]

More comments...