For a terminal-capable agent with broad network access, MCP is often optional - it can just call documented APIs and command-line tools directly. For anything that needs scoped permissions, credential isolation and an audit trail, MCP is still the cheapest way to get there. The argument that circulated in September 2026 is really an argument about how much freedom you give the agent.
Key facts
| Fact | Detail |
|---|---|
| Question answered | Is MCP still worth using in 2026? |
| Short answer | It depends on how much freedom your agent has. |
| Reading time | ~3 min |
| Last updated | 2026-09-23 |
The claim: MCP was always a bad idea
On 14 September 2026, Maharshi Patel published Why MCP Was Always a Bad Idea. The argument runs in three steps.
First, MCP arrived in November 2024, when models were weaker and agentic workflows were far less reliable - the protocol was designed for that era. Second, adoption brought context bloat: every server ships several tools, each with its own schema, and a busy setup can spend a large part of the context window before any real work begins. Third, and most important, the models changed: they write and run scripts, call APIs directly, and discover command-line tools with the –help flag. Since most remote MCP servers wrap APIs that already exist, the author conclusion is blunt - delete most of your MCP servers, and standardise how agents call HTTP APIs instead, for example servers honouring the Accept: text/markdown header so a documentation site returns Markdown rather than HTML.
It is worth reading the whole piece rather than the headline. The author also says the gateway pattern - one place to hold credentials, plus a deliberately small tool set - is a good thing for the short term, and points to the Cloudflare Code Mode approach as a better way to use MCP by having the model compose calls into a script.
The counterargument: what MCP still buys you
Simon Willison replied on 20 September 2026 that the article “entirely misses the value that MCP brings today”. He accepts the narrow case: with a full terminal agent and unfettered internet access, there is almost no reason to use MCP - let it call APIs directly.
But if you want something less permissive than that, he argues you end up wanting four things:
- control over exactly which external services the agent can access;
- authentication that does not let the agent touch your raw API keys;
- a sensible UI where a person connects and authenticates further services;
- strong audit logging of what actually happened.
MCP makes all four of those easier to provide. That is a different design goal from handing an agent a terminal and hoping, and it is why the protocol has not been replaced by direct API calls in products that have to be accountable.
Where the two actually agree
Both sides accept that a terminal-capable agent can replace a lot of MCP servers. The disagreement is about the environment: unfettered access versus a scoped, auditable one.
So the useful question is not “MCP: yes or no”. It is “how much am I willing to let this agent touch?”
A five-line decision checklist
- Does the service already have a documented API or CLI? If yes, direct calls may be enough.
- Would adding this server expose credentials you would rather keep isolated?
- Do you need per-service permissioning, or is one blanket network allowance fine?
- Could you answer “what did the agent do yesterday” from a log?
- Is your context budget tight? Prefer one gateway with a minimal tool set over a dozen broad servers.
If you hesitate on credential isolation, or on the log question, MCP is doing real work for you and is worth keeping.
What this means on a Windows desktop agent
On a desktop agent the same trade-off shows up as a permissions question. A client that runs tasks on your own machine needs a bounded way to reach outside services, and it needs to leave a record you can read afterwards - which is the gap MCP fills.
MOOGH extension architecture is built around Skills, Plugins and MCP, so capability is installed per task instead of being hard-wired into the client. If you want to feel how an approval step works in practice, download MOOGH for Windows and start with something small.
Related reading: