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 the capabilities of that system. 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 the way that the client and the server send messages to each other. The tools a server offers are ordinary tools, and everything in 8.1 applies. The rules for a good description and a good error result do not change when a client reaches a tool over a protocol.

This lesson uses one made-up example throughout: a payroll software company that keeps its customers' payslip records in one system. Three Claude applications read from it: a help assistant for customers, a helper for support staff and a reporting assistant for the finance team. Without a shared protocol, each application has its own integration. That means three sets of tool definitions, three authentication paths and three separate interpretations of the same schema. Three teams who do not talk to each other maintain them. The three integrations become different from each other. Nobody sees the difference until a field change breaks two of them, and nobody notices the breakage for a month.

What MCP Is For

MCP replaces those integrations with one server. The capability is written once. The server offers the capability over a standard protocol, and any compliant client can connect to the server. The benefit appears at the next schema change. The team that owns the underlying system makes the change in one place, and every connected client sees the change. At the payroll company, that team is the payroll records 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 payroll company, all three applications connect to the one payroll records 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. This revision changes how a client and a server start to communicate. 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, requests them 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 distinguish the three primitives, ask who decides when to use each one. The specification shows this in a table.

  • Tools are "functions that your LLM can actively call, and decides when to use them based on user requests". The model controls them. 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". The application controls them. Methods: resources/list, resources/templates/list, resources/read. Each resource has a URI. The URI is either a fixed one, such as records://schema/payslip, or a parameterised template, such as records://payslip/{payslip_id}.
  • Prompts are "pre-built instruction templates that tell the model to work with specific tools and resources". The user controls them. They are "user-controlled, requiring explicit invocation rather than automatic triggering", and applications typically show 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 the payroll company's payslip records.

python
from mcp.server import MCPServer

mcp = MCPServer("payroll-records")


@mcp.tool()
def payslip_state(payslip_id: str) -> str:
    """Return the current state of one payslip: employee, pay period,
    net pay and whether it is approved for payment.

    Args:
        payslip_id: Payslip reference as printed on the payslip, e.g. P-2026-0311
    """
    return records.render_payslip(payslip_id)


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


@mcp.prompt()
def payslip_review(payslip_id: str) -> str:
    """Standard payslip-review write-up the support staff start from."""
    return f"Write up a review of payslip {payslip_id}. Cover, in order: hours worked, gross pay against the contract rate, tax and deductions, and the payment 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. The most common case is a standard document template that people load into a session on demand. It is user-initiated and it is a template, so it is a prompt. If the template is a tool, the model makes the decision. That is the opposite of what the person wanted. Passive reference data, such as a schema or a fixed dataset, belongs in a resource that the application fetches by URI. At the payroll company, the payslip lookup is a tool and the payslip record schema is a resource. The payslip review that support staff start when a customer reports an error is a prompt.

Under the 2026-07-28 revision, a tool can declare an outputSchema. The tool's results must then carry structuredContent that conforms to that schema, and the client should validate that content. The server also puts the same JSON in a text block for older clients. This structuredContent is data that the server produces. It is 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. cacheScope says who may cache the result. public lets a shared gateway serve one cached tool list to every user. A gateway is a service that sits between the clients and the server. private keeps a per-user resources/read result inside one authorisation context, such as one employee's payslip history.

Transport Follows Topology

There are two transport mechanisms. The deployment decides the choice. A preference never decides it. 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 indicates stdio. A capability that three applications on several machines must share is remote and multi-user. That indicates the HTTP-based transport. It also makes authentication, deployment, availability and access control part of the work. The specification recommends OAuth, a standard for authorisation, for getting tokens. The payroll records 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. JSON-RPC is a standard format for request and response messages written in JSON. Log to stderr, which the specification allows for any logging, or to a file. The 2026-07-28 revision tells servers that used the now-deprecated Logging feature to use the same place: stderr on stdio, or OpenTelemetry. OpenTelemetry is an open standard for collecting logs and other monitoring data.

