Creating MCPs on FrenchForet

The Problem and the Thesis

Mon, 01 Jan 0001 00:00:00 +0000

Goal: understand what this course is for, set up the estate you will work in for the rest of it, and take a first look at that estate as three different people. By the end of the unit you will have Postgres and OpenSearch running with realistic data, and a small script that asks the same questions as an L1 analyst, an L3 responder and an auditor and gets three different answers. That difference is the whole course in miniature: once an agent can reach your systems, who it is acting for decides what it should be able to see and do.

The Current Protocol and a First Server

Mon, 01 Jan 0001 00:00:00 +0000

Goal: build your first real MCP server, a read-only CMDB server, with the official Python SDK v2, on the current protocol (2026-07-28). Along the way you’ll see exactly what changed since the hand-rolled server of Foundations §18: no handshake, no sessions, and every request carrying what it needs. You’ll drive the server with the SDK’s Client, watch every frame go over the wire, and give it a joinable log from its first line of code.

The Host Side

Mon, 01 Jan 0001 00:00:00 +0000

Goal: build the other end of the protocol, a host: the application that starts MCP servers, hands their tools to gpt-oss-120b, runs the tool calls the model asks for, and asks the person (never the model) when a server needs a decision. You’ll run two servers at once, Unit 1’s CMDB server and a new ticketing server whose one write action asks for confirmation with the 2026 protocol’s input_required.

Where this fits: Unit 1 built a server and drove it from a script. Here a model does the choosing. This unit builds on Foundations §15 (the tool-use loop) and §18 (§18’s bridge did a small version of this by hand). The host you build is also the harness the rest of the course reuses: Unit 3 measures catalogs through it, Unit 6 A/B-tests tool descriptions through it, and Unit 11 turns it into an eval runner. It still needs no Docker: both servers run on in-memory data.

Catalogs and Discovery

Mon, 01 Jan 0001 00:00:00 +0000

Goal: give a model what it needs to ask good questions of the CMDB and the SIEM, and measure the difference. You’ll build the two common answers side by side:

raw discovery: what Postgres and OpenSearch say about themselves;
a curated catalog: what the data means, how to query it, and what this caller may see.

You’ll check the catalog against what the backends actually enforce, measure what each approach costs in the model’s context, and run an eval that measures query accuracy over repeated runs. The CMDB server also moves off the fixture and onto Postgres.

Searching Logs and Incidents

Mon, 01 Jan 0001 00:00:00 +0000

Goal: build the SIEM server’s real tools: incidents, aggregations and log search over OpenSearch. Three habits run through all of them:

every query has a bounded time window, and the server picks only the indexes that window touches;
aggregate first, then drill down: count when, then who, and only then read events;
shape what comes back: catalogued fields only, long text cut short, a page at a time, the total always reported, and a cursor that belongs to the query that made it.

Then you’ll investigate the planted intrusion yourself, and let gpt-oss-120b do it with the same tools, and compare the two paths.

The Permission Dial: Restrictive vs Permissive Tools

Mon, 01 Jan 0001 00:00:00 +0000

Goal: give the same persona’s access to a model four ways, from “run any SQL” to “only these questions”, and measure what each one costs and risks:

permissive: run_sql on the CMDB, and OpenSearch’s own MCP server (raw Query DSL and any REST API) on the SIEM;
guarded: one SELECT, checked on its parse tree; one PPL query, bounded by construction and checked on its compiled plan;
restrictive: task-shaped tools, with the SQL written once by a person;
hybrid: restrictive, plus an escape hatch that runs a guarded query only when the person using the host approves it.

You’ll fire the same risky probes at all four, see what each tool list costs on every call, and run one task set through all four with gpt-oss-120b, several times each.

Designing Tools for a Model Reader

Mon, 01 Jan 0001 00:00:00 +0000

Goal: make the restrictive tools from Units 3-5 easier for a model to use correctly, without changing a line of what they do. You’ll:

serve the same nine tools with four different descriptions, from a few words each to a full rewrite;
measure what each tool list costs, and where the bytes go;
lint the definitions against a short set of rules;
grade the tools’ error messages, which are instructions too;
measure, with gpt-oss-120b, whether the model picks the right tool with the right arguments, and whether it recovers from a mistake when the error tells it how.

Where this fits: Unit 5 showed that restrictive tools have the smallest blast radius and the largest tool list. This unit works on that list: what the model reads, what it costs and what it buys. Unit 7 changes who sees which tools; Unit 9 caches the list; Unit 11 turns this unit’s evals into regression tests.

Identity, Least Privilege and Enterprise Rules

Mon, 01 Jan 0001 00:00:00 +0000

