MCP server development

What you’ll be able to do

Explain what MCP standardizes and why M×N becomes M+N
Name the three primitives a server exposes
Choose stdio or Streamable HTTP from where the server runs
Prefer an existing server over a custom build

What you need to know

The integration math

Without a standard, connecting M client applications to N data sources means M×N bespoke integrations, each written and maintained separately. MCP defines one protocol both sides speak, so it becomes M+N: each client implements the protocol once, each source exposes it once, and any client works with any server.

That ratio is the whole argument for MCP, and it's the reason the exam frames MCP as a scale decision rather than a capability one — it doesn't let you do anything a custom tool couldn't; it changes what happens when the count grows.

The three primitives

Resources — readable data the client can fetch. A patient directory, a document store, a config file. No side effects.
Tools — callable actions with effects. Book an appointment, submit a claim, send a message.
Prompts — reusable templates the server offers to clients.

The tested distinction is resource versus tool. Read-only data to fetch is a resource; something that does a thing is a tool. Modelling a read as a tool works but muddles the contract, and the exam asks you to name them correctly.

Transports follow deployment

stdio — the client launches the server as a local subprocess and they exchange JSON-RPC 2.0 messages over standard input and output. Local, single-client, no network surface at all. The spec says clients should support stdio wherever possible.
Streamable HTTP — the server runs independently and is reached over HTTP, supporting remote and multi-client use, with the authentication and transport security that implies.

Transport isn't a preference, it follows directly from where the server runs. A locally spawned server on stdio has no network surface at all, which is itself a security property worth naming when the scenario involves sensitive local data.

One piece of history worth carrying, because older material still repeats it: HTTP+SSE was the earlier remote transport and is deprecated, replaced by Streamable HTTP as of the 2025-03-26 specification. If an option offers "SSE" as the current remote transport, that's the dated answer. The protocol itself is transport-agnostic and custom transports are permitted, but these two are the standard pair.

Build last

The order the exam prefers: an existing community or vendor server, then configuring one, then writing your own. A custom MCP server is real software — protocol conformance, versioning, auth, error handling, and ongoing maintenance.

ScenarioA team needs Claude to query their PostgreSQL warehouse. A maintained community MCP server for PostgreSQL exists and covers their query patterns.

Writing their own would be a defensible engineering choice in a vacuum and the wrong answer here. Nothing in the scenario says the existing server falls short — and "we'd rather own it" is a preference, not a requirement. The exam consistently favours the option with less machinery when both solve the stated problem.

Key concept

MCP turns M×N integrations into M+N. Servers expose resources, tools, and prompts. Transport follows deployment — stdio for local, network for remote — and an existing server beats a custom build unless the scenario says otherwise.

Practice scenario

ScenarioA team needs Claude to query their PostgreSQL warehouse. A maintained community MCP server covers their query patterns. They'd rather build their own.

Work it through, then open this

Preference isn’t a requirement. A custom server means protocol conformance, auth, versioning, and maintenance they now carry. Nothing in the scenario says the existing server falls short — and the exam consistently favours the option with less machinery when both solve the stated problem.

Build exercise — Read an MCP server before you write one

Intermediate · 30 min

What you’ll learn

Telling resources, tools, and prompts apart in a real server
Choosing a transport from where the server runs

Find a maintained community MCP server for something you actually use and read what it exposes. Classify each item as a resource, a tool, or a prompt.
- Why: The resource-versus-tool distinction is tested directly, and it’s much clearer in real code than in a definition.
- You should see: Read-only data as resources, side-effecting actions as tools. Note anywhere the author blurred it.
Check how it’s transported — spawned locally over stdio, or reached over the network — and why that fits its deployment.
- Why: Transport follows from where the server runs, not from preference: stdio local, Streamable HTTP remote.
- You should see: A local server on stdio has no network surface at all, which is itself a security property.
Before writing anything of your own, write one sentence on what the existing server doesn’t do that you need.
- Why: A custom server is protocol conformance, auth, versioning, and maintenance you now own. Ownership preference is not a requirement.
- You should see: Either a real gap, or the realisation that you were about to rebuild something that exists.

Exam traps

Modelling read-only data as a tool

Readable data with no side effects is a resource. Tools are for actions that do something.

Choosing a transport by preference

stdio is for a locally spawned subprocess, Streamable HTTP for a remote server. Where it runs decides it — and HTTP+SSE is the deprecated predecessor, not a current choice.

Building a custom server when a maintained one covers the need

A custom server is protocol conformance, auth, versioning, and maintenance you now own. Ownership preference is not a requirement.

Treating MCP as a capability upgrade

It does not enable anything a custom tool could not. It changes the integration math as the number of clients and sources grows.