What is an MCP server, explained for API teams

An MCP server is a program that exposes your systems to AI assistants in a form they can actually use. MCP stands for Model Context Protocol, an open standard that defines how an AI client such as Claude, Cursor, or ChatGPT discovers what a server can do and calls it. If a REST API is how other programs talk to your service, an MCP server is how AI agents talk to it. The two are related, and for most API teams the MCP server is a thin, well-designed layer in front of the API they already run.

The protocol in one paragraph

MCP is a client-server protocol built on JSON-RPC. The client is the AI application. The server is you. On connection, the client asks the server what it offers, and the server answers with three kinds of capability: tools (functions the model can call, each with a name, a description, and a JSON Schema for its inputs), resources (data the client can read, like a file or a record), and prompts (reusable templates the user can invoke). During a conversation, the model decides a tool is relevant, sends a call with arguments, and the server executes it and returns a result the model can read. That is the whole loop. The intelligence lives in the client; the server just describes itself honestly and does what it is asked.

How a server maps to your API

For an API team, the natural mapping is: one MCP server per API product, one tool per operation you want agents to perform. A payments API might expose create_refund, get_payment, and list_disputes as tools. Each tool wraps the corresponding endpoint, translating the model's JSON arguments into a real HTTP call with real credentials.

The mapping is where the design work lives, because a good MCP server is not a one-to-one dump of your OpenAPI file:

• Fewer tools, better described. A model choosing between 200 tools picks wrong far more often than one choosing between 15. Expose the operations an agent plausibly needs, not every endpoint you have. In our own gateway data, servers with under 25 tools show markedly lower wrong-tool selection than servers with over 100.
• Descriptions are the interface. The model reads your tool descriptions the way a developer reads docs, except it cannot ask questions. "Creates a refund for a captured payment. Fails if the payment is already fully refunded" beats "Refund endpoint" every time.
• Schemas do the validating. Tight input schemas with enums, formats, and required fields stop bad calls before they reach your API. A bare string where an ISO date belongs is an invitation for the model to guess.

This is why we treat the MCP server as a publishing target of an API contract: you decide which operations an agent audience gets, and the server is generated from that decision.

Local servers and remote servers

MCP servers run in two modes, and the difference matters operationally.

A local server runs on the user's machine and talks to the client over standard input and output. This is how most early servers shipped: a developer installs a package, edits a config file, and the assistant gains a capability. Local mode is fine for personal tools and terrible for companies. Credentials live in plain text on laptops, every user runs their own copy, versions drift, and nobody can see what was called.

A remote server runs where your other services run, speaks HTTP, and authenticates callers. The client connects over the network, typically with OAuth or a scoped key. This is the mode that fits how teams actually operate software: one deployment, central credentials, logs, monitoring, and access control. The protocol added first-class support for this with streamable HTTP transport, and every serious client now supports remote servers.

What production actually requires

Running an MCP server for real traffic is running a service, and the usual service questions apply. Four of them come up on day one:

• Authentication. Who is this agent, and on whose behalf is it acting? Remote servers need per-caller identity, not one shared secret. Scoped keys per consumer, or OAuth for user-delegated access.
• Authorization. Which tools can this caller see and invoke? A partner's agent should not discover your internal admin tools, even as names. Per-tool scopes solve this at the gateway.
• Observability. When an agent misbehaves, you need the call log: which tool, which arguments, which key, what latency, what result. Without it, every incident report starts with "we think."
• Change management. Renaming a tool or tightening a schema breaks agent workflows the same way an API breaking change breaks integrations. Version the server, announce changes, and diff every release against the last one.

None of this is exotic. It is the same discipline you apply to a public API, applied to a new consumer type that reads documentation perfectly and exercises edge cases relentlessly.

Do you need one?

A useful test: would you benefit if your customers' AI assistants could operate your product on their behalf? For developer tools, fintech, commerce, and most B2B software the answer is heading toward yes, because your customers are already asking their assistants to do the work. The share of API traffic coming from agents is small today and compounding. Teams that stand up a governed MCP server now get to shape how agents use their API, instead of discovering it from scraped workarounds later.

The practical path: start from the API you have, pick the ten to twenty operations an agent should perform, write descriptions a stranger could act on, put the server behind auth with logging, and treat every change to it as a contract change. If you want the generation, hosting, gateway, and logs handled for you, that is what Elva does.