alt Hacker NewsThis 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 standardization: write once, support every AI client.
Edit:
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.
Replies
> MCP allows any client (Claude, Cursor, IDEs) to dynamically discover and interact with any resource (Postgres, Slack) without custom glue code.
I don't think MCP is what actually enables that, it's LLMs that enable that. We already had the "HTTP API" movement, and it still didn't allow "without custom glue code", because someone still had to write the glue.
And even with MCP, something still has to glue things together, and it currently is the LLMs that do so. MCP probably makes this a bit easier, but OpenAPI or something else could have as easily have done that. The hard and shitty part is still being done by a LLM, and we don't need MCP for this.
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 )
adding MCP servers isnt free, they take space in your context and if you are working at anything bigger than a startup, none of the companies allow thier workers to connect to other companies' MCPs and they can easily make thier MCP a data exfil machine
> MCP allows any client (Claude, Cursor, IDEs) to dynamically discover and interact with any resource (Postgres, Slack) without custom glue code.
My agent writes its own glue code so the benefit does not seem to really exist in practice. Definitely not for coding agents and increasingly less for non coding agents too. Give it a file system and bash in a sandbox and you have a capable system. Give it some skills and it will write itself whatever is neeeded to connect to an API.
Every time I think I have a use case for MCP I discover that when I ask the agent to just write its own skill it works better, particularly because the agent can fix it up itself.
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.
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))
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.
[dead]
> 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.