Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A critical look at MCP

raz.sh

Post reply on HN
Print view View original

21–30 of 348 posts

Re: A critical look at MCP

#21

Post by _raz »

runekaagaard wrote: post #18
justanotheratom wrote: post #3

It is indeed quite baffline why MCP is taking off, but facts are facts. I would love to be enlightened how MCP is better than an OpenAPI Spec of an existing Server.

I thinks a lot is timing and also that it's a pretty low bar to write your first mcp server: from mcp.server.fastmcp import FastMCP mcp = FastMCP("Basic Math Server") @mcp.tool() def multiply(a: int, b: int) -> int: return a * b mcp.run() If you have a large MCP server with many tools the amount of text sent to the LLM can be significant too. I've found that Claude works great with an OpenAPI spec if you provide it w…

That's kind of my point, that the protocols complexity is hidden in py sdk making it feel easy... But taking on large tech dept

Re: A critical look at MCP

#22

Post by _raz »

MuffinFlavored wrote: post #19
hirsin wrote: post #13

In the same way that crypto folks speedran "why we have finance regulations and standards", LLM folks are now speedrunning "how to build software paradigms". The concept they're trying to accomplish (expose possibly remote functions to a caller in an interrogable manner) has plenty of existing examples in DLLs, gRPC, SOAP, IDL, dCOM, etc, but they don't seem to have learned from any of them, let alone be aware that t…

Isn't MPC based on JSON-RPC?

Yes, the protocol seems fine to me in and of itself. It's the transport portion that seems to be a dumpster fire on the HTTP side of things.

Re: A critical look at MCP

#23

Post by rvz »

> However, I'm astonished by the apparent lack of mature engineering practices.

Exactly.

MCP is one of the worst 'standards' that I have seen come out from anywhere since JSON Web Tokens (JWTs) and the author rightfully points out the lack of engineering practices of a 'standard' that is to be widely used like any properly designed standard with industry-wide input.

> Increased Attack Surface: The multiple entry points for session creation and SSE connections expand the attack surface. Each entry point represents a potential vulnerability that an attacker could exploit.

JWTs have this same issue with multiple algorithms to use including the horrific 'none' algorithm. Now we have a similar issue with MCP with multiple entry points to chose from which is more ways to attack the protocol.

This one is the most damning.

> Python and JavaScript are probably one of the worst choices of languages for something you want to work on anyone else's computer. The authors seem to realize this since all examples are available as Docker containers.

Another precise point and I have to say that our industry is once again embracing the worst technologies to design immature standards like this.

The MCP spec appears to be designed without consideration for security or with any input from external companies like a normal RFC proposal should and is quite frankly repeating the same issues like JWTs.

Re: A critical look at MCP

#24

Post by foobarian »

_raz wrote: post #22
MuffinFlavored wrote: post #19

Earlier quoted context omitted.

Isn't MPC based on JSON-RPC?

Yes, the protocol seems fine to me in and of itself. It's the transport portion that seems to be a dumpster fire on the HTTP side of things.

Must have used GraphQL as a role model no doubt

Re: A critical look at MCP

#25

Post by immibis »

hirsin wrote: post #20
MuffinFlavored wrote: post #19

Earlier quoted context omitted.

Isn't MPC based on JSON-RPC?

Indeed! But seemingly only for the actual object representation - it's a start, and I wonder if JSON is uniquely suited to LLMs because it's so text-first.

I understand those with experience have found that XML works better because it's more redundant.

Re: A critical look at MCP

#26

Post by sitkack »

hirsin wrote: post #20
MuffinFlavored wrote: post #19

Earlier quoted context omitted.

Isn't MPC based on JSON-RPC?

Indeed! But seemingly only for the actual object representation - it's a start, and I wonder if JSON is uniquely suited to LLMs because it's so text-first.

Hey, at least they didn't use yaml-rpc.

Re: A critical look at MCP

#27

Post by _raz »

sitkack wrote: post #26
hirsin wrote: post #20

Earlier quoted context omitted.

Indeed! But seemingly only for the actual object representation - it's a start, and I wonder if JSON is uniquely suited to LLMs because it's so text-first.

Hey, at least they didn't use yaml-rpc.

toml-rpc anyone? :)

Re: A critical look at MCP

#28

Post by matchagaucho »

hirsin wrote: post #13

In the same way that crypto folks speedran "why we have finance regulations and standards", LLM folks are now speedrunning "how to build software paradigms". The concept they're trying to accomplish (expose possibly remote functions to a caller in an interrogable manner) has plenty of existing examples in DLLs, gRPC, SOAP, IDL, dCOM, etc, but they don't seem to have learned from any of them, let alone be aware that t…

Also missing in these strict, declarative protocols is a reliance on latent space, and the semantic strengths of LLMs.

Is it sufficient to put a agents.json file in the root of the /.well-known web folder and let agents just "figure it out" through semantic dialogue?

This forces the default use of HTTP as Agent stdio.

Re: A critical look at MCP

#29

Post by neuroelectron »

hirsin wrote: post #20
MuffinFlavored wrote: post #19

Earlier quoted context omitted.

Isn't MPC based on JSON-RPC?

Indeed! But seemingly only for the actual object representation - it's a start, and I wonder if JSON is uniquely suited to LLMs because it's so text-first.

I think JSON is preferred because it adds more complexity.

Re: A critical look at MCP

#30

Post by triyambakam »

neuroelectron wrote: post #7

MCP is the moat to keep small players outside of the AI market. Not only does implementing it require a team, it is a tarpit of sabotage, where logging and state are almost impossible to track.

Have you tried it though? There are sdks where you can set up logging and MCP server or client in a few lines. Pydantic AI and Logfire as one example
Post reply on HN