A critical look at MCP • Hacker News Board

Re: A critical look at MCP

#171

Post by worldsayshi » Sat, May 10, 2025, 10:41 PM UTC

ethbr1 wrote: post #85

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…

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

I guess there's an incentive to quickly get a first version out the door so people will start building around your products rather than your competitors.

And now you will outsource part of the thinking process. Everyone will show you examples when it doesn't work.

Re: A critical look at MCP

#172

Post by worldsayshi » Sat, May 10, 2025, 10:46 PM UTC

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

Isn't that what a lot of this is about? It's a blue ocean and everyone are full of fomo.

Re: A critical look at MCP

#173

Post by [deleted] » Sat, May 10, 2025, 10:47 PM UTC

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…

[deleted]

Re: A critical look at MCP

#174

Post by koakuma-chan » Sat, May 10, 2025, 10:50 PM UTC

saurik wrote: post #167

koakuma-chan wrote: post #117

Earlier quoted context omitted.

This article feels like an old timer who knows WebSockets just doesn't want to learn what SSE is. I support the decision to ditch WebSockets because WebSockets would only add extra bloat and complexity to your server, whereas SSE is just HTTP. I don't understand though why have "stdio" transport if you could just run an HTTP server locally.

I'm confused by the "old timer" comment, as SSE not only predates WebSockets, but the techniques surrounding its usage go really far back (I was doing SSE-like things--using script blocks to get incrementally-parsed data--back around 1999). If anything, I could see the opposite issue, where someone could argue that the spec was written by someone who just doesn't want to learn how WebSockets works, and is stuck in a…

> I'm confused by the "old timer" comment

SSE only gained traction after HTTP/2 came around with multiplexing.

Re: A critical look at MCP

#175

Post by [deleted] » Sat, May 10, 2025, 10:52 PM UTC

[deleted]

Re: A critical look at MCP

#176

Post by achierius » Sat, May 10, 2025, 11:01 PM UTC

volemo wrote: post #131

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.

Could you throw on a couple of examples of calcified early mistakes of Python? GIL is/was one, I presume?

CPython in particular exposes so much detail about its internal implementation that other implementations essentially have to choose between compatibility and performance. Contrast this with, say, JavaScript, which is implemented according to a language standard and which, despite the many issues with the language, is still implemented by three distinct groups, all reasonably performant, yet all by and large compatible.

Re: A critical look at MCP

#177

Post by aristofun » Sat, May 10, 2025, 11:05 PM UTC

fleischhauf wrote: post #166

aristofun wrote: post #152

Earlier quoted context omitted.

Any popular examples to support your claim? My claim is supported by the post article and many points there, for example. Another example is my own experience working with python ecosystem and ai/ml libraries in particular. With rare exceptions (like pandas) it is mostly garbage from DevX perspective (in comparison of course). But I admit my exposure is very limited. I don’t work in ai area professionally (which is a…

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)

> pytorch, tensorflow, numpy

I would use those as examples of an exception from my generalized point.

Anything else? Just a handful of tools you can call professional of thousands and thousands used everyday?

Re: A critical look at MCP

#178

Post by clbrmbr » Sat, May 10, 2025, 11:08 PM UTC

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.

Re: A critical look at MCP

#179

Post by yawnxyz » Sat, May 10, 2025, 11:08 PM UTC

I’ve been toying with building remote MCPs on Cloudflare workers. I came in with the idea that “you could probably use REST APIs for everything” then implemented both REST, and MCPs side by side. Also built an SSE and a “streamable http” version.

For building apps that call the server, using the APIs was way easier.

For building an LLM system for figure out what API tool calls to make, it’s quite a bit of work to recreate what the MCP folks did.

I think MCPs are a huge time saver for wrapping AI around a bag of tools, without having to hard code every API call and interaction.

If anything, I think using MCPs is a massive convenience and time saver for building and prototyping LLM + tool calling apps.

Also for SSE vs Streamable HTTP, I don’t think “streamable” uses SSE at all? I think the problem they were solving for was the annoying long lived SSE connections — you can definitely see the difference on Workers though, switching away from SSE makes the workers way faster for multiple connections

Edit: the experience of building on Cloudflare and Claude is extremely frustrating; Claude is unable to output errors properly, can’t edit config inside the app, and has to be restarted constantly. Cloudflare stops working properly on SSE connections randomly, and throws bizarre errors every now and then.

Re: A critical look at MCP

#180

Post by arresin » Sat, May 10, 2025, 11:17 PM UTC

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.