Skip to content
Domain 8Task 8.2

MCP Server Development

Learn this interactively

What You Need to Know

The Model Context Protocol (MCP) is a standard protocol for connecting an application to an outside system. An MCP server is a program that wraps the system and offers what it can do. A server offers three kinds of capability, called primitives: tools, resources and prompts. A client is the part of an application that connects to one server. The transport is how messages travel between them. The tools a server offers are ordinary tools, and everything in 8.1 applies. Being reachable over a protocol changes nothing about a good description or a good error result.

A greengrocer keeps its stock and price records in one system. Three Claude applications read from it: an online order assistant, a till helper for staff and a reordering assistant for the buyer. Without a shared protocol, each application grows its own integration. That means three sets of tool definitions, three authentication paths and three readings of the same schema. Three teams who do not talk to each other maintain them. They drift apart unseen until a field change breaks two of them, and nobody notices for a month.

What MCP Is For

MCP replaces those integrations with one server. The capability is written once and offered over a standard protocol, and any compliant client can connect to it. The gain shows at the next schema change. The change is made in one place, by the team that owns the underlying system, and every connected client sees it. For the greengrocer, that is the stock team.

This is an argument about maintenance and ownership. A custom tool inside one application can do the same job, so capability does not decide the choice.

Host, Client, Server

The specification names three participants, and the direction matters.

  • MCP Host: "The AI application that coordinates and manages one or multiple MCP clients."
  • MCP Client: "A component that maintains a connection to an MCP server and obtains context from an MCP server for the MCP host to use."
  • MCP Server: "A program that provides context to MCP clients."

The host creates one client per server. A host connected to four servers runs four clients, and each holds its own dedicated connection. Your Claude application is on the client side, and the program wrapping your internal system is the server. At the greengrocer, all three applications connect to the one stock server.

Local and remote describe where a server runs, not what it is. The same program is an MCP server whether it runs as a child process on one laptop or as a network service several teams reach.

As of September 2026 the current protocol revision is 2026-07-28, and it changes how a client and server start talking. The initialize handshake is gone, because every request now carries its own protocol version and client capabilities. Every server must answer a server/discover request with its supported versions and capabilities. A client that wants change notifications, such as toolsListChanged, opts in through a subscriptions/listen stream. The same revision deprecates three features: Roots, Sampling and Logging. They still work during the deprecation window, but new implementations should not add them.

Three Primitives, Three Controllers

To tell the three primitives apart, ask who decides when each one gets used. The specification sets this out as a table.

  • Tools are "functions that your LLM can actively call, and decides when to use them based on user requests". Controlled by the model. Methods: tools/list, tools/call.
  • Resources are "passive data sources that provide read-only access to information for context, such as file contents, database schemas, or API documentation". Controlled by the application. Methods: resources/list, resources/templates/list, resources/read. Each resource has a URI, either a fixed one such as records://schema/batch or a parameterised template such as records://batch/{batch_id}.
  • Prompts are "pre-built instruction templates that tell the model to work with specific tools and resources". Controlled by the user: they are "user-controlled, requiring explicit invocation rather than automatic triggering", and applications typically surface them as slash commands. Methods: prompts/list, prompts/get.

In the Python SDK the three are three decorators on one server object. The example below wraps a gunpowder works' batch records, not the greengrocer's.

python
from mcp.server import MCPServer

mcp = MCPServer("batch-records")


@mcp.tool()
def batch_state(batch_id: str) -> str:
    """Return the current state of one powder batch: corning house, magazine
    location, moisture reading and whether it is cleared for despatch.

    Args:
        batch_id: Batch reference as stencilled on the barrel, e.g. B-2026-0311
    """
    return records.render_batch(batch_id)


@mcp.resource("records://schema/batch")
def batch_schema() -> str:
    """Field-by-field schema of the batch record, for the application to read
    into context before it reasons about a batch."""
    return records.schema_markdown()


@mcp.prompt()
def batch_inspection(batch_id: str) -> str:
    """Standard batch-inspection write-up the powdermen start from."""
    return f"Write up a magazine inspection for batch {batch_id}. Cover, in order: seal condition, moisture reading against the limit, magazine separation distance, and the despatch decision with its reason."


if __name__ == "__main__":
    mcp.run(transport="stdio")

The usual mistake is to make all three into tools, because tools are the primitive most authors already understand. Its most common form is a standard document template that people pull into a session on demand. It is user-initiated and a template, so it is a prompt. As a tool, the decision passes to the model, the opposite of what the person wanted. Passive reference data, such as a schema or a fixed dataset, belongs in a resource the application fetches by URI. At the greengrocer, the stock lookup is a tool and the stock record schema is a resource. The delivery check that staff start when a van arrives is a prompt.

