Is this article from a while back?

> Before your agent can do anything useful, it needs to know what tools are available. MCP’s answer is to dump the entire tool catalog into the conversation as JSON Schema. Every tool, every parameter, every option.

Because this simply isn't true anymore for the best clients, like Claude Code.

Similar to how Skills were designed[1] to be searchable without dumping everything into context, MCP tools can (and does in Claude Code) work the same way.

See https://www.anthropic.com/engineering/advanced-tool-use and https://x.com/trq212/status/2011523109871108570 and https://platform.claude.com/docs/en/agents-and-tools/tool-us...

[1] https://agentskills.io/specification#progressive-disclosure

There is some important context missing from the article.

First, MCP tools are sent on every request. If you look at the notion MCP the search tool description is basically a mini tutorial. This is going right into the context window. Given that in most cases MCP tool loading is all or nothing (unless you pre-select the tools by some other means) MCP in general will bloat your context significantly. I think I counted about 20 tools in GitHub Copilot VSCode extension recently. That's a lot!

Second, MCP tools are not compossible. When I call the notion search tool I get a dump of whatever they decide to return which might be a lot. The model has no means to decide how much data to process. You normally get a JSON data dump with many token-unfriendly data-points like identifiers, urls, etc. The CLI-based approach on the other hand is scriptable. Coding assistant will typically pipe the tool in jq or tail to process the data chunk by chunk because this is how they are trained these days.

If you want to use MCP in your agent, you need to bring in the MCP model and all of its baggage which is a lot. You need to handle oauth, handle tool loading and selection, reloading, etc.

The simpler solution is to have a single MCP server handling all of the things at system level and then have a tiny CLI that can call into the tools.

In the case of mcpshim (which I posted in another comment) the CLI communicates with the sever via a very simple unix socket using simple json. In fact, it is so simple that you can create a bash client in 5 lines of code.

This method is practically universal because most AI agents these days know how to use SKILLs. So the goal is to have more CLI tools. But instead of writing CLI for every service you can simply pivot on top of their existing MCP.

This solves the context problem in a very elegant way in my opinion.

These days you can rewrite everything yourself for very cheap. So this is `mcporter` rewritten. I prefer to use Rust personally for rewrites. Opus 4.6 can churn it out pretty quickly if that's what you want.

This looks related to Awesome CLIs/TUIs and terminal trove which has lots both CLI and TUI apps.

Awesome TUIs: https://github.com/rothgar/awesome-tuis

Awesome CLIs: https://github.com/agarrharr/awesome-cli-apps

Terminal Trove: https://terminaltrove.com/

I guess this is another one shows that the CLI and Unix is coming back in 2026.

Hehe... nice one. I think we are all thinking the same thing.

I've also launched https://mcpshim.dev (https://github.com/mcpshim/mcpshim).

The unix way is the best way.

True for coding agents running SotA models where you're the human-in-the-loop approving, less true for your deployed agents running on cheap models that you don't see what's being executed.

But yeah, a concrete example is playwright-mcp vs playwright-cli: https://testcollab.com/blog/playwright-cli

Not just cheaper in terms of token usage but accuracy as well.

Even the smallest models are RL trained to use shell commands perfectly. Gemini 3 flash performs better with a cli with 20 commands vs 20+ tools in my testing.

cli also works well in terms of maintaining KV cache (changing tools mid say to improve model performance suffers from kv cache vs cli —help command only showing manual for specific command in append only fashion)

Writing your tools as unix like cli also has a nice benefit of model being able to pipe multiple commands together. In the case of browser, i wrote mini-browser which frontier models use much better than explicit tools to control browser because they can compose a giant command sequence to one shot task.

https://github.com/runablehq/mini-browser

I like this approach ... BUT the big win for me is audit logs. CLIs naturally leave a trail you can replay.

ALSO... the permission boundary is clearer. You can whitelist commands, flags, working dir... it becomes manageable.

HOWEVER... packaging still matters. A “small” CLI that pulls in a giant runtime kills the benefit.

I want the discipline of small protocol plus big cache. Cheap models can summarize what they did and avoid full context in every step...

I’m not sure how this works. A lot of that tool description is important to the Agent understanding what it can and can’t do with the specific MCP provider. You’d have to make up for that with a much longer overarching description. Especially for internal only tools that the LLM has no intrinsic context for.

This sounds similar to MCPorter[0], can anyone point out the differences?

[0] https://github.com/steipete/mcporter