Prefer CLI for a mature local developer loop
Use the CLI when it already provides stable commands, machine-readable output, useful exit codes, and a working authentication story. Humans can reproduce the command directly, CI can run it, and the model may already know common tools. Pin dangerous actions behind review and request JSON output when available.
Prefer MCP for reusable structured capability access
Use MCP when multiple compatible hosts should discover the same capabilities, arguments need schemas, a remote service needs a standardized connection, or per-user auth and tool approvals belong in the host. The MCP server can wrap an existing CLI, but it should translate failures and schemas deliberately rather than shelling out blindly.
Context and token cost must be measured
A host may load tool definitions, discover them progressively, or keep a large registry in context. A CLI path may spend tokens on help text, command construction, and parsing verbose output. Either can be smaller for a particular task. Measure the definitions and results actually sent to your model instead of repeating a third-party fixed ratio.
Auth, audit, and failure recovery exist on both sides
CLI tools can use OS accounts, configuration profiles, audited shells, and policy wrappers. MCP can use host approvals, structured logs, OAuth, and gateway policies. Neither interface automatically supplies complete governance. Compare the identity that reaches the downstream service, the action log, revocation, retries, cancellation, and recovery.
Use a hybrid decision tree
Start with the simplest existing interface. If a reliable CLI already solves the task, keep it. Add an MCP wrapper when the schema, cross-client reuse, remote auth, or managed discovery produces measurable value. Keep both when humans and automation need the CLI while AI hosts benefit from MCP. Retire one only after observing real duplication or maintenance cost.