Objectives of the session

1. Master the architecture Host Client Server and JSON-RPC 2.0
2. Choose a transport: stdio vs Streamable HTTP
3. Distinguish Tools / Resources / Prompts by their controller ← exam point #1
4. Build an MCP server and client (Python SDK)
5. Apply the security model and advanced patterns

3:30 a.m.: 2 hours of lessons + 90 minutes of exercises + quizzes

The M×N problem

Before MCP: each AI application × each tool = a specific connector

• 10 applications × 20 tools = 200 integrations to write and maintain
• Each publisher reinvents authentication, schemes, errors

With MCP: M + N

• Each tool exposes one MCP server
• Each application implements one MCP client
• Any server works with any compatible host

Official analogy: MCP is to AI what USB-C is to hardware — a universal port.
MCP = Model Context Protocol, open standard initiated by Anthropic (rapidly evolving ecosystem)

Architecture: the three components

┌──────────────── HOST (IDE, chat app) ───────────────────┐
│   ┌──────────┐     ┌──────────┐     ┌──────────┐        │
│   │ Client 1 │     │ Client 2 │     │ Client 3 │        │
│   └────┬─────┘     └────┬─────┘     └────┬─────┘        │
└────────┼────────────────┼────────────────┼──────────────┘
         │ JSON-RPC       │ JSON-RPC       │ JSON-RPC
    ┌────▼─────┐     ┌────▼─────┐     ┌────▼─────┐
    │filesystem│     │  GitHub  │     │PostgreSQL│
    └──────────┘     └──────────┘     └──────────┘

Golden rule: 1 client 1 server. 3 servers ⇒ 3 clients.

Specific roles

Classic error: believing that a client connects to several servers. No. It is the host who multiplies the customers.

JSON-RPC 2.0: the common language

3 types of messages, on all transports:

Type	id ?	Expected response?
Query
Answer	(the same)	—
Notification

{ "jsonrpc": "2.0", "id": 42, "method": "tools/call",
  "params": { "name": "search_commande",
              "arguments": { "order_id": "CMD-2026-0193" } } }

Session lifecycle

1. initialize — client → server: version + capabilities
2. Server → client: its own capabilities (tools, resources, prompts, subscriptions...)
3. notifications/initialized — open session
4. Discovery: tools/list · resources/list · prompts/list
5. Operations: tools/call · resources/read · prompts/get
6. Clean transport closure

Capacity negotiation — why?

Guaranteed exam question.

• Each party declares what it can do in the handshake
• We only use the intersection of the abilities
• A server never sends a notification that the client has not declared to support

Purpose: protocol evolution without breaking compatibility.
Old client + recent server = cooperation on the common base.

Transport 1: stdio

The server = subprocess of the host. JSON-RPC to stdin/stdout.

• Minimum latency, zero network
• No open ports · permissions inherited from the OS
• Host-related life cycle
• Logs on stderr — never stdout!

{ "mcpServers": { "commandes": {
    "command": "python",
    "args": ["/opt/mcp/serveur_commandes.py"] } } }

The stdio trap (exercise demo)

@mcp.tool()
def search(order_id: str) -> dict:
    print("debug: step 2 OK")     # ←  BOOM
    ...

• print() written to stdout → corrupts JSON-RPC stream
• Client fails to parse messages → broken session

Solution: logging configured to stderr, or file.

Classic exam trick question.

Transport 2: Streamable HTTP

Replaces SSE (deprecated) for remote servers.

• POST JSON-RPC messages to a single endpoint (/mcp)
• The server can respond in simple JSON or open a feed (progressive results, notifications)
• Sessions via header Mcp-Session-Id, resumed after interruption
• Web authentication: OAuth 2.1, bearer tokens

A deployment → thousands of clients.

Transport decision matrix

Criterion	studio	HTTP Streamable
Location	Local	Remote / cloud
Users	1	N (shared)
Auth	Legacy from OS	OAuth 2.1 / tokens
Local files	direct
Deployment	With the host app	Operated web service

Pocket rule: single-user local → stdio · authenticated shared service → HTTP Streamable · SSE only → false response.

The table to memorize

Primitive	Controller	Trigger	Analogy
Tool	The model	The LLM decides during its reasoning	Hands
Resource	The application	The host chooses what to inject into the context	Eyes (read only)
Prompt	The user	Explicit slash menu/command	Pre-filled form

model-controlled · application-controlled · user-controlled

Tools — invoked by the model

• Input: JSON Schema — the model knows which arguments to provide
• Output: structured content blocks (text, image, embedded resource)
• Side effects allowed ⇒ user consent required

{ "name": "refund_order",
  "description": "Refunds an order. Refused > $500.",
  "inputSchema": { "type": "object",
    "properties": { "order_id": {"type": "string"},
                    "amount": {"type": "number"} },
    "required": ["order_id", "amount"] } }

