Track 03 · Agents & toolsLesson 04 of 12

MCP: connecting agents to the customer's systems

Servers, clients and transports, and what to check before you trust one.

Lesson library · reference
45 min read
75 min hands-on
Pro

What you'll be able to do

Explain MCP's architecture (host, client, server) and its primitives (tools, resources, prompts on the server; elicitation, sampling and roots on the client), including which are deprecated in the current revision.
Describe the JSON-RPC message flow for both the current stateless revision (2026-07-28) and the earlier handshake-based revisions, and what that difference means for deployment.
Choose a transport (stdio or Streamable HTTP) and a deployment shape (local or remote) for an enterprise system, and justify it to a security team.
Explain the MCP authorisation model for HTTP servers: protected resource metadata, resource indicators, audience validation and the ban on token passthrough.
Build and test an MCP server with the official Python SDK, with typed tools, resources and model-readable errors, using in-memory tests and the MCP Inspector.
Assess MCP-specific security risks (tool poisoning, definition changes, over-broad scopes, confused deputy) and the controls for each.

Before you start

Designing tools a model can use well: what makes a tool good, independent of how it is exposed.
Typed output: schemas, validation and tool calls: JSON Schema and tool call wire formats.
The agent loop, written by hand: where tool calls happen.
Working knowledge of HTTP, JSON and OAuth 2.0 authorisation-code flow at the level of "I have configured an app in an IdP".

The short version

The Model Context Protocol (MCP) is an open protocol, built on JSON-RPC 2.0, for connecting AI applications to the systems that hold data and actions. An MCP host (an AI application such as an IDE, a chat app or your agent runtime) creates one client per server it connects to. Servers expose tools (actions the model can call), resources (data the application can read) and prompts (templates a user can pick). Servers run locally over stdio or remotely over Streamable HTTP, and remote servers are protected with an OAuth 2.1-based authorisation model where the MCP server is a resource server that validates tokens issued for it. As of September 2026 the current revision is 2026-07-28, which made the protocol stateless: no initialise handshake, no session, every request carries its own version and capabilities. MCP standardises how your agent reaches a system. It does not decide what the agent is allowed to do there; that is still your design.

Key takeaways:

MCP turns "N agents × M systems" custom integrations into "N clients + M servers".
Tools are model-controlled, resources are application-controlled, prompts are user-controlled.
The 2026-07-28 revision is stateless; clients and servers built for 2025-era revisions still use an initialize handshake and sessions. Expect to support both for a while.
For remote servers, authorisation is OAuth-based with strict audience rules. An MCP server must not pass a client's token through to downstream APIs.
Tool definitions from servers you do not control are untrusted input to your model.

Pro lesson

The rest of this lesson is in Pro.

The mental model, worked example, field note, failure table, exercise and self-check, with the voice tutor.

Every stage and specialisation, in full
Every lab and every role project
Halden weeks 2–10, on your record
Every drill, live in the playground
All solutions, plus the server judge
Lab Assistant and every Teach with AI

Upgrade to Pro