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

131–140 of 348 posts

Re: A critical look at MCP

#131

Post by volemo »

ethbr1 wrote: post #85
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…

> Give it more than a couple months though and I think we'll see it mature some more. Or like the early Python ecosystem, mistakes will become ossified at the bottom layers of the stack, as people rapidly build higher level tools that depend on them. Except unlike early Python, the AI ecosystem community has no excuse, BECAUSE THERE ARE ALREADY HISTORICAL EXAMPLES OF THE EXACT MISTAKES THEY'RE MAKING.

Could you throw on a couple of examples of calcified early mistakes of Python? GIL is/was one, I presume?

Re: A critical look at MCP

#132

Post by taocoyote »

mattw1810 wrote: post #127

MCP should just have been stateless HTTP to begin with. There is no good reason for almost any of the servers I have seen to be stateful at the request/session level —- either the server carries the state globally or it works fine with a session identifier of some sort.

I don't understand the logistics of MCP interactions. Can anyone explain why they aren't stateless. Why does a connection need to be held open?

Re: A critical look at MCP

#133

Post by Doxin »

volemo wrote: post #131
ethbr1 wrote: post #85

Earlier quoted context omitted.

> Give it more than a couple months though and I think we'll see it mature some more. Or like the early Python ecosystem, mistakes will become ossified at the bottom layers of the stack, as people rapidly build higher level tools that depend on them. Except unlike early Python, the AI ecosystem community has no excuse, BECAUSE THERE ARE ALREADY HISTORICAL EXAMPLES OF THE EXACT MISTAKES THEY'RE MAKING.

Could you throw on a couple of examples of calcified early mistakes of Python? GIL is/was one, I presume?

Possibly packaging too? though lately that has improved to the point where I'd not really consider it ossified at all.

Re: A critical look at MCP

#134

Post by mattw1810 »

taocoyote wrote: post #132
mattw1810 wrote: post #127

MCP should just have been stateless HTTP to begin with. There is no good reason for almost any of the servers I have seen to be stateful at the request/session level —- either the server carries the state globally or it works fine with a session identifier of some sort.

I don't understand the logistics of MCP interactions. Can anyone explain why they aren't stateless. Why does a connection need to be held open?

I think some of the advanced features around sampling from the calling LLM could theoretically benefit from a bidirectional stream.

In practice, nobody uses those parts of the protocol (it was overdesigned and hardly any clients support it). The key thing MCP brings right now is a standardized way to discover & invoke tools. This would’ve worked equally well as a plain HTTP-based protocol (certainly for a v1) and it’d have made it 10x easier to implement.

Re: A critical look at MCP

#135

Post by fendy3002 »

baxtr wrote: post #99
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…

To this date I have not found a good explanation what an MCP is. What is it in old dev language?

If you know JSON-RPC: it's a JSON-RPC wrapper exposed for AI use and discovery.

If you know REST / http request:

it's single endpoint-only, partitioned / routed by single "type" or "method" parameter, with some different specification, for AI.

Re: A critical look at MCP

#136

Post by 9dev »

oxidant wrote: post #65
_QrE wrote: post #33

Agreed with basically the entire article. Also happy to hear that someone else was as bewildered as me when they visited the MCP site and they found nothing of substance. RFCs can be a pain to read, but they're much better than 'please just use our SDK library'.

I wish there was a clear spec on the site but there isn't https://modelcontextprotocol.io/specification/2025-03-26 It seems like half of it is Sonnet output and it doesn't describe how the protocol actually works. For all its warts, the GraphQL spec is very well written https://spec.graphql.org/October2021/

I didn’t believe you before clicking the link, but hot damn. That reads like the ideas I scribbled down in school about all the cool projects I could build. There is literally zero substance in there. Amazing.

Re: A critical look at MCP

#138

Post by lo0dot0 »

mattw1810 wrote: post #127

MCP should just have been stateless HTTP to begin with. There is no good reason for almost any of the servers I have seen to be stateful at the request/session level —- either the server carries the state globally or it works fine with a session identifier of some sort.

I don't claim to have a lot of experience on this but my intuition tells me that a connection that ends after the request needs to be reopened for the next request. What is more efficient, keeping the session open or closing it, depends on the usage pattern, how much memory does the session consume, etc. etc.

Re: A critical look at MCP

#139

Post by pixl97 »

Scotrix wrote: post #116
pixl97 wrote: post #70

Earlier quoted context omitted.

I mean isn't this the point of a lot of, if not most successful software? Abstracting away the complexity making it feel easy, where most users of the software have no clue what kind of technical debt they are adopting? Just think of something like microsoft word/excel for most of its existence. Seems easy to the end user, but attempting to move away from it was complex, the format had binary objects that were hard t…

yeah, but it doesn’t need to be that way. It can be simple and makes it easier adoptable, why over engineering and reinventing the wheel of at least 2 decades experience and better practices.

Simple software is the most difficult software to make.

Historically stated as

>I apologize for such a long letter - I didn't have time to write a short one.

Re: A critical look at MCP

#140

Post by mattw1810 »

lo0dot0 wrote: post #138
mattw1810 wrote: post #127

MCP should just have been stateless HTTP to begin with. There is no good reason for almost any of the servers I have seen to be stateful at the request/session level —- either the server carries the state globally or it works fine with a session identifier of some sort.

I don't claim to have a lot of experience on this but my intuition tells me that a connection that ends after the request needs to be reopened for the next request. What is more efficient, keeping the session open or closing it, depends on the usage pattern, how much memory does the session consume, etc. etc.

This is no different from a web app though, there’s no obvious need to reinvent the wheel. We know how to do this very very well: the underlying TCP connection remains active, we multiplex requests, and cookies bridge the gap for multi-request context. Every language has great client & server support for that.

Instead we ended up with a protocol that fights with load balancers and can in most cases not just be chucked into say an existing Express/FastAPI app.

That makes everything harder (& cynically, it creates room for providers like Cloudflare to create black box tooling & advertise it as _the_ way to deploy a remote MCP server)

Post reply on HN