Hacker News Reader

Comment by _pdp_ | Hacker News Reader

I fully agree.

MCP is just too complex for what it is supposed to do. I don't get what's the benefit. It is the kind of thing that has the potential to be a huge time waste because it requires custom dev tools to develop and troubleshoot.

It is not even a protocol in the traditional sense - more of a convention.

And of course we will implement it, like everyone else, because it is gathering momentum, but I do not believe it is the right approach at all. A simpler HTTP-based OpenAPI service would have been a lot better and it is already well supported in all frameworks.

The only way I can make sense of MCP in the context of an STDIO.

View on HN

The `stdio` approach for local services makes complete sense to me. Including using JSONRPC.

But for remote HTTP MCP servers there should be a dead simple solution. A couple years ago OpenAI launched plugins as `.well-known/ai-plugin.json`, where it'd contain a link to your API spec, ChatGPT could read it, and voila. So all you needed to implement was this endpoint and ChatGPT could read your whole API. It was pretty cool.

ChatGPT Plugins failed, however. I'm confident it wasn't because of the tech stack, it was due to the fact that the integration demand wasn't really there yet: companies were in the early stages of building their own LLM stacks, ChatGPT desktop didn't exist. It also wasn't marketed as a developer-first global integration solution: little to no consistent developer advocacy was done around it. It was marketed towards consumers and it was pretty unwieldy.

IMO the single-endpoint solution and adhering to existing paradigms is the simplest and most robust solution. For MCP, I'd advocate that this is what the `mcp/` endpoint should become.

Edit: Also tool calling in models circa 2023 was not nearly as good as it is now.

I agree. What OpenAI did was simple and beautiful.

Also, I think there is a fundamental misunderstanding that MCP services are plug and play. They are not. Function names and descriptions are literally prompts so it is almost certain you would need to modify the names or descriptions to add some nuances to how you want these to be called. Since MCP servers are not really meant to be extensible in that sort of way, the only other alternative is to add more context into the prompt which is not easy unless you have a tone of experience. Most of our customers fail at prompting.

The reason I like the ai-plugin.json approach is that you don't have to change the API to make the description of a function a little bit different. One day MCP might support this but it will another layer of complexities that could have been avoided with a remotely hosted JSON / YAML file.

The good thing to note is that (AFAIK) MCP is intended to be a collaborative and industry-wide effort. Whereas plugins was OpenAI-specific.

So, hopefully, we can contribute and help direct the development! I think this dialogue is helpful and I'm hoping the creators respond via GitHub or otherwise.

It’s not just about passing prompts — in production systems like Ramp’s, they had to build a custom ETL pipeline to process data from their endpoints, and host a separate database to serve structured transaction data into the LLM context window effectively.

We’ve seen similar pre-processing strategies in many efficient LLM-integrated APIs — whether it’s GraphQL shaping data precisely, SQL transformations for LLM compatibility, or LLM-assisted data shaping like Exa does for Search.

https://engineering.ramp.com/ramp-mcp

PS: When building agents, prompt and context management becomes a real bottleneck. You often need to juggle dynamic prompts, tool descriptions, and task-specific data — all without blowing the context window or inducing hallucinations. MCP servers help solve this by acting as a "plug-and-play" prompt loader — dynamically fetching task-relevant prompts or tool wrappers just-in-time. This leads to more efficient tool selection, reduced prompt bloat, and better overall reasoning for agent workflows.

It took me a minute to even understand this comment because for me the “obvious” use-case for MCP is local filesystem tasks, not web requests. Using MCP to manipulate files is my primary LLM use-case and has been ever since Anthropic released it and integrated it into Claude Desktop. I understand where you’re coming from, but I suspect that the idea here is to build something that is more “filesystem first.”

That makes sense. But if that's the case I think we should call a spade a spade and differentiate "Local-first MCP" and "Remote MCP"; because what (many, most?) companies are really trying to do is integrate with the latter.

Which is where you see this sort of feedback, where a bunch of us API engineers are like; "there's already a well-trodden path for doing all of this stuff. Can we just do that and agree that it's the standard?"

100%. I know I’m in the “get off my lawn” phase of my career when I see things like MCP and LangChain, but know I would have been excited about them earlier in my career.

LangChain is an objectively terrible Frankenstein's monster of an API. If you were a good developer in your youth, you'd have still held it in contempt, and treat MCP with caution.

