Hacker News Reader

Comment by drdaeman | Hacker News Reader

> Until that changes

MCP is just JSON RPC API dialect. It is not "safe" or "unsafe" by design - it's a layer where notion of safety (as talked about in the article) is not applicable. Saying that "MCP is unsafe" is not a meaningful statement in the scope of what MCP is. Nothing about any RPC (by itself) can guarantee that the remote system would do or not do something when some method is invoked.

Unless someone figures out a way to make end-user comprehensible language for formal software verification, so there could be an accompanying spec that describes the behavior to the dot, and technology that validates the implementation against the spec.

Right now the only spec is the actual codebase, and most users aren't typically reviewing that at all.

View on HN

It isn't just an RPC spec, it's a use case. Specs never exist without a reason. I can assure you, a spec is a lot of work to write. You don't do it unless there is a purpose.

And with MCP, that purpose is fundamentally unsafe. It cannot be done safely without a different underlying technology. So yeah, it's pretty fair to say MCP is unsafe by design. It wouldn't exist except for that desire to create systems which cannot be secure.

MCPs are just fancy wrappers over rest apis, at least majority of the MCP servers out in the market are like that.

Having an MCP necessarily does not mean it is unsafe until and unless the company rushed execution and released something which it should not have in the first place.

Sorry, I don’t understand. My understanding of what MCP is - is that it’s just a standard on how to provide tools/functions to LLMs to call. What those functions are, what they do, and what else happens when they’re called is - in my understanding - out of scope of MCP. To me MCP is literally a plumbing between black boxes, and plumbing cannot do anything about the safety of what happens outside of it. So to me MCP is not “safe” or “unsafe” - those terms are meaningless for a plumbing (as long, of course, as plumbing itself doesn’t somehow explode or connect somewhere it’s not supposed to or stuff like that). Do you mean the purpose and/or scope are different somehow?

> My understanding of what MCP is - is that it’s just a standard on how to provide tools/functions to LLMs to call.

That's exactly the point the GP was making: this is a fundamentally unsafe idea. It's impossible to allow an LLM to automatically run tools in a safe way. So yes, MCP as means to enable this fundamentally unsafe use case is fundamentally unsafe.

My point is that the term “safe” is not a good one. In context of the article it erodes the scope of what MCP is and what it does (bringing way more stuff into the picture) and misattributes issue.

MCP safety is stuff like access controls, or lack of vulnerabilities on the protocol level (stuff like XML entity bombs). Software behavior of what MCP bridges together is not MCP anymore.

People discovering and running malware believing it’s legit is not a MCP problem. This line of thought is based on that “P” stands for “protocol” - MCP is interface, not implementation. And it’s humans who pick and connect programs (LLMs and MCP servers), not technology.

Not an XML bomb, but... at the protocol level, AFAIK, MCP allows the server to change its list of tools and what they do, and the description of what they do, at any point. The chatbot when it starts up, calls "tools/list" and gets a list of tools. So, if "approval for use" depends on that data, .. the approval is built on something that can shift at any time.

That, coupled with dynamic invocation driven by the LLM engine, seems like a security problem at the protocol level.

-----

Contrast to connecting an agent to a service that is defined by a spec. In this hypothetical world, I can tell my agent: "here's the spec and here's the endpoint that implements it". And then my agent will theoretically call only the methods in the spec. The endpoint may change, my spec won't.

I still need to trust the endpoint; that it's not compromised. Maybe I'm seeing a difference where there is none.

You’re correct. MCP is just a defined way of mapping string descriptions to functions.

I thought about it, and I think I know what the confusion could possibly be about.

To me, postmark-mcp is not a part of MCP, it’s a black box that talks MCP on one end. And its behavior is not an MCP but software trust and distribution issue, not specific to MCP (just like running any executables from random sources). I guess others may see differently.

Right but you have a good security posture and hygiene. MCP as a use case (not a protocol) is encouraging risky usage by less security minded people.

I was more referring to the environment that MCP servers run within, which at the end of the day is simply a massive interpolated string that blends instructions and data/content together in a way that an LLM will do its best to figure out a helpful response.

A 'perfectly secured' MCP server will become insecure simply by existing along neighbouring, insecure, tools. With that, I think it's safe to take a broader, less technical definition and say that you should use AI agents + MCP servers with caution.

Reply on news.ycombinator.com