This article entirely misses the value that MCP brings today.
Sure, there's almost no reason to use MCPs if you are running a full-blown terminal agent (Claude Code, Codex, Meta Muse, OpenClaw etc) with unfettered internet access - just let it call APIs directly.
If you want to operate something that's less YOLO than that, you'll find yourself wanting:
1. Control over exactly which external services it can access
2. A way to handle authentication that doesn't allow the agent to directly access API keys
3. A sensible UI to allow users to connect and authenticate further services
4. Strong audit logging for what's going on
MCP makes all of that so much easier to provide.
Thinking MCP is obsolete because full coding agents don't need it misses out on all of the other things we might want to build.
> there's almost no reason to use MCPs if you are running a full-blown terminal agent
I disagree. Adding "<a href="https://mcp.linear.app/mcp" rel="nofollow">https://mcp.linear.app/mcp" and having everything happen (discovery, usage, updates to the API, etc) without having to install or configure anything else locally is a big deal.
Funny you mention Linear’s specifically, I just posted about moving to a CLI instead because of the MCP’s egregious token-usage [1]. While this doesn’t discount the points you mentioned, I think the context savings (which can be huge, I hadn’t listed all differences in that post) outweigh them specifically in Linear’s case. It is just too inefficient in that regard.
Edit: this of course says nothing about MCP vs API/CLI in general. It’s just a bad implementation by Linear.
This surprises me a bit. I've found much better token usage with a proper/efficient MCP as even with a deep /skill defining usage, parsing MCP results is generally just better/more efficient than parsing CLI results. I say this having written a CLI tool explicitly for harness usage, and leveraging MCPs for the same.
I'm sure there are bad MCPs and great CLI tools that parse poorly/well via harness, but I'd be curious on an better research study.
Your comment doesn’t contradict mine and mine doesn’t contradict yours. Linear’s MCP is just (very?) inefficient. I explain the source of the difference in the last two paragraphs.
simonw · · focus · HN ↗
Sure, there's almost no reason to use MCPs if you are running a full-blown terminal agent (Claude Code, Codex, Meta Muse, OpenClaw etc) with unfettered internet access - just let it call APIs directly.
If you want to operate something that's less YOLO than that, you'll find yourself wanting:
1. Control over exactly which external services it can access
2. A way to handle authentication that doesn't allow the agent to directly access API keys
3. A sensible UI to allow users to connect and authenticate further services
4. Strong audit logging for what's going on
MCP makes all of that so much easier to provide.
Thinking MCP is obsolete because full coding agents don't need it misses out on all of the other things we might want to build.
jwr · · focus · HN ↗
I disagree. Adding "<a href="https://mcp.linear.app/mcp" rel="nofollow">https://mcp.linear.app/mcp" and having everything happen (discovery, usage, updates to the API, etc) without having to install or configure anything else locally is a big deal.
shibel · · focus · HN ↗
Edit: this of course says nothing about MCP vs API/CLI in general. It’s just a bad implementation by Linear.
1: <a href="https://thebiglog.com/links/linear-cli-instead-of-linear-mcp" rel="nofollow">https://thebiglog.com/links/linear-cli-instead-of-linear-mcp
w0m · · focus · HN ↗
I'm sure there are bad MCPs and great CLI tools that parse poorly/well via harness, but I'd be curious on an better research study.
shibel · · focus · HN ↗