What is an MCP server? A plain explanation with a real example

Short answer: an MCP server is a program that tells an AI application what it can do and then does it on request. MCP stands for Model Context Protocol, an open protocol that gives AI apps one standard way to call tools, read data and fetch prompt templates. The server wraps something real, such as a database, a file system or a billing system, and the AI app talks to it in a fixed format.

Why does MCP exist?

Before MCP, every AI application wired up its own integrations. If you wanted an assistant to read your tickets, you wrote a connector for that one assistant. If you switched assistants, you wrote it again. With N applications and M data sources you ended up with N times M custom pieces of glue.

MCP turns that into N plus M. A data source ships one MCP server. Any application that speaks MCP can use it. It is the same idea as the Language Server Protocol, which let one language plugin work in many editors.

How does an MCP server work?

There are three roles. The host is the AI application the person is using, like a coding assistant or a desktop chat app. The host runs one client per server. The server is your code.

When a session starts, the client asks the server what it offers. The server answers with a list. After that the model can decide to call something, the host asks the user to approve if needed, the client sends the request, and the server returns a result that goes back into the model's context.

Messages are JSON-RPC 2.0. The transport is either standard input and output, for a server that runs as a local child process, or streamable HTTP, for a server that runs somewhere else.

What can a server expose?

• Tools: functions the model can call, such as create_invoice or search_orders. Each has a name, a description and a JSON Schema for its arguments.
• Resources: read-only data the application can pull in, like a file, a database row or a log. They are identified by URI.
• Prompts: reusable templates a user can pick, for example a review checklist with slots to fill in.

Most servers people use today only expose tools. That is fine. Tools are where the useful behaviour lives.

What does a tool definition look like?

This is what a server sends when the client asks for its tools. The model sees the name and description and uses them to decide when to call it.

{
  "name": "get_stock_level",
  "description": "Return the current quantity on hand for one product in one warehouse.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "sku": { "type": "string" },
      "warehouse": { "type": "string" }
    },
    "required": ["sku", "warehouse"]
  }
}

The description matters more than most people expect. A vague description makes the model call the tool at the wrong time or not at all. Write it like a one-line comment for a coworker who has never seen your system.

Is an MCP server the same as an API?

No, though a server often wraps an API. A REST API is written for programmers who read documentation once and then hard-code calls. An MCP server is written for a model that discovers what is available at runtime and picks calls on its own. It adds discovery, a schema for each call and a place for the host to ask a human for approval.

You usually do not expose a raw API one-to-one. A good server offers fewer, higher-level tools. An assistant that has to chain fifteen low-level endpoints to answer one question will fail more often than one with a single find_overdue_invoices tool.

When do you actually need one?

• You want an AI assistant to use your own system, and you want it to work in more than one assistant.
• The action needs access control that you decide, not the assistant vendor.
• You want the integration to run on your machine or inside your network so data does not leave.

You do not need one if you are calling a model from your own backend code. In that case plain function calling in the model API is simpler. MCP earns its keep when the client is a product you did not write.

What are the risks?

A server hands a model the ability to act. Anything the model reads can contain instructions, and a tool that can delete or send needs a gate. I wrote a separate piece on MCP security and prompt injection. The short version is to give each server the least access it needs and to require approval for anything that cannot be undone.

How do you try one?

Pick a small official server, such as the file system or Git one, and attach it to a desktop client or a coding assistant. Watch which tools it lists and what the model sends. Then read how to build an MCP server and make a tiny one for something you own. Ten lines of code is enough to see the whole loop.