Like JSON, MCP solves a problem without being overengineered. Both are painful for the overengineering type.

CLI first

Bad take. And what's coming down the pipe with MCP will cement it. Has less with the model calling tools and will become about tools calling models. There is no unified integration into harnesses to support this other than MCP.

Shady title with "?" not to own the statement.

Ending with a question is a shady media way of getting aroudn the legal issue of taking responsibility.

I hate blog titles like this as the author doesn't want to take responsiblity for the claim.

Yet again, using HTTP as intended is a better solution than bespoke protocols.

MCP always seemed like something that wouldn't be necessary if AI lived up to the hype.

I have mixed feelings about this. Going all-in on Model Context Protocol (MCP) is definitely a bad idea because I noticed the Jira and GitLab MCPs were consuming an excessive amount of tokens. To solve this, I decided to install their respective CLIs instead so we could find a balance and get the best of both worlds. For example, certain MCPs bring too much overhead, especially when they only handle a single task. Instead of letting the coding agent constantly waste resources re-discovering how to fetch a specific work item field, I had Claude recursively run --help on the CLIs and save all possible actions into separate Markdown files. This approach allowed me to build two lightweight plugins that do exactly what an MCP is supposed to do but with significantly less token consumption. If anyone wants to check out the code or use them, I have open-sourced both repositories on my profile:

* * acli-skills: An Atlassian CLI agent skill that maps out Jira commands cleanly. * glab-skills: A GitLab CLI companion built directly for efficient agent workflows. *

To maintain visibility with this setup, we also developed a custom [Claude Code](https://code.claude.com/docs/en/plugins) plugin that streams live updates regarding our background operations directly into the console. That said, MCPs are still extremely useful for rapid prototyping and when we build custom internal tools to speed up development. We found them particularly valuable for:

* * Sampling: Asking the LLM directly to detect entities and summarize log files. * Notifications: Handling long-running tasks that require fetching data from multiple sources. By logging each step and aggregating them via sampling, a single update is sent back to the coding agent, preventing it from spinning up multiple redundant processes. *

MCP is now only good at getting credentials from any source. If SaaS cared about their API the same way we would have OAuth for all APIs, MCP would just die

Maybe I'm not "using it right" but I often spin up my own MCPs as an authorisation control mechanism, as a wrapper around existing tools. For example, an MCP server that can only do GET requests. This way I can stay relatively secure about the fact that when the agent uses the MCP, it isn't going to mistakenly execute something I didn't want it to.

I know there are other ways to achieve this but to me this, but they all seem "soft" controls - a hard limitation feels more reassuring than simply a line in context that says "don't do this".

In the spirit of the linked post, one could argue I should just write cli wrappers - but I think I like the explicit routing of `Agent -> MCP -> available tools` instead of `Agent -> available tools`. The former lets me control the surface available to the agent. While LLMs are smarter now, at the same time, the applications that use those LLMs have become more assuming of what I want to allow them to do. I don't want to be one hallucination away from a disaster.

Why are they still having this debate in 2026 when CodeAct have existed for years, and the LLM's are getting much better at coding in the first place?