Resources — exposed by the application

• Identified by URI: file:///rapports/q2.pdf · db://clients/12345 · api://meteo/paris
• Read only — if it modifies a state, it's a Tool
• Templates: db://commandes/{order_id} — resource families
• Subscriptions: resources/subscribe → notifications/resources/updated

Why “application-controlled”? The host filters what enters the context: window protection and privacy.

Prompts — triggered by the user

• Configured prompt templates: name, description, arguments
• Presented by the host: slash command, drop-down menu
• Use cases: repeatable and structured flows

{ "name": "rapport_incident",
  "arguments": [
    { "name": "severite", "required": true },
    { "name": "systeme",  "required": true } ] }

Examples: PR analysis · contract review · incident report

Exam Trap #1

“A database search is a reading, therefore it is a Resource” — FALSE

• If the model dynamically decides to search ⇒ Tool (even when reading)
• If the application pre-selects the data to inject ⇒ Resource

The boundary is through the controller, not through read/write.

Decision tree

1. Side effect / state modification? → Tool
2. Data to read, injected by decision of the application? → Resource
3. Flow triggered explicitly by the human, with parameters? → Prompt
4. The model must decide alone to go searching? → Tool, even in reading

(Interactive selector in the session web page)

MCP server in Python — skeleton

from mcp.server.fastmcp import FastMCP
mcp = FastMCP("commandes")

@mcp.tool()
def search_commande(order_id: str) -> dict:
    """The model decides WHEN to call — write it for the model."""
    ...

@mcp.resource("db://commandes/{order_id}")
def fiche(order_id: str) -> str: ...

@mcp.prompt()
def analyse_litige(order_id: str, motif: str) -> str: ...

mcp.run()   # stdio by default

SDK API evolving — check version.

Server-side safeguard: the $500

MAX_REFUND = 500.0

@mcp.tool()
def refund_order(order_id: str, amount: float) -> dict:
    if amount > MAX_REFUND:
        return { "status": "refused", "escalate": True,
                 "reason": "Human validation required" }
    return { "status": "completed", ... }

In the prompt: a suggestion, bypassable by injection.
In the server: a law, which holds even if the model is manipulated.
Defense in Depth — exam question.

Standardization at the border

Two MCP servers, two date formats:
15/03/2026 (internal) · 27 Mar 2026 (carrier)

def normaliser_date(valeur: str) -> str:
    for fmt in ("%Y-%m-%d", "%d/%m/%Y", "%d %b %Y"):
        try:
            return datetime.strptime(valeur, fmt).date().isoformat()
        except ValueError: continue
    raise ValueError(f"Format inconnu : {valeur!r}")

ISO 8601 everywhere, in code, at the border.
Never “the model will guess” — ambiguity 03/04 = April 3 or March 4?

MCP client in Python

async with stdio_client(params) as (read, write):
    async with ClientSession(read, write) as session:
        init = await session.initialize()        # negotiation
        tools = await session.list_tools()      # discovery
        result = await session.call_tool(      # invocation
            "refund_order",
            {"order_id": "CMD-1", "amount": 750.0})

• ClientSession manages handshake, id, request/response correlation
• Multiple servers ⇒ multiple sessions + namespacing tools
  (nordcommerce.search / carrier.status)

Security model — 3 pillars

1. Server isolation — separate processes, 1:1 dedicated client, no inter-server leaks: they never talk to each other, only the host sees everything
2. User consent — any side effect tool call is presented and approved
3. Least privilege — narrow-scope tokens, explicitly allowed directories

Third-party tool output = unreliable data, never instructions (anti-prompt injection).

The ecosystem

50+ community servers (rapid growing — check)

filesystem · GitHub · Slack · PostgreSQL · Google Drive · browser · memory...

Architect’s reflex:
search for an existing server before writing one.
We develop for our internal business systems, not for generic integrations.

Advanced patterns (1/2)

Dynamic tool registration

• The server adds/removes tools in session
• Issues notifications/tools/list_changed → the client restarts tools/list
• Case: admin tools exposed after authentication

Resource Subscription

• resources/subscribe → notifications/resources/updated
• Case: monitored configuration, evolving ticket, dashboard

Advanced patterns (2/2)

Prompt chaining

• A Prompt MCP orchestrates a sequence: research → verification → proposal → escalation

Standardization at the border

• The server/client converts dates, currencies, units to a canon (ISO 8601)
• The MCP server = anti-corruption layer between heterogeneous systems

Certification summary — 7 reflexes

1. Client:Server = 1:1, host orchestrates
2. Everything is JSON-RPC 2.0 (request/response/notification)
3. stdio = local · Streamable HTTP = remote · SSE = deprecated
4. Tool = model · Resource = application · Prompt = user
5. Capacity negotiation = evolutionary compatibility
6. Business guardrails server side (the $500!)
7. Tool outputs = unreliable data + consent for side effects