Live data from Hacker News

MCP is a fad

tombedor.dev

91–100 of 129 posts

Re: MCP is a fad

#91
post #86
post #62

We're at a point in the LLM curve where there's two huge, polarized groups of developers: - the ones who don't see any value on AI for coding and dismiss it as a fad at every change they get - the ones who are in love with the new tools and adopting as many as they can on their workflows I know the arguments of the second bunch well. But very curious about what the "AI is a fad" bunch thinks will happen. Are we going…

> Are we going to suddenly realize all these productivity gains people are claiming are all lies and go back to coding by typing characters on emacs and memorizing CS books? If you have not learned CS, how do you expect to separate the LLM wheat from the chaff? > Will StackOverflow suddenly return as the most popular source of copy-paste code slop? Coding sites manually populated by humans are dead.

> If you have not learned CS, how do you expect to separate the LLM wheat from the chaff?

I didn't mention anything about learning CS. You can be a great engineer without having A* memorized line by line, no?

Re: MCP is a fad

#92
post #79

Earlier quoted context omitted.

> To address the security concerns below: MCP is just the wire protocol like TCP or HTTP. We don't expect TCP to natively handle RBAC or prevent data exfil. That is the job of the application/server implementation. That is simply incorrect. It is not a wire protocol. Please do not mix terminology. MCPs communicate via JSON-RPC which is the wire protocol. And TCP you describing as wire protocol isn't a wire protocol a…

Would you say MCP is a protocol (or standard) similar to how REST is a protocol in that they both define how two parties communicate with each other? Or, in other words, REST is a protocol for web APIs and MCP is a protocol for AI capabilities?

[deleted]

Re: MCP is a fad

#93
post #62

We're at a point in the LLM curve where there's two huge, polarized groups of developers: - the ones who don't see any value on AI for coding and dismiss it as a fad at every change they get - the ones who are in love with the new tools and adopting as many as they can on their workflows I know the arguments of the second bunch well. But very curious about what the "AI is a fad" bunch thinks will happen. Are we going…

> Are we going to suddenly realize all these productivity gains people are claiming are all lies

I'll grant you that many have become adamant that LLMs suddenly, out of the blue, became useful just last week, which is much too soon to have any concrete data for, but coding agents in some shape have been around for quite a while and in the data we have there isn't offering of any suggestion of productivity gains yet.

And I'm not sure many are even claiming that they are more productive, just that the LLMs have allowed them to carry out a task faster. Here's the thing: At least my experience, coding was never the bottleneck. The bottleneck has always been the business people squabbling over what the customers and business need. They haven't yet figured out how to get past their egos.

The most promise for productivity seems to be from lone startup founders who aren't constrained by the squabbling found in a larger organization and can now get more done thanks to the task shortening. However, the economic conditions are not favourable to that environment right now. Consumers are feeling tapped out, marketing has become way harder, and, even when everything else is in place, nobody is going to consider your "SaaS" when they believe the foundational LLMs will be able to do the same thing tomorrow.

Re: MCP is a fad

#94
post #18

This analysis dismisses MCP by focusing too narrowly on local file system interactions. The real value isn't just running scripts; it's interoperability. MCP allows any client (Claude, Cursor, IDEs) to dynamically discover and interact with any resource (Postgres, Slack) without custom glue code. Comparing it to local scripts is like calling USB a fad because parallel ports worked for printers. The power is standardi…

The thing is, current models are good enough that you can mostly achieve the same by just putting a markdown file[1] on your server that describes their API, and tell people to point their agent at that.

For complex interactions it might be marginally more efficient to use an MCP server, but current SOTA models are good at cobbling together tools, and unless you're prepared to spend a lot of time testing how the models actually end up interacting with your MCP tools you might find it better to "just" describe your API to avoid a mismatch between what you expose and what the model thinks it needs.

[1] Slightly different, but fun: For code.claude.com, you can add ".md" to most paths and get back the docs as a Markdown file; Claude Code is aware of this, and uses it to get docs about itself. E.g. https://code.claude.com/docs/en/overview.md )

Re: MCP is a fad

#96
post #39

What do MCPs do that the CLI cannot? i.e. assuming your agent has access to the terminal, and therefore CLIs, what additional value do MCPs provide?

