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

191–200 of 348 posts

Re: A critical look at MCP

#191

Post by glimps »

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…

I get the distinct feeling the spec was created by llm too. As with the doc, every evidence hints at it.

Makes great IPO to tell investor most tour product are already created be averaging out the most likely outcome

Re: A critical look at MCP

#192

Post by Brainlag »

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.

Why is it baffling? Worse is better! Look at PHP, why took that prank of a programming language ever anyone serious?

Re: A critical look at MCP

#193

Post by meander_water »

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…

I can't say whether the original spec was written with AI assistance, but having a cursory look through the commit history [0] it doesn't look like they're just blatantly auto-generating the docs. The git history indicates that they do think about the spec and manually update the docs as the spec changes.

[0] https://github.com/modelcontextprotocol/modelcontextprotocol...

Re: A critical look at MCP

#194

Post by fendy3002 »

arresin wrote: post #180
fendy3002 wrote: post #123

Opinion aside (still reading), > Simply put, it is a JSON-RPC protocol with predefined methods/endpoints designed to be used in conjunction with an LLM. Is a spot on / simplest explanation of MCP, wonder why nobody use that or insist that it's usb-c for AI on their tutorials! Seeing this early can makes me understand MCP in 5 minutes

Llms are bad at summaries. So if you vibe spec and vibe doc it’s makes it nice for you but frustrating for any poor schmuck who has to work with it because it’s inexplicably now the flavour of the month among vibe coders.

Yeah one main thing I really hate about ai in general: they overhype and targeted to non technical person, and everyone involved in it want to sell the shovels in a gold rush. It's frustrating to find a good technical material. Or good tips / practice

Re: A critical look at MCP

#195

Post by 0x457 »

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?

Well, the point is to provide context, it's easier to do if server has state.

For example, you have a MCP client (let's say it's amazon q cli), a you have a MCP server for executing commands over ssh. If connection is maintained between MCP client and server, then MCP server can keep ssh connection alive.

Replace SSH server with anything else that has state - a browser for example (now your AI assistant also can have 500 open tabs)

Re: A critical look at MCP

#196

Post by comradesmith »

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…

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

Re: A critical look at MCP

#197

Post by albert_e »

comradesmith wrote: post #196
ComplexSystems wrote: post #188

Earlier quoted context omitted.

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…

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

Maybe the first sentence? I am guessing they meant "DeepSeek API does not enforce any rate limit on users." would be more appropriate.

_Constraining the rate 'limit'_ seems like incorrect usage - but it is an a easy mistake to make in a first draft. Review should have caught it.

Re: A critical look at MCP

#198

Post by walterbell »

jerf wrote: post #186
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…

It had not occurred to me that the AI coding vendors are basically positively motivated to themselves produce code that is not documented. They want code that is comprehensible to AIs but actively not comprehensible to humans. Then you need their AIs to manipulate it. AI code as the biggest "lock you in the box" in programming history. That takes rather a lot of the luster out of it.... They'd better be right that th…

Self Alignment™

Re: A critical look at MCP

#199

Post by OJFord »

moralestapia wrote: post #43
OJFord wrote: post #4

Earlier quoted context omitted.

I think 'bidirectional' is unclear there, they really mean a back and forth dialogue, interactive bidirectional communication. Which, yeah, a socket (as they said) seems a better choice.

I think stdin and stdio are meant to always be piped forward, and a program further down the pipe cannot modify a tool back in the pipeline, maybe that's what he's trying to convey with "bidirectional"?

I don't think so, because it's a description of a system which does work.

But it's more like an HTTP API, writing or requesting some data, getting a response, doing something else with that, etc. - whereas typically with stdin/stdout you're doing something more like `generate-data | transform | transform2 | store`, manipulating an initial input, not decision-making and providing more input based on the output of early input. Not to say you can't, but it does seem a bit weird to me too.

(To be fair I suppose a shell is an obvious counter-example. Or anything that launches an interactive prompt or interpreter.)

Re: A critical look at MCP

#200

Post by lolinder »

comradesmith wrote: post #196
ComplexSystems wrote: post #188

Earlier quoted context omitted.

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…

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 from the server" is again grammatical but also awkward. "Our response times may be slower" would be more natural.

The last sentence is also awkward but the whole thing would need to be restructured, which is too much for an HN comment.

Basically: everything about this screams English as a second language. Which does mean that it's unlikely to have been LLM generated, because from what I've seen DeepSeek itself does a pretty good job with English!

Post reply on HN