Live data from Hacker News

MCP is a fad

tombedor.dev

71–80 of 129 posts

Re: MCP is a fad

#72
We went from "Review any services and their interaction without local system and network" to "Defending local and remote logic created on the fly to mangle the local file system, and why that's a good thing" ...

That's not a productivity boost. That's a rapid increase in cognitive tax you're offloading for later and as you get backlogged in reviewing it, you lose more control over what it does...

Re: MCP is a fad

#73
I think this article misses the most important point of MCP: Authentication. Granted, it wasn't in the initial spec, but it is now, and it really opens interoperability without compromising on security.

Think about how to provide your SaaS service to users of ChatGPT or Claude.ai (not only coding tools like VSCode). At one time, the user will need to allow the SaaS service to interact with their agent, and will have to authenticate in the SaaS service so that the agent can act on their behalf. This is all baked in the MCP spec (through OAuth) [1], and scripting can't beat that.

That's why the Extensions/Applications marketplaces of consumer AI assistants like ChatGPT Apps [2] are a thin layer on top of MCP.

Another domain where MCP is required is for Generative UI. We need a standard that allows third-party apps to return more sophisticated content than just text The MCP spec now encloses the MCP Apps specification [3], which is exactly that: a specification for how third-party apps can generate UI components in their response. On the other hand, scripting will only let you return text.

[1]: https://modelcontextprotocol.io/specification/2025-03-26/bas... [2]: https://help.openai.com/en/articles/11487775-apps-in-chatgpt [3]: https://github.com/modelcontextprotocol/ext-apps

Re: MCP is a fad

#74
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…

Yeah, it might be useful for some people to stop thinking about MCP in relation to agentic harnesses. Think more about environments you don't control, such as Claude Web or ChatGPT. MCP is just a standard (fallible like most standards) but has gained traction and likely to stick around. Extremely useful for non technical people if all their apps/agents are communicating with each other (mcp).

Useful for service providers who want to expose themselves to technical consumers without having to write custom sdk's that consume their restful/graphql endpoints.

The best implementation of MCP is when you won't even hear about it.

I definitely agree that it is currently pretty shit and unnecessary for agentic coding, cli's or some other solutions will come along. (the premise being the same though, searchable/discoverable and executable tools in your agentic harness is likely going to be a very good thing instead of having to document in claude.md which os and cli specific commands it should run (even though this seems far more powerful and sensible at this point in time))

Re: MCP is a fad

#75
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…

> 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 at all! TCP is a transport protocol. IT isn't only philosophy, you need some technical knowledge too.

Re: MCP is a fad

#79
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…

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

Re: MCP is a fad

#80
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…

Interoperability? MCP has zero "interoperability", the model has to mash together everything manually.

That's why anthropic keeps walking back MCP towards just code. They'd run it back but that would be embarrassing.

Post reply on HN