MCP vs API: what changes when an AI agent calls your product

An API is written for developers: someone reads your docs and writes code that calls your endpoints. An MCP server is read by a model at runtime. The AI application lists your tools, the model reads each tool's name, description and input schema, and it decides which to call and with what arguments. Your API stays where it is; the MCP server sits in front of it. What changes is who chooses the calls, so the tool definitions become the interface, and tools shaped around jobs work better than one tool per endpoint.

What stays the same

Your API, your business logic, your rate limits and your data stay as they are. A remote MCP server is a program that calls your API on the user's behalf and returns the results. You don't rebuild the product; you add a layer that a model can use.

What changes

Discovery happens at runtime. An MCP client asks your server what it offers with tools/list and passes the tools to the model. Nobody writes integration code against your server in advance: the model reads the list each time. Under the 2026-07-28 protocol, every request carries its own protocol version and client details, and a client can ask a server what it supports with server/discover.

The description is the documentation. Each tool has a name, a title, a description and a JSON Schema for its input. The model has nothing else to go on, so a vague description means wrong calls. The MCP spec's tools page describes the description as what the tool does, and directories enforce it: Claude's reviewers check that a description says what the tool does and when to use it, without telling Claude how to behave.

Errors go back to the model. A failed call returns a result marked isError with a message the model can act on, such as "Invalid departure date: must be in the future." The spec separates these tool execution errors, which the model can use to correct itself, from protocol errors such as an unknown tool name.

Every user signs in. The HTTP transport can carry API keys, but MCP recommends OAuth, and its authorization spec makes your server an OAuth resource server: each user authorizes the client, and your server accepts only tokens issued for it. Our MCP OAuth guide covers the setup.

Behavior is declared. Tools carry hints such as readOnlyHint and destructiveHint, and directories check them. The spec tells clients to ask the user before sensitive operations, and hints are one way a client knows which those are, so they must be accurate.

Tools for jobs, not endpoints

The tempting first version wraps every endpoint as a tool. Anthropic's guidance on writing tools for agents argues against it: build a few tools aimed at specific, high-impact workflows, consolidate steps that always happen together, and prefer a search tool to a tool that lists everything. Its example is a schedule_event tool instead of separate tools to list users, list events and create an event. It also recommends returning meaningful identifiers rather than opaque IDs, and paging or filtering large results so they fit the model's context.

Here is how that looks for a hypothetical project management API. This mapping is an illustration, not a client's product:

| Endpoints | One tool per endpoint | Tools for jobs | |---|---|---| | GET /projects, GET /projects/:id/tasks, GET /users | list_projects, list_project_tasks, list_users | find_tasks: search tasks by text, assignee, status or project, with paging | | POST /tasks | create_task | create_task: accepts a project name and an assignee's name, and looks up the IDs itself | | PATCH /tasks/:id | update_task (any field) | update_task_status and reassign_task: each with its own hints and a narrow input | | DELETE /tasks/:id | delete_task | delete_task: marked destructive, so the client can ask the user first |

The right-hand column has fewer tools, each with a description the model can choose by, and no tool that both reads and writes. That last point is also a review rule: Claude rejects a catch-all tool that mixes safe and unsafe HTTP methods. In a Connector Launch Sprint we design 8 to 20 tools around the jobs your users do.

When you need MCP, and when an API is enough

If developers integrate with you in code they write and maintain, your API serves them already. If you want people to reach your product from inside Claude, ChatGPT, Cursor and other agents, you need an MCP server, and for most directories a listing as well. Once the server is public, you can publish it to the Official MCP Registry under a namespace you authenticate.

Not sure which of your endpoints should become tools? That is the first thing the Agent Distribution Audit answers.