MCP Server Basics and How AI Agents Use Your API

What an MCP server is

MCP stands for Model Context Protocol, an open protocol that describes how an AI application talks to an external system. The AI application is the client, for example a chat assistant, a coding tool or an agent your team wrote. The MCP server is the program that sits in front of your system and tells the client what it can do there. Instead of a custom plugin for each assistant, you build one server and every compatible client can use it.

An MCP server offers three kinds of things. Tools are actions the model can call, such as search orders, create a ticket or cancel a booking. Resources are pieces of data the client can read for context, such as a record or a schema. Prompts are reusable instructions the server suggests to the user. Most business servers are mostly tools, with a few resources.

How an agent uses an MCP server

When a client connects, it asks the server for its list of tools. Each tool comes with a name, a description and a JSON schema of its arguments. The model reads those descriptions the same way a developer reads API docs. When a user asks a question such as which invoices are overdue for this customer, the model decides which tool fits, fills in the arguments and asks the client to call it. The server runs the call against your system and returns a result, and the model uses it to answer or to call the next tool.

Three consequences follow from this flow. First, tool descriptions matter as much as code, because the model chooses tools from them. Second, every call is a real request against your system, with real effects. Third, the server, not the model, decides what is allowed.

MCP server and your API

In most companies the system behind an MCP server is an API. The server translates tools into API calls: a tool named list_overdue_invoices becomes a GET request with a filter, and a tool named cancel_booking becomes a POST to an action endpoint. That is why the best MCP servers are derived from a well designed API rather than written next to it. When the API changes, the tools have to change too, or the model keeps calling arguments that no longer exist.

• One API, many clients: web app, mobile app, partners and agents.
• One set of validation rules, shared by the API and the tools.
• One place for keys, limits and logs.

What makes an MCP server safe

Giving a model a tool is giving it a key to part of your business. Production servers need the same controls as any API client, and a few more.

• A separate key per agent or per user, never a shared admin credential.
• Scopes that decide which tools a key sees, so a support agent cannot reach billing actions.
• Read tools separated from write tools, with write tools enabled deliberately.
• Rate limits, because a model in a loop can send hundreds of calls in a minute.
• Logs of every call with the key, the tool and the result.
• Validation of every argument, because the model can and will send unexpected values.

When many teams run many servers, a gateway in front of them keeps these rules in one place. See the mcp gateway page for how that works.

Writing tool descriptions models understand

Good tool descriptions are short, specific and honest about side effects. Name tools with a verb and an object, such as create_invoice. Describe what the tool returns and when to use it instead of a similar tool. Mark destructive actions clearly. List the allowed values of enums in the argument schema instead of in prose. Keep the number of tools per server reasonable, because a model choosing from three hundred tools chooses worse than one choosing from twenty.

Building an MCP server

You can write an MCP server by hand with an official SDK, which is a good way to learn the protocol. For a system with dozens of resources, hand written servers drift: every new field needs a code change in the API, the docs and the server. Generating the server from the same source as the API removes that drift. APIGenerator does exactly that: from a description, a database schema or an OpenAPI file it generates the API and a custom mcp server with tools, keys, limits and logs. For databases, the postgres mcp server page shows how row rules keep agents inside their data.

Key points

• An MCP server tells AI clients which tools and data your system offers.
• Agents pick tools from their descriptions and call them with real effects.
• Derive the server from your API so both stay in sync.
• Treat agents as API clients with their own keys, scopes, limits and logs.