Building an MCP server, at concept level

MCP Server Development is 2.1% of the exam, the smallest sub-skill in either of your domains. So this lesson is deliberately short. Concepts, not an implementation walkthrough, because the return on going deeper here is poor and your time is better spent on the tool loop.

What a server exposes

Three primitives, and the useful way to hold them is who decides.

Tools. Actions. The model decides to invoke one mid-run. This is the primitive that connects to everything you learned in Module 2, and it is the one the connector's mcp_toolset is about.

Resources. Data the client can read and supply as context. The application decides. The model does not go and fetch a resource on a whim; the host hands it over.

Prompts. Templates the server offers. The user or client selects one. Think of a slash command surfaced by a server rather than baked into the app.

Model-driven, application-driven, user-driven. If you remember the three drivers, you can reconstruct the three primitives from scratch.

The trap in this sub-skill is that all three can end up as text in front of the model, so if you sort them by outcome they collapse into one thing. Sort them by who pulled the trigger and they stay separate, which is what a question describing a workflow is testing.

Transport, briefly

A server talks to a client over a transport. There is a local shape, where the client runs the server as a subprocess and speaks over standard input and output, and a remote shape over HTTP.

For the Messages API connector specifically, you do not have to infer this from the field names. The docs say it outright: the server must be publicly exposed over HTTP, and local stdio servers cannot be connected directly. The connector's type field accepts only url, and that URL must start with https://. On the remote side it speaks both Streamable HTTP and SSE.

Worth separating those two claims carefully, because a question can lean on either. The protocol supports both transports. The connector consumes one of them. Saying "MCP cannot do stdio" is wrong; saying "the connector cannot reach a stdio server" is right.

There is a real escape hatch worth knowing, because it stops the constraint reading as a dead end. If you need a local stdio server, you run the MCP client yourself and use the SDK's MCP helpers to convert that server's tools into Claude API tools for the Tool Runner. The connector is what cannot reach stdio; your own process can, and then the tools arrive by the ordinary tool-definition route.

Where to stop

You do not need to write a server to answer 2.1% of a paper correctly. Know the three primitives, know who drives each, know that transport is local or remote. Then go back and re-drill the tool loop, which is worth several times as many marks and where a wrong answer costs you far more.