MCP, API/CLI or agent-to-agent, choosing the connection mechanism

A company wants its ticketing system to be usable from Claude Code, from Claude Desktop and from two in-house agents built with the Agent SDK. One of the agents already has hand-written tool definitions that call the API, and the other team was about to copy them. The API’s authentication changed twice this year, and each change broke the integration for days. The problem isn’t code: it’s the mechanism.

Three mechanisms, three questions

The choice comes from two questions: how many different clients need this integration? and is there an operation on the other side, or someone who decides?

If the scenario says…	It fits
Several clients (Claude Code, Desktop, in-house agents) need the same operations	An MCP server
A fixed process, with a defined field mapping, that needs no judgment	A direct API or CLI call, no model
The other party is an autonomous agent with its own rules and there’s negotiation over several rounds	Agent-to-agent communication

MCP: build once, connect many

The Model Context Protocol (MCP) is an open standard for exposing tools, resources and prompts to any application that speaks it. A server is built once and every compatible client uses it: the authentication change is made in one place, and tool definitions stop being copied into each agent.

The transport depends on where it runs:

• stdio: the server runs as a local process of the application. It suits tools on each person’s machine.
• HTTP: a remote server, shared by many clients. This is where the OAuth authorization from lesson 1 comes in (token audience, no passthrough).

MCP isn’t free: it’s one more server to operate, version and secure. If a single application calls an API with two operations and nobody else will use it, defining the tools directly in that application is also valid.

Direct API or CLI: when no model is needed

A nightly export of a status file with a fixed field mapping is a deterministic process. Running it through an agent as a tool it “calls every night” adds cost, latency and variability with no benefit. A scheduled script that calls the REST API does it better.

The same logic applies to development: a CLI can be the simplest way to give Claude Code a capability in a specific environment, but it isn’t a common interface for Desktop and several agents, and it spreads credentials across every machine.

Agent-to-agent: when someone on the other side decides

If a logistics provider has its own agent that assigns delivery slots based on capacity, driver hours and commitments to other customers, with rules it won’t share, you can’t “rebuild its rules” as tools. The decision is theirs. What fits is for your agent to negotiate with theirs, over several rounds of proposal and counter-proposal.

Giving your agent read access to the other party’s database doesn’t work either: it doesn’t provide the internal rules and it shares credentials across companies, which is exactly what security wants to avoid.

The usual traps

• Copying the same tool definitions into every client.
• An agent that “owns” a system for simple operations like searching and commenting.
• Running a deterministic process through a model “to keep everything in the agent”.
• Rebuilding another organization’s private rules as your own tools.
• Sharing database access across companies to avoid an integration.
• Switching to stdio “so the token doesn’t travel” when the clients are remote.

In the exam

Count the consumers and look at who decides. If several clients need the same operations, the answer is an MCP server. If the scenario describes a fixed mapping or a scheduled task, look for the option without a model: a script against the API. If the other party “has its own judgment”, “won’t share its rules” or there’s “negotiation”, it’s agent-to-agent. Two-answer questions often combine two of these cases.