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 Agentic AI Foundation under the Linux Foundation, gives the open agentic AI ecosystem a shared protocol for connecting agents to tools, data, and applications. That shared protocol matters because teams should not have to rebuild the same integration patterns for every agent runtime. But MCP is not a reason to wrap every executable in a server. Sometimes a CLI is exactly the right interface. Sometimes an MCP server is. Often, the answer is both, with different responsibilities.

Here is the rubric I use.

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.

The five-question rubric

When deciding between a CLI, an MCP server, or both, I like to ask five questions.

1. Is this primarily an interactive human workflow?

If yes, prefer a CLI.

Developers still need tools that work when no agent is involved. If a human would reasonably run the tool while sitting inside a repo, reading logs, adjusting flags, and retrying, a CLI is usually the right primary interface.

That does not mean agents cannot use it. Agents are quite good at driving existing developer workflows when the commands are documented and the outputs are predictable. This is where AGENTS.md 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 agentgateway become relevant. Once agent traffic spans MCP servers, APIs, models, and services, teams need consistent policy, routing, and observability. That is a different layer than the individual tool decision, but the design choices connect.

4. Is the operation stateful?

State changes raise the bar.

A read-only diagnostic command is one thing. A tool that creates tickets, deploys services, updates customer data, rotates secrets, or changes infrastructure is another.

For state-changing actions, the interface should make the action hard to misuse. That can be done in a CLI, an MCP server, or both. The question is which interface gives you the better control surface.

A CLI might be right when the state change belongs in a developer-controlled workflow:

• Apply this migration to my local database
• Generate this file in my branch
• Create a release artifact after tests pass

An MCP server might be right when the state change touches an external system:

• Create an incident
• Update a CRM record
• Open a pull request with a structured payload
• Provision access for a user
• Trigger a workflow in a deployment platform

For stateful MCP tools, I would avoid generic verbs like run, execute, or update when the action can be modeled more specifically. The tool should say what it does. The input schema should constrain what can happen. The response should include enough structured data for the agent to verify the result.

For stateful CLIs, I want dry-run support, confirmation controls that can be disabled only in explicit automation modes, and output that makes it clear what changed.

The shared principle is the same: the agent should not be guessing.

5. What is the maintenance cost?

Every new interface becomes a product surface.

A CLI needs packaging, versioning, docs, help text, examples, and compatibility guarantees. An MCP server needs all of that plus server lifecycle, transport decisions, schema design, client compatibility, authentication, deployment, monitoring, and operational ownership.

That cost may be worth it. But it should buy something real.

An MCP wrapper around a CLI can be useful when it adds:

• Better tool descriptions
• Safer input validation
• Structured outputs
• Scoped permissions
• Shared access across agent clients
• A stable abstraction over a messy underlying command
• Resource access the CLI does not provide well

An MCP wrapper is probably not worth it when it only shells out to an existing command and returns the same text output the agent would have seen anyway.

That does not mean “never wrap a CLI.” It means the wrapper should create leverage. If the MCP server is only a thinner, less debuggable path to the same command, keep the CLI and document it well.

The “both” pattern

Many teams should build both, but not as duplicates.

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.