{"slug": "mcp-server-or-cli-a-decision-rubric-for-developer-tooling", "title": "MCP Server or CLI: A Decision Rubric for Developer Tooling", "summary": "A developer at the Agentic AI Foundation proposes a rubric for deciding whether to expose internal tools as an MCP server or a CLI for agent use. The rubric emphasizes that CLIs are best for human-driven, terminal-native workflows, while MCP servers excel when agents need structured, discoverable capabilities. The decision hinges on whether the tool is primarily for human developers or for autonomous agent reuse.", "body_md": "Teams are rushing to make their internal tools available to agents. That is good. It is also where a lot of design mistakes begin.\n\nThe question usually shows up like this:\n\nShould we expose this as an MCP server, or should the agent just use our CLI?\n\nThat 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?\n\nMCP, now hosted by the [Agentic AI Foundation](https://aaif.io) 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.\n\nHere is the rubric I use.\n\nA CLI is strongest when the workflow already belongs to a human developer.\n\nIf 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.\n\nGood CLI-shaped examples:\n\nAn 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.\n\nGood MCP-shaped examples:\n\nThe trap is assuming that “agent can run command” and “agent has a good tool interface” are the same thing. They are not.\n\nA 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.\n\nWhen deciding between a CLI, an MCP server, or both, I like to ask five questions.\n\nIf yes, prefer a CLI.\n\nDevelopers 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.\n\nThat 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](https://aaif.io/projects/agents-md/) fits naturally: document which commands are safe, how to run tests, what directories are off-limits, and what failure modes are expected.\n\nThe CLI should be boring in the best way:\n\nIf 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.\n\nIf yes, lean toward MCP.\n\nOne 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.\n\nThat matters when the capability is meant to be reused across agents or across teams.\n\nA 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.\n\nUse MCP when the agent should be able to answer questions like:\n\nThis 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.\n\nIf the action crosses an authorization boundary, consider MCP carefully.\n\nA 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.\n\nMCP 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.\n\nThis 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.\n\nAsk:\n\nIf the answer to those questions is yes, a CLI alone may be too blunt.\n\nFor production-facing systems, this is also where infrastructure projects like [agentgateway](https://aaif.io/projects/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.\n\nState changes raise the bar.\n\nA read-only diagnostic command is one thing. A tool that creates tickets, deploys services, updates customer data, rotates secrets, or changes infrastructure is another.\n\nFor 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.\n\nA CLI might be right when the state change belongs in a developer-controlled workflow:\n\nAn MCP server might be right when the state change touches an external system:\n\nFor stateful MCP tools, I would avoid generic verbs like `run`\n\n, `execute`\n\n, or `update`\n\nwhen 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.\n\nFor 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.\n\nThe shared principle is the same: the agent should not be guessing.\n\nEvery new interface becomes a product surface.\n\nA 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.\n\nThat cost may be worth it. But it should buy something real.\n\nAn MCP wrapper around a CLI can be useful when it adds:\n\nAn 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.\n\nThat 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.\n\nMany teams should build both, but not as duplicates.\n\nA good pattern is:\n\nFor example, imagine an internal deployment tool.\n\nThe 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.\n\nThe 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.\n\nBoth interfaces can call the same underlying deployment library. They do not need to expose the same surface area.\n\nThat separation is healthy. Humans need power tools. Agents need constrained capabilities with clear contracts.\n\nUse a CLI when:\n\nUse an MCP server when:\n\nUse both when:\n\nDo neither, at least for now, when:\n\nThe open agentic AI ecosystem needs standards like MCP. It also needs restraint.\n\nIf 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.\n\nThe goal is not to make everything agent-accessible. The goal is to make the right capabilities available through the right contract.\n\nThat 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.\n\nThese projects are stronger when we use them for the problems they actually solve.\n\nA 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:\n\nIf the work belongs in the developer workflow, start with a CLI.\n\nIf the agent needs a structured, discoverable, permissioned capability, build an MCP server.\n\nIf both humans and agents need it, design both surfaces intentionally and keep the shared logic underneath.\n\nThat is the rubric. Not CLI versus MCP. CLI where the workflow lives. MCP where the capability needs a contract.", "url": "https://wpnews.pro/news/mcp-server-or-cli-a-decision-rubric-for-developer-tooling", "canonical_source": "https://dev.to/bengreenberg/mcp-server-or-cli-a-decision-rubric-for-developer-tooling-2ch6", "published_at": "2026-07-01 14:29:03+00:00", "updated_at": "2026-07-01 14:49:23.171016+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "large-language-models"], "entities": ["Agentic AI Foundation", "Linux Foundation", "MCP"], "alternates": {"html": "https://wpnews.pro/news/mcp-server-or-cli-a-decision-rubric-for-developer-tooling", "markdown": "https://wpnews.pro/news/mcp-server-or-cli-a-decision-rubric-for-developer-tooling.md", "text": "https://wpnews.pro/news/mcp-server-or-cli-a-decision-rubric-for-developer-tooling.txt", "jsonld": "https://wpnews.pro/news/mcp-server-or-cli-a-decision-rubric-for-developer-tooling.jsonld"}}