Goal: turn the single-persona servers of Units 3-6 into shared servers that know who is calling and act as that person all the way down. You’ll:

issue signed access tokens from a small local issuer, and verify them on every request;
refuse tokens minted for another server, so no server can replay yours;
give each caller their own tool list, and their own choices inside it;
carry the caller’s identity to Postgres and OpenSearch through a gateway login that holds nothing itself;
add a policy layer: enterprise rules as data, evaluated on every call, every verdict logged, approvals through elicitation;
watch the same questions refused at four different layers, and take each layer away to see what was behind it.

Where this fits: every server so far has acted as one persona from an environment variable (MCP_PERSONA). That’s fine on a laptop for one person. It doesn’t work for a server the whole SOC shares. Unit 6 made the tools easy to use; this unit decides who may use which, and what they get back. Unit 8 limits how much each caller may use; Unit 11 writes this unit’s verdicts to the audit table; enterprise track E3 replaces the local issuer with the full OAuth flow.

Resource Management: Many Callers, Finite Backends

Mon, 01 Jan 0001 00:00:00 +0000

Goal: put Unit 7’s shared servers inside an operating envelope, so that many agents calling at once can’t exhaust the backends, and one agent stuck in a loop can’t starve the rest. You’ll:

measure first, with a load generator that runs many agents against the servers and watches the backends while it does;
replace a connection per call with bounded, shared pools;
give every caller its own limits: rate, result-token quota, concurrency, and the cursors its searches leave open;
write refusals a model acts on: which limit, how long to wait, or what to ask instead;
put time budgets at every layer, and restore one Unit 7 lost without anyone noticing;
price queries before they run, and cap a single tool for everyone.

Where this fits: Unit 7 made the servers shared and carried each caller’s identity to the backends through one gateway login. That login is now the only thing Postgres and OpenSearch see, so their own per-user limits no longer separate one agent from another. This unit does. Unit 9 then scales the servers out; Unit 11 turns the numbers you collect here into per-caller metrics; enterprise track E1 adds write APIs, where a retried call can do damage twice.

Performance and Scale

Mon, 01 Jan 0001 00:00:00 +0000

Goal: run Unit 8’s servers as several replicas, and find out what that buys and what it breaks. You’ll:

measure the two transports against each other, per call, at start-up and in memory;
find what limits throughput before adding anything, from where the CPU goes;
run three replicas on one port, and size their pools so they fit the backend’s limits;
move the per-caller limits into shared state, so three replicas enforce one set;
add a result cache in the one place it’s safe, and watch a cache in the wrong place leak;
measure four OpenSearch choices, including one where the cluster’s own cache quietly does nothing;
package the server as an image with health checks and no secrets inside.

Where this fits: Unit 8 put one server per backend inside an operating envelope. Its limits live in that one process, which its Limits note flagged. Unit 7 left a CMDB lookup on every log question that names a host, with a note that this unit would cache it. Unit 10 then attacks the servers you’ve scaled; Unit 11 watches them.

Attacking and Defending MCP

Mon, 01 Jan 0001 00:00:00 +0000

Status: in progress. This unit’s defences, servers and lab are complete. The negative cases, one per OWASP category, are placeholders that the course team is writing: each is marked Placeholder below and reported as todo by examples/10/cases.py.

Goal: know which defence answers each item of the OWASP MCP Top 10, and where in the stack it lives. You’ll:

map the ten categories onto the gateway you’ve built since Unit 1;
add the defences that belong in the host: an allowlist with namespaced tools, description screening with pinning, an egress rule, redaction, fencing and an audit record;
add the ones that belong in the server: least privilege, parameterised queries, no secrets in results, and approvals for anything that changes something;
see why fencing is a hint to the model and not a control;
find the false positives a heuristic defence produces on your own honest tools.

Where this fits: Units 5, 7 and 8 already built several of these defences without naming them as such: the blast radius on the permission dial, verified identity and the policy layer, and the operating envelope. The estate has carried hostile data since Unit 0: an instruction planted in a syslog line on jump-prod-02, and another in the CMDB description of build-legacy-01. Unit 11 records and tests everything this unit decides.

Observability, Audit and Testing

Mon, 01 Jan 0001 00:00:00 +0000

Goal: know what the gateway did, for whom, and why, and know when a change breaks it. You’ll:

carry one trace across the client, the SDK and the server, and see the SDK’s own spans;
ship every joinable record to OpenSearch without slowing or failing a request;
write an audit log that records every call, allowed or refused, and withholds a result it can’t record;
build per-caller metrics and a service-level objective from the gateway’s own telemetry;
pin the server’s contract with snapshot tests, its decisions with behaviour tests, and the model’s tool choices with an eval gate.