Do not rely on a transport name to choose the answer

This part of the specification has already changed once. The exam guide's own wording for this sub-skill says "stdio, sockets". The current specification lists two standard mechanisms. As of September 2026, sockets appear only as a custom transport that should reuse the stdio framing. Framing is the way each message is separated from the next. 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 (where the server runs and who reaches it decides the transport), 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 design and a list of who may connect. When several surfaces depend on the server, an outage of the server is also an outage for those surfaces. The benefit of reuse and the operational obligation come together, and a complete design considers both. If the payroll records server stops working, all three applications lose it. Ideally, the team that owns the underlying system also owns the server. That ownership prevents the next field change from breaking a consumer silently.

State across calls now has to be explicit. The 2026-07-28 revision removed protocol-level sessions and the Mcp-Session-Id header. So a server cannot depend on per-connection state to relate one call to the next. A server that needs state across calls returns an explicit, opaque handle from a creation tool. A pay calculation that is assembled over several calls is one example of such state. The server 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 the handle is expired or unknown. The model can then recover by creating a new handle.

Reaching a Server from a Claude Application

One server can serve several Claude surfaces at once. Each surface configures its connection differently. Domain 3 covers the configuration details for Claude Code.

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 payroll company's help assistant can use the connector only if the payroll records server is public over HTTP, and only for its tools.

The request carries an mcp_servers array of server definitions. It also carries an mcp_toolset entry in tools that names one of those servers. Claude's calls appear in the response 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 provide client-side helper functions. As of September 2026 the connector is a beta. It is not available on Amazon Bedrock or Claude Models on Google Cloud (Google managed). A newer beta header, mcp-client-2026-09-15, lets you pin a server's tool list. A server that changes its tools during a conversation then does not change what Claude sees.

In the exam

MCP is in the domain's name, but this sub-skill has the least weight in the domain. The correct answers depend on three things: what MCP gives you, which primitive a capability belongs on, and how the topology selects the transport.

Most questions depend on keeping ownership separate from capability. A question that names several applications and independent maintenance is not asking whether a custom tool could do the job. The exam guide's own Domain 8 sample tests this point. Its question text states reusability across several Claude applications and independent maintenance.

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

Exam Traps

Exam Trap

Assuming the MCP connector carries a server's prompts and resources, or can reach a local server

As of October 2026, the connector supports tool calls only and needs a server publicly exposed through HTTP. Prompts, resources and local stdio servers go through a client connection the application manages, using the SDK's client-side helpers.

Exam Trap

Choosing stdio for a capability three teams share, and the HTTP-based transport for one developer's local command line wrapper

Local stdio servers typically serve a single client; remote Streamable HTTP servers typically serve many. Stdio for a shared capability means separate copies that become different over time. A remote transport for a local wrapper adds deployment and authentication work for no reuse.

Exam Trap

Exposing a schema document, a reference dataset or a standard template as callable tools

It hands the decision to the model. Passive read-only data belongs in a resource the application fetches by URI; a template a person loads deliberately belongs in a prompt, which is user-invoked by design.

Exam Trap

Answering an ownership question with the argument that a custom tool could do the same thing

It could, but that is not the deciding fact. A second consumer, independent maintenance or a system whose owning team should own its integration is a reason for a shared server. The exam guide's Domain 8 sample has this shape.

Practice Scenario

An invoicing software company keeps its invoice and payment 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 company also wants its account managers to be able to load a standard dispute-review template into a session whenever they start a dispute review. A single running instance must serve all three applications, and loading the template must be the decision of the account manager 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, with a description and error result that meet 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 that a wrong option will 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 most examinable judgement in this sub-skill, and making the choice on your own material is what makes you remember 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 worth only as much as the reuse you can name, and the configuration you repeated is the real cost against 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 authentication design and an availability expectation.

Sources

Drill This DomainBuild ExercisesQuick ReferenceGlossary
Previous LessonTool ImplementationNext LessonAgentic Customisation