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

211–220 of 348 posts

Re: A critical look at MCP

#211

Post by Spivak »

_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'.

And then you read the SDK code and the bewildering doesn't stop at the code quality, organization, complete lack of using exiting tools to solve their problems, it's an absolute mess for a spec that's like 5 JSON schemas in a trench coat.

Re: A critical look at MCP

#212

Post by jes5199 »

I recently wrote an MCP server, in node, after trying and failing to get the official javascript SDK to work. I agree with the criticisms — this is a stunningly bad specification, perhaps the worst I have seen in my career. I don’t think the authors have actually tried to use it.

Trying to fix “you must hold a single connection open to receive all responses and notifications” by replacing it with “you must hold open as many connections as you have long-running requests, plus one more for notifications” is downright unhinged, and from reading the spec I’m not even sure they know that’s what they are asking clients to do

Re: A critical look at MCP

#213

Post by jes5199 »

clbrmbr wrote: post #178
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…

Certainly a shame if true, there are some really sharp folks at Anthropic and this is an important building block in the emerging ecosystem.

someone is going to write an MCP adaptor that lets Claude use OpenAPI and then we can forget that MCP was a thing

Re: A critical look at MCP

#214

Post by acchow »

lolinder wrote: post #169
fleischhauf wrote: post #166

Earlier quoted context omitted.

pytorch, tensorflow, numpy there are quite a few examples ai/ml has been steadily more commodetized, so it's far from only being developed by mathematicians. Hence every highschools student and his mother has an AI startup now. (And I'm not even mad, it's actually very exciting to see what people come up with nowadays)

Unfortunately when someone says "AI" these days they're not talking about pytorch, tensorflow, or numpy. They're talking specifically about LLMs, which are built on top of those tools but which do show the tendency that OP is identifying to generally appear to be vibe-coded over a weekend rather than designed by a rigorous engineering process like what we've come to expect from foundational tech like web browsers or…

Which LLMs seem to be vibe-coded over a weekend?

Do you perhaps mean small language models?

I doubt Llama or Deepseek were vibe coded..

Re: A critical look at MCP

#215

Post by jes5199 »

ethical_source wrote: post #67
punkpeye wrote: post #60

I am the founder of one of the MCP registries ( https://glama.ai/mcp/servers ). I somewhat agree with author’s comments, but also want to note that the protocol is in the extremely early stages of development, and it will likely evolve a lot over the next year. I think that no one (including me) anticipated just how much attention this will get straight out the door. When I started working on the registry, there were…

> I somewhat agree with author’s comments, but also want to note that the protocol is in the extremely early stages of development, and it will likely evolve a lot over the next year. And that's why it's so important to spec with humility. When you make mistakes early in protocol design, you live with them FOREVER. Do you really want to live with a SSE Rube Goldberg machine forever? Who the hell does? Do you think yo…

they already did though. the late-2024 version and the early-2025 version have completely incompatible SSE rube goldberg machines

Re: A critical look at MCP

#216

Post by reliabilityguy »

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…

> "Our response times may be slower" would be more natural.

How can the time be slower? Response times may be longer, but not slower

Re: A critical look at MCP

#218

Post by jes5199 »

neuroelectron wrote: post #7

MCP is the moat to keep small players outside of the AI market. Not only does implementing it require a team, it is a tarpit of sabotage, where logging and state are almost impossible to track.

I had the idea that maybe it was actually a flytrap for large companies! force them to waste cycles chasing a moving target so they don’t even notice they’re being leapfrogged

Re: A critical look at MCP

#219

Post by lolinder »

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

In colloquial English my construction is just fine, but sure, you'd be welcome to pick longer too.

Some examples of my usage in the wild ("response times may be slower" is present verbatim on each page):

https://github.com/aquasecurity/trivy/discussions/8133

https://www.ameristarstaffingny.com/the-negative-effects-of-...

https://oci.wi.gov/Pages/Regulation/Bulletin20200320Regulato...

https://playrix.helpshift.com/hc/en/27-questbound/faq/13930-...

Re: A critical look at MCP

#220

Post by fakedang »

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…

I've seen documents that were applications by CCP-affiliated provincial government bodies, things like detailed studies for loan applications to international banks, etc. and trust me, the Deepseek documentation is miles ahead of that. These are official government documents from one government agency to some international agency.
Post reply on HN