MCP, API, skill or CLI: how to connect an agent to its tools

Choose how an agent reaches a tool by what it costs in context before the first useful call, not by which protocol is newest. There are four common ways: a skill the agent reads, an MCP server the client lists for the model, a CLI the agent runs in a shell, and a plain HTTP API. They are not rivals. They suit different agents, and the number that separates them is measurable: Anthropic's own figures put 50 MCP tools loaded up front at about 77,000 tokens of context before any work begins, against 8,700 when tools are fetched on demand. AMXP will expose the same catalog and balance through all four, built around that number.

Four ways, one real difference

A skill is a file the agent reads. In the Agent Skills format, a skill is a folder with a SKILL.md that has at least a name and a description plus instructions, and optionally scripts and reference files. Agents load skills by progressive disclosure: at startup only the name and description of each skill enter context; the full instructions load when a task matches; bundled files load only if the instructions call for them. Anthropic shipped skills on October 16, 2025 and published the format as an open standard on December 18, 2025 (Introducing Agent Skills). This is why the AMXP install is one line:

Read https://amxp.ai/SKILL.md and configure AMXP.

MCP is a protocol between a client and a server. The Model Context Protocol, introduced by Anthropic on November 25, 2024, uses JSON-RPC 2.0 over a stateful connection; a server offers tools, resources and prompts, and the client shows the tools to the model as callable functions. The current revision is dated 2025-11-25 (spec). The spec also says hosts must obtain explicit user consent before invoking any tool, which matters for an agent that spends money.

A CLI is commands in a shell. It suits scripts, cron jobs and coding agents that already have a terminal, and it prints costs and run status in a form both people and models can read.

An HTTP API is everything else. Under the other three sits a plain API with a key: POST /v1/discover, GET /v1/tools/{id}, POST /v1/runs. If the agent lives in your backend, call it directly.

The real difference is not transport. It is how much of the model's context each method consumes before the agent has done anything, and who decides what goes in.

The number that decides: context before the first call

Most MCP clients load every tool definition from every connected server into context at the start of a session (Anthropic, code execution with MCP). Anthropic measured what that costs on the Claude Developer Platform: with 50+ MCP tools loaded up front, tool definitions alone took about 72,000 tokens and total context before any work was about 77,000. With a tool search step that loads only the definitions a task needs, the same session started at about 8,700 tokens, an 85% reduction, and tool-selection accuracy rose from 49% to 74% on Opus 4 and from 79.5% to 88.1% on Opus 4.5 (advanced tool use, November 24, 2025).

The arithmetic compounds because context is re-read on every turn. A 20-turn session with 50 tools loaded up front re-sends roughly 77,000 × 20 = 1,540,000 tokens of tool overhead; the same session on demand re-sends about 8,700 × 20 = 174,000. Add the second cost Anthropic names: every intermediate result passes through the model, so a 2-hour meeting transcript fetched by one tool and handed to another costs about 50,000 extra tokens, and moving that workflow into code brought one example from 150,000 tokens to 2,000, a 98.7% saving (code execution with MCP).

This is why AMXP's MCP server will expose three tools, amxp_discover, amxp_inspect and amxp_execute, rather than one tool per catalog operation. The model carries three definitions and searches the catalog only when a task needs it. Providers who run large APIs reached the same design: Stripe's MCP server routes most of its API through generic stripe_api_read and stripe_api_write tools, which Stripe says makes "much of the API available through MCP without increasing the context window unnecessarily" (Stripe MCP).

Skills carry the "how", MCP carries the "what"

A tool definition tells the model what a function takes and returns. It does not say when to use it, what to check before spending, or what to do on a 429. That knowledge is cheapest as a skill: it costs a name and a description until the task matches, then a few hundred lines of instructions once. The AMXP skill tells the agent to check its own tools first, to read the price from inspect before execute, and to stay under the spend caps. None of that fits in a JSON schema.

The split also shows in who can install each one. A skill needs no software on your side; the agent reads a URL. An MCP server needs a client that speaks the protocol, a config entry and, for a remote server, authentication. Stripe's remote server, for example, uses OAuth or an agent API key, and from December 2026 refuses full-access secret keys and restricted keys without the Agent tag (Stripe MCP). CoinGecko runs a keyless MCP server with shared rate limits and a keyed one with the full tool set (CoinGecko MCP). Each provider's server comes with its own auth, its own limits and its own tool list. Ten providers through MCP is ten of each; the same ten through one catalog is one.

When the agent is code, skip the model entirely

If your agent is a program that happens to call a model, the question of context cost changes. A backend that runs POST /v1/runs from a job queue never puts a tool definition in front of the model at all: the code decides which tool to call, and the model sees only the result, or nothing. A cron job that runs amxp execute in a shell is the same. Choose the CLI when a person or a coding agent will read the output; choose the API when another program will.

Payment follows the same logic. x402 lets a server price a single HTTP request and an agent pay it in the same exchange, which is natural for code calling an API and awkward inside a chat client that must approve each tool call. A prepaid balance with per-call reservations works through all four methods, which is why AMXP charges that way rather than per request onchain.

Which one should you pick?

Whichever you choose, it is the same catalog, the same prices and the same balance.

What most people get wrong

1. Connecting every MCP server they can find. Each one adds its tool definitions to every turn. At Anthropic's measured rate, 50 tools is roughly 77,000 tokens before the first message. Fix: connect servers with few tools, or one server that searches a catalog.
2. Treating a tool list as documentation. Schemas say what, not when. Fix: pair the server with a skill that holds the judgment: check your own tools first, read the price, respect the caps.
3. Piping large results through the model. A transcript fetched by one tool and sent to another via the model costs its full length in tokens twice. Fix: move data-to-data steps into code (CLI or API) and give the model the summary.
4. Assuming MCP means authenticated. Many servers are keyless and share rate limits by IP; others are changing which keys they accept. Fix: read each server's auth page before relying on it in production.
5. Picking a transport before picking the agent. A cron job does not need MCP; a chat assistant cannot run a CLI. Fix: start from the table above.

Where this argument is weak

The token figures are Anthropic's, measured on Claude with its tool search feature; other clients and models will differ, and a client that already prunes tool lists narrows the gap. The 20-turn multiplication assumes no prompt caching, which many platforms now apply to repeated prefixes, so the dollar cost of up-front loading is lower than the raw token count suggests. And for an agent that uses three tools, all day, from one provider, that provider's own MCP server is simpler than a catalog, and probably better maintained. The case for a searchable catalog with three tools is strongest where the tool set is wide and the usage is sparse, which describes most agents, not all.

Common questions

Is MCP better than a REST API for agents?

Different job. MCP is for a model-driven client that needs to discover and call tools at runtime; a REST API is for code that already knows what to call. Many agents use both: the API in the backend, MCP in the chat surface.

What is the difference between a skill and an MCP server?

A skill is instructions the agent reads (a SKILL.md with a name, a description and procedure); an MCP server is a running service that exposes functions. Skills tell the model how and when; servers give it what to call.

How many MCP tools is too many?

Anthropic's measurement is the best public number: 50+ tools cost about 77,000 tokens up front, and loading on demand cut that to about 8,700. If your tool list is in the tens, consider a search step or a server that exposes a few generic tools.

AMXP is in private preview. The skill, MCP server, CLI and API described here open soon; see the docs for the interface that ships.