Under the 2026-07-28 revision, a tool can declare an outputSchema. Its results must then carry structuredContent that conforms to it, and the client should validate it. The same JSON also goes in a text block for older clients. This is server-produced data, unrelated to strict or to the model's structured outputs. List and read results also carry required caching hints. ttlMs is a freshness hint in milliseconds, and cacheScope says who may cache. public lets a shared gateway serve one cached tool list to every user. private keeps a per-user resources/read result inside one authorisation context, such as one greengrocer customer's order history.

Transport Follows Topology

There are two transport mechanisms. The choice is a reading of the deployment, never a preference. In the specification's words:

Stdio transport: Uses standard input/output streams for direct process communication between local processes on the same machine, providing optimal performance with no network overhead. Streamable HTTP transport: Uses HTTP POST for client-to-server messages with optional Server-Sent Events for streaming capabilities. This transport enables remote server communication and supports standard HTTP authentication methods including bearer tokens, API keys, and custom headers.

The specification gives the selection rule directly. Local servers on the stdio transport typically serve a single client. Remote servers on the Streamable HTTP transport typically serve many. So ask who needs to reach this server, and from where. One developer wrapping a local command line is local and single-user, which points at stdio. A capability that three applications on several machines must share is remote and multi-user. That points at the HTTP-based transport, and it pulls authentication, deployment, availability and access control into scope. The specification recommends OAuth for obtaining tokens. The greengrocer's stock server is the shared case.

Stdio has one rule that real servers break. The server's stdout is the protocol channel. The specification says the server must not write anything there that is not a valid MCP message. A stray print() in a Python handler corrupts the JSON-RPC messages and breaks the server. Log to stderr, which the specification allows for any logging, or to a file. The 2026-07-28 revision points servers that used the now-deprecated Logging feature to the same place: stderr on stdio, or OpenTelemetry.

Don't answer from a transport name

This part of the specification has already moved once. The exam guide's own wording for this sub-skill says "stdio, sockets". The current specification lists two standard mechanisms, and as of September 2026 sockets appear only as a custom transport that should reuse the stdio framing. Anthropic's MCP connector page still names SSE alongside Streamable HTTP for its own remote requirement. The 2026-07-28 revision marks the old HTTP+SSE transport Deprecated. Learn the topology rule, which is stable. The Domain 8 quick reference lists the current names, with dates.

A Remote Server Is a Service

Choosing the HTTP-based transport is a decision to run infrastructure. A stdio server is a program on somebody's machine. A remote server has a version, an owner, an availability expectation, an authentication story and a list of who may connect. Once several surfaces depend on it, its outages are their outages. The reuse benefit and the operational obligation arrive together, and an honest design weighs both. If the greengrocer's stock server goes down, all three applications lose it. Ideally the owner is the team that owns the underlying system, because that stops the next field change breaking a consumer silently.

Cross-call state now has to be explicit. The 2026-07-28 revision removed protocol-level sessions and the Mcp-Session-Id header. So a server cannot rely on per-connection state to relate one call to the next. A server that needs state across calls, such as an order built up over several calls, returns an explicit, opaque handle from a creation tool. It accepts that handle as an ordinary argument on later calls. A call against an expired or unknown handle should return a tool error that says so. The model can then recover by creating a new one.

Reaching a Server from a Claude Application

One server can serve several Claude surfaces at once, each configuring its connection differently. Claude Code's configuration specifics belong to Domain 3.

On the Claude API, the MCP connector "enables you to connect to remote MCP servers directly from the Messages API without a separate MCP client". The docs page states its two limitations verbatim. The first is "Of the feature set of the MCP specification, only tool calls are currently supported". The second is "The server must be publicly exposed through HTTP (supports both Streamable HTTP and SSE transports). Local STDIO servers cannot be connected directly". So the greengrocer's order assistant can use the connector only if the stock server is public over HTTP, and only for its tools.

The request carries an mcp_servers array of server definitions, plus an mcp_toolset entry in tools naming one of them. Claude's calls come back as mcp_tool_use and mcp_tool_result blocks. For local stdio servers, or when you need MCP prompts and resources rather than tools alone, the SDKs ship client-side helper functions. As of September 2026 the connector is a beta, not available on Amazon Bedrock or Google Cloud. A newer beta header, mcp-client-2026-09-15, lets you pin a server's tool list. A server that changes its tools partway through a conversation then does not change what Claude sees.

