CLI, MCP Server or Code Sandbox: Picking a Wrapper

Read the table as a set of independent dials rather than a ranking. You can raise contract stability on a CLI by adding a JSON mode. You can lower the operational burden of an MCP server by keeping its tool count small. You cannot, however, get audit evidence out of a surface that does not have an enforcement point.

The case for a CLI is real and the evidence is concrete. One engineer who built several MCP servers, deleted them, and rebuilt the same tools as CLIs measured roughly 40 percent lower token usage for a file conversion task after the switch, because a CLI call only consumes tokens when it runs while MCP tool definitions sit in the prompt persistently in this write-up of the redesign. The same account notes MCP servers crash, lose connections and add startup latency, while a CLI binary is stateless and always available.

That is the honest case for CLIs: low ambient cost and no service to operate. But the contract is where teams get hurt. If your wrapper parses human-formatted output, a column reordering or a status string going from "Running" to "running" causes silent failures rather than errors, the same account warns.

You can make a CLI contract much more durable with four habits.

1. Emit JSON to stdout and send everything else (progress, warnings, spinners) to stderr. Stdout becomes your API.
2. Use exit codes as control flow, documented and distinct per condition, so the agent can branch without parsing prose.
3. Make commands idempotent, because agents retry and networks fail.
4. Keep the schema flat and the types consistent across subcommands.

The practices behind both accounts converge on the same mechanics. A production CLI rebuilt for humans and agents alike routes every output decision through a terminal check, so spinners appear only on a TTY, and emits a --json path that returns the full data structure the human table trims for brevity per this CLI design retrospective.

Exit codes deserve their own paragraph because they are the most commonly broken part of the contract. A process that succeeds exits 0. Beyond that, a wrapper owes the agent a documented mapping, for example 1 for a general failure, 2 for a usage error, 3 for not found, 4 for permission denied and 5 for a conflict. Note also that shells report a signal termination as 128 plus the signal number, so a process killed with signal 9 surfaces as 137, as the classic exit code appendix explains in the Advanced Bash-Scripting Guide. If your wrapper passes that number through without explanation, the agent has no idea whether to retry, escalate or stop.

The security boundary is the CLI's weakest dimension. Some agent frameworks mediate CLI access through sandboxed execution with approval gates rather than raw shell access, but a developer's terminal accumulates tools, scripts, credentials and ambient permissions over time, and the agent will test multiple strategies when more than one can complete a task as this analysis of CLI versus MCP governance puts it. When an MCP server fails, agents with shell access fall back to raw API calls using credentials from the user's environment, which the same analysis observes in Claude Code and Cursor.

Observability follows the same pattern. You get whatever the shell or the agent framework happens to record, which is operational telemetry at best. There is no enforcement point where you can log an authorization decision, only a process that either ran or did not.

An MCP server moves the boundary from "a program the agent runs" to "a service that exposes named tools." Each tool has a name, a description and an input schema. The provider owns the definition, the schema and the behavior, and the LLM cannot call outside those boundaries per the same governance analysis.

That ownership is the whole value proposition. The Model Context Protocol is an open standard donated to the Linux Foundation's Agentic AI Foundation in December 2025, which standardizes how models connect to external tools and data sources as described in this guide to agent code execution. A standard contract plus a single hosted endpoint means every call can cross one enforcement point.

Three properties matter most for a practitioner choosing MCP.

Discoverability. The agent can list tools and read their schemas at runtime. Your internal system's capabilities become self-describing, which reduces the prompt engineering needed to route work correctly.

Enforceability. Authorization, rate limits and logging live in the server, not in the model's instructions. That placement is the difference between a control and a hope. On the audit side, the recommended placement is explicit: logging for authorization belongs at the policy decision point or an MCP gateway that enforces before a tool executes, because that is the moment intent becomes a possible side effect, and logging only after the tool runs misses the control point in this audit trail guide. An auditor eventually samples sensitive actions and asks for the initiator, any approval, the policy that allowed it, and evidence that denials were logged too.

Operability cost. You now run a service. It can be down, slow or misconfigured. Every tool you expose also loads its description and schema into the agent's context on every turn, so a bloated server with dozens of tools burns context before doing any work as this side-by-side test describes. The mitigation is progressive disclosure: expose a small set of tools, or one discovery tool, instead of the full catalog per the CLI redesign account.

A useful sanity check on whether MCP is warranted: MCP earns its overhead when you expose many tools behind one server, need stateful sessions across calls, require dynamic discovery at scale, or build multi-agent systems where protocol-level composition matters. For everything else, a well-designed CLI often wins again from the redesign account.

The sandbox is a different category. A CLI and an MCP server both expose a fixed set of operations. A sandbox exposes execution itself: the agent writes code and something isolated runs it.

