Tools, Not Clicks
Appendix C

Resources and Further Reading

“Community Groups are for incubation. The Recommendation Track is for standardization.”

— W3C, Community and Business Groups FAQ1

WebMCP keeps moving after a book is printed, so this appendix is less a reading list than a map of where to look. It lists the primary sources the chapters rely on, grouped by who publishes them, with one line on what each one is good for. Then it maps the folders of the book’s demos repository to the chapters, and it ends with the short routine I use to track changes myself.

Every URL here was fetched again on 2 November 2026 for this edition, and each one answered with a working page, with two kinds of exception you should know about. The npmjs.com package pages serve a bot check to scripts, so for packages I give the npm registry’s own record, which is what npm install reads. And the book’s own repositories in Section C.9 open only for readers who have access to them.2 Dates in the annotations are the dates printed on the pages themselves.

C.1 The specification and its repository

C.2 Chrome

Chrome’s WebMCP documentation is a small set of pages, and they change more often than the spec does. Here they are one by one, with the dates printed on each page on 2 November 2026. Two of them carry my name in the byline.

C.3 Microsoft Edge

C.4 Standards positions, reviews and process

C.5 The Model Context Protocol

C.6 Packages the chapters use

The middle column is what the demos pin, which is what the npm registry reported as latest on 15 October 2026 (except Angular, where the demos pin 22.2.2). The right column is what the registry reported on 2 November 2026.2 Several of these change weekly, so please pin them. The demos stay on the October versions unless a chapter says otherwise.

Table C.1 — npm packages used in the chapters and demos

Package Demos pin Latest, 2 November 2026 What it is Chapters
@modelcontextprotocol/server 2.3.1 2.4.0 MCP TypeScript SDK v2, server package 3
@modelcontextprotocol/client 2.3.1 2.4.0 MCP TypeScript SDK v2, client package 3
@modelcontextprotocol/node 2.1.1 2.1.2 Node.js HTTP middleware for the SDK 3
@modelcontextprotocol/inspector 2.11.0 2.13.0 The MCP Inspector 3
zod 4.6.7 4.6.7 Schema library the SDK uses for tool inputs 3
webmcp-types 0.1.10 0.1.10 TypeScript definitions for WebMCP 5, 9, 10
@mcp-b/global 6.0.3 6.0.3 WebMCP polyfill from MCP-B 9, 15
@mcp-b/webmcp-polyfill 6.0.3 6.0.3 Upstream polyfill “plus temporary declarative tools” 9, 10, 15
@mcp-b/webmcp-local-relay 6.0.3 6.0.3 Relay from a tab’s tools to desktop MCP clients 9
usewebmcp 6.0.3 6.0.3 React hooks for document.modelContext 10, 15
@mcp-b/react-webmcp 6.0.3 6.0.3 MCP-B’s broader React hooks package 10
use-webmcp-tool not used 0.3.0 The React hook package Chrome’s Imperative API page now points to 10
@vueuse/core not used 15.0.0 Vue utilities, including the useWebMCP composable Chrome’s page points to 10
@angular/core, @angular/forms 22.2.2 22.2.4 Angular, whose WebMCP guide Chapter 10 follows 10
playwright 1.64.1 1.64.1 Browser automation used by every demo’s tests 6–17

The packages’ registry records (the npmjs.com pages show the same data to a browser):

C.7 Community projects and framework guides

C.8 Web platform background

C.9 The book’s own repositories

Every folder in the demos repository has a README that maps its files to listings, explains how to run the tests and records what passed. The listings are byte-identical to the book, and most folders include a test that checks this against the chapter’s Markdown. Behavioural tests run against a small document.modelContext mock and, wherever the API allows, against Chromium 156 with --enable-features=WebMCPTesting. Table C.2 maps the folders to the chapters. Chapters 1 and 2 have no code, and Chapter 4’s first listing is the seed of fjord-table/, which Chapter 5 builds out.

Table C.2 — Folders in the demos repository and what each one demonstrates

