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

251–260 of 348 posts

Re: A critical look at MCP

#251

Post by brabel »

FridgeSeal wrote: post #209
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.

Hey there, expecting basically literacy or comprehension out of a sub-industry seemingly dedicated to minimising human understanding and involvement is bridge too far. Clearly if these things are problems, AI will simply solve them, duhhh. /s

You joke, but with the right prompt, I am almost certain that an LLM would've written a better spec than MCP. Like others said, there are many protocols that can be used as inspiration for what MCP tries to achieve, so LLMs should "know" how it should be done... which is definitely NOT by using SSE and a freaking separate "write" endpoint.

Re: A critical look at MCP

#252

Post by brabel »

krackers wrote: post #208
fendy3002 wrote: post #135

Earlier quoted context omitted.

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.

Wasn't the point of REST supposed to be runtime discoverability though? Of course REST in practice just seems to be json-rpc without the easy discoverability which seems to have been bolted on with Swagger or whatnot. But what does MCP do that (properly implemented) REST can't?

> Of course REST in practice just seems to be json-rpc

That's so wrong. REST in practice is more like HTTP with JSON payloads. If you find anything similar to json-rpc calling itself REST just please ask them politely to stop doing that.

Re: A critical look at MCP

#253

Post by TheOtherHobbes »

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…

It's a classic Worse is Better situation.

Most users don't care about the implementation. They care about the way that MCP makes it easier to Do Cool Stuff by gluing little boxes of code together with minimal effort.

So this will run ahead because it catches developer imagination and lowers cost of entry.

The implementation could certainly be improved. I'm not convinced websockets are a better option because they're notorious for firewall issues, which can be showstoppers for this kind of work.

If the docs are improved there's no reason a custom implementation in Go or Arm assembler or whatever else takes your fancy shouldn't be possible.

Don't forget you can ask an LLM to do this for you. God only knows what you'll get with the current state of the art, but we are getting to the point where this kind of information can be explored interactively with questions and AI codegen, instead of being kept in a fixed document that has to be updated manually (and usually isn't anyway) and hand coded.

Re: A critical look at MCP

#254

Post by tdullien »

aristofun wrote: post #114

This is a part of the bigger problem. Near all of AI is done by mathematicians, (data) scientists, students and amateur enthusiasts. Not by professional software engineers. This is why nearly everything looks like a one weekend pet project by the standards of software engineering.

As a trained mathematician with 20+ years shipping software products, I object to this.

A lot of AI work is done by people that "dash-shaped" -- broad, but with no depth anywhere.

Then there's a few I-shaped people that drive research progress, and a few T-shaped people that work on the infrastructure that allows the training runs to go through.

But something like a protocol will certainly be designed by a dash, not an I or a T, because those are needed to keep the matrices multiplying.

Re: A critical look at MCP

#255

Post by brabel »

mattw1810 wrote: post #134
taocoyote wrote: post #132

Earlier quoted context omitted.

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’…

> This would’ve worked equally well as a plain HTTP-based protocol

With plain HTTP you can quite easily "stream" both the request's and the response's body: that's a HTTP/1 feature called "chunking" (the message body is not just one byte array, it's "chunked" so that each chunk can be received in sequence). I really don't get why people think you need WS (or ffs SSE) for "streaming". I've implemented a chat using just good old HTTP/1.1 with chunking. It's actually a perfect use case, so it suits LLMs quite well.

Re: A critical look at MCP

#256

Post by taylorius »

lolinder wrote: post #200
comradesmith wrote: post #196

Earlier quoted context omitted.

What’s the problem? Can you point out a specific thing you would change from that quote?

Are you a native English speaker? "does NOT constrain user's rate limit" should be "does NOT rate limit incoming requests" or similar. "We will try out best" should be "our best". "when our servers are under high traffic pressure" is at least grammatical, but it's awkward. Normally you'd say "when our servers are dealing with high load" or something similar. "your requests may take some time to receive a response fro…

I'm a native English speaker, and I partially disagree with your claims of awkwardness.

"when our servers are under high traffic pressure" - this is a bit awkward I agree, but only the last three words.

If we rearrange it to "when our servers are under pressure from high traffic", I think it sounds good. It's using a metaphor, and I think that should be encouraged. It's interesting. And the phrase "high traffic" conveys some drama.

