WebMCP Track · course 5 of 6 · the last one · 8 lessons
WebMCP in production: page, server, test battery, and report
Serve the same action through the screen, through WebMCP on the page, and through an MCP server, with a single rule. Log every call, freeze the test battery, watch the spec, and turn off a tool without a deploy. WebMCP is a draft as of 10/16/2026: production here means preparing with tests, not betting.
- 8lessons
- 7checks in the final report
- 4test modes: no API, polyfill, native, and MCP server
- 0model calls or paid API
The 6 courses in the track
This is course 5, the last one. Lesson 8 brings together the pieces from all six. Suggested order: 0 → 1 → 2 → 3 → 4 → 5.
Course 0Foundation: how agents use a siteRead, operate the screen, or call a tool; accessibility tree; stable vs. draft; a diagnosis of your site.Open the course 
Course 1An MCP server for your serviceOfficial SDK v2 on the 2026-07-28 revision: tools, stateless Streamable HTTP, MRTR, OAuth, and MCP Apps.Open the course 
Course 2WebMCP on your sitedocument.modelContext with detection and fallback, lifecycle, annotations, confirmation, and the test battery in all three modes.Open the course 
Course 3Browser agentsTest your site the way the agent sees it: Playwright MCP, Chrome DevTools MCP, and your site's task battery.Open the course 
Course 4Security between site and agentPrompt injection, data as data, confirmation, exposure, a secure server, and the identity of who arrives.Open the course 
Course 5 · you are hereWebMCP in productionThree surfaces, the log, the frozen battery, the spec watch, governance, and your site's report.Open the course
The lessons
From the 8 layers to the report: three surfaces, log, frozen test battery, neighboring protocols, spec watcher, and governance.
Lesson 1 · 14 minLayered architecture revisited with the state as of Oct 2026A site ready for agents is not an API: it is eight layers, from the ones that describe the site to the ones that protect it. The WebMCP track already had this map; here it comes back with the status of each layer as of 10/19/2026 and a script that searches your code for the evidence of each one.
Lesson 2 · 18 minOne action, three surfaces: HTML, WebMCP on the page, and MCP on the serverThe same booking can arrive through the person on the form, through an agent inside the browser (WebMCP), or through an agent outside it (MCP). If each path has its own copy of the rule, they drift apart. In this lesson the rule lives in a single file, and a script proves that the three surfaces respond the same way and ask for the person.
Lesson 3 · 15 minObservability: logging calls, errors, and cancellationsIn production, "the agent couldn't book" only gets solved with a log. Every tool call, through any door, leaves a line: surface, tool, result, and time. No personal data. In this lesson you trigger the possible outcomes and read what each one leaves in the log.
Lesson 4 · 18 minA frozen battery for your tools, and regression when the spec changesWhen the code or the spec changes, a site with WebMCP fails silently: detection does not find the API, falls back to the form, and nobody notices. Only a battery catches it. In this lesson you freeze the contract and the cases for the tools, run them in all four modes, and watch the battery catch the old API name.
Lesson 5 · 14 minNeighbor protocols as a map: A2A, ACP, AP2, NLWeb, llms.txt — what is still a draftEvery week a new acronym shows up promising to make your site "AI-ready." Almost all of them are drafts or proposals, and each one lives in a different layer. In this lesson you place each neighbor protocol on the map, with a status and a date, and decide for your site: adopt, wait, or does not apply.
Lesson 6 · 15 minLiving with an API that changes: watch the spec, Chrome Status and the MCP changelogThe WebMCP API has already moved once: from navigator to document. It will change again before any stable release. Instead of finding out from a visitor, record what the sources said on the day the test suite passed and let a script compare. Changed? Run the test suite and read it before touching anything.
Lesson 7 · 16 minProduction and governance: who approves a new tool, versioning, shutting it off fastA tool for an agent is an action on your site performed by someone else. It needs an owner, an approval date, an autonomy level, and a way to go offline in minutes without breaking the form. In this lesson the approved catalog becomes a file that the page and the server read, a script checks it, and a state shuts a tool off.
Lesson 8 · 20 minFinal project: your site + server + battery + reportThe final project brings the pieces together: the page with tools, the MCP server with the same rule, the frozen battery, the log, the watch, and the approved catalog. One script runs the seven checks and writes your site's dated report. You leave with it and with the maintenance plan for when the spec changes.
Who it's for
- 1People who took course 2 (WebMCP on the page) and course 4 (security), or who already register tools and run an MCP server.
- 2A dev or technical owner who will maintain a site used by agents for months, with the API still changing.
- 3People who want to prove with a test, not a screenshot, that the site works with and without an agent.
What you'll be able to do
- 1Serve one action through the screen, through WebMCP, and through MCP with the same rule.
- 2Log calls, errors, refusals, and cancellations without storing personal data.
- 3Freeze the test battery and catch the regression when the spec or the code changes.
- 4Approve, version, and turn off tools through the catalog, without a code deploy.
Where this course fits in the WebMCP Track
- 1This is course 5, the last one: it brings together the page (course 2), the server (course 1), the agent's view (course 3), and security (course 4).
- 2Each topic that belongs to another course is linked; here the focus is operations.
- 3Before you start: Node 20 or newer, git, and disk space for Playwright's Chromium.