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

271–280 of 348 posts

Re: A critical look at MCP

#271

Post by ethan_smith »

_heimdall wrote: post #46

I haven't dug too deeply into MCP yet so I may very well be wrong here, but it feels like get another attempt to paper over the fact that we abandoned REST APIs nearly 20 years ago. XML is ugly and building APIs that describe both the data and available actions is tough. Instead we picked JSON RPCs that we still call REST, and we inevitably run into situations like Alexa or LLMs where we want a machine to understand…

OpenAPI/Swagger already solves the machine-discoverable API problem MCP is attempting to address, with years of maturity and tooling support. The real innovation needed isn't yet another protocol but better LLM understanding of existing API description formats.

Re: A critical look at MCP

#272

Post by nyclounge »

> “RPC-like use of WebSocket adds overhead” – Actually, WebSocket reduces overhead in high-frequency RPC-like interactions by keeping a persistent connection.

Is this really true? Thought the whole reason to use SSE is that it is more lightweight than WebSocket?

Re: A critical look at MCP

#273

Post by fnord123 »

reliabilityguy wrote: post #216
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…

> "Our response times may be slower" would be more natural. How can the time be slower? Response times may be longer, but not slower

When you remark on improvements, up is generally better and down is generally worse. So saying "response times will be higher" gives an immediate sentiment of improvement. But, obviously, a moments thinking helps you re-orient and realize it's better. This is why plots often have "lower is better" in the legend, to help readers understand.

I often use 'slower' and 'faster' as a native speaker to help reinforce the meaning of the direction.

Re: A critical look at MCP

#274

Post by fullstackchris »

Well... if the author wants websockets, why doesn't the author just do it? They state clearly in pull request the community is totally free to make their own.

My guess is one will crop up within the next few months...

Speaking from the TypeScript side of things...

I will say the documentation is indeed garbage - it still includes code snippets of APIs / source code examples that don't exist anymore. Also, the choice to use zod types is also in my opinion, way over the top... the fact that I need to import a third party library to write a MCP server is wild - when you're already writing in a typed language (TypeScript)... (and yes I know the other advantages zod provides)

Otherwise it's simple enough to get started, if just tinkering around.

Re: A critical look at MCP

#275

Post by k__ »

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…

That text would be cut to at least half its length by an editor.

Re: A critical look at MCP

#276

Post by taylorius »

ricardobeat wrote: post #260
taylorius wrote: post #256

Earlier quoted context omitted.

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

I'm not claiming it was intentional on their part. My point was solely one of language, so how the sentence came to be written that way is out of scope. And given the word swap I suggested, I don't think it is awkward at all (unlike your examples from Dutch, which definitely are).

As for it being patronising, why is telling a non-native speaker their sentence is interesting unacceptable, but telling them it's awkward is ok? (Assuming both are genuinely held opinions).

I'll reiterate my point that common English usage (non-awkward?) has narrowed enormously in the last 50 years. I think that this is a bad thing.

Re: A critical look at MCP

#277

Post by meindnoch »

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…

That's just standard Chinglish.

Re: A critical look at MCP

#278

Post by kgeist »

Why can't it just be an OpenAPI spec and standard HTTP requests? Can't AI already figure out which endpoints to call on its own? The whole Streamable HTTP approach feels like premature optimization. Is there something else to it?

Re: A critical look at MCP

#279

Post by Sammi »

bsenftner wrote: post #270

I'll say it: MPC is immature trash, and will be replaced with... nothing. It is not needed, nor necessary if one has any functional engineering experience. It's yet another poorly considered distraction created by the software industry that cannot tie it's own shoes.

MPC is a poor way of doing function calls or web requests, when you could just do function calls or web requests.

I'd love to be wrong, but the more I learn about MCP the more I fear that I'm right.

Re: A critical look at MCP

#280

Post by noor_z »

One advantage of MCP being "inspired by" LSP, at least to people like myself who work on LSP tools, is that a decent chunk of existing LSP code can be reused and repurposed. For example, most editors already ship with code for managing local server sidecars over stdio. There are a few annoying differences though like the lack of a header section in MCP.
Post reply on HN