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

31–40 of 348 posts

Re: A critical look at MCP

#31

Post by hrpnk »

This critical look focuses just on the protocol. The fun starts with the actual MCP server implementations... Seems that providing an MCP server is the to be or not to be for all sorts of vendors. All REST APIs get wrapped into an MCP to make products LLM-compatible and tick checkmarks on newly extended checklists.

Many pass REST responses directly to LLMs that quickly leads to token burn. Wish providers took a closer look on the actual engineering practices for the servers.

Has someone seen a good implementation of an MCP server with a comprehensive test suite?

Re: A critical look at MCP

#32

Post by neuroelectron »

rvz wrote: post #23

> However, I'm astonished by the apparent lack of mature engineering practices. Exactly. MCP is one of the worst 'standards' that I have seen come out from anywhere since JSON Web Tokens (JWTs) and the author rightfully points out the lack of engineering practices of a 'standard' that is to be widely used like any properly designed standard with industry-wide input. > Increased Attack Surface: The multiple entry poin…

I think it's clear that they want a proprietary solution that takes a year or more for others to copy. That gives them another year head start on the competition.

Re: A critical look at MCP

#33

Post by _QrE »

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

Re: A critical look at MCP

#34

Post by _raz »

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

Glad to here, also thought I was alone :)

Re: A critical look at MCP

#35

Post by neuroelectron »

triyambakam wrote: post #30
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.

Have you tried it though? There are sdks where you can set up logging and MCP server or client in a few lines. Pydantic AI and Logfire as one example

Yes, there are SDKs that abstract away some of the setup. But what exactly is being logged? Where is the data going? How tamper-proof is that logging? How is the network communication implemented? How do you check those logs? What exactly is being sent through the line? It’s hard to audit, especially without deep visibility into the underlying layers which include binary blobs and their tokens for trust. How do you model internal state? How do you write regression tests?

Re: A critical look at MCP

#37

Post by snthpy »

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…

Bravo. Agree with both of your examples.

Re: A critical look at MCP

#38

Post by nicomt »

The post misses the mark on why a stateless protocol like MCP actually makes sense today. Most modern devs aren’t spinning up custom servers or fiddling with sticky sessions—they’re using serverless platforms like AWS Lambda or Cloudflare Workers because they’re cheaper, easier to scale, and less of a headache to manage. MCP’s statelessness fits right into that model and makes life simpler, not harder.

Sure, if you’re running your own infrastructure, you’ve got other problems to worry about—and MCP won’t be the thing holding you back. Complaining that it doesn’t cater to old-school setups kind of misses the point. It’s built for the way things work now, not the way they used to.

Re: A critical look at MCP

#39

Post by wisemang »

immibis wrote: post #25
hirsin wrote: post #20

Earlier quoted context omitted.

Indeed! But seemingly only for the actual object representation - it's a start, and I wonder if JSON is uniquely suited to LLMs because it's so text-first.

I understand those with experience have found that XML works better because it's more redundant.

Is it the redundancy? Or is it because markup is a more natural way to annotate language, which obviously is what LLMs are all about?

Genuinely curious, I don’t know the answer. But intuitively JSON is nice for easy to read payloads for transport but to be able to provide rich context around specific parts of text seems right up XML’s alley?

Re: A critical look at MCP

#40

Post by fhd2 »

simonw wrote: post #10
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.

My theory is that a lot of the buzz around MCP is actually buzz around the fact that LLM tool usage works pretty well now. OpenAI plugins flopped back in 2023 because the LLMs at the time weren't reliable enough for tool usage to be anything more than interesting-but-flawed. MCP's timing was much better.

I'm still having relatively disastrous results compared to just sending pre curated context (i.e. calling tools deterministically upfront) to the model.

Doesn't cover all the use cases, but for information retrieval stuff, the difference is pretty light and day. Not to mention the deterministic context management approach is quite a bit cheaper in terms of tokens.

Post reply on HN