MCP, API or CLI: what should you choose, and why?

A retailer already has an inventory API. Its application uses it to display available quantities. The team now wants to generate a nightly report and let an AI assistant answer: “Is this jacket still available in Lyon?”

There are three options: call the existing API, provide a terminal command or build an MCP server. All three can lead to the same answer: six jackets available. What changes is the work needed to get that answer, reuse the integration and maintain it.

The problem: the same result, different constraints

“APIs for software, CLIs for scripts, MCP for agents” is too simplistic. A script can call an API. An agent can use a CLI if its environment allows command execution. An AI application can call an API through functions written by its developers.

The decision therefore depends on three questions: who controls the application calling the service, where does it run, and how many clients need to reuse the integration?

The solution: choose which work you want to avoid

In this article, API means the business service’s HTTP API. A CLI is a program operated through commands. MCP is a common protocol between an AI application and a server that exposes capabilities, including tools. MCP itself defines a programmable interface, so these three terms do not describe alternatives at the same level. MCP architecture

Our decision rule is to favor the API when we control the integration, a CLI when existing commands simplify terminal work, and MCP when the same tools need to reach several compatible AI applications. Here is the reasoning.

How it works: where does the work happen?

Consider checking the jacket’s stock. The calls below are illustrative.

Interface	Call	Responsibility
HTTP API	GET /stores/lyon/stock?sku=JACKET-M	Application code prepares the request and handles the response.
CLI	catalog stock --store lyon --sku JACKET-M --json	The command prepares the request; the script collects its output and exit code.
MCP	Tool check_stock, with store and product	The MCP client sends the call; the server executes the business operation.

With the API, the developer knows the endpoint and its contract. An OpenAPI description can document parameters and responses, and support client generation. For an agent, the application can provide a check_stock function that wraps this request: MCP is not required. OpenAPI specification

With the CLI, the application launches a process. Reliable automation needs usable output, such as JSON, and a mode that does not ask interactive questions. The script can then filter the result or save it to a file. CLI design guidelines

With MCP, the client discovers tools and their parameters through tools/list, then invokes one through tools/call. In our example, the server translates that call into an inventory API request. The model proposes an action; the AI application manages its execution. MCP tools specification

Why combine them?

The diagram shows one possible architecture: the API centralizes inventory access, while the CLI and MCP adapt that access for different users.

Combining them has a concrete benefit: fixing the inventory calculation in the business service improves all three paths. One calculation rule supports several ways of using it. The adapters still handle their own parameters and errors.

This architecture becomes useful when all three needs exist. A daily report alone does not justify building both a CLI and an MCP server. An MCP server can also call a library directly: an intermediate HTTP API is an architecture choice, not a protocol requirement.

Benefits: what each interface saves

• API — control over a specific integration. For our sales application, we can program exactly which data to request, set timeouts and handle errors. If we also build the assistant and its few actions, reusing this integration avoids another server. The benefit is control over the workflow and reuse of the existing service.

• CLI — reuse of operations that are already packaged. Imagine a command that exports out-of-stock products across every store and already handles pagination. The nightly report can reuse it instead of implementing that access logic again. Its output can feed other programs. This benefit depends on what the CLI actually provides; a command wrapping a single request may add little to a working script.

• MCP — reuse of an integration across AI applications. If sales staff, support and partners use different compatible clients, one server can offer check_stock to all of them. Each client uses the same discovery and invocation mechanisms. The benefit grows when this avoids building a separate connector for each application; it is smaller for a single assistant whose code we already control.

Limits: what still needs to be built

• API — agent integration remains your responsibility. You need to select useful operations, describe them and connect the model’s calls to execution. OpenAPI can help generate this layer, but a well-documented endpoint cannot resolve an ambiguous request such as “remove this jacket” on its own.

• CLI — the execution environment becomes a dependency. You need to install and run the program, manage its versions, permissions and output formats. A hosted assistant without process access cannot use that CLI directly. Output designed only for human readers can also be difficult to consume automatically.

• MCP — standardization has an operating cost. You need to maintain the server, check the capabilities of your target clients and configure access. The protocol provides an authorization framework for HTTP; business permissions, such as access only to the Lyon store, still need enforcing in the service. MCP authorization

• No interface guarantees a better agent by itself. A poorly described MCP tool can be less useful than a clear CLI. A direct API integration can be simpler to operate than an additional adapter. Reliability, latency and context size depend on the implementation: measure them on real tasks rather than infer them from the protocol’s name.

Our choice for this retailer

We would start with the existing API, then add an interface only when it removes an identified piece of work.

Situation	Recommended choice	Reason
Our own assistant, with a few known actions	Functions calling the API	We control the code and can reuse the integration.
A nightly report based on a few requests	A script calling the API	An additional command does not yet offer a benefit.
Recurring exports, a mature CLI and terminal access	CLI	Ready-to-use operations avoid rebuilding the workflow.
The same tools for several compatible AI clients	MCP over the existing service	Clients can reuse the discovery and invocation contract.

What already exists can change this decision. If the vendor provides a maintained MCP server and our assistant supports it, MCP can be the simplest path even for one client. Conversely, building that server to replace three reliable API calls can add work without an immediate benefit.

A decision tree to help you choose

For a team that can integrate the service in its code, this tree suggests a first option to test. If several options fit, compare the work they save and their maintenance cost.

Before committing to this choice, we would test a successful lookup, a forbidden store and a service outage. We would compare the code to maintain, the quality of errors and response times. Choose the interface that simplifies the intended tasks, taking account of what already exists.

Continue with an introduction to MCP and how to write good tools.