The MCP API is pretty bad, too, it's just that a paradigm is starting to emege regarding modularity, integration and agentic tooling, and MCP happens to be the only real shot in that direction st this particular moment.

How is the MCP API bad? It uses simple and widely available standards-based transports while still allowing custom transport implementations, along with a simple API that can be used easily without any libraries, in any programming language under the sun?

Could you elaborate on your issues with LangChain?

We're kinda headed towards using it as it seems to be a flexible enough abstraction that is relatively stable to work with, so I'd like to know if I'm overlooking something..?

A lot of folks use it to get started quickly and then realize the unnecessary abstractions are obfuscating the actual hard parts.

A big soup of untyped json blobs and python, all working highly asynchronously in complicated ways.

Is this variable available in my agent’s state?

Depends! Is it an agent that started an hour ago before you made that other change? Is it in the manager state or not? Did the previous agent run correctly or not? Did something else go wrong?

You spend more time fighting the tool/framework than working on the product you’re trying to build.

Cryptic errors that will make you tear your hair out and docs that are constantly changing

I’m seriously considering getting out of IT because of it

because of MCP and langchain?

Eh, more the wider cultural effects of them. Vibe coding, everyone now creating kitchen sink apps that do everything under the sun, k8s everywhere, agents everywhere. It feels like a big part of the industry has lost all focus and is sprinting towards some endless vague panacea instead of focusing on solving specific well defined business problems.

It’s always been a bit like this but it feels particularly bad since AI hit mainstream coding tooling. Just my 2c :)

Yeah, I had more luck with just giving an ai the openapi spec and letting it figure everything out. I like a lot about MCP (structure, tool guidance, etc), but couldn't it just have been a REST API and a webserver?

I think people often think of their specific use-case and tend to forget the bigger picture. MCP does not force one transport or the other and that is great—use any transport you want as long as it uses JSON RPC as the payload.

The two built in transports are also extremely minimalistic and for SSE transport use regular HTTP—no need for web sockets or other heavier dependencies because SSE events are lightweight and broadly supported.

I tend to agree here. Alot of the use cases are around STDIO and using MCPs within existing apps like Cursor/Windsurf etc. Most developers want to build and integrate their own tools and the complexity required here (build out the server, bundle a client, and the additional latency) is probably not worth the ROI. There also seems to be a notion that security is "handled" by MCP which might be premature. I mean, there are several good decisions in the standard (tls with sse, sampling etc), but critical choices around auth and scope for agents or 3rd party mcp providers are still wide open IMO.

Overall, a step in the right direction, but still early. I wrote more on this here. https://newsletter.victordibia.com/p/no-mcps-have-not-won-ye...

How much of this is already addressed by Cloudflare’s Remote MCP setup? https://blog.cloudflare.com/remote-model-context-protocol-se...

Second that. A lot of our use cases are "remote tooling", i.e. calling APIs. Implementing an MCP server to wrap APIs seems very complex - both in terms of implementation and infrastructure.

We have found GraphQL to be a great "semantic" interface for API tooling definitions since GraphQL schema allows for descriptions in the spec and is very humanly readable. For "data-heavy" AI use cases, the flexibility of GraphQL is nice so you can expose different levels of "data-depth" which is very useful in controlling cost (i.e. context window) and performance of LLM apps.

In case anybody else wants to call GraphQL APIs as tools in their chatbot/agents/LLM apps, we open sourced a library for the boilerplate code: https://github.com/DataSQRL/acorn.js

Why does it require you to build a server to wrap APIs? I think if the api uses HTTP you could just expose a SSE endpoint for the mcp client to use?

Oh wow. Amazing. I did not think of that. I am not fan of GraphQL but you might be onto something here. I have not checked the code and perhaps this is not the right channel for this but my read is that this library allows any generic GraphQL server to exposed in this sort of way?

Exactly, any generic GraphQL server can be turned into a set of LLM tools with minimal overhead and complexity.

I am actually working on such a thing, and I want to get it righr. This is like RSS or Atom or Jabber or XMPP wars. Or OpenGraph vs Twitter’s meta tags etc. I want interoperability which is cool, but I also want it to seamlessly interoperate with human roles and services.

What is the best way to connect with you? I would like to discuss ideas and protocols if you’re up for that.

Exactly my points: https://taoofmac.com/space/notes/2025/03/22/1900

https://engineering.ramp.com/ramp-mcp

https://blog.cloudflare.com/remote-model-context-protocol-se...

Reply on news.ycombinator.com