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

311–320 of 348 posts

Re: A critical look at MCP

#311

Post by collingreen »

jdlshore wrote: post #187
jgalt212 wrote: post #168

Earlier quoted context omitted.

it is amazing we used to prize determinism, but now it's like determinism is slowing me down. I mean how do you even write test cases for LLM agents. Do you have another LLM judge the results as close enough, or not close enough?

Yes, and you have to do it in a loop on every request. Not joking. It’s called “LLM as judge.”

What an amazing business to convince people to use. Making people pay to use LLMs to supervise the LLMs they pay for in order to get decent results is diabolically genius.

At the risk of offending some folks it feels like the genius of the Mormon church making its "customers" pay the church AND work for it for free AND market it for free in person AND shame anyone who wants to leave. Why have cost centers if you don't have to!

It's a business model I wasn't smart or audacious enough to even come up with.

Re: A critical look at MCP

#312

Post by somnium_sn »

Hey, I am one of the MCP authors.

We appreciate the criticism and take it very seriously. We know things are not perfect and there is lots of room for improvement. We are trying to balance the needs of the fast paced AI world, and the careful, time consuming needs of writing a spec. We’d love to improve the spec and the language, and would of course appreciate help here. We also work with an increasingly larger community that help us get this right. The most recent Authorization specification changes are just one example.

Similarly we are working on the SDKs and other parts of MCP to improve the ecosystem. Again, it’s all very early and we appreciate help from the community.

Re: A critical look at MCP

#313

Post by jgalt212 »

collingreen wrote: post #311
jdlshore wrote: post #187

Earlier quoted context omitted.

Yes, and you have to do it in a loop on every request. Not joking. It’s called “LLM as judge.”

What an amazing business to convince people to use. Making people pay to use LLMs to supervise the LLMs they pay for in order to get decent results is diabolically genius. At the risk of offending some folks it feels like the genius of the Mormon church making its "customers" pay the church AND work for it for free AND market it for free in person AND shame anyone who wants to leave. Why have cost centers if you don'…

It's a bit like paying more for AWS logging services than for the AWS services that provide the services your customers actually consume.

Re: A critical look at MCP

#314

Post by Kiro »

mrcsharp wrote: post #202

> "In HTTP+SSE mode, to achieve full duplex, the client sets up an SSE session to (e.g.) GET /sse for reads. The first read provides a URL where writes can be posted. The client then proceeds to use the given endpoint for writes, e.g., a request to POST /a-endpoint?session-id=1234. The server returns a 202 Accepted with no body, and the response to the request should be read from the pre-existing open SSE connection…

What benefit are WebSockets providing? It's the same. You send something to one endpoint and need to listen for a response in another handler.

Re: A critical look at MCP

#315

Post by jacob019 »

ximus wrote: post #309
jacob019 wrote: post #304

The consensus around here seems to be that the protocol itself is fine, but the transport is controversial. Personally, even the stdio transport feels suboptimal. I mostly write python and startup time for a new process is nontrivial. Starting a new process for each request doesn't feel right. It works ok, and I'll admit that there's a certain elegance to it. It would be more practical if I were using a statically co…

> Starting a new process for each request doesn't feel right. I think there is a misunderstanding of how stdio works. The process can be long running and receive requests via stdio at any time. No need to start one for each request.

Sure, but that is not what I'm seeing in FastMCP proxy mode, and it can only talk with the parent process. You make a good point though, stdio is similar to tcp sockets and cross-platform without namespace issues, but can only support one client per process. I could use socat if I want it to talk sockets.

Re: A critical look at MCP

#316

Post by pelagicAustral »

somnium_sn wrote: post #312

Hey, I am one of the MCP authors. We appreciate the criticism and take it very seriously. We know things are not perfect and there is lots of room for improvement. We are trying to balance the needs of the fast paced AI world, and the careful, time consuming needs of writing a spec. We’d love to improve the spec and the language, and would of course appreciate help here. We also work with an increasingly larger commu…

AI post

Re: A critical look at MCP

#317

Post by somnium_sn »

pelagicAustral wrote: post #316
somnium_sn wrote: post #312

Hey, I am one of the MCP authors. We appreciate the criticism and take it very seriously. We know things are not perfect and there is lots of room for improvement. We are trying to balance the needs of the fast paced AI world, and the careful, time consuming needs of writing a spec. We’d love to improve the spec and the language, and would of course appreciate help here. We also work with an increasingly larger commu…

AI post

Literally hand written. Maybe I just sound like an AI. Who knows

Re: A critical look at MCP

#318

Post by svachalek »

9dev wrote: post #136
oxidant wrote: post #65

Earlier quoted context omitted.

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.

I thought it was just me. When I first saw all the hype around MCP I went to go read this mess and still have no idea what MCP even is.

Re: A critical look at MCP

#319

Post by 827a »

ComplexSystems wrote: post #188
lolinder wrote: post #165

> the documentation is poorly written (all LLM vendors seem to have an internal competition in writing confusing documentation). This is almost certainly because they're all using LLMs to write the documentation, which is still a very bad idea. The MCP spec [0] has LLM fingerprints all over it. In fact, misusing LLMs to build a spec is much worse than misusing them to avoid writing good docs because when it comes to…

DeepSeek's documentation has a different problem, which is that there are spelling errors and weird grammatical constructions everywhere: "DeepSeek API does NOT constrain user's rate limit. We will try out best to serve every request. However, please note that when our servers are under high traffic pressure, your requests may take some time to receive a response from the server. During this period, your HTTP request…

Similarly strange and incorrect grammatical constructions are found in the English translations for Game Science’s hit game Black Myth Wukong. My expectations for, for example, the construction manual for a bookshelf is pretty different than a game or AI model & service costing tens of millions of dollars in development (or more).

Heck, they could literally pay any native English speaker to take their English-ish translations and regionalize them; you don’t even need to know Chinese to fix those paragraphs. Why is this such a common problem with the English China exports? Is it cultural? Are they so disconnected from the west that they don’t realize?

A great counter-example is NetEase’s Marvel Rivals; their English translations are fantastic, and even their dev interviews with their Chinese development team is fantastically regionalized. They make a real effort to appeal to English audiences.

Re: A critical look at MCP

#320

Post by aerhardt »

Timwi wrote: post #207
volemo wrote: post #131

Earlier quoted context omitted.

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

Static functions (len, map/filter,...) that should have been methods on objects.

What’s the root cause?

It certainly makes functional semantics in Python suck. Comprehensions don’t make up for it.

Post reply on HN