MCP vs CLI for AI Agents: When a Command Line Beats a Server

Use a CLI when the agent already runs in a shell, on a machine where the tool is installed and signed in, and the tool is one the model knows or can learn from --help: git, gh, a cloud provider’s CLI, your own build scripts. It costs almost nothing in context until it is used, it composes with pipes, and it needs no extra server. Use an MCP server when the assistant has no shell (Claude or ChatGPT in a browser), when the access should be a scoped, revocable grant made through a sign-in rather than whatever is logged in on that machine, when one integration has to work across several assistants and people, or when the service is remote and nothing should be installed. Most teams that use agents heavily end up with both, split by job.

This is the general case. The tool-by-tool versions, with real commands and each vendor’s limits, are in Trello MCP or CLI, Todoist MCP vs CLI and Linear MCP vs CLI vs API. If the comparison you need is a server against a script calling the API, see MCP vs REST API.

The two shapes

• CLI: the agent writes a command as text, the shell runs it with the machine’s environment and stored credentials, and the agent reads standard output, standard error and the exit code.
• MCP: the client connects to a server, receives a list of named tools with descriptions and input schemas, and the model calls a tool by name with JSON arguments. The server decides what each tool may do, and returns a result the protocol defines.

Discovery

An MCP server tells the client what it can do every time it connects: tools/list returns each tool’s name, description and input schema, and the model chooses from that list. Nothing depends on what the model learned in training. A CLI relies on one of two things. Either the model already knows it well, which is true of git, gh and the big cloud CLIs, or it reads the help. Anthropic’s Claude Code best practices↗ (opens in a new tab) suggest exactly that for unfamiliar tools: tell Claude to run foo-cli-tool --help and then use it. For an internal CLI with thin help text, that is where agents go wrong, and an MCP server with good descriptions is the more reliable door.

Context cost

This is the argument most often made for CLIs, and it is real. The same best-practices page calls CLI tools “the most context-efficient way to interact with external services”. A CLI costs nothing until the agent runs it, and then only the output it chose to print, which it can cut down with --json, jq, head or grep before reading.

MCP’s cost depends on the client. Anthropic’s engineering post on code execution with MCP↗ (opens in a new tab) notes that most clients load every tool definition into context up front, and that intermediate results pass through the model as well. Claude Code now defers them: with tool search, on by default, only tool names and server instructions load at the start and full schemas load when needed. Results are still bounded by what the server returns, and Claude Code warns when one tool result passes 10,000 tokens. So the gap is smaller than it was, but a well-used CLI is still the cheapest option in tokens.

Auth, and whose credentials

A CLI runs as whoever is signed in on that machine. That is usually you, with your whole account, and the token often sits in a config file every process on the machine can read. Handing an agent a shell hands it that credential too. Narrowing it means creating a separate token with fewer rights, if the service supports one, and remembering to use it.

A remote MCP server signs in with OAuth. The person sees a consent page and approves a grant, and the MCP authorization specification↗ (opens in a new tab) requires clients to request tokens for that specific server, so a token issued for one server cannot be replayed at another. The grant can carry scopes and can be revoked without touching the person’s own sign-in. A local stdio MCP server that takes an API key from an environment variable is no better than a CLI on this point: the real line is between a shared machine credential and a per-client grant.

Structured results and errors

A CLI returns text, an exit code and whatever it wrote to standard error. Many modern CLIs add a JSON mode (gh issue list --json number,title is typical), and the agent then has to know that flag exists. An MCP tool result has a defined shape: text for the model, optional structuredContent matching an output schema, and an isError flag for a failure the model should read and correct. Errors are where this shows. A CLI that prints a usage message and exits with 1 tells the agent little; a tool that returns “No task T-9. Call list_tasks to see the ids” tells it what to do next.

Control in the client

Both can be restricted, but differently. MCP tools have fixed names, so a client can allow them one by one; in Claude Code a rule such as mcp__github__get_* allows only one server’s read tools. Shell commands are strings, so rules match patterns. Claude Code’s permissions documentation↗ (opens in a new tab) shows the traps: Bash(git log *) allows only git log, but Bash(git *) allows every git subcommand, including options that make git run another program. A CLI allow-list is workable, and it needs more care than a tool list.

Sharing across tools and people

One MCP server works in every client that speaks the protocol: Claude Code, Claude on the web, ChatGPT, Cursor, VS Code with Copilot. You describe the tools once and each person connects with their own sign-in. A CLI works only where there is a shell, has to be installed on every machine the agent runs on, and is signed in separately each time. For a chat assistant in a browser, a CLI is not an option at all.

Remote use

A remote MCP server is a URL. Nothing is installed, the vendor updates it, and a cloud agent can reach it as easily as your laptop can. A CLI has to be present wherever the agent runs, which in a cloud sandbox means installing it on every run and getting a credential into that environment safely. That is fine for git, which is already there, and more work for anything else.

Audit

With a CLI, the service sees your credential, so its own logs show you. The only record that separates what the agent did from what you did is the agent’s transcript. With MCP it depends on the server: the grant belongs to a named client, so a server can record which assistant acted and for whom. Not every server does, so check before you rely on it; the audit trail for AI agents covers what a useful record contains.

When each wins

• CLI: coding agents in a terminal, tools the model knows well, one-off or piped work, local tools with no server, and anything where every token counts.
• CLI: work that already has a trusted, narrow credential on the machine, such as a CI job with its own token.
• MCP: assistants without a shell, and any setup shared by several people or several different assistants.
• MCP: access that should be granted through a sign-in, limited by scopes and revocable on its own.
• MCP: internal tools whose CLI help would not teach a model enough, and services with no CLI at all.

Using both

The usual split in a coding agent is by job. Source control and builds go through the CLI (git, gh, the test runner), because the agent is in a shell anyway and those tools are cheap and well known. The systems where work is planned and recorded, such as a tracker, a board or a wiki, go through MCP, because the same connection also serves the people who use a chat assistant, and the grant is scoped and revocable. Put the rule in the project’s instructions file so the agent does not choose afresh each session. And where the job is a procedure rather than a connection, a skill can describe steps that call either; MCP vs Claude Skills covers that third option.

Where fenbs sits

fenbs, a task board where AI assistants are members with roles, offers MCP as its door for assistants, at https://fenbs.ai/api/mcp. A person connects an assistant through a browser sign-in and ticks what it may do: reading is always on, adding and changing tasks and commenting are optional. A script, a CI job or a client with no browser uses a token issued by hand under Settings, “Connect an AI assistant”, with a name, scopes and an optional expiry, sent as an Authorization: Bearer header. A client that speaks only stdio runs the fenbs-mcp bridge (npx -y fenbs-mcp) with that token in the FENBS_TOKEN environment variable. Either way the token holds no more than the person’s role, revoking it stops it at once, and every change is recorded in History as, for example, “Claude via Sam Ade”.