MCP
Open protocol for connecting AI models and agents to external tools and data sources
HN commenters value MCP as a widely adopted standard for connecting AI agents to APIs and internal tools,1234 and for letting servers describe their capabilities in natural language so clients can use them without prior knowledge.56 The most common criticism is that CLIs and skills make it unnecessary,78 with others calling the spec poorly written.9
Why people recommend it
Broad ecosystem · 3
Commenters prefer one widely compatible standard over many competing integration methods, despite its flaws.
I appreciate their reluctance towards MCP, but /something/ is better than nothing. It’s suboptimal for the reasons the author outlines: but so is USB-C. So is NVME, so is HDMI. We use these hugely successful technologies in spite of their flaws because they’re widely compatible and easy for the end user. That’s why MCP is everywhere. It might not be performant, robust and uniform but it WILL get better over time. And
“MCP is going to be around for a long time, and we can expect it to get much better than it is today.”
Show 1 more
“anybody involved with MCP's launch should be ashamed of what they put out there”
Practical integrations · 3
Used to expose internal tools and APIs to agents for work such as CAD, music production and evals.
“MCP is exactly the lipstick we needed to put on our pigs”
“I use MCP to accelerate CAD mould-making and for music production.”
Show 1 more
“the local tool-use model works well because I control both sides”
Semantic layer · 2
Servers explain their API in natural language, and the protocol handles much of the common app plumbing.
“I am a complete convert.”
“So mcp is really an "app framework" than a protocol”
Agent tooling · 1
Paired with tool search or code mode in agent harnesses, MCP is seen as the current way to go.
“it's back to Agent <> MCP now; couple that with tool search/code mode (whatever you want to call it) in your Agentic AI harness, MCPs seem to be the way to go for now.”
Local control · 1
Running local servers lets users choose trusted servers, see every tool call and deny anything suspicious.
“the local tool-use model works well because I control both sides”
Caveats and dissent
Unnecessary abstraction · 2
Some argue CLIs, APIs and skills now do the job better, and that MCP carries baggage from earlier, less capable models.
“I still think MCP is completely unnecessary (and have from the start).”
“I'm frustrated to see that new projects on my team still consider MCP as a reasonable first pass solution”
Poor spec · 1
One commenter calls the specification poorly thought out and poorly communicated, with broken navigation links.
“anybody involved with MCP's launch should be ashamed of what they put out there”
Agent adoption · 1
Agents may not use MCP tools unless explicitly asked, with Claude preferring the shell.
“MCP is nice, but does your agent use it without you explicitly asking it to do so?”
Performance, robustness · 1
Even supporters concede it is not performant, robust or uniform yet.
I appreciate their reluctance towards MCP, but /something/ is better than nothing. It’s suboptimal for the reasons the author outlines: but so is USB-C. So is NVME, so is HDMI. We use these hugely successful technologies in spite of their flaws because they’re widely compatible and easy for the end user. That’s why MCP is everywhere. It might not be performant, robust and uniform but it WILL get better over time. And
Often compared with
Who recommends it in their own words
Threads where it came up
- Zero-Touch OAuth for MCP 2 mentions
- You said no MCP 1 mention
- MCP was always a bad idea? 1 mention
- Ask HN: Who is using MCP in production? 1 mention
- New MCP Roadmap 1 mention
- Stateless MCP has recaptured my interest 1 mention
Data: mcp.json. Quotes are verbatim; the verdict and theme labels are written by a model from these comments, and every clause links to its sources.
All comments 12
I appreciate their reluctance towards MCP, but /something/ is better than nothing. It’s suboptimal for the reasons the author outlines: but so is USB-C. So is NVME, so is HDMI. We use these hugely successful technologies in spite of their flaws because they’re widely compatible and easy for the end user. That’s why MCP is everywhere. It might not be performant, robust and uniform but it WILL get better over time. And
“MCP is exactly the lipstick we needed to put on our pigs”
“I'm frustrated to see that new projects on my team still consider MCP as a reasonable first pass solution”
“I use MCP to accelerate CAD mould-making and for music production.”
“MCP is nice, but does your agent use it without you explicitly asking it to do so?”
“I am a complete convert.”
“So mcp is really an "app framework" than a protocol”
“it's back to Agent <> MCP now; couple that with tool search/code mode (whatever you want to call it) in your Agentic AI harness, MCPs seem to be the way to go for now.”
“anybody involved with MCP's launch should be ashamed of what they put out there”
“I still think MCP is completely unnecessary (and have from the start).”
“the local tool-use model works well because I control both sides”
“MCP is going to be around for a long time, and we can expect it to get much better than it is today.”