MCP or CLI

When an AI agent is supposed to do something useful inside a company, it eventually has to reach into the system where the data lives: Jira, SharePoint, a warehouse, an ERP (enterprise resource planning) system or an internal API (application programming interface). That connection is usually treated as a technical detail for the team to settle, yet it determines what the integration costs to maintain, who is allowed to trigger it, and whether anyone can reconstruct what the agent did after an incident.

Two ways to connect a tool

The first is MCP (Model Context Protocol), an open protocol describing how an agent discovers the tools and resources a server exposes and how it calls them. An MCP server sits in front of the target system and speaks a shared language, so the client, be it an IDE assistant, a chat application or a custom agent, does not have to learn a new integration language for every system.

The second is a CLI (command line interface) call. The agent is granted the right to run a specific command or script, and the contract is the arguments, the exit code and the output written to standard output. Authorization, validation and logging all live in code the team wrote itself.

The difference is one of abstraction level. MCP standardizes the description of capabilities, the negotiation of permissions and the shape of results, while a script leaves those decisions to team convention, an advantage with one integration and a liability with ten.

MCP status in September 2026

On 9 December 2025 MCP moved to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI, backed by Google, Microsoft, AWS, Cloudflare and Bloomberg. The announcement cited more than 10,000 active public MCP servers and more than 97 million monthly SDK (software development kit) downloads across Python and TypeScript.¹ A public server registry has run since September 2025.

The specification revision in force is dated 2026-07-28 and brings the largest change since launch: a stateless core with no session handshake, per-request capability negotiation, tightened authorization rules and an extensions framework. The changes break backward compatibility, and the previous revision was dated 2025-11-25, so an integration written against the older specification needs a review before the next library upgrade. The standard has serious backing from the largest vendors and is also moving quickly, so an integration built on MCP needs budget for regular library upgrades well beyond the first deployment.

When MCP earns its keep

Standardization pays off when the same tool has to be called from several places. One server covers the IDE assistant, the chat application and a custom agent, instead of three pieces of glue maintained by three different people. The second strong case is a vendor-maintained server, which turns compatibility with successive API versions from the team’s cost into part of a product somebody else owns.

The third is server-side authentication. Where access has to be granted per user, with token refresh and revocation, the protocol’s authorization layer does work that would otherwise be written by hand and maintained forever.

The fourth is a changing tool set. When the catalogue of functions grows and shifts every few weeks, discovering tools at runtime is easier than updating prompts on every change.

When a simpler script is enough

For one integration used by one client, an MCP server adds a layer that returns nothing. If the repository already holds a tested script for issuing invoices or updating tickets, letting the agent call it is cheaper than rewriting it as a protocol server.

Scripts also win on high-stakes operations, where the goal is a narrow and rigid surface of action. Five explicitly defined commands are easier to review than a server exposing forty tools the agent picks from on its own.

In one deployment we settled on a read and write split: reads through the vendor’s ready-made MCP server, every write through an in-house script with credentials in environment variables and a log entry per call. The trade-off is maintaining two mechanisms rather than one, and in exchange every state-changing operation requires an explicit path and leaves a trace.

The context cost nobody mentions

Tool definitions occupy space in the model’s context, and with a dozen servers connected the catalogue alone can consume tens of thousands of tokens before the agent does anything useful. In November 2025 Anthropic described a pattern for calling MCP tools from code running in a sandbox: definitions loaded on demand, intermediate data processed in code, only the finished result handed back to the model. In its example, one workflow dropped from roughly 150,000 tokens to roughly 2,000.² That is one documented case, so the numbers will not transfer directly to another environment, though the direction is telling: the boundary between the two approaches is blurring, because MCP supplies the tool descriptions while execution drops into code anyway.

Dimension	MCP	CLI and scripts
Entry cost	Higher: server, permissions, maintenance	Low: whatever the team already runs
Context consumption	The tool catalogue takes prompt space	Zero until the call is made
Resilience to API change	Tool description lives in one place	Every script separately
Who owns the code	The server is often somebody else’s	The code is ours and auditable
When it wins	Many systems, frequent change	A few systems, stable interfaces

Security and the audit trail

On 15 April 2026 researchers described an attack class named “Comment and Control.”³ Content injected into a pull request title or an issue comment hijacked agents triggered automatically in GitHub Actions, including Claude Code Security Review, Gemini CLI Action and GitHub Copilot Agent, and made them exfiltrate secrets from the runner. The vendors paid bug bounties without publishing CVE (common vulnerabilities and exposures) identifiers.

The conclusion holds regardless of connection method. An agent treats the content it reads as trusted context, and its permissions become the attacker’s permissions. Four controls applied together limit the blast radius: an allowlist of tools, an identity attached to every call, a log containing arguments and results, plus human approval on irreversible operations.

Here a script holds an advantage worth remembering when audit gets involved: the call log appears by itself and the permission boundary is visible in the code. With MCP the audit trail has to be designed deliberately, because the call passes through a layer the team did not write, on a server that is often somebody else’s. Extensions defined separately from the core protocol address this area, and which of them a given client supports is something to check during connection negotiation rather than during tool selection.

Deciding a specific case

Four questions are usually enough. How many clients will call this tool over the next year? Does the vendor maintain an MCP server, or would it have to be written and maintained in-house? Is the operation reversible, and if not, where does human approval sit? Does the repository already hold a reviewed script for the same job?

The most common mistake is treating this as a one-time decision for the whole organization. It is better settled integration by integration, with a short written rationale, because within months both the protocol revisions and the list of maintained servers will have changed.

Footnotes

1. Model Context Protocol, 9 December 2025 announcement of the move to the Agentic AI Foundation, including the server and SDK download figures: https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/. ↩

2. Anthropic, the pattern for calling MCP tools from code: https://www.anthropic.com/engineering/code-execution-with-mcp. ↩

3. Cloud Security Alliance, research note on AI agents in GitHub Actions exfiltrating secrets: https://labs.cloudsecurityalliance.org/research/csa-research-note-comment-control-github-prompt-injection-20/. ↩