In the exam

This sub-skill carries the domain's name and the least of its weight. Three things get keyed: what MCP buys you, which primitive a capability belongs on, and how the topology picks the transport.

Most items turn on keeping ownership apart from capability. A stem naming several applications and independent maintenance is not asking whether a custom tool could do the job. The exam guide's own Domain 8 sample keys this, with reusability across several Claude applications and independent maintenance stated in the stem.

The split of primitives by controller is the most examinable distinction in the sub-skill. The usual trap flattens all three into tools. The local and remote point removes a whole family of distractors. The connector's two limitations are examinable as consequences, not trivia.

Exam Traps

Exam Trap

Selecting the option that states MCP is for local integrations only, or that a remote server cannot be shared across several applications.

Both are flat statements of fact that happen to be false, and they read authoritative next to a correct answer that has to describe a design. A server is an MCP server wherever it runs, and serving many clients is precisely what the Streamable HTTP transport is for.

Exam Trap

Reading the inverted pairing as transport knowledge: stdio for the capability three teams must share, and the HTTP-based transport for one developer wrapping a local command line.

Both halves sound like transport facts and only the topology reading separates them. Stdio for a genuinely shared capability means one copy per machine, which is the drift MCP was adopted to remove; a remote transport for a local wrapper buys deployment, authentication and availability obligations for no reuse.

Exam Trap

Exposing a schema document, a reference dataset or a standard template as callable tools, because tools are the familiar primitive.

It puts control in the wrong place. Passive read-only data belongs in a resource the application fetches by URI; a template a person wants to pull in deliberately belongs in a prompt, which is user-invoked by design. When a stem contains a template people invoke on demand, the tool-shaped option is the near-miss and the prompt is the answer.

Exam Trap

Answering an ownership question with a capability argument, by choosing the option that points out a custom tool could do the same thing.

It could, and that is not what the stem asked. When a stem names a second consumer, a demand that the capability be maintained independently of any one application, or a system whose owning team should own its integration, it has told you the deciding fact. This is the exact shape of the exam guide's own Domain 8 sample.

Practice Scenario

A gunpowder works keeps its batch and magazine records in one internal system. Three Claude-based applications read from it, each through its own hand-written integration, and a field change last month broke two of them silently. The works also wants its powdermen to be able to pull a standard batch-inspection template into a session whenever they start an inspection. A single running instance must serve all three applications, and loading the template must be the powderman's decision alone. Which design fits?

Build Exercise

Build Exercise

One Capability, Two Clients, and the Code You Did Not Write Twice

Difficulty
40 minutes

What you'll learn

  • How to move a capability from one application into a shared MCP server without rewriting it
  • Which of tools, resources and prompts a given capability belongs on, and why
  • How to confirm the three primitives independently through their list methods
  • What choosing a remote transport actually adds to your obligations
  1. Take a capability you already expose as a custom tool inside one application and re-implement it once as an MCP server, holding its description and error result to the same standard 8.1 demands

    Why: Doing the move deliberately shows that it is a relocation of the same capability behind a protocol rather than a rewrite, which is the fact a distractor will try to deny.

    You should see: A server file whose tool function is recognisably the same code you started with.

  2. Add one resource and one prompt to the same server: a piece of reference data the application should read for context, and a template a person would want to invoke deliberately

    Why: Choosing the primitive is the sharpest examinable judgement in this sub-skill, and making the choice on your own material is what fixes it.

    You should see: Three declarations on one server, each on a different primitive.

  3. Run it over stdio and connect one client. Confirm that tools/list, resources/list and prompts/list each return what you expect

    Why: Seeing the three list methods answer separately makes the three-primitive split concrete rather than a table you memorised.

    You should see: Three distinct listings, with your template appearing under prompts and not under tools.

  4. Connect a second, different client to the same server and use the capability from both. Write down exactly what you did not have to write twice, and what you DID have to configure twice

    Why: The reuse argument is only worth what you can name, and the configuration you repeated is the honest cost side of it.

    You should see: One implementation, two connections, and a short list of per-client configuration.

  5. Now write down what would change if the two clients were on different machines: which transport, and what that decision adds to your obligations for authentication, deployment and availability

    Why: Choosing a remote transport is a decision to run a service, and an answer that names only the benefit is the answer this sub-skill is trying to prevent.

    You should see: A short note naming the transport, an owner, an auth story and an availability expectation.

Sources

Drill This DomainQuick Reference
Previous LessonTool ImplementationNext LessonAgentic Customisation