Mmcp.market

MCP explained

MCP vs CLI

Coding agents that can run a shell already have thousands of tools: git, gh, kubectl, psql, the Playwright CLI. So why add an MCP server at all? Sometimes you should not.

The short answer

If the agent has a shell and the tool has a good CLI it already knows, the CLI is often cheaper and simpler. MCP wins when there is no shell, when you need scoped auth or a remote service, or when you want typed tools and per-tool permissions.

MCP and CLI side by side

MCPCLI
Needs a shellNoYes
How the model learns itTool list and schemas sent on connect--help output, and what it saw in training
Context costEvery tool description loads up frontOnly the output of commands actually run
AuthOAuth or scoped keys held by the serverWhatever credentials the shell has
PermissionsPer tool: allow reads, ask before writesPer command, if your client supports it
Works in chat appsYes (Claude, ChatGPT and others)Only where a terminal exists

What MCP is, in one paragraph

The Model Context Protocol is an open standard, first published by Anthropic in November 2024, for connecting AI applications to outside tools and data. An MCP server describes what it can do (tools the model can call, resources it can read, prompt templates) in a machine-readable way, and any MCP client, such as Claude, Cursor, VS Code or ChatGPT, can connect to it without custom glue code. Messages are JSON-RPC 2.0, sent over standard input and output for a local server or over HTTP for a remote one.

The case for the CLI

Well known command-line tools are in every model's training data. An agent already knows how to use git, gh, docker and curl, and it can pipe one into another. Nothing loads until a command runs, so a CLI costs no context up front, while an MCP server with forty tools puts forty descriptions in the prompt on every turn.

For a coding agent in a terminal, using the CLI a developer would use is often the most reliable option. Browser automation shows the trade-off well: the same clicks and page reads cost far less context as shell commands than as a large browser tool list sent on every turn.

The case for MCP

Many places an agent runs have no shell: Claude and ChatGPT in the browser, a customer support bot, an agent in a Slack workspace. There, MCP is the only standard way to reach tools.

MCP also handles things a shell does not. A remote MCP server can use OAuth, so the agent gets a scoped token instead of your full credentials. Clients can approve tools one by one, letting reads run freely and asking before any write. And many services have no good CLI at all.

How to choose

Use the CLI when the agent has a terminal, the tool is widely known, and the credentials on that machine are ones you are happy for the agent to use.

Use MCP when the agent runs somewhere without a shell, when you need auth scoped to less than a full account, when the service is remote with no CLI, or when you want the client to ask before every write action.

Safety either way

A shell gives an agent everything the user can do. An MCP server gives it everything the server's tools can do, which is usually less, but a local MCP package still runs code on your machine. Check what a package runs at install time, whether it shells out with strings built from model input, and which of its tools write.

Questions people ask

Is MCP better than letting an agent use the terminal?
Not always. In a terminal, a well known CLI is often cheaper and just as reliable. MCP is better where there is no terminal, or where you need scoped auth and per-tool approval.
Why do MCP servers use so many tokens?
Every tool's name, description and input schema is sent to the model when the client connects, so a large server costs context on every turn. Clients increasingly load tools on demand to cut this.
Can an MCP server run shell commands?
Some do. Treat those like giving the agent a terminal, and check the safety report for command injection findings first.
Browser automation MCP servers DevOps MCP servers What the safety scan checks