Live data from Hacker News

MCP is dead?

quandri.io

431–440 of 444 posts

Re: MCP is dead?

#431

Earlier quoted context omitted.

MCP is more than is more than tools. Tools is one of three major features: prompts[0] and resources[1] being the other two. Prompts are effectively "server delivered skills" which are are quite powerful because it solves a distribution and synchronization problem. It also allows server materialization and dynamic construction of skills. MCP also has a few other under utilized mechanisms: elicitation[2] on the client…

this is bad. Anyone doing any cursory work with agents will realize how brittle > can be. Adding an extra layer of indirection isn’t helpful, it’s a gigantic hindrance that gives you a moving eval target. Being an MCP developer means you have a moving target of model optimization. It is a win for nobody. The tools we need to solve this problem exist and they are boring. Types, jsonschema, openapi, all of it is a bett…

For those of us who lived this wild arc from the advent of normative protocols widely adopted, standards, open source, and the variety of “paradigm shifts” over the last several decades it’s not surprising to see a profusion of attempts at standards with poor adherence across tooling, and fits and starts along the way. Those using the modern web, but not old enough to have built it, which has largely calmed down, probably look about them at the relative order of things and sigh in contentment then squint at the AI agent standards and huff at the confusion. Those few other gray heads who went through the various fits and starts look about at what’s going and recognize it quite clearly as “this is how things look at the beginning.”

We are really only a few years into all this stuff, and the real taking it very seriously has only been about 8 months. Web standards took 8 years to be barely usable. That was built on 30 years of internet standards that were barely usable.

Relax padwan and enjoy the ride.

Re: MCP is dead?

#432

Earlier quoted context omitted.

You do know MCPs are loaded on demand same as skills now right? The only place where sometimes it still uses too much context is if you have too many MCPs (same issue with skills) or some MCP is poorly designed and responds with huge description or MCP calls respond with way too much info, but skills can have this issue as well.

Yes, MCP taking the form of 'skill' because MCP serves no purpose. The concept of 'mcp server' is a brittle abstraction that need not exist. A 'skill' is utterly superior in every sense: a 'right sized abstraction for whatever it is you're trying to do' - that can include cli / rest - and other key bits of information.

MCP is a JSON-RPC + a fixed auth/discovery handshake + a fixed tool schema protocol for backend endpoints.

Your skills or CLIs still need to call a backend endpoint at some point. MCP is just a standard server JSON-RPC protocol. Having a standard for that is really nice, you get standardize auth, discovery, API shape, etc.

Is it the greatest RPC design ever, no, most annoying is how it's based around a statefull session. But it's really awesome that we have a standard. Otherwise you'd just have a bunch of random servers all doing their own things that you'd have to figure out how they work and all, it would be much worse.

Re: MCP is dead?

#433
post #399

Earlier quoted context omitted.

A 'skill' is generic concept - as short set of right-sized instructions for a given cli or api call, it can be applied in any context. If MCP did not exist today, we wold not invent it. We'd probably hormonize in basic conventions around json calls, and not much more. The rest would just be api use / instructions. LLMS to day are exceedingly good at calling RESTful APIs, the MCP standard provides little advantage. Th…

Yea so your answer is to build something that’s like MCP basically. You’d standardize conventions around json, great, now standardize auth. Oauth is nice right? That’s MCP. MCP is literally a restful API using JSON with OAuth. You’re arguing against MCP but have nothing to offer that isn’t nearly the same thing.

Agreed, not sure what people arguing against MCP are even arguing against. The only valid critique of MCP is that you think the RPC protocol isn't ideal, sure, you could argue about the protocol design, for example I wish there was better support for stateless calls. But why wouldn't you want a protocol for back-end API calls? Otherwise you need custom clients for each possible backend you want to invoke.

Re: MCP is dead?

#434

Earlier quoted context omitted.

A CLI needs to work on windows, mac, linux, android, iOS, etc. And it still needs some backend APIs to call. So creating one is a lot more work than just making an MCP.

That kind of code is easily portable in C or Rust or Go or Java or Python so long as it is a CLI and not GUI.

The language barely matters, the issue is packaging, distribution, platform permissions, pushing updates, keeping client/server versions in sync, shell support, etc.

Where-as if you just expose HTTP endpoints, all that doesn't matter, you just need cURL or any app, like the chatGPT mobile app, can just call into your endpoint.

Re: MCP is dead?

#435

Earlier quoted context omitted.

Seems to me that you're saying the MCP is a simplified API with good documentation geared towards agents. But if that's the case, could you not exposes the simplified interface as part of the API, instead of exposing it in MCP?

When it is part of the API, the agent still has the choice between multiple options. If it chooses the less efficient one, the request can become significantly more CPU- and token-intensive than necessary. The problem is that the agent does not care. Its primary goal is to get the job done. Maybe the agent is smart enough to choose the optimal path, but that strongly depends on the model being used. You also do not k…

Interesting, thanks!

Re: MCP is dead?

#436
post #258

Earlier quoted context omitted.

> One advantage is the MCP advertises itself to the agent with its schema and api shape. So, OpenAPI/Swagger for REST? GraphQL? SOAP schemas? All of these (and more) exist. What does MCP add that these don't have?

I’m confused by the question. You listed a bunch of standards over time, all of which reach to solve a similar problem (you left off XDR/RPC, CORBA, and about 10000 others), and unironically ask why is there a n+1 standard? Are you genuinely confused? https://xkcd.com/927

You wouldn't be confused if you actually tried to understand what I was saying. .

Your claim was: "One advantage is the MCP advertises itself to the agent with its schema and api shape".

This "advantage" has already existed, as you correctly pointed out, in about 10000 other standards and protocols. MCP is not special, and doesnmt have some advantage. It's a vibe-coded hype-driven n+1 standard that is busy ignoring anything that came before it, for no reason.

Re: MCP is dead?

#437

Earlier quoted context omitted.

That was exactly my thought when I saw MCP: like we know so much about creating protocols but get a bunch of people together with no experience and that’s what you get. Reminds me a lot of Microsoft’s WS-disaster of the early 2000s except the latter was thought through a little better. To be fair a while back I did design an API for a general purpose model trainer which was absolutely atrocious for a few reasons, my…

You mean a swagger?

yes

Re: MCP is dead?

#438

Earlier quoted context omitted.

i mean yeah but is just a spec

What do you mean?

MCP is a way to define tools that works with many apps and has a lot of extra functionality built in, it's not the only way, but it's popular because many apps support it. You can also make tools using the opencode API or any other API, and you can give them large descriptions that take up a lot of context. No matter how you define the tools, they are injected into the context of the model using the same chat template provided by the developers of the model.

Re: MCP is dead?

#439
post #219

Earlier quoted context omitted.

Instead of requiring each session to understand the n tools used to solve a particular problem, you bundle up the solution in a conventional script (that's what I meant by "can", as in canning) that the agent can use with very little documentation in the context. When the model is smart enough to figure out the composition of underlying tools during regular execution, it will also be able to do the canning up as a sc…

Won't you just end up with hundred of very specific scripts that can only do a very narrow thing? And now they'll all have their description and name in context.

depends on how many different problems the agent has to solve?

Re: MCP is dead?

#440
Perhaps this should be "People don't understand how to implement good MCP servers" as opposed to MCP is dead.

MCP shouldn't be 1-1 to API. It should empower users and LLMs to perform tasks and see data.

CLIs don't improve upon that issue if they're designed the same way people are implementing MCPs.

Post reply on HN