What Is an MCP Server?
Filed as AFR/MCP-01 · task class Code modification · all MCP topics
What the server role actually covers
An MCP server is a program that exposes capabilities to an agent application and answers requests for them over the Model Context Protocol. It is one end of a connection; the other end is a client, held inside a host application. The two open with an initialization exchange in which each declares what it supports, and from then on the server answers requests: list what you offer, run this operation with these arguments, read this piece of content. The connection is stateful and stays open, which is why a server is a running process and not a handler invoked once per call.
Almost every server is a boundary rather than a store. Behind it sits something that already exists — an internal API, a database, a filesystem, a ticketing system — and the server translates a protocol request into a call against that system and the result back again. That is also where the credentials live: the server holds whatever reaching that system requires, and those credentials are never part of the protocol conversation.
In operational terms a server is an ordinary long-running program and inherits the ordinary questions. Something has to start it, notice when it stops, and start it again. Where the host launches it as a subprocess, its lifetime is the session’s and the host answers those questions by default; where it runs on its own and is reached over a network, availability and restarts belong to whoever operates it, and every connected caller meets the same instance. Which of the two a deployment is remains outside the specification.
The three primitives, and who reaches for each
A server publishes three kinds of thing, and the distinction decides how each is used. Tools are operations offered for invocation. Resources are content offered for reading, addressed by URI. Prompts are named message templates offered for filling in. A server may publish any combination of the three, including only one of them, and it says which of them it supports as the connection opens. What it publishes is entirely its own decision — the specification fixes the shape of the answer, never its contents.
The three are separated by who is expected to reach for them, which is the part most often missed on a first reading. An operation is the kind of thing selected in the middle of an exchange, on a decision taken at that moment. Content is brought in deliberately, by the application or by the person using it. A template is normally picked out of a menu. A server designing its surface is therefore not choosing between three interchangeable containers; it is choosing who it expects to initiate each thing it offers.
What a server does not decide
What stays outside the role is the choosing. A server does not hold the conversation with a language model, does not see it, and has no say in whether the host offers its operations during a given exchange. It answers what it is asked, in the order it is asked, and the question belongs to the application at the other end. A server may send requests of its own back down the connection, but those are requests: the host decides whether to answer them.
How the Registry classifies running an MCP server
Standing a server up, keeping it running under supervision and changing what it exposes is engineering work against a live system, which is what the code modification class covers. On the order form's task class field, select Code modification, which covers writing, editing, refactoring, and testing code. That class has its own page at /tasks/code.
The Registry files this topic under one canonical task, fixed in advance and published here rather than generated per visit:
Deploy an MCP server that exposes an internal inventory service to an agent, and keep it running under process supervision.
That string, hashed once, is 5917fad82fe95253… — the first
sixteen of sixty-four hex characters. An assessment ordered against a task of this
kind is computed from the class, the wording submitted, and the permanent chart the
Registry derives for the model configuration named on the order: its ascendant, its
ruling planet, and the composite harmony that constrains the range of verdicts
available to it. The whole derivation is published at /method.
The risk in server work is rarely the code path. It is scope: an operation exposed more widely than the task required, or a change to what the server offers that some caller elsewhere was quietly relying on. 4 risk factors are tracked for code modification tasks generally; an assessment reports 3 of them, selected by the submitted task's own seed rather than chosen. Their names, severities and descriptions are certificate content and are not published on a free page.
What this page does not claim
The Registry makes no representation that an assessment predicts the outcome of any task, and no assessment is validated against real-world results.
This page defines a term and states a classification. It publishes no verdict: the Registry does not test implementations, does not measure how often anything works, and has never run the canonical task above against any model. How the process is supervised, what it is written in, and what it does when the system behind it is unavailable are decisions a real deployment makes and the canonical brief leaves open.
What is sold is a permanent, numbered assessment for one submitted task at one model configuration — a verdict on a seven-point scale, a recommended execution window, and, above the first tier, the risk factors the class tracks. EUR 1.90 Standard, EUR 4.90 Extended, and EUR 14.90 Full Chart, which adds the permanent chart for the configuration itself. Assessments from EUR 1.90; machine-readable at /pricing.json.
Related surfaces
← All MCP topics · The AFR-1 method · Code modification task class
Related topics: MCP client · Tools · Building a server
Questions about an MCP server
- What is an MCP server?
- A program that exposes capabilities to an agent application over the Model Context Protocol. It answers a client’s requests — what do you offer, run this operation, read this content — and typically sits in front of an existing system such as an API, a database or a filesystem, holding the credentials needed to reach it.
- What does an MCP server expose?
- Three kinds of thing, in any combination: operations offered for invocation, content offered for reading and addressed by URI, and named message templates offered for filling in. It declares which of the three it supports when a connection opens, and a caller lists what is actually there afterwards.
- Does an MCP server contain a language model?
- No. A server publishes operations and content and answers requests for them. The conversation with a language model happens in the host application at the other end of the connection, which decides what to put in front of it and when.
- Who starts an MCP server?
- That depends on the deployment rather than on the protocol. A host may launch the server as a subprocess and own its lifetime, or the server may already be running somewhere and be reached over a network, in which case its availability and its restarts belong to whoever operates it.
- Can one host connect to several servers at once?
- Yes, and it is the usual arrangement: one client per server, all held by the same host, which routes each request to the connection it belongs to. The servers have no knowledge of one another.