Folder Chapter What it demonstrates
fjord-table/ 4, 5 Fjord Table’s booking page in plain HTML and JavaScript modules, with search_availability and book_table registered through document.modelContext, unregistered with an AbortSignal, and typed with webmcp-types.
chapters/03-mcp-in-practice/ 3 Trailhead’s backend MCP server on the TypeScript SDK v2: search_products, get_order_status, a returns-policy resource and a packing_list prompt, served over stdio and Streamable HTTP in both protocol eras, tested with an SDK client and the Inspector CLI.
chapters/05-registering-tools/ 5 A Chromium 156 probe that backs Chapter 5’s statements about what Chromium does where it differs from the draft: outputSchema dropped, no input validation, return values, UnknownError. Chapter 5’s listings themselves live in fjord-table/.
chapters/06-annotations-lifecycle-errors/ 6 Trailhead’s product, cart and checkout tools with annotations, the call lifecycle, cancellation through the execution signal, tool-level errors versus platform errors, toolactivated/toolcancel logging, toolchange and debugging tools.
chapters/07-frames-origins-agents/ 7 The Helpdesk Widget across two origins: Ledgerly delegating the tools policy to Supportly’s iframe, exposedTo and fromOrigins, an in-page agent built on getTools() and executeTool(), and an extension that uses the API from a content script.
chapters/08-declarative-api/ 8 Fjord Table’s search and booking forms as declarative tools: toolname, tooldescription, toolparamdescription, toolautosubmit, agentInvoked, respondWith(), the CSS pseudo-classes and validation feedback, tested in Chrome’s trial implementation.
chapters/09-first-webmcp-app/ 9 Fjord Table end to end: progressive enhancement with native WebMCP or an opt-in pinned polyfill, the scriptable Test Agent with a Prompt API planner, an origin-trial meta tag and a desktop-relay configuration.
chapters/10-webmcp-in-frameworks/ 10 Trailhead in React 19 with Vite and usewebmcp (route-scoped checkout, StrictMode-safe registration, a shared external store), and an Angular version with tools in the injector and Signal Forms.
chapters/11-designing-tools/ 11 Trailhead’s catalogue and cart tools and the Helpdesk Widget redesigned: descriptions within character budgets, oneOf enums with titles, a validator that uses the published schema, a description linter, and results and errors a model can act on.
chapters/12-threat-models/ 12 Attacks and mitigations: a same-origin registerTool() wrapper attack (demonstration only), a pre-release audit of the registered tools, cross-origin exposure between Ledgerly and Supportly, and Trailhead tools hardened against injection and over-parameterisation.
chapters/13-privacy-consent-human-in-the-loop/ 13 Trailhead’s checkout, which never completes without a person: the confirmation sheet with trusted clicks and an arming delay, cancellation, and the proposed requestUserInput() IDL.
chapters/14-testing-debugging-evals/ 14 Testing in layers: unit tests for execute, a browser-contract suite, a driver for the DevTools Protocol’s WebMCP domain, an eval runner with a task suite for Fjord Table, and an instrumentation wrapper for real-user measurement.
chapters/15-browser-support-and-standards/ 15 Origin-trial tokens for Chrome and Edge (meta tags and headers), feature detection across WebMCP builds, and standards-watch.mjs, which snapshots seven primary sources and reports what changed.
chapters/16-product-and-business-implications/ 16 Trailhead’s tool catalog owned like product copy, a CI check for Chrome’s character budgets, a measurement wrapper and order attribution, in TypeScript.
chapters/17-the-road-ahead/ 17 Future-proofing: tools as plain data, one adapter that knows the API shape (feature detection, input validation, one signal for the whole catalog), and a probe that reports what a browser supports, from navigator.modelContext to whether outputSchema survives getTools().
appendices/a-api-reference/ Appendix A The WebMCP IDL and the 25 probes behind Appendix A’s tables, run in Chromium 156.
appendices/d-migration/ Appendix D Before-and-after migration listings, with the “after” code (including the all-or-nothing tool set) tested in Chromium 156.

C.10 How to track changes

Most of what dates this book shows up in five places first. A twenty-minute check once a month covers them, and that is exactly how the second edition’s changes were found.

  1. The spec’s date line and commit history. If the date under the title has changed, read the commits since your last visit. Each one is small and dated.
  2. New and closed issues. Watch the repository on GitHub (Watch → Custom → Issues and Pull requests) and skim the titles. Chapter 17 lists the open questions most likely to change your code.
  3. chromestatus and Chrome’s docs. The JSON form of the feature entry changes when a trial is extended, a stage moves or a review lands. The “Last updated” dates on the pages in Section C.2 tell you which Chrome guide to re-read (three of them changed in the two weeks after the first edition).
  4. Positions and reviews. The labels on the Mozilla, WebKit and TAG issues are the signal, and the comments explain it.
  5. The charter. The Agentic Web WG draft, its strategy issue and the public-new-work list will show whether WebMCP gets a Working Group home.

Chapter 15’s standards-watch.mjs, in the demos repository, automates most of this list. It fetches the spec, the commit history, chromestatus, the Edge trial page and the three position and review threads, saves a snapshot, and exits with a non-zero code when anything changed, so you can run it on a schedule in CI.

Still in fluxthis appendix

URLs are the most fragile thing in a book. Several moved while this one was being written: modelcontextprotocol.io/specification/latest redirects to the dated 2026-07-28 page, the MCP specification repository lives at modelcontextprotocol/modelcontextprotocol, the spec’s old #violation-same-origin-boundaries anchor gave way to #interaction-with-same-origin-policy on 27 October 2026, and the book’s own web edition moved to webmcp.salnikov.no. If an address here fails, search the publisher’s site for the title. The repositories in C.1 are the least likely to move.

C.11 Summary

  • The spec, its issues and its commit history are the primary sources. Chrome’s documentation shows what one implementation does, and the demos repository shows what Chromium 156 actually did.
  • Chrome’s WebMCP pages each carry a “Last updated” date. Re-read the ones that changed.
  • Chrome and Edge both run origin trials, and chromestatus and the Edge trial page carry their dates.
  • The standards picture lives in four GitHub threads (Mozilla, WebKit, the TAG and the W3C charter work) plus the W3C’s own announcements.
  • Pin package versions. Table C.1 shows both what the demos pin and what was current on 2 November 2026.
  • Run a monthly check, or Chapter 15’s watcher, to know when the book has drifted.

Notes

Notes

  1. W3C, “Community and Business Groups: Frequently Asked Questions”, answer to “Does the Community Group Process replace the Recommendation Track?” (retrieved November 2026). https://www.w3.org/community/about/faq/

  2. Every URL in this appendix was fetched on 14 and 15 October 2026 for the first edition, and again on 2 November 2026 for this one, with a script. On 2 November every URL returned HTTP 200 with three exceptions. The npmjs.com package pages answered the script with a bot check (HTTP 403), so packages and versions were confirmed in the npm registry records instead, for example https://registry.npmjs.org/usewebmcp/latest. The book’s manuscript repository in Section C.9 is private and answers HTTP 404 to anyone without access. The demos repository is public. And webmcp.salnikov.no, the web edition’s new address, was not yet serving when this appendix was checked. One commit-pinned GitHub page (Appendix D’s docs/proposal.md) answered with GitHub’s rate limit and was confirmed through the GitHub API.