Where this fits: Unit 1 stamped every request with a session, a trace and a step. Units 4 to 9 added fields to that record: what a query cost, who the caller was, what the policy decided, which limit said no. Unit 10 named MCP08, Lack of Audit and Telemetry, as the category this unit answers. Unit 12, the capstone, is reviewed against what this unit records.

The Measured Default (Capstone)

Mon, 01 Jan 0001 00:00:00 +0000

Goal: put everything the course built behind one endpoint, use it to work a real incident from alert to containment proposal, and decide, with evidence, whether it’s ready for production. You’ll:

compose the SOC / IT-ops gateway from the CMDB and SIEM tools, the policy, the envelope and the record, without changing any of them;
add one tool, propose_containment, that proposes a step for a person to approve and executes nothing;
triage the planted incident end to end, the measured way, and follow it through the audit log and the telemetry;
give the same gateway to the model and compare its path with the scripted one;
run a production-readiness review that reports what passes, what’s a caveat, what fails and what nobody has proven yet.

Where this fits: every earlier unit left one layer and one check behind. Units 3 and 4 made the tools; Unit 5 placed them on the permission dial; Unit 7 gave them a caller and a policy; Units 8 and 9 an envelope that holds under load; Unit 10 the threat model; Unit 11 the record and the tests. This unit is where they meet, and the review is where each check earns its keep.

References & Further Reading

Mon, 01 Jan 0001 00:00:00 +0000

The specifications, standards and documentation this course is built on, grouped by topic, with the unit that leans on each. Where the course makes a claim about a protocol, a database or a security property, the source is here. Read the source when your version differs from the course’s: specs and products move faster than courses.

The course targets MCP 2026-07-28 with the Python SDK v2, Postgres 17 and OpenSearch with its security plugin. Links were checked in October 2026.

E1. Backend APIs with Approvals

Mon, 01 Jan 0001 00:00:00 +0000

Goal: let the capstone gateway carry out the step it proposed, through backend APIs that fail the way real ones do, without ever doing it twice, doing it unapproved, or doing it at the wrong time. You’ll:

call an EDR and a ticketing API through a client with timeouts, retries, backoff and a circuit breaker, and make the retries safe with idempotency keys;
put a destructive tool behind three gates in the right order: prechecks, then the person’s approval, then the call;
refuse production changes outside the change window, with an emergency route that is recorded as one;
turn a slow action into a task with the Tasks extension, and serve clients that don’t understand tasks just as well;
prove every claim against a ledger of what the backends really did.

Where this fits: this is the first unit of the optional enterprise track, and it plugs into Unit 12’s gateway. It leans on Unit 7 (the policy and its ticket approval), Unit 8 (backpressure, timeouts and errors a model can act on) and Unit 12 (propose_containment). No model is needed.

E2. The Local Systems Server

Mon, 01 Jan 0001 00:00:00 +0000

Goal: give an agent controlled access to a host under investigation: who logged in, what is running, what it talks to, what will start it again, and what a file is. You’ll:

place host triage on the permission dial, and see why the right rung runs no commands at all;
build a server whose every tool parses a file, with path rules that keep it inside the host it examines and away from credentials;
gate the one write, collecting evidence, behind a person’s approval;
run the server inside the Foundations §16–17 sandbox, because what it parses was written by the attacker, and probe the walls from inside;
triage db-prod-01, the host the attacker pivoted to, and check every finding.

Where this fits: the second unit of the optional enterprise track. It picks up where Unit 12’s triage stopped, uses Unit 5’s dial, Unit 7’s ticket approval and Unit 10’s redaction, and puts Foundations §16 and §17 around an MCP server. No estate and no model are needed; Docker makes it a sandbox.

E3. Full OAuth for Remote Servers

Mon, 01 Jan 0001 00:00:00 +0000

Goal: let a host that has never seen your server connect to it the way a real deployment does: find the issuer, register, send a person to consent, and get a token that works at that server and nowhere else. You’ll:

discover everything from one URL and a 401, with no configuration in the host;
run an authorization server with client registration, PKCE, consent bounded by the person’s groups, and rotating refresh tokens;
ask for more scope only when a tool needs it (step-up), and see who can approve it;
call a downstream API for the person with token exchange, never by passing their token on;
walk the flow by hand and hit every guard: a hostile redirect URI, no resource, a wrong PKCE verifier, a code used twice, a refresh token replayed.

Where this fits: the third unit of the optional enterprise track, after Unit 7. Unit 7’s issuer handed tokens out directly and said the full flow was for later; this is later. The gateway keeps Unit 7’s verification rules (signature, issuer, audience, expiry) and gains everything around them. No estate and no model are needed: three small servers start on loopback ports.