"your requests may take some time to receive a response from the server" - I think that's fine, to be honest. I like it.

I think you are conflating "awkwardness" with linguistic flair. Technical documentation English has become standardised to a large degree, which of course is useful, and efficient. But it is also a narrow usage of English, and breaking out of its straitjacket does not make language awkward.

Re: A critical look at MCP

#257

Post by stuaxo »

There is so much stuff like this right now:

I have a similar feeling looming at the converse API.

Why, do we have a thing that keeps returning all the text, when something on the other end is just appending to it.

Then there is the code inside langchain, some of which feels rushed.

I'm unconvinced of the abstraction that everything is a "Document". In an app I'm working on, once we switched to PGVector in Django the need for a lot of things went away.

What is great with langchain is the support for lots of things.. but not everything.

So, wanting to always use a thin abstraction over native libraries we find ourself using litellm, which covers some bits and langchain for the others (though the code for both of those is not much).

And then there's models: we can't even agree on standard names for the same models.

And this makes it painful when you support different backends, of course if Bedrock is a backend they have their own models you can't use anywhere else.

Re: A critical look at MCP

#258

Post by stuaxo »

ljm wrote: post #185
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…

Sometimes I wonder if I have ADHD or if it's induced by the content, because I can spend hours soaking up interesting literature and putting my weird thoughts down onto paper but I can barely make it a few words through LLM-driven drivel. It's crazy seeing bots posting AITA rage bait on Reddit that always follows the same pattern: some inter-personal conflict that escalates to a wider group: "I told my husband I wasn…

Yeah it's unreadable for me.

There's been a trend to post LLM slop about tech subjects and they anger me - I don't know why someone wanted to waste people's time like that.

Even worse - I've come across an AI slop site that masquerades as dev information, with just plain wrong information.

Re: A critical look at MCP

#259

Post by stuaxo »

__loam wrote: post #86
dlandis wrote: post #45

Earlier quoted context omitted.

Agree... this is an important blog. People need to press pause on MCP in terms of adoption...it was simply not designed with a solid enough technical foundation that would make it suitable to be an industry standard. People are hyped about it, kind of like they were for LangChain and many other projects, but people are going to gradually (after diving into implementations) that it's not actually what they were lookin…

The Langchain repo is actually hilariously bad if you ever go read the source. I can't believe they raised money with that crap. Right place right time I guess.

My first surprise on it:

I made an error trying with aws bedrock where I used "bedrock" instead of "bedrock-runtime".

The native library will give you an error back.

Langchain didn't try and do anything, just kept parsing the json and gave me a KeyError.

I was able to get a small fix, but was surprised they have no error like ConfigurationError that goes across all their backends at all.

The best I could get them to add was ValueError and worked with the devs to make the text somewhat useful.

But was pretty surprised, I'd expect a badly configured endpoint to be the kind of thing that happens when setting stuff up for the first time, relatively often.

Re: A critical look at MCP

#260

Post by ricardobeat »

taylorius wrote: post #256
lolinder wrote: post #200

Earlier quoted context omitted.

Are you a native English speaker? "does NOT constrain user's rate limit" should be "does NOT rate limit incoming requests" or similar. "We will try out best" should be "our best". "when our servers are under high traffic pressure" is at least grammatical, but it's awkward. Normally you'd say "when our servers are dealing with high load" or something similar. "your requests may take some time to receive a response fro…

I'm a native English speaker, and I partially disagree with your claims of awkwardness. "when our servers are under high traffic pressure" - this is a bit awkward I agree, but only the last three words. If we rearrange it to "when our servers are under pressure from high traffic", I think it sounds good. It's using a metaphor, and I think that should be encouraged. It's interesting. And the phrase "high traffic" conv…

That’s a very generous interpretation. I don’t know mandarin but these are likely a transfer of grammar constructs from the primary language to english, in the same way the Dutch will say “make a picture” or “the house of my parents”, which can be justly classified as awkward rather than as linguistic flair.

If someone was editing my writing, it would feel a bit patronizing if they said grammar mistakes (many of which come from my mother tongue Portuguese) are “adding flair”, as they are not a stylistic choice.

Post reply on HN