MCP can wrap things which have stateful processes, debuggers for example. Agents will use batch mode but it is quite limited and due to tool calls always being implemented as synchronous invocations, non-batch mode doesn’t work for tool calls. MCP solves this by giving the agent a handle it can use to refer to in multiple invocations. Burns a lot of tokens though and if you need more than batch-mode gdb to debug some…

> and due to tool calls always being implemented as synchronous invocations

Claude Code wil happily start long-running processes and put in the background, and is able to refer back to them. You don't need MCP for that - you can hand the model handles to refer to background jobs just fine with just tool-calling.

Re: MCP is a fad

#97

Earlier quoted context omitted.

At this point, when people say this I just assume they’ve not used the latest models or haven’t invested time in learning how to use these tools properly. There’s slop out there, yes, but in the hands of an engineer who cares to use tools well, LLMs allow you to move much more quickly and increase the quality of your output dramatically.

Good software isn't about quantity but quality of the code. AI cannot produce better quality code than someone who is actually qualified in the problem domain. What I've seen AI be very good at is creating a lot of legacy code very quickly, which itself needs extensive use of AI just to maintain it. A decent approach to move quickly for PoC or prototypes, or to enable product managers to build things without a team.…

Have you been in the same industry as the rest of us? 90% of all developers out there in the wild create "legacy code very quickly" anyways, they too create "slop" before we coined the term "AI slop". This mythical "someone who is actually qualified in the problem domain" you mention is maybe 5% of the entire software development ecosystem. If you work with only those developers, you're extremely privileged and lucky, but also in a very isolated bubble.

Re: MCP is a fad

#98
post #18

This analysis dismisses MCP by focusing too narrowly on local file system interactions. The real value isn't just running scripts; it's interoperability. MCP allows any client (Claude, Cursor, IDEs) to dynamically discover and interact with any resource (Postgres, Slack) without custom glue code. Comparing it to local scripts is like calling USB a fad because parallel ports worked for printers. The power is standardi…

Doesn't that require a complete lack of concern on the part of the postgres side? I feel like I'm missing something in terms of why anyone would even ever allow that.

you can ask the LLM for an adhoc report. it can look at the schema, run the queries and give you the results. of course you can just give it read access.

Re: MCP is a fad

#99

Earlier quoted context omitted.

> REST (Representational State Transfer) is a software architectural style italics mine https://en.wikipedia.org/wiki/REST also REST is less about communicating, more about the high level user interface and the underlying implementations to arrive at that (although one could argue that’s a form of communicating). the style does detail a series of constraints. but it’s not really a formal standard, which can get prett…

Thanks, and call me wrong, I think "Protocol" in MCP is somehow misused. Sure it is somehow a protocol, because it commits on something, but not in the technical sense. MCI (Model Context Interface) would probably the better name?

I agree that interface would be a better name than protocol, but Model Context Integration/Integrator would be even better as that is it's core intent: To integrate context into the model. Alternatively, Universal Model Context Interface (or integrator) would be an even better name imo, as that actually explains what it intends to do/be used for, whereas MCP is rather ambiguous/nebulous/inaccurate on the face of it as previously established further up-thread.

That said, I think as the above user points out, part of the friction with the name is that MCP is two parts, a framework and a standard. So with that in mind, I'd assert that it should be redefined as Model Context Interface Standard, and Model Context Interface Framework (or Integration or whatever other word the community best feels suits it in place of Protocol).

Ultimately though, I think that ship has sailed thanks to momentum and mindshare, unless such a "rebranding" would coincide with a 2.0 update to MCP (or whatever we're calling it) or some such functional change in that vein to coincide with it. Rebranding it for "clarity's sake" when the industry is already quite familiar with what it is likely wouldn't gain much traction.

Re: MCP is a fad

#100
post #57

Simon Willison made many of the same points (without the technical deep dive) back in October 2025 [1], when Anthropic announced Skills. A couple of choice quotes, which are echoed in this new article: > I like to joke that one of the reasons it took off is that every company knew they needed an “AI strategy”, and building (or announcing) an MCP implementation was an easy way to tick that box. > Almost everything I m…

I am pretty sure he is right about it. Let's just hope MCP won't last too long but I fear it will.

Especially if there is already an API perfectly described by an OpenAPI spec (note OpenAPI!=OpenAI ;)). Why should I host an additional MCP server or extra endpoints? Because it's trendy?

Post reply on HN