What is an MCP server?

An MCP server is a small program that exposes your tools and data to AI applications over a standard protocol, so any AI app that speaks that protocol can use them without a custom integration being written for it specifically.

That is the whole idea. The rest of this page is the detail behind it.

MCP stands for Model Context Protocol. It is an open standard for connecting AI applications to external systems: files, databases, APIs, internal services. The official documentation compares it to a USB-C port for AI applications, which is a fair analogy in one important respect: the value is not in any single connection, it is in not having to invent a new connector every time.

The problem it solves

Before a standard existed, connecting an AI assistant to a system meant building a bespoke integration for that assistant. Connect the same system to a second assistant and you build it again, differently. Ten systems and three assistants is thirty integrations.

MCP turns that into ten. You write one server per system, and every client that implements the protocol can use it. The integrations that already exist for Claude, ChatGPT, Visual Studio Code, Cursor and others all work against the same servers.

Host, client, server

The terminology trips people up because “client” does not mean what you might assume. There are three participants:

• MCP host is the AI application itself, for example Claude Desktop or VS Code.
• MCP client is a component inside the host. The host creates one client per server it connects to, and each client maintains a dedicated connection.
• MCP server is the program that provides the context.

So a single AI application connected to four servers is running four MCP clients internally. The client is plumbing inside the host, not a separate app you install.

“Server” is also slightly misleading, because a server does not have to be remote. A server running on your own laptop over standard input and output is still called a server. The word describes its role in the protocol, not where it lives.

What a server exposes

A server can offer three kinds of thing, and knowing which is which is most of understanding MCP:

Tools are executable functions the AI can invoke to do something: run a query, call an API, write a file. These are the ones with side effects, and they are what people usually mean when they talk about giving an AI capabilities.

Resources are data sources that provide context: file contents, database records, API responses. Read-only material the model can pull in.

Prompts are reusable templates that structure an interaction, for example a system prompt or a set of few-shot examples for using the tools well.

A database server might reasonably expose all three: tools to run queries, a resource containing the schema, and a prompt with worked examples of querying it sensibly.

There is also a primitive running the other way. Elicitation lets a server ask the user for more information mid-task, which is how a server requests a missing detail or asks for confirmation before doing something consequential.

How it talks

Underneath, MCP is JSON-RPC 2.0. Requests, responses, and notifications where no response is needed.

The protocol is stateless: every request carries the protocol version and the relevant capabilities in a _meta field, so a server can handle each request on its own without remembering the ones before it. A client that wants to know what a server supports first can send a server/discover request, which every server must implement, and get back the supported protocol versions and capabilities in one go.

Discovering and calling a tool looks like this:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": { "location": "San Francisco", "units": "imperial" }
  }
}

Each primitive follows the same shape: */list to discover what is available, then tools/call to execute. Because listing is a live request rather than a static manifest, the available tools can change while the client is connected.

Two transports

Stdio uses standard input and output between processes on the same machine. It is what a local server uses, and it has no network overhead. Typically one server serves one client.

Streamable HTTP uses HTTP POST for client-to-server messages, with optional Server-Sent Events for streaming. This is what remote servers use, it supports the usual HTTP authentication methods, and the specification recommends OAuth for obtaining tokens. One remote server typically serves many clients.

The data layer is identical across both. The same JSON-RPC messages travel over either transport, which is why a server can often be moved from local to remote without its logic changing.

When you actually need one

Not every AI integration needs an MCP server. It earns its place when:

• More than one AI client needs the same system. One server, many clients, is the entire economic argument. With exactly one client and one system forever, a direct integration is simpler.
• The access needs to be governed. A server is a real boundary. It exposes named operations you chose, under permissions you control, and every call is a request you can log. That is a considerably better position than staff pasting exported spreadsheets into a chat window, which is what usually happens otherwise.
• The tool surface needs to be deliberate. Exposing an entire API to a model tends to produce worse results than exposing eight well-named operations. A server is where that curation happens.

The case against is equally real. A server is another service to deploy, monitor and keep current with a protocol that is still moving. If one team wants one integration once, that overhead may not pay for itself.

The part people get wrong

An MCP server does not “give an AI access to your database”. It gives the AI access to the specific operations you defined, and a well-designed server runs those under the permissions of whoever is calling rather than holding one shared admin token.

Getting that wrong is the main way these deployments go badly. A server built around a superuser credential means every user effectively has superuser access through the assistant, whatever your actual access control says. The permission model is worth designing before the first tool is written, not after.

Where to go next

The official specification is readable and is the authority on anything here. If you are weighing whether an MCP server is the right answer for a system in your organisation, our MCP server development page describes how we approach that, including the tool-surface and permission questions above.