MCP Server or CLI: A Decision Rubric for Developer Tooling

Teams are rushing to make their internal tools available to agents. That is good. It is also where a lot of design mistakes begin.

The question usually shows up like this:

Should we expose this as an MCP server, or should the agent just use our CLI?

That framing makes it sound like one option is more “agentic” than the other. I do not think that is the useful distinction. A CLI and an MCP server solve different problems. The better question is: where does this capability naturally live, and what contract does the agent need in order to use it well?

MCP, now hosted by the

Start with the workflow

A CLI is strongest when the workflow already belongs to a human developer.

If the task is repo-local, terminal-native, and already part of how developers build, test, debug, or ship software, start with the CLI. Developers know how to inspect it. CI can run it. Logs are usually visible. Failures can be reproduced outside the agent. The same interface works for humans, scripts, and automation.

Good CLI-shaped examples:

• Running a project-specific code generator


• Applying a migration in a local development environment


• Linting, formatting, testing, or packaging


• Inspecting repo state


• Scaffolding files inside a checked-out project


• Running one-off diagnostics where stdout and exit codes are enough

An MCP server is strongest when the workflow does not naturally belong in a terminal session, or when the agent needs a structured, discoverable capability instead of a command string.

Good MCP-shaped examples:

• Reading from or writing to a SaaS API


• Searching a private knowledge base


• Fetching typed records from an internal system


• Performing actions that need scoped authorization


• Exposing capabilities across multiple agent clients


• Providing context as resources, not just command output


• Giving the agent a constrained set of tool calls instead of broad shell access

The trap is assuming that “agent can run command” and “agent has a good tool interface” are the same thing. They are not.

A CLI gives an agent a way to execute. MCP gives an agent a way to understand what capabilities exist, what inputs they accept, and what kind of result comes back.

fits naturally: document which commands are safe, how to run tests, what directories are off-limits, and what failure modes are expected.

The CLI should be boring in the best way:

• Clear subcommands


• Stable flags


• Machine-readable output where useful


• Non-zero exit codes on failure


• Dry-run modes for risky actions


• Good help text


• No hidden interactive prompts in automation paths

If the tool needs a human to make judgment calls mid-run, keep that interaction in the CLI. Do not hide it behind an MCP tool and pretend the workflow became autonomous.

2. Does the agent need to discover the capability?

If yes, lean toward MCP.

One of the real advantages of MCP is that tools can be described to the agent as tools. The agent does not need to infer everything from a README, shell history, or tribal knowledge. It can see available tool names, descriptions, schemas, and expected inputs.

That matters when the capability is meant to be reused across agents or across teams.

A CLI can be documented well, but discovery is still indirect. The agent needs to know the command exists, know where it is installed, know how to call it, and know how to interpret the output. MCP makes the capability part of the agent’s tool surface.

Use MCP when the agent should be able to answer questions like:

• What tools are available to me?


• What arguments does this action require?


• What resources can I inspect?


• What shape will the result have?


• What actions are allowed in this environment?

This is especially useful for APIs and internal systems where a raw CLI would either expose too much or force the agent to learn a human-oriented interface.

3. Where is the auth boundary?

If the action crosses an authorization boundary, consider MCP carefully.

A CLI often inherits the developer’s local environment: shell credentials, config files, tokens, SSH agents, cloud profiles. That can be fine for local workflows. It can also be too broad for agent access.

MCP gives teams a cleaner place to define permission boundaries. The server can expose only the operations the agent should have. It can scope credentials server-side. It can validate inputs before touching the underlying system. It can log tool calls in a way that is easier to review than arbitrary shell execution.

This does not make MCP magically safe. A poorly designed MCP server can still be dangerous. But the server boundary gives you a place to enforce policy.

Ask:

• Should the agent inherit the user’s full shell environment?


• Should this action use delegated or scoped credentials?


• Do we need per-tool authorization?


• Do we need audit logs of agent actions?


• Do we need to prevent arbitrary command composition?

If the answer to those questions is yes, a CLI alone may be too blunt.

For production-facing systems, this is also where infrastructure projects like

A good pattern is:

• The CLI remains the human and CI interface.


• The MCP server exposes selected capabilities for agents.


• Shared core logic lives below both interfaces.


• The MCP server does not become a dumping ground for every CLI command.


• The CLI does not become an escape hatch for unsafe agent actions.

For example, imagine an internal deployment tool.

The CLI might support the full developer workflow: build, validate, preview, deploy, rollback, inspect logs, and run local checks. It assumes the user is a developer with repo access and deployment permissions.

The MCP server might expose narrower tools: get deployment status, list services, create a preview environment, request a rollback plan, or fetch logs for a specific service. Those tools can have tighter schemas and safer defaults. They can also return structured data that an agent can reason over without parsing terminal output.

Both interfaces can call the same underlying deployment library. They do not need to expose the same surface area.

That separation is healthy. Humans need power tools. Agents need constrained capabilities with clear contracts.

A practical decision guide

Use a CLI when:

• The task is repo-local or terminal-native


• Humans need to run it directly


• CI should run the same interface


• Shell composition is a feature


• Text output and exit codes are enough


• The auth model is already appropriate for the local developer context

Use an MCP server when:

• The agent needs discoverable tools or resources


• The task touches an external system


• Inputs and outputs should be typed


• Permissions need to be scoped


• Multiple agent clients should share the same integration


• The tool should hide implementation details


• Auditability and policy matter

Use both when:

• Humans and agents both need the capability


• The CLI is already valuable


• The MCP server can expose a safer or more structured subset


• Shared core logic can prevent drift


• The agent interface should be stable even if the CLI evolves

Do neither, at least for now, when:

• The workflow is not understood yet


• The tool would expose broad credentials without guardrails


• The “agent use case” is just novelty


• A README update would solve the immediate problem


• The maintenance owner is unclear

What this means for the open agentic AI ecosystem

The open agentic AI ecosystem needs standards like MCP. It also needs restraint.

If every team turns every script into an MCP server, agents get a larger tool list but not necessarily better tools. Tool overload is real. Poor descriptions, loose schemas, unsafe side effects, and noisy outputs make agents worse, not better.

The goal is not to make everything agent-accessible. The goal is to make the right capabilities available through the right contract.

That is why this decision matters so much at this particular moment. MCP gives builders a common way to expose tools and context. AGENTS.md gives projects a common place to tell coding agents how to work inside a repo. agentgateway points toward the operational layer teams need when agent traffic becomes production traffic.

These projects are stronger when we use them for the problems they actually solve.

A CLI is not “less agentic” because it runs in a terminal. An MCP server is not “better architecture” because it speaks a protocol. The useful line is simpler:

If the work belongs in the developer workflow, start with a CLI.

If the agent needs a structured, discoverable, permissioned capability, build an MCP server.

If both humans and agents need it, design both surfaces intentionally and keep the shared logic underneath.

That is the rubric. Not CLI versus MCP. CLI where the workflow lives. MCP where the capability needs a contract.