MCP is a discovery layer, and your exposure list is a governance decision

CircleCI published an explainer that declines the usual framing: MCP does not replace the API underneath it, and in many implementations an MCP tool ends up calling the same REST, GraphQL, or RPC interfaces the rest of the product already uses ^[3]. An MCP server sits in front of the APIs you already run and turns low-level operations into capabilities an agent can find and invoke at runtime ^[2], which means the deliverable is less a service than a list of what you are willing to let an agent do.

The distinction worth holding onto is not runtime versus design time. Both APIs and MCP tools are invoked at runtime; the useful difference is how the caller knows what to invoke ^[10]. In a conventional integration a developer decides which operations the application needs and encodes that ahead of time; with MCP, the client inspects the capabilities a server exposes and chooses among them based on the current task ^[11]. That inspection runs on whatever you wrote in the manifest: tool names, descriptions, and typed inputs ^[9].

The example in the piece is deliberately mundane. Answering questions about a customer's latest order can involve `GET /customers/{customer-id}`, `GET /customers/{customer-id}/orders`, and `GET /orders/{order-id}/shipments` ^[12], three chained resources with identifiers passed between them ^[13]. Given "find the customer's latest order and tell me why it hasn't shipped" ^[6], an agent may need to look up the customer, retrieve recent orders, inspect fulfillment status, check inventory, or query a shipping provider, and which of those matter depends on what it finds along the way ^[17]. CircleCI's argument is that your API may already expose everything the agent needs, and the harder problem is helping it work out which operations matter for the task it was given ^[4]. An OpenAPI document tells a model which requests are valid without giving it a task-oriented vocabulary for deciding which ones answer the question ^[8].

So somebody has to decide which parts of the API get exposed, how those capabilities are named and described, what inputs they require, and what comes back ^[7]. Read that list again as a control document rather than a spec. Because the tool resolves to the same underlying call ^[3], the consequence of an agent invoking it is the consequence of that call ^[18]: refunds, deletions, and writes to production do not become gentler for being wrapped in a description an LLM can read. The naming is not cosmetic either, since the description is the mechanism by which selection happens ^[9]. That is a decision about authority and blast radius, and it is currently being made by whoever is closest to the SDK.

The counterweight in the source is worth keeping. For deterministic software, encoding a known sequence directly gives predictable behaviour with minimal overhead: a webhook handler should not re-decide which endpoint is appropriate on every event, and a checkout service already knows what has to happen ^[14]. You could build the agent-facing translation layer yourself; MCP's contribution is standardising it so you are not maintaining bespoke integrations per AI client ^[15][16].

What to watch is whether tool manifests get reviewed the way schema migrations are, or shipped the way READMEs are. The second is cheaper and is what will happen by default.