# MCP vs. Bash > Source: > Published: 2026-08-03 06:41:34+00:00 # MCP vs. Bash ## In Which the Author Winds Up Treating the Latter as a Verb With major coding agent harnesses, you have two main ways to extend their functionality: - Let them run command-line programs using a tool (Claude Code calls the tool `Bash` , despite it perhaps not using that specific shell) - Use the Model Context Protocol (MCP) In theory, I have preferred MCP, though my experience has somewhat mirrored [Simon Willison's](https://simonwillison.net/2026/Jul/31/stateless-mcp/). Shell access is super-flexible, after all. However, the problem is that shell access is super-flexible. As Simon put it: Giving an agent a shell environment with the ability to access the internet is fraught with risk, and requires a strong model that is capable of effectively driving such an environment. MCP tools are easier to audit and control, and simple enough that smaller models that run on a laptop can still drive them reasonably well. Simon's post is about [MCP 2.0](https://blog.modelcontextprotocol.io/posts/2026-07-28/). This revision simplifies the protocol, making it stateless, whereas before there were session handles that had to be tracked by the harness. My sincere hope is that more toolsmiths will adopt MCP and offer them alongside CLI access. Even though third parties can sometimes fill the gap, I would *much* rather use first-part options. For example, consider Gradle. It has a rich CLI and a rich API. What it lacks is its own MCP support. There is [a popular third-party MCP server for Gradle](https://github.com/rnett/gradle-mcp), and you need to be comfortable adding that third party to your build process, at least for agent-triggered builds. Some developers will have no issue with this, and others will be a bit reticent. Ideally, the Gradle team will add their own MCP support someday, and perhaps the simpler MCP 2.0 will accelerate that support. One argument against MCP is verbosity. In effect, MCP adds a bunch of tools to your harness. Tools, like skills, add bloat to your system prompt. Folks are working on solutions to that, to allow agents to progressively "discover" what they need for a given interaction, rather than include all possibilities in the system prompt. For example, the agent harness, through the system prompt, could offer support for "search for skills and tools" — the output of that gives the agent stuff to use that are in context (i.e., likely to be relevant to the work at hand) as well as being in context (here referring to the chat transcript). My next chunk of work on Knosh will be adding MCP client support via [Koog's MCP API](https://docs.koog.ai/model-context-protocol/). Right now, that certainly only supports the original MCP, but in time is likely to get upgraded to MCP 2.0. As we continue to try to better lock down coding agents, I expect there will be increased interest in MCP, because shell access is just too open. Besides, perhaps it will help cure Claude of its Python addiction. 😀