The architectural invariant that keeps this safe is a separation of concerns. Production agent systems split reasoning (what code to write), execution (where and how it runs) and integration (what systems the code can reach), and the reasoning layer never executes anything directly. It emits structured calls, and a separate layer runs them, keeping API keys, database credentials and production infrastructure out of the model's reach per this execution architecture guide.

Isolation strength is the dial. Options range from sandboxed interpreters and serverless functions to microVMs with hardware-enforced boundaries, where each workload runs a separate kernel so an exploit inside one sandbox cannot reach the host or its neighbors. Historically stronger isolation meant slower startup; snapshot restore has narrowed that gap, with platforms resuming microVMs from standby in under 25 milliseconds per the same guide.

The contract question changes shape here. There is no output format to break, because the agent writes the parser each time. But that flexibility is also the risk: the "contract" is the sandbox's permission set, network reach and time limits, and those are what you have to version carefully. A sandbox with unrestricted filesystem access and no timeout enforcement is a liability, not a feature.

Sandboxes shine for exploratory work over data the agent should sample rather than load. Practitioners report pointing agents at duckdb and jq so they introspect large CSV, Parquet and JSON files with probing queries instead of pulling hundreds of megabytes into context in this discussion of when MCP makes sense versus a CLI. That pattern needs execution, not a fixed tool list.

Here is the decision rule most teams miss. Tool traces and LLM traces are operational telemetry, not control evidence. A trace tells you the model said something and a function was called. An authorization record tells you whether the action was permitted under the policy in force at that moment, for that agent, acting for that user, against that resource per Permit.io's audit guide.

Build your audit envelope before you pick the wrapper, then check which surface can fill it. The fields that matter:

- Agent identity (unique, not a shared service account)
- Human principal or delegation chain
- Tool name and parameters
- Resource and action
- Policy ID and version
- Decision (allow or deny) plus reason
- Approval record if human-in-the-loop was required
- Timestamp, request ID, trace ID, tenant and environment
- Outcome of the side effect

Shared service accounts are a common failure. When multiple agents and humans share one credential, you cannot determine which actor performed which action, and incident response time climbs as a result. Agent identity answers which autonomous process acted; user identity answers which human allowed it; both are required for non-repudiation per this audit trail best practices piece. The same source recommends recording the agent's configuration and model information, a cryptographic hash of each log entry to detect tampering, and human approval details including who reviewed, when, and the outcome.

Against that bar: a bare CLI wrapper usually fails it, an MCP server with a policy point passes it, and a sandbox passes execution evidence but not authorization evidence unless you add a decision log in front of it. Alerting is a separate design problem; the same piece suggests alerting on sequences rather than single calls, since privilege escalation chains, clustered policy denials and intent drift show up in patterns.

Work through these five steps in order. Stop at the first one that decides the question.

1. Write the audit envelope you must produce. If a regulator, customer or internal control requires authorization evidence, a bare CLI is out unless you add a mediating layer. This step alone settles most enterprise cases.
2. Count the operations. If you are exposing a small handful of well-understood operations to a single-user or developer workflow, a CLI with a strict JSON and exit code contract is the cheapest durable option.
3. Check who the callers are. Multi-user, remote or browser-based agents need a hosted endpoint with credentials off the client. That is MCP territory, since CLI tools work locally and hosting them yourself means rebuilding the security you were trying to avoid per the governance analysis.
4. Ask whether the agent must compute. If the work is exploratory, data-heavy or requires writing code against a schema you cannot enumerate, you need a sandbox with a scoped permission set and timeouts, not a longer tool list.
5. Plan the failure path. For every surface, decide what the agent sees when the underlying system changes. A typed schema fails validation loudly; a parsed table fails silently. Prefer loud.

A worked example with numbers makes the tradeoff concrete. Suppose an internal inventory system exposes 12 operations, used by 40 employees through a shared agent and by 6 developers running agents locally.

For the 40 employees, the audit requirement is likely real. Twelve tools fit comfortably in a context window, so tool bloat is not a problem. One MCP server with a policy point in front, logging the envelope above, is the right call. For the 6 developers, the same operations behind a CLI with --json and documented exit codes will feel faster and cost fewer tokens, and their work stays on their machines where the shell is already the audit trail they have.

Both wrappers can share one internal client library. That is the practical insight: build the client once, then expose two thin surfaces over it, and keep the JSON schema in one place so the CLI's --json output and the MCP tool's output schema cannot drift apart.

If your team would rather have a working surface than build one, the skill library behind every Quanta expert can be installed into a coding agent, and an expert can take the job end to end: Quanta Skills. For teams that need every kind of model behind one key while they build the wrapper, Quanta Inference exposes text, image, video, audio and embedding models through a single OpenAI-compatible endpoint.

One caution to carry into implementation: an agent's report that it finished is generated text, not a record of what ran. Teams that get reliable results put independent checks behind the agent, run them on the final state, and hand the recorded output to a reviewer per this definition of done guide. The same discipline applies to wrappers: prove the call happened with a record the agent did not write.