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.
Exactly, in our company, we have built MCPs that simplifies interactions with internal tools we use a lot, which saves time and tokens. Sure, we could let the agent poke and fumble around with a not-so-ideal API too, but it makes sense to formalize it and give the agents quick access to what we want it to fetch 99% of the time.
What interactions with internal tools? If you can answer that question then the clankers can help you write a deterministic program for that same interaction and you only spend the tokens once.
I've been doing this myself but it's been extremely hard to get buy-in from the rest of the org. They keep churning MCPs for deterministic interactions while I have tons of little tools written by clankers, not only for clanker-use but also for my own use when needed.
> If you can answer that question then the clankers can help you write a deterministic program for that same interaction and you only spend the tokens once.
The MCP is the deterministic program.
You need to take a step back and look at the problem you're discussing. What's exactly this MCP thing? It's a protocol to allow agents and coding assistants to access tools, services, and data sources, through a standardized interface.
It's the interface for your deterministic program. That's it.
It's easier if you started a while back shunning all human labor (including your own) in favor of fully deterministic systems. Reality is deterministic so your company or project logically can be run off a single compiled binary with formal verification of correctness for every possible scenario.
Retrieving messages from Slack over MCP allows a shared read-only bot account accessible from the web browser and CLI. Setup is automated so users can just ask Claude to read them and do something.
Sharing Slack with Claude:
- Using the "normal" way, it shares too much, including privates messages.
- Using your own token, it doesn't work with Claude.AI or Cowork and requires you to go to slack.com to generate an application, tokens and more.
- Using a shared token, now you need context to tell Claude to retrieve it. It still doesn't work for non-Claude Code workflows. Rotation may break currently running workflows.
Yeah. Like I had Claude code write an upload Slab script, and a few linear integration scripts, now it just runs these to interact with those systems. I had it write a redshift proxy that doesn’t take login creds and is just a logging read only account but it can just write sql to research to its hearts content (some columns hashed on replies) and I don’t need much trust but I get a lot of good analysis and verification done.
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.
rsolva · · focus · HN ↗
0x445442 · · focus · HN ↗
piva00 · · focus · HN ↗
Best of both worlds in my view.
0x696C6961 · · focus · HN ↗
mjmas · · focus · HN ↗
0x445442 · · focus · HN ↗
jimbokun · · focus · HN ↗
wezabis · · focus · HN ↗
[dead]
locknitpicker · · focus · HN ↗
The MCP is the deterministic program.
You need to take a step back and look at the problem you're discussing. What's exactly this MCP thing? It's a protocol to allow agents and coding assistants to access tools, services, and data sources, through a standardized interface.
It's the interface for your deterministic program. That's it.
8note · · focus · HN ↗
locknitpicker · · focus · HN ↗
That only applies if you are talking about a well established recurrent workflow. That's not how MCPs are used to begin with.
themgt · · focus · HN ↗
jimbokun · · focus · HN ↗
shwaj · · focus · HN ↗
jimbokun · · focus · HN ↗
Sayrus · · focus · HN ↗
Sharing Slack with Claude:
- Using the "normal" way, it shares too much, including privates messages.
- Using your own token, it doesn't work with Claude.AI or Cowork and requires you to go to slack.com to generate an application, tokens and more.
- Using a shared token, now you need context to tell Claude to retrieve it. It still doesn't work for non-Claude Code workflows. Rotation may break currently running workflows.
lanstin · · focus · HN ↗
jimbokun · · focus · HN ↗
Less token spend, lower latency, more predictable results compared to having the LLM perform the task directly every time.