MCP Learning Roadmap

Why MCP

The Model Context Protocol is how an AI host, such as an IDE assistant or an agent, finds and calls tools, data and prompts on a separate server. One server written once works with every host that speaks the protocol. This roadmap goes from a first server to one you can put behind a load balancer and protect with OAuth. Every lesson runs on your machine with the mcp 2.3.0 Python SDK, and none of them needs a paid model.

Stage 1: Servers, Tools and Data (Days 1-2)

Goal: build a server that exposes tools, resources and prompts, and call it from a client.

Topics:

• LLM Tool Use and Function Calling: how a model picks a tool, the idea MCP standardises
• MCP: Your First Server and Client: run a one-tool server over stdio and call it from a scripted client
• MCP Tools: Schemas, Results and Errors: read the schema built from type hints, and tell tool errors from protocol errors
• Structured Outputs in Production: return output a program can trust, not just text
• MCP Resources and URI Templates: expose files and records by URI, including templates and binary data
• MCP Prompts and Argument Completion: ship reusable prompt templates and suggest argument values

Milestone: write a server for something you use, such as a notes folder or a small SQLite database, with two tools, one resource template and one prompt. A scripted client must list all three and call each one.

Stage 2: The Protocol Underneath (Days 3-4)

Goal: know what goes over the wire, so you can debug any client or server.

Topics:

• The MCP Wire Protocol: JSON-RPC by Hand: send raw messages and read the _meta envelope, server/discover and the error codes
• Logging, Progress and Cancellation in MCP: report progress from a slow tool, and cancel or time out a call cleanly

Milestone: drive your Stage 1 server with nothing but JSON lines over a pipe: discover it, list its tools, call one with a bad argument, and explain each error code you get back.

Stage 3: Client Features, HTTP and Testing (Days 5-7)

Goal: let a server ask the client for input, serve it over HTTP, and test it properly.

Topics:

• Elicitation, Sampling and Roots: pause a tool to ask the user, ask the client’s model, and read the client’s roots
• Streamable HTTP, Testing and the MCP Inspector: serve over HTTP with the required headers, test in memory with pytest, check it with the Inspector
• An Agent Loop Over MCP Tools, With Human Approval: let an agent choose tools from several servers, and require a human yes before destructive ones

Milestone: put your server on Streamable HTTP, add one tool that asks for confirmation through elicitation, and cover every tool with a pytest test that runs without a network.

Stage 4: Security and Authorization (Week 2)

Goal: protect the server, and defend the host from servers it shouldn’t trust.

Topics:

• MCP Server Security: contain file paths, audit and pin tool descriptions, and treat annotations as untrusted
• LLM Security Beyond Guardrails: prompt injection and tool abuse from the model’s side
• OAuth and Token-Based Authorization: the general ideas: roles, scopes, audience, refresh tokens, PKCE and DPoP
• MCP Authorization: OAuth 2.1, CIMD and a Real Identity Provider: the MCP flow end to end, CIMD versus DCR, token refresh and Keycloak

Milestone: require a token on your HTTP server. A token for another audience must get a 401, a token without the right scope must get a 403, and a path-traversal attempt on a resource must fail.

Stage 5: Production and Observability (Week 3)

Goal: run several instances behind a load balancer, and see what each request did.

Topics:

• MCP Observability with OpenTelemetry Traces: read the spans the SDK emits, follow one trace across client and server, and export to Jaeger
• Running MCP in Production: put two instances behind nginx, share the request-state key, cache tool lists, and run on Kubernetes

Milestone: run two copies of your server behind nginx. An elicitation that starts on one instance must finish on the other, and every call must show up as a trace in Jaeger.

Not Covered Yet

The Tasks extension, for long-running operations with tasks/get and tasks/update, isn’t covered, because the mcp 2.3.0 Python SDK doesn’t support it yet. A lesson will follow once the SDK implements it natively.

What Comes After MCP

• AI Agents: planning, memory and multi-agent systems that use MCP tools
• Large Language Models: evaluation, retrieval and serving the model that sits in the host
• Building hosts: connecting several servers to one assistant, and choosing which tools a model may see