From aecfeef28a8e6b86635811f1b6bd74f1e6264e26 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Sun, 15 Feb 2026 16:18:52 +0800
Subject: [PATCH 01/46] Add files via upload

---
 webmcp-technical-note-1.md | 171 +++++++++++++++++++++++++++++++++++++
 webmcp-technical-note-2.md | 102 ++++++++++++++++++++++
 2 files changed, 273 insertions(+)
 create mode 100644 webmcp-technical-note-1.md
 create mode 100644 webmcp-technical-note-2.md

diff --git a/webmcp-technical-note-1.md b/webmcp-technical-note-1.md
new file mode 100644
index 0000000..a0a47b3
--- /dev/null
+++ b/webmcp-technical-note-1.md
@@ -0,0 +1,171 @@
+# WebMCP: How a Browser Hack Became a Proposed Web Standard
+
+**Anthropomorphic Press -- Technical Note**
+**15 February 2026**
+
+---
+
+On February 10, 2026, Google's Chrome team launched an early preview of something called WebMCP -- a proposed web standard that would allow any website to expose structured, callable tools to AI agents through a new browser API called navigator.modelContext. Within 72 hours, the announcement had generated coverage in VentureBeat, Search Engine Land, WinBuzzer, The New Stack, and dozens of developer blogs. SEO commentators called it the biggest shift in technical SEO since structured data.
+([Source](https://searchengineland.com/google-releases-preview-of-webmcp-how-ai-agents-interact-with-websites-469024))
+
+Members of the W3C community group where the specification is supposedly being incubated however learned about it from that same press coverage -- not from the group itself.
+
+This technical note reconstructs the chain of events.
+
+## What Is WebMCP
+
+WebMCP (Web Model Context Protocol) is a proposed JavaScript API that allows web developers to expose their web application functionality as "tools" -- JavaScript functions with natural language descriptions and structured schemas that can be invoked by AI agents, browser assistants, and assistive technologies. As the specification states: "Web pages that use WebMCP can be thought of as Model Context Protocol servers that implement tools in client-side script instead of on the backend."
+([Source](https://webmachinelearning.github.io/webmcp/))
+
+The specification proposes two APIs. A Declarative API handles standard actions that can be defined directly in HTML forms. An Imperative API handles more complex, dynamic interactions requiring JavaScript execution through navigator.modelContext.registerTool(). Together they allow web pages to function as tool servers for AI agents, running entirely client-side in the browser.
+([Source](https://github.com/webmachinelearning/webmcp/blob/main/docs/proposal.md))
+
+Critically, WebMCP is not the same thing as Anthropic's Model Context Protocol (MCP), despite sharing a name fragment and conceptual lineage. The two protocols operate in different layers and serve different purposes. Anthropic's MCP is a backend protocol: it uses JSON-RPC for client-server communication, runs on hosted servers (typically in Python or Node.js), connects AI platforms like Claude or ChatGPT to external services, and does not require a browser or a human user to be present. WebMCP is a frontend, browser-native API: it runs entirely client-side in JavaScript, uses the browser's postMessage system for communication, requires an active browser session with a human user present, and exposes website functionality directly to agents operating within that browser context. A company might use both: an MCP server for direct API integrations with AI platforms, and WebMCP tools on its consumer-facing website so that browser-based agents can interact with the site while the user is actively browsing. The two are complementary, not competing.
+([Source](https://webmachinelearning.github.io/webmcp/) and [Source](https://github.com/webmachinelearning/webmcp/blob/main/docs/proposal.md))
+
+The WebMCP specification explicitly declares that headless browsing, fully autonomous agents, and backend service integration are out of scope. "Headless browsing" refers to running a browser without a visible interface -- no screen, no human watching -- as automated tools like Puppeteer and Playwright do. By excluding this, WebMCP requires that a human user is present in an active browser session whenever agents invoke tools. This is a deliberate design choice: the standard is built around cooperative, human-in-the-loop workflows, not unsupervised automation.
+([Source](https://webmachinelearning.github.io/webmcp/))
+
+## Origin: From Amazon Frustration to Browser Hack
+
+The concept traces back to Alex Nahas, a backend engineer at Amazon. When Anthropic's MCP arrived in early 2025, Amazon spun up what amounted to one enormous MCP server with thousands of tools. The real problem, however, was authorization: MCP's spec had adopted OAuth 2.1, which essentially nobody at Amazon had implemented internally. Every internal service had its own authentication story.
+([Source](https://www.arcade.dev/blog/web-mcp-alex-nahas-interview))
+
+Nahas realized the browser itself could solve the auth problem -- users are already signed in through federated browser sessions. He developed MCP-B (Model Context Protocol for Browsers), a Chrome extension that let websites expose MCP-compatible tools directly through browser JavaScript, using existing authentication and security models. The underlying protocol he called "WebMCP."
+([Source](https://github.com/MiguelsPizza/WebMCP))
+([Source](https://docs.mcp-b.ai/introduction))
+
+Independently, a separate early implementation by Jason McGhee also used the name "WebMCP" for a similar concept -- a widget allowing any website to act as an MCP server client-side. McGhee has since deferred to the W3C version, noting his implementation is "not compliant with the W3C spec" and that "much more capable folks that develop the web" have taken up the work.
+([Source](https://github.com/jasonjmcghee/WebMCP))
+
+## Google and Microsoft Enter: The W3C Pathway
+
+On August 28, 2025, Patrick Brosset of the Microsoft Edge team published a blog post introducing WebMCP as "a proposal to let you, web developers, control how AI agents interact with your web pages." He described it as a joint effort between the Edge and Google teams and solicited early feedback.
+([Source](https://patrickbrosset.com/articles/2025-08-28-ai-agents-and-the-web-a-proposal-to-keep-developers-in-the-loop/))
+
+In an interview published by The New Stack, Kyle Pflug, group product manager for the web platform at Microsoft Edge, confirmed that WebMCP was a joint Microsoft-Google initiative. Pflug noted that Alex Nahas had joined the group, and that the priority for the rest of 2025 was "deeper conversations with web developers" and working toward "an early developer preview in Chromium."
+([Source](https://thenewstack.io/how-webmcp-lets-developers-control-ai-agents-with-javascript/))
+
+The specification was placed in the GitHub repository of the W3C Web Machine Learning Community Group at github.com/webmachinelearning/webmcp. The repo shows open issues dating from October-November 2025, primarily filed by Khushal Sagar of Google (a spec editor), with issue tracker activity through at least November 17, 2025.
+([Source](https://github.com/webmachinelearning/webmcp/issues))
+
+## Where Is It Housed: The Web Machine Learning Community Group
+
+The specification itself states: "This specification was published by the Web Machine Learning Community Group. It is not a W3C Standard nor is it on the W3C Standards Track." The draft is dated February 12, 2026 and lists three editors: Brandon Walderman (Microsoft), Khushal Sagar (Google), and Dominic Farolino (Google).
+([Source](https://webmachinelearning.github.io/webmcp/))
+
+The Web Machine Learning Community Group was originally proposed on October 3, 2018 by Anssi Kostiainen (Intel) to incubate the Web Neural Network API. It has since expanded its charter to include additional deliverables. The updated charter now lists the "WebMCP API" as a specification deliverable, described as "An API for web apps to expose their functionality as tools to AI agents and assistive technologies."
+([Source](https://webmachinelearning.github.io/charter/))
+
+The charter also notes that the WebML CG "should coordinate with" the AI Agent Protocol Community Group "to ensure these protocols consider WebMCP API requirements, as applicable."
+([Source](https://webmachinelearning.github.io/charter/))
+
+The CG participant lists show that Google LLC, Microsoft Corporation, Intel Corporation, Samsung, Apple Inc., Huawei, and others have representatives in the group.
+([CG participants](https://www.w3.org/groups/cg/webmachinelearning/participants/))
+([WG participants](https://www.w3.org/groups/wg/webmachinelearning/participants/))
+
+The webmachinelearning GitHub organization (https://github.com/webmachinelearning) hosts the WebMCP repo alongside the Web Neural Network API (WebNN), Prompt API, Translation API, Writing Assistance APIs, and Proofreader API. The webmcp repo shows 436 stars and 21 forks as of this writing, with its last update on December 12, 2025.
+([Source](https://github.com/orgs/webmachinelearning/repositories))
+
+Separately, a "WebMCP-org" GitHub organization (https://github.com/WebMCP-org) hosts MCP-B-related implementation code, npm packages, and example applications, including React hooks and transport layers. This is the implementation side, distinct from the specification repo.
+([Source](https://github.com/WebMCP-org))
+
+## The Chrome Launch: February 10, 2026
+
+On February 10, 2026, Google's Andre Cipriani Bandarra announced the WebMCP Early Preview Program. The announcement stated that WebMCP aims to provide a standard way for exposing structured tools, ensuring AI agents can perform actions with increased speed, reliability, and precision. Access to the preview is available in Chrome 146 Canary behind the "WebMCP for testing" flag at chrome://flags.
+([Source](https://searchengineland.com/google-releases-preview-of-webmcp-how-ai-agents-interact-with-websites-469024))
+
+The announcement generated immediate and extensive press coverage. VentureBeat reported the specification was transitioning from community incubation within the W3C to a formal draft, and noted the comparison drawn by Chrome staff engineer Khushal Sagar that WebMCP aims to become "the USB-C of AI agent interactions with the web."
+([Source](https://venturebeat.com/infrastructure/google-chrome-ships-webmcp-in-early-preview-turning-every-website-into-a))
+
+WinBuzzer reported early benchmarks showing approximately 67% reduction in computational overhead compared to traditional visual agent-browser interactions. No other browser vendor has announced implementation timelines, though Microsoft's co-authorship suggests Edge support is probable.
+([Source](https://winbuzzer.com/2026/02/13/google-chrome-webmcp-early-preview-ai-agents-xcxwbn/))
+
+## The Process Question
+
+The technical merits of WebMCP are not the concern raised here. The concern is procedural.
+
+The specification is described as being incubated by a W3C Community Group. A CG draft carries a specific meaning in W3C process -- it is a collaborative, community-driven document subject to group deliberation, review, and consensus-building. Yet the Chrome team shipped a working implementation in Chrome 146 and launched a public developer program before the specification was mature. The spec on GitHub contains multiple sections marked TODO. Open issues remain unresolved.
+([Source](https://github.com/webmachinelearning/webmcp/issues))
+
+As one critical assessment noted, Chrome's unilateral advancement through an early preview program raises questions about whether competing browser vendors will adopt compatible approaches, and the announcement provides limited technical documentation about API structure, authentication mechanisms, or permission models.
+([Source](https://ppc.land/chromes-webmcp-could-end-ai-agents-pixel-parsing-nightmare/))
+
+Members of the Web Machine Learning Community Group report learning about WebMCP from external press coverage rather than through the group's own communication channels. This raises the question of whether the CG incubation process served as genuine community deliberation or as a hosting arrangement for a specification driven primarily by two browser vendors.
+
+This pattern -- browser vendors shipping early implementations to generate developer momentum while the standardization process is still in progress -- is not new. It has a long history in web standards. But it raises particular questions when applied to AI agent infrastructure, where the security, privacy, and trust implications of exposing website functionality to autonomous systems are significant and largely unresolved.
+
+## De Facto Standard in the Making?
+
+To be precise about the status: WebMCP is a Draft Community Group Report. The W3C FAQ explicitly states that "Community and Business Group Reports are not yet W3C Standards" and that groups should not refer to CG work as "standards work" or "draft standards." CG Reports are not W3C Recommendations and do not carry the weight of the W3C Recommendation Track process.
+([Source](https://www.w3.org/community/about/faq/))
+
+Yet Chrome 146 already ships a working implementation behind a feature flag. This is the classic pattern of a de facto standard: ship the implementation, build developer adoption, and the specification follows the code rather than the other way around. The question is whether the community process will shape the final standard, or whether the Chrome implementation will become the reference that everyone else must follow.
+
+It should be noted that WebMCP was discussed at W3C TPAC 2025 in Kobe, Japan, within the Web Machine Learning Community Group sessions. The W3C blog reports that WebMCP was "a major topic" including "considerations about how to manage consent and permissions for sensitive actions in a WebMCP context."
+([Source](https://www.w3.org/blog/ -- TPAC 2025 report))
+
+## How to Contribute
+
+For developers, standards practitioners, and anyone concerned about how AI agents will interact with the web, here are the concrete pathways to participate in shaping WebMCP:
+
+**1. Join the W3C Web Machine Learning Community Group.** W3C Community Groups are open to all. No W3C Membership is required and there is no fee. You need a free W3C account and must agree to the W3C Community Contributor License Agreement (CLA). Join at: https://www.w3.org/community/webmachinelearning/
+([Source](https://www.w3.org/community/about/))
+
+**2. File issues and contribute via GitHub.** The charter states that participants should make all contributions in the GitHub repo, by pull request (preferred), by raising an issue, or by commenting on an existing issue. The spec repo is at: https://github.com/webmachinelearning/webmcp
+([Source](https://webmachinelearning.github.io/charter/))
+
+**3. Test the Chrome implementation and provide feedback.** The early preview is available in Chrome 146 Canary by enabling the "WebMCP for testing" flag at chrome://flags. Developers can apply for access to documentation and demos through Google's Early Preview Program.
+
+**4. Engage with the AI Agent Protocol Community Group.** The WebML CG charter identifies coordination with this separate CG, which develops protocols for AI agent discovery and collaboration across the web. If you work on agent interoperability, this is a relevant touchpoint.
+
+## What to Watch
+
+Several questions remain open. How will WebMCP interact with existing accessibility frameworks, given the specification's claim that the API would benefit assistive technologies? How will rate limiting and abuse prevention work when agents can invoke website tools programmatically? What happens when prompt injection meets client-side tool registration? And critically -- will the W3C community group process catch up to the Chrome implementation, or will the implementation become the de facto standard regardless of community input? The specification is open. The implementation is live. The window for community influence is now.
+
+## Chronology
+
+- **October 3, 2018** -- Web Machine Learning Community Group proposed at W3C by Anssi Kostiainen (Intel) to incubate Web Neural Network API. ([Source](https://www.w3.org/community/webmachinelearning/))
+
+- **Early 2025** -- Anthropic's Model Context Protocol gains adoption. Alex Nahas at Amazon encounters OAuth 2.1 authorization problems with internal MCP deployment. ([Source](https://www.arcade.dev/blog/web-mcp-alex-nahas-interview))
+
+- **2025** -- Alex Nahas develops MCP-B Chrome extension; Jason McGhee independently develops early WebMCP widget. Both demonstrate browser-based MCP feasibility. ([Source](https://github.com/MiguelsPizza/WebMCP) and [Source](https://github.com/jasonjmcghee/WebMCP))
+
+- **August 28, 2025** -- Patrick Brosset (Microsoft Edge) publishes blog post introducing WebMCP as joint Edge-Google proposal, soliciting early developer feedback. ([Source](https://patrickbrosset.com/articles/2025-08-28-ai-agents-and-the-web-a-proposal-to-keep-developers-in-the-loop/))
+
+- **September-October 2025** -- Kyle Pflug (Microsoft Edge) confirms joint initiative in interview with The New Stack. Alex Nahas joins the group. Specification placed in webmachinelearning GitHub org. ([Source](https://thenewstack.io/how-webmcp-lets-developers-control-ai-agents-with-javascript/))
+
+- **October-November 2025** -- Open issues filed on webmachinelearning/webmcp repo, primarily by spec editor Khushal Sagar (Google). Issues tagged "Agenda+" for CG discussion. ([Source](https://github.com/webmachinelearning/webmcp/issues))
+
+- **December 12, 2025** -- Last recorded update to webmcp repo on GitHub. ([Source](https://github.com/orgs/webmachinelearning/repositories))
+
+- **February 10, 2026** -- Google launches WebMCP Early Preview Program in Chrome 146 Canary. Press coverage erupts. ([Source](https://searchengineland.com/google-releases-preview-of-webmcp-how-ai-agents-interact-with-websites-469024))
+
+- **February 12, 2026** -- WebMCP specification dated as "Draft Community Group Report." ([Source](https://webmachinelearning.github.io/webmcp/))
+
+## Reference URLs
+
+- WebMCP specification (Draft CG Report, 12 Feb 2026): https://webmachinelearning.github.io/webmcp/
+- WebMCP proposal/explainer: https://github.com/webmachinelearning/webmcp/blob/main/docs/proposal.md
+- WebMCP GitHub repo (webmachinelearning org): https://github.com/webmachinelearning/webmcp
+- Open issues: https://github.com/webmachinelearning/webmcp/issues
+- WebML CG charter (lists WebMCP as deliverable): https://webmachinelearning.github.io/charter/
+- WebML CG home page: https://www.w3.org/community/webmachinelearning/
+- WebML CG participants: https://www.w3.org/groups/cg/webmachinelearning/participants/
+- WebML WG participants: https://www.w3.org/groups/wg/webmachinelearning/participants/
+- webmachinelearning GitHub org: https://github.com/orgs/webmachinelearning/repositories
+- Brosset blog post (Aug 28, 2025): https://patrickbrosset.com/articles/2025-08-28-ai-agents-and-the-web-a-proposal-to-keep-developers-in-the-loop/
+- The New Stack interview with Pflug: https://thenewstack.io/how-webmcp-lets-developers-control-ai-agents-with-javascript/
+- Arcade.dev Nahas interview: https://www.arcade.dev/blog/web-mcp-alex-nahas-interview
+- Nahas MCP-B repo: https://github.com/MiguelsPizza/WebMCP
+- McGhee early WebMCP: https://github.com/jasonjmcghee/WebMCP
+- WebMCP-org GitHub: https://github.com/WebMCP-org
+- MCP-B docs: https://docs.mcp-b.ai/introduction
+- Search Engine Land (Feb 11): https://searchengineland.com/google-releases-preview-of-webmcp-how-ai-agents-interact-with-websites-469024
+- VentureBeat (Feb 12): https://venturebeat.com/infrastructure/google-chrome-ships-webmcp-in-early-preview-turning-every-website-into-a
+- WinBuzzer (Feb 13): https://winbuzzer.com/2026/02/13/google-chrome-webmcp-early-preview-ai-agents-xcxwbn/
+- PPC Land (Feb 15): https://ppc.land/chromes-webmcp-could-end-ai-agents-pixel-parsing-nightmare/
+
+---
+
+*Anthropomorphic Press, indexed in Dow Jones Factiva. CWIRE*
diff --git a/webmcp-technical-note-2.md b/webmcp-technical-note-2.md
new file mode 100644
index 0000000..4d7f304
--- /dev/null
+++ b/webmcp-technical-note-2.md
@@ -0,0 +1,102 @@
+# WebMCP Technical Note 2: What to Test, What to Watch, What to Tell the Standards Body
+
+**Anthropomorphic Press -- Technical Note 2**
+**15 February 2026**
+
+---
+
+Google's WebMCP early preview is live in Chrome 146 Canary. The specification is still a draft. The community group process is still open. This means the window for meaningful community input is right now -- before implementation momentum makes the current design effectively permanent.
+
+This note is a practical guide. It is written for developers, accessibility practitioners, security researchers, standards participants, and anyone who builds things for the web and wants to understand what WebMCP means for their work. It covers what WebMCP is for, what to test, what the benefits are, what the risks are, and how to communicate findings to the W3C community group that hosts the specification.
+
+## What WebMCP Is For: The Use Cases
+
+WebMCP allows a website to declare a set of tools -- JavaScript functions with structured schemas and natural language descriptions -- that AI agents can discover and invoke. The specification targets several categories of use.
+
+The first is **e-commerce and transactional sites**. A travel booking site could register tools like searchFlights(origin, destination, dates), filterResults(price, stops, airline), and bookFlight(flightId, passengerDetails). Instead of an AI agent trying to parse a complex search interface by reading pixels or DOM elements, it calls the function directly and gets structured JSON back. The site controls exactly what the agent can do and how.
+
+The second is **productivity and SaaS applications**. A project management tool could expose createTask(title, assignee, dueDate), moveCard(cardId, column), and generateReport(dateRange). Browser-based AI assistants could help users manage workflows without the application needing to build and maintain a separate backend MCP server or API integration for every AI platform.
+
+The third is **content and media**. A news site could register searchArticles(topic, dateRange) and getArticleSummary(articleId). A mapping service could expose getDirections(from, to, mode) and findNearby(category, radius). These tools let agents interact with content in structured ways rather than scraping and guessing.
+
+The fourth -- and potentially most significant -- is **accessibility**. The specification claims WebMCP could benefit assistive technologies by providing structured, semantically meaningful interfaces to website functionality. A screen reader enhanced with agent capabilities could invoke tools directly rather than navigating complex visual layouts. This is a strong claim that deserves rigorous testing.
+
+The fifth is **form automation and multi-step workflows**. Complex processes like insurance applications, government forms, or account setup flows could be exposed as sequences of tool calls, allowing agents to guide users through them step by step while the site maintains control over validation, sequencing, and data handling.
+
+## What the Benefits Are
+
+WebMCP offers several concrete advantages over current approaches to AI-web interaction.
+
+**Reliability** is the most immediate. Today's browser agents -- whether using visual parsing or DOM inspection -- are brittle. A minor CSS change can break a visual agent. A DOM restructuring can invalidate a scraping approach. WebMCP tools are explicit contracts: the site declares what is available, the agent calls it, the response is structured. This should dramatically reduce failure rates for agent-web interaction.
+
+**Performance** is the second. Visual agents must capture screenshots, send them to a vision model, interpret the response, generate mouse coordinates, and repeat. WinBuzzer reported a 67% reduction in computational overhead with WebMCP compared to visual approaches. Even if that number proves optimistic in production, the architectural advantage is clear: a function call is faster than a screenshot-interpret-click loop.
+
+**Developer control** is the third. With visual or DOM-based agents, the website has no say in how an agent interacts with it. The agent reverse-engineers the interface. With WebMCP, the developer explicitly defines the interaction surface. Tools can include rate limits, validation, permission requirements, and structured error messages. The site becomes a willing participant in the interaction rather than a passive target.
+
+**Authentication reuse** is the fourth, and was the original motivation. Because WebMCP runs in the browser session, it inherits whatever authentication the user already has. No OAuth flows, no API keys, no separate credential management. The user is already logged in. The agent operates within that session. This solves one of the hardest problems in AI-service integration.
+
+**Standardization** is the fifth. If WebMCP succeeds, a developer implements tools once and every conformant agent can use them -- rather than building separate integrations for ChatGPT, Claude, Gemini, and whatever comes next. This is the "USB-C" argument: one interface, many devices.
+
+## What the Risks Are
+
+The risks are significant, and several are not yet adequately addressed in the specification.
+
+**Prompt injection** is the most acute. WebMCP tools return data to AI agents that then process it in their language model context. A malicious or compromised website could craft tool responses that manipulate the agent's behavior -- injecting instructions, altering the agent's understanding of the task, or causing it to take unintended actions on other sites. The specification does not currently define a defense against this beyond same-origin policy boundaries.
+
+**Scope creep of agent permissions** is the second. WebMCP is designed for human-in-the-loop workflows, with headless browsing explicitly out of scope. But the technical mechanism -- JavaScript functions callable by external code -- does not inherently enforce this. If browser vendors later relax the human-presence requirement, or if extensions find ways to invoke WebMCP tools without user awareness, the permission model collapses. The specification should define what "human in the loop" means technically, not just philosophically.
+
+**Consent and transparency** is the third. When a user visits a site that registers WebMCP tools, do they know? The current design provides no visible indicator to the user that tools have been registered, what data they expose, or when an agent invokes them. Compare this to other browser permission systems -- camera, microphone, location -- where the user explicitly grants access. WebMCP tools operate silently.
+
+**Competitive dynamics** is the fourth. WebMCP gives first-mover advantage to sites that implement tools early, potentially favoring large platforms with engineering resources. Smaller sites that do not implement WebMCP may become invisible to agent-mediated browsing. This could accelerate web consolidation. The specification should consider whether a minimal tool set (search, navigation, content retrieval) should be automatically generated from existing web standards like HTML forms, structured data, and ARIA attributes.
+
+**Data leakage through tool schemas** is the fifth. The natural language descriptions and parameter schemas of registered tools reveal information about a site's internal architecture, business logic, and data models. An agent -- or the platform behind it -- could catalog available tools across thousands of sites to build competitive intelligence. The specification does not address whether tool schemas should be treated as sensitive information.
+
+**Abuse and rate limiting** is the sixth. Agents can invoke tools at machine speed. A poorly defended site could face thousands of tool invocations per second from a single browser session. The specification mentions rate limiting as a consideration but does not define a standard mechanism. Without one, each site must build its own defenses, and many will not.
+
+**Cross-site tool chaining** is the seventh. If an agent can invoke tools on multiple open tabs, it could chain actions across sites in ways no individual site anticipated or authorized. Transfer money on a banking site, then use the confirmation on a shopping site, then post about it on a social network -- all within one agent workflow. The security boundaries for cross-site tool interaction are not yet defined.
+
+## What to Test
+
+For those with access to Chrome 146 Canary, here are the concrete areas that need community evaluation. Each should generate feedback for the W3C community group.
+
+**Test the Declarative API with real HTML forms.** Register tools that wrap existing form actions and verify that validation, error handling, and submission behavior match what a human user would experience. Try edge cases: forms with CAPTCHAs, multi-step forms with session state, forms that redirect on submit. Document where the abstraction breaks.
+
+**Test the Imperative API with dynamic content.** Register tools that interact with JavaScript-heavy applications -- single-page apps, dashboards with real-time data, applications that maintain complex client-side state. Evaluate whether tool calls can reliably interact with application state without causing inconsistencies.
+
+**Test authentication boundaries.** Log into a site, register tools, then observe what happens when the session expires, when the user logs out in another tab, when cookies are cleared. The specification's authentication reuse claim needs verification under adversarial conditions.
+
+**Test tool discovery and enumeration.** If multiple sites in different tabs register tools, how does the agent disambiguate? What happens when two sites register tools with the same name? How does the agent present available tools to the user? Is tool discovery observable by the page (can a site detect that an agent has read its tool list)?
+
+**Test accessibility integration.** If you work with assistive technologies, evaluate whether WebMCP tools provide genuinely better access to site functionality than existing ARIA roles and landmarks. Test with screen readers, switch access devices, and voice control. Document whether WebMCP complements or conflicts with existing accessibility standards.
+
+**Test prompt injection resilience.** Craft tool responses that contain instruction-like text and observe whether the consuming agent's behavior is affected. This is critical safety research. If tool responses can manipulate agent behavior, the security model is fundamentally incomplete.
+
+**Test performance claims.** Measure actual latency and token usage for equivalent tasks performed via WebMCP tools versus visual agent interaction. The 67% overhead reduction claim needs independent verification across different site types and task complexities.
+
+**Test failure modes.** What happens when a tool throws an error? When it returns unexpected data types? When it hangs? When the page navigates away mid-call? The specification should define standard error handling, but the current draft has TODO sections in these areas. Documenting real failure modes will directly shape the specification.
+
+## How to Communicate Findings
+
+Feedback is only useful if it reaches the people writing the specification. Here are the concrete channels, in order of effectiveness.
+
+**File a GitHub issue** at https://github.com/webmachinelearning/webmcp/issues with a clear title, reproducible steps, and a specific recommendation. Tag it with the relevant label if available. The spec editors (Brandon Walderman, Khushal Sagar, Dominic Farolino) monitor this repo. Issues with reproducible test cases and concrete proposals get traction. Issues that say "I don't like this" do not.
+
+**Join the W3C Web Machine Learning Community Group** at https://www.w3.org/community/webmachinelearning/ and participate in discussion. Community Groups are free and open. Participation in CG calls and mailing list threads carries weight in W3C process.
+
+If your findings relate to **agent interoperability** -- how WebMCP tools interact with broader agent ecosystems, discovery protocols, or multi-agent workflows -- also engage with the AI Agent Protocol Community Group, which the WebML CG charter identifies as a coordination partner.
+
+If your findings relate to **security or privacy**, file issues with clear severity assessments. W3C specifications have a tradition of security and privacy self-review questionnaires. Check whether the WebMCP specification has completed one, and if not, request it.
+
+If you publish your findings -- on a blog, in a report, in an academic paper -- link back to the relevant GitHub issues so the discussion stays connected to the specification process.
+
+## The Window
+
+The pattern in web standards is well established. Once an implementation ships in a dominant browser and developers build on it, the specification follows the code. Chrome holds roughly 65% of browser market share. The early preview is live. Developer adoption is beginning. The longer the community waits to engage, the narrower the design space becomes.
+
+This is not an argument against WebMCP. The technical concept is sound, the use cases are real, and the problem it solves -- giving developers control over AI agent interaction -- is important. But a good idea implemented badly, or without adequate security review, or without accessibility testing, or without community input, becomes a liability embedded in the web platform for decades.
+
+The specification is at https://webmachinelearning.github.io/webmcp/. The implementation is in Chrome 146 Canary. The issues page is at https://github.com/webmachinelearning/webmcp/issues. The community group is open to all at no cost. The work is now.
+
+---
+
+*Anthropomorphic Press, indexed in Dow Jones Factiva. CWIRE*

From 53d4aada03b1bea7d467e8ef1a98f4b47dbc1f89 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Sun, 15 Feb 2026 16:21:12 +0800
Subject: [PATCH 02/46] Add files via upload


From fedb0088b380f48e2f3eb99f34fdf6d0769bfb7d Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Sun, 15 Feb 2026 17:02:06 +0800
Subject: [PATCH 03/46] Add files via upload

---
 webmcp-technical-note-3.md | 71 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 71 insertions(+)
 create mode 100644 webmcp-technical-note-3.md

diff --git a/webmcp-technical-note-3.md b/webmcp-technical-note-3.md
new file mode 100644
index 0000000..3f241eb
--- /dev/null
+++ b/webmcp-technical-note-3.md
@@ -0,0 +1,71 @@
+# WebMCP Technical Note 3: WebMCP Is Not an MCP Server
+
+**Anthropomorphic Press -- Technical Note 3**
+**15 February 2026**
+
+---
+
+A persistent claim in the WebMCP ecosystem is that WebMCP turns a website into an MCP server. The W3C specification repository itself states that web pages using WebMCP "can be thought of as Model Context Protocol (MCP) servers that implement tools in client-side script instead of on the backend." Early independent implementations by Jason McGhee and Alex Nahas (MCP-B) literally did function as MCP servers, bridging browser JavaScript to MCP clients through localhost websocket connections using the standard MCP protocol.
+([W3C spec repo](https://github.com/webmachinelearning/webmcp))
+([McGhee implementation](https://github.com/jasonjmcghee/WebMCP))
+([Nahas MCP-B](https://github.com/MiguelsPizza/WebMCP))
+
+The framing is understandable. It is also architecturally misleading, and the confusion has consequences for how developers, security reviewers, and standards participants evaluate the specification.
+
+## The Analogy and Its Limits
+
+WebMCP and Anthropic's Model Context Protocol share a conceptual ancestor: both define "tools" as functions with natural language descriptions and structured schemas that AI agents can discover and invoke. That is where the meaningful similarity ends.
+
+**Anthropic's MCP** is a backend protocol. It uses JSON-RPC 2.0 as its message format, transported over stdio, HTTP with Server-Sent Events, or Streamable HTTP. MCP servers are hosted processes -- typically written in Python or Node.js -- that run on backend infrastructure. They connect AI platforms like Claude, ChatGPT, or Gemini to external services. Authentication follows OAuth 2.1 or custom API key schemes. No browser is required. No human user needs to be present. Headless, fully automated operation is the norm.
+([Source](https://modelcontextprotocol.io/introduction))
+
+**WebMCP** is a frontend browser API. It uses the browser's native postMessage system for communication between the web page and the agent. Tools are registered and executed as client-side JavaScript within an active browser tab. Authentication is inherited from the browser session -- whatever cookies or federated login the user already has. A human user must be present in an active browser session. Headless browsing is explicitly out of scope.
+([Source](https://webmachinelearning.github.io/webmcp/))
+
+The specification's own language -- "can be thought of as" -- acknowledges this is an analogy, not an identity. But the README, the press coverage, and the developer ecosystem have largely dropped the qualifier. The result is that WebMCP is widely discussed as though it were MCP running in the browser, with all the assumptions that entails.
+
+## What the Framing Gets Wrong
+
+When a developer hears "your website becomes an MCP server," they import a set of assumptions from the MCP architecture. Every one of these assumptions is wrong for WebMCP.
+
+**Transport.** MCP uses JSON-RPC 2.0, a well-specified request-response protocol with defined error codes, batching, and notification semantics. WebMCP uses postMessage, the browser's cross-origin communication mechanism. These have different reliability characteristics, different error handling models, and different security boundaries. Code written for one transport does not work with the other.
+
+**Execution context.** An MCP server runs in a controlled backend environment -- a container, a VM, a serverless function -- where the service provider manages the runtime, dependencies, and resource limits. WebMCP tools run in the browser's JavaScript engine, in the same execution context as the web page's own code. They are subject to the browser's security sandbox, but also to its constraints: single-threaded execution, same-origin policy, and the full surface area of client-side attack vectors.
+
+**Authentication.** MCP's specification has adopted OAuth 2.1 for authentication between clients and servers. This was, notably, the problem that motivated WebMCP's creation -- Alex Nahas at Amazon found that OAuth 2.1 was impractical for internal MCP deployments. WebMCP sidesteps this entirely by inheriting the browser session. This is elegant for usability but means the authentication model is whatever the website happens to use, with no protocol-level guarantees.
+
+**Trust direction.** In MCP, the AI platform (client) connects to a known, registered server. The platform decides which servers to trust. In WebMCP, any website the user visits can register tools. The trust decision shifts from the AI platform to the browser, and potentially to the user -- who may not know that tools have been registered at all, since the current specification provides no visible indicator.
+
+**Operational mode.** MCP servers are designed for automated, programmatic access. They can run continuously, handle concurrent requests, and operate without human involvement. WebMCP requires an active browser tab with a human user present. The specification explicitly excludes headless browsing. These are fundamentally different operational paradigms with different scaling characteristics, different failure modes, and different abuse surfaces.
+
+## Why This Matters for Standards Review
+
+The "MCP server" framing is not just imprecise. It actively interferes with rigorous evaluation of the specification.
+
+**Security reviewers** who approach WebMCP as "MCP in the browser" will evaluate it against MCP's threat model. But MCP's threat model assumes a controlled backend environment, authenticated client-server connections, and server-side access control. WebMCP's actual threat model involves client-side JavaScript execution, browser-based trust boundaries, and the full range of web security concerns including cross-site scripting, prompt injection via tool responses, and silent tool registration. Importing the wrong threat model means asking the wrong security questions.
+
+**Developers** who approach WebMCP as "MCP in the browser" may expect protocol-level interoperability -- that a WebMCP tool definition could be used interchangeably with an MCP server tool definition, or that MCP client libraries could connect to WebMCP pages. They cannot. The tool schema format may be similar, but the transport, discovery, and invocation mechanisms are incompatible.
+
+**Standards participants** who approach WebMCP as "MCP in the browser" may underestimate the scope of new specification work required. WebMCP is not an adaptation of MCP to a new environment. It is a new browser API that borrows one concept (the tool abstraction) from MCP and implements everything else differently. It needs its own security review, its own privacy analysis, its own accessibility evaluation, and its own consent model -- none of which can be inherited from MCP.
+
+## What WebMCP Actually Is
+
+WebMCP is a proposed browser API -- specifically, a new interface on navigator.modelContext -- that allows web pages to declare JavaScript functions as tools that browser-based AI agents can discover and invoke. It uses the browser's existing communication, security, and session management infrastructure rather than introducing a new protocol.
+
+The design has real strengths. Authentication reuse eliminates one of the hardest problems in AI-service integration. Client-side execution means no backend infrastructure is needed. The human-in-the-loop requirement provides a natural consent and oversight mechanism -- if implemented correctly.
+
+But these strengths are specific to WebMCP's actual architecture, not to the MCP analogy. Evaluating WebMCP on its own terms -- as a browser API with browser security characteristics -- leads to better questions, better testing, and better specifications than evaluating it as a variant of MCP.
+
+## A Suggested Clarification
+
+The W3C specification and its README should explicitly state that WebMCP is not an implementation of the Model Context Protocol and does not use the MCP wire protocol. It borrows the "tool" abstraction -- functions with schemas and natural language descriptions -- but implements discovery, registration, invocation, and communication through browser-native mechanisms that are architecturally distinct from MCP.
+
+The analogy is useful for first contact. A developer unfamiliar with WebMCP can quickly grasp the concept by thinking "it is like an MCP server, but in the browser." But the specification itself, the security review, and the community evaluation should not rely on the analogy. They should address WebMCP as what it is: a new browser API with its own architecture, its own threat model, and its own design space.
+
+## Both Can Coexist
+
+None of this is an argument against WebMCP or against MCP. A company might maintain an MCP server for direct API integrations with AI platforms and simultaneously implement WebMCP tools on its consumer-facing website for browser-based agent interaction. The two are complementary, not competing, and not identical. Recognizing the distinction is necessary for evaluating each on its own merits.
+
+---
+
+*Anthropomorphic Press, indexed in Dow Jones Factiva. CWIRE*

From bc700c004ff6cbf22d337c4774fc36d393ed3d12 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Sun, 15 Feb 2026 17:16:03 +0800
Subject: [PATCH 04/46] Update webmcp-technical-note-1.md

---
 webmcp-technical-note-1.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/webmcp-technical-note-1.md b/webmcp-technical-note-1.md
index a0a47b3..73736de 100644
--- a/webmcp-technical-note-1.md
+++ b/webmcp-technical-note-1.md
@@ -168,4 +168,4 @@ Several questions remain open. How will WebMCP interact with existing accessibil
 
 ---
 
-*Anthropomorphic Press, indexed in Dow Jones Factiva. CWIRE*
+*Anthropomorphic Press, indexed in Dow Jones Factiva. CWRE*

From f86654edf0d101a706fd04ee495376e144e662da Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Sun, 15 Feb 2026 17:17:16 +0800
Subject: [PATCH 05/46] Update webmcp-technical-note-2.md

---
 webmcp-technical-note-2.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/webmcp-technical-note-2.md b/webmcp-technical-note-2.md
index 4d7f304..8b96ab8 100644
--- a/webmcp-technical-note-2.md
+++ b/webmcp-technical-note-2.md
@@ -99,4 +99,4 @@ The specification is at https://webmachinelearning.github.io/webmcp/. The implem
 
 ---
 
-*Anthropomorphic Press, indexed in Dow Jones Factiva. CWIRE*
+*Anthropomorphic Press, indexed in Dow Jones Factiva. CWRE*

From da69860030968826c84a9d4519ca0766d238402b Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Sun, 15 Feb 2026 17:18:14 +0800
Subject: [PATCH 06/46] Update webmcp-technical-note-3.md

---
 webmcp-technical-note-3.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/webmcp-technical-note-3.md b/webmcp-technical-note-3.md
index 3f241eb..78d3911 100644
--- a/webmcp-technical-note-3.md
+++ b/webmcp-technical-note-3.md
@@ -68,4 +68,4 @@ None of this is an argument against WebMCP or against MCP. A company might maint
 
 ---
 
-*Anthropomorphic Press, indexed in Dow Jones Factiva. CWIRE*
+*Anthropomorphic Press, indexed in Dow Jones Factiva. CWRE*

From 0a9ed5cc0d3961dc18b103f76500181e929004ed Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Sun, 15 Feb 2026 23:23:38 +0800
Subject: [PATCH 07/46] Create index.html

---
 index.html | 966 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 966 insertions(+)
 create mode 100644 index.html

diff --git a/index.html b/index.html
new file mode 100644
index 0000000..fc80ce8
--- /dev/null
+++ b/index.html
@@ -0,0 +1,966 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+  <meta charset="UTF-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1.0">
+  <title>WebMCP Model Card Generator</title>
+  <meta name="description" content="Generate standardized documentation for WebMCP browser-side tools. Extends MCP Model Card Specification v1.0 for the browser ecosystem.">
+  <meta name="author" content="Paola Di Maio, PhD (W3C AI-KR CG Chair) & Claude (Anthropic)">
+  <link rel="preconnect" href="https://fonts.googleapis.com">
+  <link href="https://fonts.googleapis.com/css2?family=DM+Sans:wght@400;500;600;700&family=DM+Mono:wght@400;500&family=Outfit:wght@300;400;600;700;800&display=swap" rel="stylesheet">
+  <script src="https://cdnjs.cloudflare.com/ajax/libs/react/18.2.0/umd/react.production.min.js"></script>
+  <script src="https://cdnjs.cloudflare.com/ajax/libs/react-dom/18.2.0/umd/react-dom.production.min.js"></script>
+  <script src="https://cdnjs.cloudflare.com/ajax/libs/babel-standalone/7.23.9/babel.min.js"></script>
+  <style>
+    * { margin: 0; padding: 0; box-sizing: border-box; }
+    body { font-family: 'DM Sans', sans-serif; }
+  </style>
+</head>
+<body>
+  <div id="root"></div>
+  <script type="text/babel">
+    const { useState, useCallback, useRef } = React;
+
+
+const SECTIONS = [
+  "identity", "apiMode", "tools", "session", "browser",
+  "security", "interaction", "context", "limitations",
+  "discovery", "testing", "backendRelationship",
+];
+
+const SECTION_LABELS = {
+  identity: "Identity & Provenance",
+  apiMode: "API Mode",
+  tools: "Tool Documentation",
+  session: "Session & Auth",
+  browser: "Browser Compat",
+  security: "Security",
+  interaction: "Interaction",
+  context: "Context Reqs",
+  limitations: "Limitations",
+  discovery: "Discovery",
+  testing: "Testing",
+  backendRelationship: "Backend MCP",
+};
+
+const SECTION_ICONS = {
+  identity: "\u{1F3F7}\uFE0F", apiMode: "\u{2699}\uFE0F", tools: "\u{1F527}",
+  session: "\u{1F512}", browser: "\u{1F310}", security: "\u{1F6E1}\uFE0F",
+  interaction: "\u{1F504}", context: "\u{1F4CB}", limitations: "\u{26A0}\uFE0F",
+  discovery: "\u{1F50D}", testing: "\u{2705}", backendRelationship: "\u{1F517}",
+};
+
+// -- TUTORIAL CONTENT per section --
+// Each entry: { title, intro, mcpWay, webmcpWay, keyDifference, tips }
+
+const TUTORIAL = {
+  identity: {
+    title: "What is a WebMCP Model Card?",
+    intro: "A model card is standardized documentation -- like a nutrition label for your tool. It tells agents and developers exactly what they're getting.",
+    mcpWay: "In Anthropic's MCP, servers run on backends (Node.js, Python). Identity includes server name, version, npm package, and JSON-RPC transport.",
+    webmcpWay: "In WebMCP, tools live inside web pages. Identity includes the page URL where tools are registered, plus the HTML page itself becomes the 'server'. No separate infrastructure needed.",
+    keyDifference: "MCP = backend server with its own process. WebMCP = your web page IS the server.",
+    tips: [
+      "Page URL is critical -- it's where agents will find your tools",
+      "Attribution matters: document whether AI helped create the tool",
+      "Version your tools independently from your website version",
+    ],
+    codeExample: null,
+  },
+  apiMode: {
+    title: "Two Ways to Register Tools",
+    intro: "WebMCP offers something MCP doesn't: a declarative HTML-only path alongside the programmatic approach.",
+    mcpWay: "MCP servers define tools in code using JSON-RPC handlers. Every tool requires a server-side function:\n\nserver.setRequestHandler(ListToolsRequestSchema, async () => ({\n  tools: [{ name: 'search', ... }]\n}));",
+    webmcpWay: "WebMCP provides TWO registration paths:\n\nDeclarative -- just add attributes to HTML forms:\n<form toolname=\"searchFlights\" tooldescription=\"Search flights\">\n  <input name=\"origin\" type=\"text\" required>\n</form>\n\nImperative -- JavaScript registration:\nnavigator.modelContext.registerTool({\n  name: 'searchFlights',\n  description: 'Search flights',\n  inputSchema: {...},\n  execute: async (input) => {...}\n});",
+    keyDifference: "MCP requires code for every tool. WebMCP lets you expose existing HTML forms to agents with zero JavaScript.",
+    tips: [
+      "Start with declarative for existing forms -- it's the fastest path",
+      "Use imperative for complex logic, multi-step flows, or dynamic tools",
+      "MCP-B (@mcp-b/global) is a community polyfill before native browser support",
+      "The webmcp.js widget is another option for quick integration",
+    ],
+  },
+  tools: {
+    title: "Documenting Your Tools",
+    intro: "Tool documentation is the heart of any model card. It tells agents what they can call, what to send, and what to expect back.",
+    mcpWay: "MCP tools use JSON Schema for inputSchema, return content arrays with text/image blocks, and annotate with readOnlyHint, destructiveHint, etc.",
+    webmcpWay: "WebMCP tools use the same JSON Schema for inputSchema (great!), but the execute callback runs in the browser -- it can access DOM, session cookies, and framework state. New: requestUserInteraction() lets a tool pause and ask the human for confirmation mid-execution.",
+    keyDifference: "MCP tools run on a server and return data. WebMCP tools run in the browser and can interact with the visible page AND the human.",
+    tips: [
+      "The inputSchema format is identical between MCP and WebMCP -- reuse schemas!",
+      "readOnlyHint in annotations helps agents decide what's safe to call autonomously",
+      "requestUserInteraction() is unique to WebMCP -- use it for destructive actions",
+      "Document error states clearly; agents need to know what can go wrong",
+    ],
+  },
+  session: {
+    title: "Authentication: Inherited, Not Configured",
+    intro: "This is one of the biggest architectural differences between MCP and WebMCP.",
+    mcpWay: "MCP servers manage their own auth: API keys in environment variables, OAuth flows, personal access tokens. The client must configure credentials separately.\n\nGITHUB_TOKEN=ghp_xxx npx mcp-server-github",
+    webmcpWay: "WebMCP inherits the browser session automatically. If the user is logged into the website, the tool has the same privileges. No separate credential management needed.\n\nThe browser's cookie jar, OAuth tokens, and session storage are all available to the execute callback -- because it runs in the same origin.",
+    keyDifference: "MCP = you configure API keys for each server. WebMCP = the browser session IS the authentication.",
+    tips: [
+      "This is both a strength and a risk -- document what privileges the tool inherits",
+      "If some tools need elevated permissions, note which user roles are required",
+      "Mixed auth (some tools public, some need login) is common -- document clearly",
+    ],
+  },
+  browser: {
+    title: "Browser as Runtime",
+    intro: "WebMCP runs inside a web browser. This is fundamentally different from MCP's server-side execution model.",
+    mcpWay: "MCP servers run as standalone processes -- Node.js, Python, Docker containers. They communicate via stdio or HTTP+SSE. Browser compatibility isn't a concept.",
+    webmcpWay: "WebMCP tools execute inside the browser's JavaScript engine. Currently Chrome 146+ Canary only (behind a flag). The MCP-B community project provides a polyfill/extension for broader support.\n\nWhen WebMCP isn't available, the page should degrade gracefully -- human users still see the normal UI.",
+    keyDifference: "MCP = server process, always running. WebMCP = browser tab, only alive while the page is open.",
+    tips: [
+      "Always implement graceful degradation -- not every visitor has WebMCP",
+      "Chrome DevTools MCP bridge connects Claude Desktop to browser tools",
+      "Test in Chrome Canary with chrome://flags > 'WebMCP for testing'",
+      "Edge support expected mid-2026 (Microsoft co-authors the spec)",
+    ],
+  },
+  security: {
+    title: "The Lethal Trifecta",
+    intro: "WebMCP introduces unique security concerns because tools run in the browser with access to user sessions and page content.",
+    mcpWay: "MCP security centers on: API key management, least-privilege scopes, rate limiting, and the trust boundary between client and server.",
+    webmcpWay: "WebMCP adds browser-specific risks. The 'lethal trifecta' identified by security researchers:\n\n1. Data access (tool reads user data)\n2. Untrusted content (page shows third-party content)\n3. External communication (tool can send data out)\n\nAll three together = exfiltration risk. WebMCP mitigates with same-origin scope, CSP compatibility, and mandatory human-in-the-loop design.",
+    keyDifference: "MCP's trust boundary is API keys. WebMCP's trust boundary is the browser's same-origin policy + human oversight.",
+    tips: [
+      "Check the lethal trifecta box honestly -- it's a real risk assessment",
+      "Human-in-the-loop is a design principle, not just a checkbox",
+      "Same-origin scope means tools can only access data from their own domain",
+      "CSP headers affect what your tools can do -- document compatibility",
+    ],
+  },
+  interaction: {
+    title: "Stateful Pages, Stateless Protocols",
+    intro: "Web pages maintain rich visual state. This creates interaction patterns MCP servers don't have.",
+    mcpWay: "MCP tools are typically stateless -- each call is independent. State lives in the backend service (database, API). The MCP protocol itself is stateless.",
+    webmcpWay: "WebMCP tools can be deeply stateful because they share the page's JavaScript runtime. A searchFlights tool might populate results that a bookFlight tool then references. Tools can modify the visible DOM, triggering UI updates the human can see and verify.",
+    keyDifference: "MCP tools return data. WebMCP tools can change what the human sees on screen.",
+    tips: [
+      "Document tool dependencies: which tools must run before others?",
+      "If a tool modifies page state, the human can see the change -- this IS the human-in-the-loop",
+      "Latency matters differently: users see the page, so blocking tools freeze the UI",
+      "Stateful tools need careful error handling -- what if the page state is unexpected?",
+    ],
+  },
+  context: {
+    title: "Page Context as Input",
+    intro: "WebMCP tools can read the rich context of the page they live on. MCP servers only know what's explicitly passed to them.",
+    mcpWay: "MCP tools receive only their explicit input parameters. Any context (user preferences, previous results) must be passed in each call by the client.",
+    webmcpWay: "WebMCP tools can access:\n- DOM state (what's visible on the page)\n- React/Redux/Vue state (framework data)\n- Navigation state (current URL, route)\n- Session data (cookies, localStorage)\n- provideContext() data (explicitly shared by the page)\n\nThis rich context means tools can be much smarter about what the user is doing.",
+    keyDifference: "MCP = explicit input only. WebMCP = the entire page is your context.",
+    tips: [
+      "Document what context your tool reads -- agents need to know what influences behavior",
+      "provideContext() lets you explicitly share data with agents (recommended over implicit DOM reading)",
+      "If your tool reads React state, note which framework version is required",
+      "Navigation dependencies mean agents need to be on the right page first",
+    ],
+  },
+  limitations: {
+    title: "Honest Boundaries",
+    intro: "Good documentation is honest about what tools can't do. This is especially important for WebMCP because browser constraints are different from server constraints.",
+    mcpWay: "MCP limitations are typically: API rate limits, missing features, version requirements, network dependencies.",
+    webmcpWay: "WebMCP adds browser-specific limitations:\n- 50 tools per page recommended (performance)\n- Tools only work while the tab is open\n- No background execution\n- Cross-origin restrictions\n- Mobile browser support varies\n- Extensions may interfere",
+    keyDifference: "MCP limits are about the service. WebMCP limits are about the browser environment.",
+    tips: [
+      "Be specific about failure modes -- what does the agent see when something breaks?",
+      "Edge cases are more common in browsers (ad blockers, extensions, network changes)",
+      "The 50-tool-per-page recommendation is practical, not a hard limit",
+      "Scale limits help agents choose which tools to prioritize",
+    ],
+  },
+  discovery: {
+    title: "Finding Tools Before You Visit",
+    intro: "Discovery is an unsolved problem in WebMCP. Unlike MCP servers, browser tools only exist when you're on the page.",
+    mcpWay: "MCP has established discovery: MCP Registry, GitHub listings, npm packages, .well-known/mcp endpoints. Agents can discover servers before connecting.",
+    webmcpWay: "WebMCP discovery is nascent:\n- Tools are only visible after navigating to the page\n- .well-known/webmcp is proposed but not standardized\n- No equivalent of the MCP Registry for browser tools yet\n- Chrome DevTools MCP can aggregate tools across open tabs\n\nThis is a gap the model card itself helps fill -- it makes tools discoverable via documentation.",
+    keyDifference: "MCP tools can be found before use. WebMCP tools currently require visiting the page first.",
+    tips: [
+      "Model cards themselves aid discovery -- publish them alongside your site",
+      ".well-known/webmcp support would enable pre-visit discovery (advocate for it!)",
+      "The W3C AI-KR CG is working on documentation standards for exactly this gap",
+      "Consider listing your WebMCP tools in your site's structured data / sitemap",
+    ],
+  },
+  testing: {
+    title: "Testing with Real Agents",
+    intro: "WebMCP tools should be tested with actual AI agents, not just unit tests.",
+    mcpWay: "MCP testing: MCP Inspector tool, protocol compliance checks, tool schema validation, integration tests with Claude Desktop or other clients.",
+    webmcpWay: "WebMCP testing adds:\n- Chrome Model Context Tool Inspector extension\n- Live demo testing (travel-demo.bandarra.me)\n- Token usage benchmarks (structured calls vs screenshots)\n- Multi-agent testing (does it work with Claude, GPT, Gemini?)\n- The DevTools quickstart includes benchmark scripts",
+    keyDifference: "MCP tests protocol compliance. WebMCP tests real-world agent interaction in a browser.",
+    tips: [
+      "Test with multiple agents -- tool descriptions that work for Claude may confuse GPT",
+      "Benchmark token usage: one WebMCP call should replace many screenshot interactions",
+      "The Chrome extension lets you inspect tool registrations in real-time",
+      "Document which agents you've tested -- it builds trust",
+    ],
+  },
+  backendRelationship: {
+    title: "Bridging Browser and Backend",
+    intro: "Many applications will have BOTH a backend MCP server and browser-side WebMCP tools. Documenting the relationship between them is crucial.",
+    mcpWay: "MCP servers are standalone. They don't know or care about browser-side tools. Each server is an independent process with its own auth and capabilities.",
+    webmcpWay: "WebMCP tools often complement a backend MCP server:\n- Backend handles: payment processing, database writes, heavy computation\n- Browser handles: UI updates, session-aware searches, human confirmations\n- Auth can be shared (browser session authenticates backend calls)\n\nExample: A flight booking site might have a backend MCP server for payment and a WebMCP tool for search + UI.",
+    keyDifference: "MCP and WebMCP are complementary, not competitive. One spec, two profiles.",
+    tips: [
+      "Document which capabilities are browser-only vs backend-only",
+      "Auth sharing simplifies the developer experience -- note if it works",
+      "Agents may use both in a single workflow: WebMCP for browsing, MCP for transactions",
+      "This is where the 'one spec, two profiles' approach pays off",
+    ],
+  },
+};
+
+// -- Form defaults --
+const defaultForm = {
+  toolName: "", version: "", author: "", creationDate: new Date().toISOString().split("T")[0],
+  license: "MIT", pageUrl: "", attribution: "human", sourceRepo: "", description: "",
+  apiMode: "imperative", declarativeFormName: "", declarativeFormDescription: "",
+  imperativeRegistration: "registerTool",
+  sessionType: "authenticated", permissionsRequired: "", oauthDependencies: "", inheritsSession: true,
+  chromeVersion: "146", mcpbPolyfill: false, browserNotes: "", gracefulDegradation: "",
+  sameOrigin: true, cspCompatible: true, humanInTheLoop: true, dataExposure: "",
+  exfiltrationRisk: "low", rateLimiting: "", lethalTrifecta: false,
+  statefulness: "stateless", toolDependencies: "", pageStateModification: false,
+  latencyEstimate: "", blocking: false,
+  provideContextData: "", domStateAccess: false, reactReduxAccess: false, navigationDependencies: "",
+  cannotDo: "", edgeCases: "", scaleLimits: "50 tools per page recommended", failureModes: "",
+  registryListed: false, wellKnownWebmcp: false, preVisitDiscoverability: "",
+  testMethodology: "", agentsTested: [], passFailCriteria: "", testSuiteLink: "",
+  hasBackendMcp: false, backendServerName: "", capabilityDifferences: "", authSharing: false,
+};
+
+const defaultTool = {
+  name: "", description: "",
+  inputSchema: '{\n  "type": "object",\n  "properties": {},\n  "required": []\n}',
+  outputFormat: "json", errorStates: "", multimodalSupport: false,
+  readOnlyHint: false, destructive: false, async: true, requiresUserInteraction: false,
+};
+
+// -- UI Components --
+
+const S = {
+  input: {
+    width: "100%", padding: "8px 10px", border: "1.5px solid #d1d5db", borderRadius: 7,
+    fontSize: 12.5, fontFamily: "'DM Mono', 'Fira Code', monospace", background: "#fafbfc",
+    color: "#1a1a2e", outline: "none", transition: "border-color 0.2s", boxSizing: "border-box",
+  },
+  focused: { borderColor: "#2563eb", boxShadow: "0 0 0 2px rgba(37,99,235,0.08)" },
+};
+
+function Field({ label, req, hint, children }) {
+  return (
+    <div style={{ marginBottom: 14 }}>
+      <label style={{ display: "block", fontSize: 12, fontWeight: 600, color: "#1a1a2e", marginBottom: 3, fontFamily: "'DM Sans', sans-serif" }}>
+        {label}{req && <span style={{ color: "#e63946", marginLeft: 2 }}>*</span>}
+      </label>
+      {hint && <div style={{ fontSize: 10.5, color: "#6b7280", marginBottom: 4, lineHeight: 1.3, fontFamily: "'DM Sans', sans-serif" }}>{hint}</div>}
+      {children}
+    </div>
+  );
+}
+
+function TI({ value, onChange, placeholder, ...p }) {
+  const [f, setF] = useState(false);
+  return <input type="text" value={value} onChange={e => onChange(e.target.value)} placeholder={placeholder}
+    style={{ ...S.input, ...(f ? S.focused : {}) }} onFocus={() => setF(true)} onBlur={() => setF(false)} {...p} />;
+}
+
+function TA({ value, onChange, placeholder, rows = 3, mono = false }) {
+  const [f, setF] = useState(false);
+  return <textarea value={value} onChange={e => onChange(e.target.value)} placeholder={placeholder} rows={rows}
+    style={{ ...S.input, fontFamily: mono ? "'DM Mono', monospace" : "'DM Sans', sans-serif", resize: "vertical", minHeight: 50, ...(f ? S.focused : {}) }}
+    onFocus={() => setF(true)} onBlur={() => setF(false)} />;
+}
+
+function Sel({ value, onChange, options }) {
+  return <select value={value} onChange={e => onChange(e.target.value)}
+    style={{ ...S.input, fontFamily: "'DM Sans', sans-serif", cursor: "pointer" }}>
+    {options.map(o => <option key={o.value} value={o.value}>{o.label}</option>)}
+  </select>;
+}
+
+function CB({ checked, onChange, label }) {
+  return <label style={{ display: "flex", alignItems: "center", gap: 6, cursor: "pointer", fontSize: 12, fontFamily: "'DM Sans', sans-serif", color: "#374151", marginBottom: 5 }}>
+    <input type="checkbox" checked={checked} onChange={e => onChange(e.target.checked)} style={{ accentColor: "#2563eb", width: 15, height: 15 }} />
+    {label}
+  </label>;
+}
+
+function MC({ options, selected, onChange }) {
+  const toggle = v => selected.includes(v) ? onChange(selected.filter(s => s !== v)) : onChange([...selected, v]);
+  return <div style={{ display: "flex", flexWrap: "wrap", gap: 5 }}>
+    {options.map(o => <label key={o.value} style={{
+      display: "flex", alignItems: "center", gap: 4, padding: "4px 9px", borderRadius: 6,
+      border: selected.includes(o.value) ? "1.5px solid #2563eb" : "1.5px solid #e5e7eb",
+      background: selected.includes(o.value) ? "#eff6ff" : "#fafbfc", cursor: "pointer",
+      fontSize: 11, fontFamily: "'DM Sans', sans-serif", transition: "all 0.15s",
+    }}>
+      <input type="checkbox" checked={selected.includes(o.value)} onChange={() => toggle(o.value)}
+        style={{ accentColor: "#2563eb", width: 13, height: 13 }} />
+      {o.label}
+    </label>)}
+  </div>;
+}
+
+// -- Tutorial Sidebar --
+
+function TutorialPanel({ section }) {
+  const t = TUTORIAL[section];
+  if (!t) return null;
+
+  const boxStyle = (bg, border, titleColor) => ({
+    padding: "10px 12px", borderRadius: 8, marginBottom: 10,
+    background: bg, border: `1px solid ${border}`,
+  });
+  const titleStyle = (color) => ({
+    fontSize: 10, fontWeight: 700, textTransform: "uppercase", letterSpacing: "0.08em",
+    color, marginBottom: 5, fontFamily: "'DM Sans', sans-serif",
+  });
+  const bodyStyle = {
+    fontSize: 11.5, lineHeight: 1.55, color: "#e2e8f0", fontFamily: "'DM Sans', sans-serif",
+    whiteSpace: "pre-wrap",
+  };
+
+  return (
+    <div style={{
+      background: "linear-gradient(180deg, #0f172a 0%, #1e293b 100%)",
+      borderRadius: 14, padding: "18px 16px", height: "100%",
+      border: "1px solid rgba(255,255,255,0.06)",
+      overflowY: "auto",
+    }}>
+      <h3 style={{
+        fontSize: 15, fontWeight: 700, color: "#f1f5f9", margin: "0 0 4px",
+        fontFamily: "'Outfit', sans-serif",
+      }}>{t.title}</h3>
+      <p style={{ ...bodyStyle, color: "#94a3b8", marginBottom: 14, fontSize: 11.5 }}>{t.intro}</p>
+
+      {/* MCP Way */}
+      <div style={boxStyle("rgba(239,68,68,0.06)", "rgba(239,68,68,0.15)")}>
+        <div style={titleStyle("#f87171")}>Anthropic MCP (Backend)</div>
+        <div style={bodyStyle}>{t.mcpWay}</div>
+      </div>
+
+      {/* WebMCP Way */}
+      <div style={boxStyle("rgba(34,197,94,0.06)", "rgba(34,197,94,0.15)")}>
+        <div style={titleStyle("#4ade80")}>W3C WebMCP (Browser)</div>
+        <div style={bodyStyle}>{t.webmcpWay}</div>
+      </div>
+
+      {/* Key Difference */}
+      <div style={{
+        padding: "10px 12px", borderRadius: 8, marginBottom: 10,
+        background: "linear-gradient(135deg, rgba(37,99,235,0.1), rgba(124,58,237,0.1))",
+        border: "1px solid rgba(37,99,235,0.2)",
+      }}>
+        <div style={titleStyle("#60a5fa")}>Key Difference</div>
+        <div style={{ ...bodyStyle, fontWeight: 600, color: "#93c5fd" }}>{t.keyDifference}</div>
+      </div>
+
+      {/* Tips */}
+      <div style={{ marginTop: 6 }}>
+        <div style={{ ...titleStyle("#fbbf24"), marginBottom: 6 }}>Tips</div>
+        {t.tips.map((tip, i) => (
+          <div key={i} style={{
+            display: "flex", gap: 6, marginBottom: 5, fontSize: 11, lineHeight: 1.45,
+            color: "#cbd5e1", fontFamily: "'DM Sans', sans-serif",
+          }}>
+            <span style={{ color: "#fbbf24", flexShrink: 0 }}>--</span>
+            <span>{tip}</span>
+          </div>
+        ))}
+      </div>
+    </div>
+  );
+}
+
+// -- Section Forms --
+
+function IdentitySection({ form, sf }) {
+  return <>
+    <Field label="Tool/Page Name" req hint={'What\'s your tool called? Give it a clear, recognizable name. Example: "Flight Search Demo" or "Todo Manager"'}>
+      <TI value={form.toolName} onChange={v => sf("toolName", v)} placeholder="e.g. Flight Search Demo" />
+    </Field>
+    <Field label="Version" req hint={'Use major.minor.patch format. First release? Type 1.0.0. Early prototype? Type 0.1.0. Not sure? Just type 1.0.0'}>
+      <TI value={form.version} onChange={v => sf("version", v)} placeholder="1.0.0" />
+    </Field>
+    <Field label="Description" req hint={'In 1-2 sentences, what does your page let AI agents do? Example: "Travel booking page exposing flight search and hotel filtering tools via WebMCP"'}>
+      <TA value={form.description} onChange={v => sf("description", v)} placeholder="Travel booking page exposing flight search, hotel filtering, and itinerary tools via WebMCP declarative and imperative APIs" />
+    </Field>
+    <Field label="Author" hint={'Your name, your team, or your company. Example: "Jane Smith" or "Acme Dev Team". Leave blank if you prefer.'}>
+      <TI value={form.author} onChange={v => sf("author", v)} placeholder="Jane Smith" />
+    </Field>
+    <Field label="Creation Date" hint="Auto-filled with today. Change it if you built the tool earlier.">
+      <TI value={form.creationDate} onChange={v => sf("creationDate", v)} />
+    </Field>
+    <Field label="License" req hint="MIT is the most common and permissive. Pick Proprietary if closed-source. Not sure? MIT is safe.">
+      <Sel value={form.license} onChange={v => sf("license", v)} options={[
+        { value: "MIT", label: "MIT -- most permissive, most common" },
+        { value: "Apache-2.0", label: "Apache 2.0 -- permissive + patent protection" },
+        { value: "GPL-3.0", label: "GPL 3.0 -- copyleft, derivatives must be open" },
+        { value: "Proprietary", label: "Proprietary -- closed source" },
+        { value: "W3C-CLA", label: "W3C Community CLA -- for W3C group work" },
+      ]} />
+    </Field>
+    <Field label="Page URL" hint={'The web address where your tools live. This is where agents go. Example: "https://travel-demo.bandarra.me/" -- type "tbd" if not deployed yet.'}>
+      <TI value={form.pageUrl} onChange={v => sf("pageUrl", v)} placeholder="https://mysite.com/booking" />
+    </Field>
+    <Field label="Attribution" req hint="Be honest! Human-authored = you wrote it all. AI co-created = you and AI built it together. AI-generated = AI wrote it, you reviewed.">
+      <Sel value={form.attribution} onChange={v => sf("attribution", v)} options={[
+        { value: "human", label: "Human-authored -- a person wrote all the code" },
+        { value: "ai-co-created", label: "AI co-created -- human + AI built it together" },
+        { value: "ai-generated", label: "AI-generated -- AI wrote it, human reviewed" },
+      ]} />
+    </Field>
+    <Field label="Source Repository" hint={'Link to your code on GitHub/GitLab. Example: "https://github.com/user/my-webmcp-app". Leave blank if closed source.'}>
+      <TI value={form.sourceRepo} onChange={v => sf("sourceRepo", v)} placeholder="https://github.com/user/my-webmcp-app" />
+    </Field>
+  </>;
+}
+
+function ApiModeSection({ form, sf }) {
+  return <>
+    <Field label="Primary API Mode" req hint="How do agents talk to your tools? Declarative = you just add attributes to HTML forms (easiest). Imperative = you write JavaScript to register tools (more powerful). Both = you use a mix.">
+      <Sel value={form.apiMode} onChange={v => sf("apiMode", v)} options={[
+        { value: "declarative", label: "Declarative -- just HTML form attributes (easiest)" },
+        { value: "imperative", label: "Imperative -- JavaScript registration (most common)" },
+        { value: "both", label: "Both -- forms for simple, JS for complex" },
+      ]} />
+    </Field>
+    {(form.apiMode === "declarative" || form.apiMode === "both") && <>
+      <Field label="Form toolname" hint={'The exact toolname attribute on your HTML <form> tag. Example: if your form says toolname="searchFlights", type searchFlights here.'}>
+        <TI value={form.declarativeFormName} onChange={v => sf("declarativeFormName", v)} placeholder="searchFlights" />
+      </Field>
+      <Field label="Form tooldescription" hint={'The human-readable description in your form tag. Agents read this to understand what the form does. Example: "Search flights by origin and destination"'}>
+        <TI value={form.declarativeFormDescription} onChange={v => sf("declarativeFormDescription", v)} placeholder="Search flights by origin and destination" />
+      </Field>
+    </>}
+    {(form.apiMode === "imperative" || form.apiMode === "both") &&
+      <Field label="Registration Method" hint="How do you register tools in your JavaScript? The W3C standard is registerTool(). If you use the MCP-B library or the webmcp.js widget, pick those instead. Not sure? Pick registerTool().">
+        <Sel value={form.imperativeRegistration} onChange={v => sf("imperativeRegistration", v)} options={[
+          { value: "registerTool", label: "registerTool() -- W3C standard (recommended)" },
+          { value: "provideContext", label: "provideContext() -- registers multiple tools at once" },
+          { value: "mcp-b-global", label: "MCP-B @mcp-b/global -- community polyfill library" },
+          { value: "webmcp-widget", label: "WebMCP widget -- just a <script> tag (simplest)" },
+        ]} />
+      </Field>
+    }
+  </>;
+}
+
+function ToolsSection({ tools, setTools }) {
+  const [c, setC] = useState({ ...defaultTool });
+  const add = () => { if (!c.name || !c.description) return; setTools([...tools, { ...c }]); setC({ ...defaultTool }); };
+  const rm = i => setTools(tools.filter((_, j) => j !== i));
+  return <>
+    <div style={{ marginBottom: 12, padding: 12, background: "#f0f7ff", borderRadius: 9, border: "1px solid #bfdbfe" }}>
+      <div style={{ fontSize: 11, fontWeight: 600, color: "#1e40af", marginBottom: 2, fontFamily: "'DM Sans', sans-serif" }}>
+        Add a Tool ({tools.length} added)
+      </div>
+      <div style={{ fontSize: 10, color: "#6b7280", marginBottom: 10, fontFamily: "'DM Sans', sans-serif" }}>
+        Fill in one tool at a time, then click "+ Add Tool". Repeat for each tool your page exposes. You can skip this tab if you just want to test the generator.
+      </div>
+      <Field label="Tool Name" req hint={'The exact function name agents will call. Must match your code. Example: "searchFlights", "addToCart", "toggleTheme". Keep it short and descriptive.'}>
+        <TI value={c.name} onChange={v => setC({ ...c, name: v })} placeholder="searchFlights" />
+      </Field>
+      <Field label="Description" req hint={'Tell agents what this tool does in plain language. Example: "Search for available flights between two airports on a given date. Returns flights with prices and times." The better your description, the better agents will use your tool.'}>
+        <TA value={c.description} onChange={v => setC({ ...c, description: v })} placeholder="Search for available flights between two airports on a given date. Returns a list with prices, times, and airlines." />
+      </Field>
+      <Field label="Input Schema (JSON Schema)" req hint={'Describes what data the tool accepts. A default empty schema is pre-filled. If your tool takes parameters, list them inside "properties". Don\'t know JSON Schema? The default is fine for testing.'}>
+        <TA value={c.inputSchema} onChange={v => setC({ ...c, inputSchema: v })} rows={5} mono />
+      </Field>
+      <Field label="Output Format" hint="What kind of data does the tool return? JSON is most common (structured data). Pick Text for simple messages, HTML for rich content, Mixed if it varies.">
+        <Sel value={c.outputFormat} onChange={v => setC({ ...c, outputFormat: v })} options={[
+          { value: "json", label: "JSON -- structured data (most common)" },
+          { value: "text", label: "Text -- plain text response" },
+          { value: "html", label: "HTML -- rich content fragment" },
+          { value: "mixed", label: "Mixed -- varies by call" },
+        ]} />
+      </Field>
+      <Field label="Error States" hint={'What can go wrong? One error per line. Example:\nInvalidInput: origin must be 3-letter airport code\nNetworkError: API timeout after 30s\nLeave blank if you\'re not sure yet.'}>
+        <TA value={c.errorStates} onChange={v => setC({ ...c, errorStates: v })} placeholder={"InvalidInput: origin must be 3-letter IATA code\nNetworkError: upstream API timeout after 30s\nAuthRequired: user must be logged in"} />
+      </Field>
+      <div style={{ fontSize: 10, color: "#6b7280", marginBottom: 6, fontFamily: "'DM Sans', sans-serif" }}>
+        Check the boxes that apply. Not sure? Read-only = only fetches data. Async = almost always yes. The rest are special cases.
+      </div>
+      <div style={{ display: "flex", flexWrap: "wrap", gap: 8, marginBottom: 8 }}>
+        <CB checked={c.readOnlyHint} onChange={v => setC({ ...c, readOnlyHint: v })} label="Read-only (only fetches data, changes nothing)" />
+        <CB checked={c.destructive} onChange={v => setC({ ...c, destructive: v })} label="Destructive (deletes or irreversibly changes data)" />
+        <CB checked={c.async} onChange={v => setC({ ...c, async: v })} label="Async (makes network calls -- almost always yes)" />
+        <CB checked={c.requiresUserInteraction} onChange={v => setC({ ...c, requiresUserInteraction: v })} label="Asks the human mid-execution (WebMCP-only feature!)" />
+        <CB checked={c.multimodalSupport} onChange={v => setC({ ...c, multimodalSupport: v })} label="Handles images/audio/video (not just text)" />
+      </div>
+      <button onClick={add} disabled={!c.name || !c.description} style={{
+        padding: "7px 16px", background: c.name && c.description ? "#2563eb" : "#94a3b8",
+        color: "#fff", border: "none", borderRadius: 7, fontSize: 12, fontWeight: 600,
+        cursor: c.name && c.description ? "pointer" : "not-allowed", fontFamily: "'DM Sans', sans-serif",
+      }}>+ Add Tool</button>
+    </div>
+    {tools.map((t, i) => (
+      <div key={i} style={{ display: "flex", justifyContent: "space-between", alignItems: "center", padding: "6px 10px", marginBottom: 4, background: "#f9fafb", borderRadius: 7, border: "1px solid #e5e7eb" }}>
+        <div><span style={{ fontFamily: "'DM Mono', monospace", fontSize: 12, fontWeight: 600, color: "#1e40af" }}>{t.name}</span>
+          <span style={{ fontSize: 10, color: "#6b7280", marginLeft: 6 }}>{t.description.slice(0, 50)}{t.description.length > 50 ? "..." : ""}</span></div>
+        <button onClick={() => rm(i)} style={{ background: "none", border: "none", color: "#ef4444", cursor: "pointer", fontSize: 14, fontWeight: 700 }}>x</button>
+      </div>
+    ))}
+  </>;
+}
+
+function SessionSection({ form, sf }) {
+  return <>
+    <Field label="Session Type" req hint="Does the user need to be logged in? Authenticated = yes, login required (most real apps). Anonymous = no login needed (public demos, search). Mixed = some tools public, some need login.">
+      <Sel value={form.sessionType} onChange={v => sf("sessionType", v)} options={[
+        { value: "authenticated", label: "Authenticated -- user must be logged in" },
+        { value: "anonymous", label: "Anonymous -- works for anyone, no login" },
+        { value: "mixed", label: "Mixed -- some tools public, some need login" },
+      ]} />
+    </Field>
+    <Field label="Permissions Required" hint={'What access level does the user need? Examples: "Any logged-in user", "Admin role", "Premium subscriber". Leave blank if anonymous.'}>
+      <TI value={form.permissionsRequired} onChange={v => sf("permissionsRequired", v)} placeholder="Any logged-in user" />
+    </Field>
+    <Field label="OAuth / Cookie Dependencies" hint={'What auth mechanisms does the tool rely on? One per line. Examples:\nSession cookie from login flow\nOAuth2 bearer token for API calls\nLeave blank if anonymous or not sure.'}>
+      <TA value={form.oauthDependencies} onChange={v => sf("oauthDependencies", v)} placeholder={"Session cookie from login flow\nOAuth2 bearer token for API calls"} />
+    </Field>
+    <CB checked={form.inheritsSession} onChange={v => sf("inheritsSession", v)} label="Inherits browser session automatically (almost always yes -- this is the big difference from backend MCP!)" />
+  </>;
+}
+
+function BrowserSection({ form, sf }) {
+  return <>
+    <Field label="Minimum Chrome Version" req hint="WebMCP currently only works in Chrome 146 Canary with a flag enabled. Leave the default (146) unless you know otherwise.">
+      <TI value={form.chromeVersion} onChange={v => sf("chromeVersion", v)} placeholder="146" />
+    </Field>
+    <CB checked={form.mcpbPolyfill} onChange={v => sf("mcpbPolyfill", v)} label="Also works with MCP-B Chrome extension (community polyfill for current browsers)" />
+    <Field label="Browser-Specific Notes" hint={'Anything developers should know about browser support. One note per line. Examples:\nChrome DevTools MCP bridge needed for Claude Desktop\nEdge support expected mid-2026\nMobile not yet supported'}>
+      <TA value={form.browserNotes} onChange={v => sf("browserNotes", v)} placeholder={"Chrome DevTools MCP bridge required for Claude Desktop\nEdge support expected mid-2026\nMobile Chrome: not yet supported"} />
+    </Field>
+    <Field label="Graceful Degradation" hint={'What happens for users without WebMCP? Example: "Falls back to standard HTML form submission -- UI works normally for human users." This is important because most visitors won\'t have WebMCP yet.'}>
+      <TA value={form.gracefulDegradation} onChange={v => sf("gracefulDegradation", v)} placeholder="Falls back to standard HTML form submission. UI remains fully functional for human users." />
+    </Field>
+  </>;
+}
+
+function SecuritySection({ form, sf }) {
+  return <>
+    <div style={{ fontSize: 10, color: "#6b7280", marginBottom: 8, fontFamily: "'DM Sans', sans-serif", lineHeight: 1.4 }}>
+      These checkboxes are pre-set to safe defaults. Only uncheck if you know your tool behaves differently.
+    </div>
+    <CB checked={form.sameOrigin} onChange={v => sf("sameOrigin", v)} label="Same-origin only (tool only accesses data from its own domain -- almost always yes)" />
+    <CB checked={form.cspCompatible} onChange={v => sf("cspCompatible", v)} label="CSP compatible (works with Content Security Policy headers -- yes if you use CSP)" />
+    <CB checked={form.humanInTheLoop} onChange={v => sf("humanInTheLoop", v)} label="Human-in-the-loop (a person can see what the agent is doing -- core WebMCP principle)" />
+    <Field label="Data Exposure" hint={'What user data can agents see through your tools? Be specific. Examples: "Search results with flight prices", "User profile name and email", or "No user data exposed -- only public catalog info"'}>
+      <TA value={form.dataExposure} onChange={v => sf("dataExposure", v)} placeholder={"Search results including flight prices and availability\nNo personal user data exposed"} />
+    </Field>
+    <Field label="Exfiltration Risk" req hint={'The "lethal trifecta" test: Does your tool have ALL THREE of (1) access to user data + (2) untrusted content on the page (ads, user posts) + (3) ability to send data externally? If yes = High. If only 1-2 = Medium. If none or read-only = Low. Most tools are Low.'}>
+      <Sel value={form.exfiltrationRisk} onChange={v => sf("exfiltrationRisk", v)} options={[
+        { value: "low", label: "Low -- read-only or no external calls (most tools)" },
+        { value: "medium", label: "Medium -- some data access, but controlled" },
+        { value: "high", label: "High -- all 3 trifecta factors present (rare, be careful)" },
+      ]} />
+    </Field>
+    <CB checked={form.lethalTrifecta} onChange={v => sf("lethalTrifecta", v)} label="LETHAL TRIFECTA PRESENT -- all 3 factors: user data + untrusted page content + external communication (only check if truly all three)" />
+    <Field label="Rate Limiting" hint={'Any limits on how often the tool can be called? Examples: "10 calls/minute per session", "100 calls/hour", "No rate limiting". Leave blank if not sure.'}>
+      <TI value={form.rateLimiting} onChange={v => sf("rateLimiting", v)} placeholder="10 calls/minute per session" />
+    </Field>
+  </>;
+}
+
+function InteractionSection({ form, sf }) {
+  return <>
+    <Field label="Statefulness" req hint="Does each tool call stand alone, or do they build on each other? Stateless = each call is independent (e.g. a search). Stateful = results from one call feed into the next (e.g. search then book). Mixed = some of each.">
+      <Sel value={form.statefulness} onChange={v => sf("statefulness", v)} options={[
+        { value: "stateless", label: "Stateless -- each call is independent (most common)" },
+        { value: "stateful", label: "Stateful -- calls build on each other" },
+        { value: "mixed", label: "Mixed -- some independent, some chained" },
+      ]} />
+    </Field>
+    <Field label="Tool Dependencies" hint={'Does calling one tool require another to have been called first? One per line. Example:\nbookFlight needs searchFlights to have run first\nselectSeat needs bookFlight confirmation\nLeave blank if all tools are independent.'}>
+      <TA value={form.toolDependencies} onChange={v => sf("toolDependencies", v)} placeholder={"bookFlight depends on searchFlights result\nselectSeat depends on bookFlight confirmation"} />
+    </Field>
+    <CB checked={form.pageStateModification} onChange={v => sf("pageStateModification", v)} label="Tool changes what the user sees on screen (e.g. updates search results, toggles UI elements)" />
+    <Field label="Latency Estimate" hint={'How long do tool calls typically take? Examples: "Under 100ms" (fast, local), "200-500ms" (API call), "1-3 seconds" (complex operation). Leave blank if not sure.'}>
+      <TI value={form.latencyEstimate} onChange={v => sf("latencyEstimate", v)} placeholder="200-500ms for searches, 1-3s for bookings" />
+    </Field>
+    <CB checked={form.blocking} onChange={v => sf("blocking", v)} label="Freezes the page while running (ideally no -- tools should run without blocking the user)" />
+  </>;
+}
+
+function ContextSection({ form, sf }) {
+  return <>
+    <Field label="provideContext() Data" hint={'What information does your page explicitly share with agents? This is data you proactively give agents via the provideContext() API. Example: "Current search filters, selected travel dates, number of passengers, user locale". Leave blank if you don\'t use provideContext().'}>
+      <TA value={form.provideContextData} onChange={v => sf("provideContextData", v)} placeholder={"Current search filters, selected dates, passenger count\nUser locale and currency preference"} />
+    </Field>
+    <CB checked={form.domStateAccess} onChange={v => sf("domStateAccess", v)} label="Tool reads the visible page (HTML elements, form values, text on screen)" />
+    <CB checked={form.reactReduxAccess} onChange={v => sf("reactReduxAccess", v)} label="Tool reads framework state (React hooks, Redux store, Vue data) -- means your tool is coupled to a specific framework" />
+    <Field label="Navigation Dependencies" hint={'Does the tool only work on certain pages or routes? Example: "Must be on /search-results page for bookFlight to work". Type "Works on any page" or leave blank if no restriction.'}>
+      <TI value={form.navigationDependencies} onChange={v => sf("navigationDependencies", v)} placeholder="Works on any page" />
+    </Field>
+  </>;
+}
+
+function LimitationsSection({ form, sf }) {
+  return <>
+    <Field label="Cannot Do" req hint={'Be honest about what your tool CAN\'T do. One limitation per line. This builds trust! Examples:\nCannot process payments directly\nMaximum 10 passengers per search\nNo wheelchair-accessible seat filtering yet'}>
+      <TA value={form.cannotDo} onChange={v => sf("cannotDo", v)} rows={3} placeholder={"Cannot process payments directly\nMaximum 10 results per search\nDoes not support multi-city routing"} />
+    </Field>
+    <Field label="Edge Cases" hint={'Things that might surprise users or agents. Weird scenarios, known quirks. Examples:\nDates more than 330 days out return empty results\nSearch during maintenance windows returns stale data\nLeave blank if none known yet.'}>
+      <TA value={form.edgeCases} onChange={v => sf("edgeCases", v)} placeholder={"Dates more than 330 days out return empty results\nAirports with only charter flights may not appear"} />
+    </Field>
+    <Field label="Scale Limits" hint='The default "50 tools per page" is the WebMCP performance recommendation. Adjust if your page has specific limits.'>
+      <TI value={form.scaleLimits} onChange={v => sf("scaleLimits", v)} />
+    </Field>
+    <Field label="Failure Modes" hint={'How does the tool fail? What does the agent see when something goes wrong? Examples:\nReturns {error: "TIMEOUT"} after 30 seconds\nThrows TypeError if page not fully loaded\nReturns empty array (not error) when no matches found'}>
+      <TA value={form.failureModes} onChange={v => sf("failureModes", v)} placeholder={'Returns {error: "TIMEOUT", message: "..."} after 30s\nReturns empty results array when no matches found'} />
+    </Field>
+  </>;
+}
+
+function DiscoverySection({ form, sf }) {
+  return <>
+    <div style={{ fontSize: 10, color: "#6b7280", marginBottom: 8, fontFamily: "'DM Sans', sans-serif", lineHeight: 1.4 }}>
+      Discovery is an unsolved problem in WebMCP -- agents can only find tools after visiting a page. These fields document what discovery mechanisms exist (if any). Most people will leave these unchecked, and that's fine.
+    </div>
+    <CB checked={form.registryListed} onChange={v => sf("registryListed", v)} label="Listed in a tool registry or catalog (check if your tools appear in any searchable directory)" />
+    <CB checked={form.wellKnownWebmcp} onChange={v => sf("wellKnownWebmcp", v)} label="Site serves .well-known/webmcp file (proposed standard -- check if you've implemented this, most haven't)" />
+    <Field label="Pre-Visit Discoverability" hint={'Can agents know your tools exist BEFORE visiting your page? Be honest -- for most WebMCP tools the answer is "no" and that\'s okay. This model card itself helps with discovery! Examples:\n"Documented in this model card"\n"Listed in site sitemap"\n"No pre-visit discovery -- tools available after page load"'}>
+      <TA value={form.preVisitDiscoverability} onChange={v => sf("preVisitDiscoverability", v)} placeholder={"Documented in this model card\nNo pre-visit discovery -- tools only available after page load"} />
+    </Field>
+  </>;
+}
+
+function TestingSection({ form, sf }) {
+  return <>
+    <Field label="Test Methodology" hint={'How did you test your tools with AI agents? Examples:\nManual testing via Chrome DevTools MCP bridge\nAutomated benchmark comparing token usage\nUser testing with 3 people using Claude Desktop\nOr just: "Not yet tested" -- honesty is fine here.'}>
+      <TA value={form.testMethodology} onChange={v => sf("testMethodology", v)} placeholder={"Manual testing via Chrome DevTools MCP bridge\nBenchmark comparing structured calls vs screenshot method"} />
+    </Field>
+    <Field label="Agents Tested" hint="Check every AI agent you've tested your tools with. This builds trust -- agents that know they've been tested get used more confidently. None tested yet? Leave all unchecked.">
+      <MC options={[
+        { value: "claude", label: "Claude" }, { value: "gpt", label: "GPT / ChatGPT" },
+        { value: "gemini", label: "Gemini" }, { value: "copilot", label: "Copilot" },
+        { value: "other", label: "Other" },
+      ]} selected={form.agentsTested} onChange={v => sf("agentsTested", v)} />
+    </Field>
+    <Field label="Pass/Fail Criteria" hint={'What counts as "it works"? Examples:\nReturns valid JSON with results\nNo console errors during execution\nCompletes within 5 seconds\nHuman can see and verify changes'}>
+      <TA value={form.passFailCriteria} onChange={v => sf("passFailCriteria", v)} placeholder={"Returns valid JSON with results array\nNo console errors during execution\nCompletes within 5 seconds"} />
+    </Field>
+    <Field label="Test Suite Link" hint="URL to your test scripts or CI pipeline. Leave blank if no automated tests yet -- you can add this later.">
+      <TI value={form.testSuiteLink} onChange={v => sf("testSuiteLink", v)} placeholder="https://github.com/user/repo/tree/main/tests" />
+    </Field>
+  </>;
+}
+
+function BackendSection({ form, sf }) {
+  return <>
+    <div style={{ fontSize: 10, color: "#6b7280", marginBottom: 8, fontFamily: "'DM Sans', sans-serif", lineHeight: 1.4 }}>
+      Many real apps have BOTH: a backend MCP server (Anthropic-style, runs on Node.js/Python) AND browser-side WebMCP tools. This section documents the relationship. If your tool is browser-only, just leave unchecked.
+    </div>
+    <CB checked={form.hasBackendMcp} onChange={v => sf("hasBackendMcp", v)} label="This service also has a backend MCP server (check if there's a separate server-side MCP alongside the browser tools)" />
+    {form.hasBackendMcp && <>
+      <Field label="Backend Server Name" hint={'The name of the backend MCP server. Example: "flights-mcp-server" or "@company/booking-mcp". This is the npm package or server name, not the WebMCP tool name.'}>
+        <TI value={form.backendServerName} onChange={v => sf("backendServerName", v)} placeholder="flights-mcp-server" />
+      </Field>
+      <Field label="Capability Differences" hint={'What does the browser tool do that the backend doesn\'t, and vice versa? Example:\nBrowser: live UI updates, session-aware search, human confirmation\nBackend: payment processing, database writes, heavy computation\nThis helps agents choose which to use.'}>
+        <TA value={form.capabilityDifferences} onChange={v => sf("capabilityDifferences", v)} placeholder={"Browser: live UI updates, session-aware search, human confirmations\nBackend: payment processing, database writes, batch operations\nBrowser inherits user session; backend needs separate API key"} />
+      </Field>
+      <CB checked={form.authSharing} onChange={v => sf("authSharing", v)} label="Same authentication works for both browser and backend (e.g. same OAuth token)" />
+    </>}
+  </>;
+}
+
+// -- Generator --
+
+function generateJSON(form, tools) {
+  const card = {
+    webmcp_model_card_version: "1.0.0",
+    specification: "WebMCP Model Card Specification v1.0",
+    specification_basis: "MCP Model Card Specification v1.0 (Extended for WebMCP)",
+    w3c_groups: ["W3C AI Knowledge Representation CG", "W3C Web Machine Learning CG"],
+    generated_at: new Date().toISOString(),
+    identity: {
+      name: form.toolName, version: form.version, description: form.description,
+      author: form.author, creation_date: form.creationDate, license: form.license,
+      page_url: form.pageUrl, attribution: form.attribution, source_repository: form.sourceRepo,
+    },
+    api_mode: {
+      primary: form.apiMode,
+      ...(form.apiMode !== "imperative" ? { declarative: { form_toolname: form.declarativeFormName, form_tooldescription: form.declarativeFormDescription } } : {}),
+      ...(form.apiMode !== "declarative" ? { imperative: { registration_method: form.imperativeRegistration } } : {}),
+    },
+    tools: tools.map(t => {
+      let ps; try { ps = JSON.parse(t.inputSchema); } catch { ps = { error: "Invalid JSON" }; }
+      return { name: t.name, description: t.description, input_schema: ps, output_format: t.outputFormat,
+        error_states: t.errorStates ? t.errorStates.split("\n").filter(Boolean) : [],
+        annotations: { read_only_hint: t.readOnlyHint, destructive: t.destructive, async: t.async,
+          requires_user_interaction: t.requiresUserInteraction, multimodal_support: t.multimodalSupport } };
+    }),
+    session: { type: form.sessionType, permissions_required: form.permissionsRequired,
+      oauth_dependencies: form.oauthDependencies ? form.oauthDependencies.split("\n").filter(Boolean) : [],
+      inherits_browser_session: form.inheritsSession },
+    browser_compatibility: { minimum_chrome_version: form.chromeVersion, mcpb_polyfill_support: form.mcpbPolyfill,
+      browser_notes: form.browserNotes ? form.browserNotes.split("\n").filter(Boolean) : [],
+      graceful_degradation: form.gracefulDegradation },
+    security: { same_origin_scope: form.sameOrigin, csp_compatible: form.cspCompatible,
+      human_in_the_loop: form.humanInTheLoop, data_exposure: form.dataExposure,
+      exfiltration_risk: form.exfiltrationRisk, lethal_trifecta_present: form.lethalTrifecta,
+      rate_limiting: form.rateLimiting },
+    interaction_patterns: { statefulness: form.statefulness,
+      tool_dependencies: form.toolDependencies ? form.toolDependencies.split("\n").filter(Boolean) : [],
+      page_state_modification: form.pageStateModification, latency_estimate: form.latencyEstimate, blocking: form.blocking },
+    context_requirements: { provide_context_data: form.provideContextData, dom_state_access: form.domStateAccess,
+      framework_state_access: form.reactReduxAccess, navigation_dependencies: form.navigationDependencies },
+    limitations: { cannot_do: form.cannotDo ? form.cannotDo.split("\n").filter(Boolean) : [],
+      edge_cases: form.edgeCases ? form.edgeCases.split("\n").filter(Boolean) : [],
+      scale_limits: form.scaleLimits, failure_modes: form.failureModes ? form.failureModes.split("\n").filter(Boolean) : [] },
+    discovery: { registry_listed: form.registryListed, well_known_webmcp: form.wellKnownWebmcp,
+      pre_visit_discoverability: form.preVisitDiscoverability },
+    testing: { methodology: form.testMethodology, agents_tested: form.agentsTested,
+      pass_fail_criteria: form.passFailCriteria, test_suite_link: form.testSuiteLink },
+    backend_relationship: { has_backend_mcp: form.hasBackendMcp, backend_server_name: form.backendServerName,
+      capability_differences: form.capabilityDifferences, auth_sharing: form.authSharing },
+  };
+  return JSON.stringify(card, null, 2);
+}
+
+function generateMarkdown(form, tools) {
+  const L = [];
+  L.push(`# WebMCP Model Card: ${form.toolName || "Untitled"}\n`);
+  L.push(`> Generated by WebMCP Model Card Generator v1.0`);
+  L.push(`> Based on MCP Model Card Specification v1.0 (Extended for WebMCP)`);
+  L.push(`> W3C AI-KR CG + W3C Web Machine Learning CG`);
+  L.push(`> ${new Date().toISOString()}\n---\n`);
+
+  L.push(`## 1. Identity & Provenance\n`);
+  L.push(`| Field | Value |\n|-------|-------|\n| **Name** | ${form.toolName} |\n| **Version** | ${form.version} |\n| **Description** | ${form.description} |`);
+  if (form.author) L.push(`| **Author** | ${form.author} |`);
+  L.push(`| **Created** | ${form.creationDate} |\n| **License** | ${form.license} |\n| **Attribution** | ${form.attribution} |`);
+  if (form.pageUrl) L.push(`| **Page URL** | ${form.pageUrl} |`);
+  if (form.sourceRepo) L.push(`| **Repository** | ${form.sourceRepo} |`);
+  L.push("");
+
+  L.push(`## 2. API Mode\n\n**Primary**: ${form.apiMode}\n`);
+  if (form.apiMode !== "imperative") L.push(`- Declarative form: \`${form.declarativeFormName}\` -- "${form.declarativeFormDescription}"`);
+  if (form.apiMode !== "declarative") L.push(`- Imperative: \`${form.imperativeRegistration}\``);
+  L.push("");
+
+  L.push(`## 3. Tool Catalog\n`);
+  if (tools.length === 0) L.push("*No tools documented.*\n");
+  else tools.forEach((t, i) => {
+    L.push(`### 3.${i+1} \`${t.name}\`\n\n${t.description}\n`);
+    L.push(`| Property | Value |\n|----------|-------|\n| Read-only | ${t.readOnlyHint?"Yes":"No"} |\n| Destructive | ${t.destructive?"Yes":"No"} |\n| Async | ${t.async?"Yes":"No"} |\n| User interaction | ${t.requiresUserInteraction?"Yes":"No"} |\n| Output | ${t.outputFormat} |\n`);
+    L.push("```json\n" + t.inputSchema + "\n```\n");
+    if (t.errorStates) { L.push("**Errors**:"); t.errorStates.split("\n").filter(Boolean).forEach(e => L.push(`- ${e}`)); L.push(""); }
+  });
+
+  L.push(`## 4. Session & Auth\n\n- Type: ${form.sessionType}\n- Inherits session: ${form.inheritsSession?"Yes":"No"}`);
+  if (form.permissionsRequired) L.push(`- Permissions: ${form.permissionsRequired}`);
+  L.push("");
+
+  L.push(`## 5. Browser Compatibility\n\n- Chrome ${form.chromeVersion}+\n- MCP-B polyfill: ${form.mcpbPolyfill?"Yes":"No"}`);
+  if (form.gracefulDegradation) L.push(`- Degradation: ${form.gracefulDegradation}`);
+  L.push("");
+
+  L.push(`## 6. Security\n\n| Property | Value |\n|----------|-------|\n| Same-origin | ${form.sameOrigin?"Yes":"No"} |\n| CSP | ${form.cspCompatible?"Yes":"No"} |\n| Human-in-loop | ${form.humanInTheLoop?"Yes":"No"} |\n| Exfiltration risk | ${form.exfiltrationRisk} |\n| Lethal trifecta | ${form.lethalTrifecta?"PRESENT":"No"} |\n`);
+
+  L.push(`## 7. Interaction\n\n- Statefulness: ${form.statefulness}\n- Modifies page: ${form.pageStateModification?"Yes":"No"}\n- Blocking: ${form.blocking?"Yes":"No"}`);
+  if (form.latencyEstimate) L.push(`- Latency: ${form.latencyEstimate}`);
+  L.push("");
+
+  L.push(`## 8. Context Requirements\n\n- DOM access: ${form.domStateAccess?"Yes":"No"}\n- Framework state: ${form.reactReduxAccess?"Yes":"No"}`);
+  if (form.provideContextData) L.push(`- provideContext(): ${form.provideContextData}`);
+  L.push("");
+
+  L.push(`## 9. Limitations\n`);
+  if (form.cannotDo) form.cannotDo.split("\n").filter(Boolean).forEach(l => L.push(`- ${l}`));
+  if (form.scaleLimits) L.push(`\nScale: ${form.scaleLimits}`);
+  L.push("");
+
+  L.push(`## 10. Discovery\n\n- Registry: ${form.registryListed?"Yes":"No"}\n- .well-known/webmcp: ${form.wellKnownWebmcp?"Yes":"No"}\n`);
+
+  L.push(`## 11. Testing\n`);
+  if (form.agentsTested.length) L.push(`Agents: ${form.agentsTested.join(", ")}`);
+  if (form.testMethodology) L.push(`Method: ${form.testMethodology}`);
+  L.push("");
+
+  L.push(`## 12. Backend MCP\n\n- Has backend: ${form.hasBackendMcp?"Yes":"No"}`);
+  if (form.hasBackendMcp && form.backendServerName) L.push(`- Server: ${form.backendServerName}`);
+  L.push("");
+
+  L.push(`---\n\n*Co-created by Paola Di Maio, PhD (W3C AI-KR CG Chair) & Claude (Anthropic)*\n*Extends MCP Model Card Specification v1.0 for the WebMCP browser ecosystem*`);
+  return L.join("\n");
+}
+
+// -- MAIN APP --
+
+function App() {
+  const [form, setForm] = useState({ ...defaultForm });
+  const [tools, setTools] = useState([]);
+  const [sec, setSec] = useState("identity");
+  const [output, setOutput] = useState(null);
+  const [fmt, setFmt] = useState("json");
+  const [showTutorial, setShowTutorial] = useState(true);
+  const outRef = useRef(null);
+
+  const sf = useCallback((k, v) => setForm(p => ({ ...p, [k]: v })), []);
+  const si = SECTIONS.indexOf(sec);
+
+  const gen = () => {
+    setOutput({ json: generateJSON(form, tools), md: generateMarkdown(form, tools) });
+    setFmt("json");
+    setTimeout(() => outRef.current?.scrollIntoView({ behavior: "smooth" }), 100);
+  };
+
+  const copy = () => navigator.clipboard.writeText(fmt === "json" ? output.json : output.md);
+
+  const renderSec = () => {
+    const p = { form, sf };
+    switch (sec) {
+      case "identity": return <IdentitySection {...p} />;
+      case "apiMode": return <ApiModeSection {...p} />;
+      case "tools": return <ToolsSection tools={tools} setTools={setTools} />;
+      case "session": return <SessionSection {...p} />;
+      case "browser": return <BrowserSection {...p} />;
+      case "security": return <SecuritySection {...p} />;
+      case "interaction": return <InteractionSection {...p} />;
+      case "context": return <ContextSection {...p} />;
+      case "limitations": return <LimitationsSection {...p} />;
+      case "discovery": return <DiscoverySection {...p} />;
+      case "testing": return <TestingSection {...p} />;
+      case "backendRelationship": return <BackendSection {...p} />;
+      default: return null;
+    }
+  };
+
+  const navBtn = (label, onClick, primary = false, disabled = false) => (
+    <button onClick={onClick} disabled={disabled} style={{
+      padding: "7px 16px", fontSize: 12, fontWeight: 600, fontFamily: "'DM Sans', sans-serif",
+      background: disabled ? "#94a3b8" : primary ? "linear-gradient(135deg, #2563eb, #3b82f6)" : "#f1f5f9",
+      color: disabled ? "#cbd5e1" : primary ? "#fff" : "#374151",
+      border: primary ? "none" : "1px solid #e5e7eb", borderRadius: 7,
+      cursor: disabled ? "not-allowed" : "pointer", transition: "all 0.2s",
+    }}>{label}</button>
+  );
+
+  return (
+    <div style={{ minHeight: "100vh", background: "linear-gradient(165deg, #0f172a 0%, #1e293b 40%, #0f172a 100%)", fontFamily: "'DM Sans', sans-serif" }}>
+      <link href="https://fonts.googleapis.com/css2?family=DM+Sans:wght@400;500;600;700&family=DM+Mono:wght@400;500&family=Outfit:wght@300;400;600;700;800&display=swap" rel="stylesheet" />
+
+      {/* Header */}
+      <div style={{ background: "linear-gradient(135deg, rgba(37,99,235,0.12), rgba(124,58,237,0.08))", borderBottom: "1px solid rgba(255,255,255,0.06)", padding: "20px 20px 16px" }}>
+        <div style={{ maxWidth: 1200, margin: "0 auto", display: "flex", justifyContent: "space-between", alignItems: "center" }}>
+          <div style={{ display: "flex", alignItems: "center", gap: 10 }}>
+            <div style={{ width: 38, height: 38, borderRadius: 10, background: "linear-gradient(135deg, #2563eb, #7c3aed)", display: "flex", alignItems: "center", justifyContent: "center", fontSize: 18, color: "#fff", fontWeight: 700, boxShadow: "0 4px 16px rgba(37,99,235,0.3)" }}>W</div>
+            <div>
+              <h1 style={{ fontSize: 19, fontWeight: 800, color: "#f1f5f9", margin: 0, fontFamily: "'Outfit', sans-serif", letterSpacing: "-0.02em" }}>WebMCP Model Card Generator</h1>
+              <div style={{ fontSize: 11, color: "#94a3b8", marginTop: 1 }}>MCP Model Card Spec v1.0 -- Extended for browser-side tools</div>
+            </div>
+          </div>
+          <button onClick={() => setShowTutorial(!showTutorial)} style={{
+            padding: "6px 14px", fontSize: 11, fontWeight: 600,
+            background: showTutorial ? "rgba(34,197,94,0.15)" : "rgba(255,255,255,0.05)",
+            color: showTutorial ? "#4ade80" : "#94a3b8",
+            border: showTutorial ? "1px solid rgba(34,197,94,0.3)" : "1px solid rgba(255,255,255,0.08)",
+            borderRadius: 7, cursor: "pointer", fontFamily: "'DM Sans', sans-serif",
+          }}>
+            {showTutorial ? "Tutorial ON" : "Tutorial OFF"}
+          </button>
+        </div>
+      </div>
+
+      {/* Section Tabs */}
+      <div style={{ maxWidth: 1200, margin: "0 auto", padding: "12px 20px 0", display: "flex", flexWrap: "wrap", gap: 3 }}>
+        {SECTIONS.map((s, i) => (
+          <button key={s} onClick={() => setSec(s)} style={{
+            padding: "5px 10px", fontSize: 10.5, fontWeight: sec === s ? 700 : 500,
+            fontFamily: "'DM Sans', sans-serif",
+            background: sec === s ? "linear-gradient(135deg, #2563eb, #3b82f6)" : "rgba(255,255,255,0.04)",
+            color: sec === s ? "#fff" : "#94a3b8",
+            border: sec === s ? "none" : "1px solid rgba(255,255,255,0.06)",
+            borderRadius: 7, cursor: "pointer", transition: "all 0.15s", whiteSpace: "nowrap",
+          }}>
+            <span style={{ marginRight: 3 }}>{SECTION_ICONS[s]}</span>
+            {i + 1}. {SECTION_LABELS[s]}
+          </button>
+        ))}
+      </div>
+
+      {/* Main: Form + Tutorial Side-by-Side */}
+      <div style={{
+        maxWidth: 1200, margin: "14px auto 0", padding: "0 20px",
+        display: "grid",
+        gridTemplateColumns: showTutorial ? "1fr 340px" : "1fr",
+        gap: 16, alignItems: "start",
+      }}>
+        {/* Form Panel */}
+        <div style={{
+          background: "#fff", borderRadius: 14, padding: "20px 22px",
+          boxShadow: "0 6px 30px rgba(0,0,0,0.2)", border: "1px solid rgba(255,255,255,0.08)",
+        }}>
+          <div style={{ display: "flex", alignItems: "center", gap: 8, marginBottom: 16, paddingBottom: 12, borderBottom: "1px solid #e5e7eb" }}>
+            <span style={{ fontSize: 22 }}>{SECTION_ICONS[sec]}</span>
+            <div>
+              <h2 style={{ fontSize: 15, fontWeight: 700, color: "#1a1a2e", margin: 0, fontFamily: "'Outfit', sans-serif" }}>
+                {si + 1}. {SECTION_LABELS[sec]}
+              </h2>
+              <div style={{ fontSize: 10, color: "#6b7280", marginTop: 1 }}>{si + 1} of {SECTIONS.length}</div>
+            </div>
+          </div>
+
+          {renderSec()}
+
+          <div style={{ display: "flex", justifyContent: "space-between", alignItems: "center", marginTop: 18, paddingTop: 14, borderTop: "1px solid #e5e7eb" }}>
+            {navBtn("Previous", () => si > 0 && setSec(SECTIONS[si - 1]), false, si === 0)}
+            <div style={{ display: "flex", gap: 6 }}>
+              <button onClick={gen} style={{
+                padding: "7px 18px", fontSize: 12, fontWeight: 700,
+                background: "linear-gradient(135deg, #059669, #10b981)", color: "#fff",
+                border: "none", borderRadius: 7, cursor: "pointer", fontFamily: "'DM Sans', sans-serif",
+                boxShadow: "0 2px 8px rgba(5,150,105,0.3)",
+              }}>Generate</button>
+              {si < SECTIONS.length - 1 && navBtn("Next", () => setSec(SECTIONS[si + 1]), true)}
+            </div>
+          </div>
+        </div>
+
+        {/* Tutorial Panel */}
+        {showTutorial && <TutorialPanel section={sec} />}
+      </div>
+
+      {/* Output */}
+      {output && (
+        <div ref={outRef} style={{ maxWidth: 1200, margin: "16px auto", padding: "0 20px 36px" }}>
+          <div style={{ background: "#fff", borderRadius: 14, padding: "20px 22px", boxShadow: "0 6px 30px rgba(0,0,0,0.2)" }}>
+            <div style={{ display: "flex", justifyContent: "space-between", alignItems: "center", marginBottom: 14 }}>
+              <h2 style={{ fontSize: 15, fontWeight: 700, color: "#1a1a2e", margin: 0, fontFamily: "'Outfit', sans-serif" }}>Generated Model Card</h2>
+              <div style={{ display: "flex", gap: 5 }}>
+                {["json", "md"].map(f => (
+                  <button key={f} onClick={() => setFmt(f)} style={{
+                    padding: "4px 12px", fontSize: 11, fontWeight: 600,
+                    background: fmt === f ? "#2563eb" : "#f1f5f9",
+                    color: fmt === f ? "#fff" : "#374151",
+                    border: "none", borderRadius: 5, cursor: "pointer", fontFamily: "'DM Sans', sans-serif",
+                  }}>{f === "json" ? "JSON" : "Markdown"}</button>
+                ))}
+                <button onClick={copy} style={{
+                  padding: "4px 12px", fontSize: 11, fontWeight: 600, background: "#059669",
+                  color: "#fff", border: "none", borderRadius: 5, cursor: "pointer", fontFamily: "'DM Sans', sans-serif",
+                }}>Copy</button>
+              </div>
+            </div>
+            <pre style={{
+              background: "#0f172a", color: "#e2e8f0", padding: 16, borderRadius: 9,
+              fontSize: 11, lineHeight: 1.55, fontFamily: "'DM Mono', monospace",
+              overflow: "auto", maxHeight: 440, border: "1px solid rgba(255,255,255,0.06)",
+            }}>
+              {fmt === "json" ? output.json : output.md}
+            </pre>
+          </div>
+        </div>
+      )}
+    </div>
+  );
+}
+
+    ReactDOM.createRoot(document.getElementById('root')).render(React.createElement(App));
+  </script>
+</body>
+</html>

From dc0cb4b3d6089dbcd1efbab5e5d79bdc99e5efb8 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Sun, 15 Feb 2026 23:34:22 +0800
Subject: [PATCH 08/46] add User Guide

Learn
---
 WebMCP_Model_Card_Generator_USER_GUIDE.md | 588 ++++++++++++++++++++++
 1 file changed, 588 insertions(+)
 create mode 100644 WebMCP_Model_Card_Generator_USER_GUIDE.md

diff --git a/WebMCP_Model_Card_Generator_USER_GUIDE.md b/WebMCP_Model_Card_Generator_USER_GUIDE.md
new file mode 100644
index 0000000..3c7d98b
--- /dev/null
+++ b/WebMCP_Model_Card_Generator_USER_GUIDE.md
@@ -0,0 +1,588 @@
+# WebMCP Model Card Generator -- Guide for the Clueless
+
+**A field-by-field walkthrough so you can fill out every tab without knowing anything about WebMCP beforehand.**
+
+Co-created by Paola Di Maio, PhD (W3C AI-KR CG Chair) & Claude (Anthropic)
+February 2026
+
+---
+
+## What You're Making
+
+A **model card** for a browser-side tool. Think of it as a label for a product: it tells AI agents (and humans) what your tool does, what it needs, what can go wrong, and how to use it safely.
+
+You fill in a form. The generator produces two files:
+- **JSON** -- for machines to read (registries, agents, validators)
+- **Markdown** -- for humans to read (documentation, GitHub, specifications)
+
+**Time needed**: 15-30 minutes if you know your tool. 5 minutes if you just want to test the generator.
+
+---
+
+## Tab 1: Identity & Provenance
+
+*Who made this, what is it, where does it live?*
+
+### Tool/Page Name (required)
+
+The name of your WebMCP-enabled tool or web page. This is what agents will see when they discover your tools.
+
+- Good: "Easely Design Editor", "Flight Search Demo", "Todo Manager"
+- Bad: "my-tool", "test", "page1"
+
+### Version (required)
+
+Use semantic versioning: **major.minor.patch**
+
+- `1.0.0` = first stable release
+- `0.1.0` = early prototype
+- `2.3.1` = mature, updated
+
+If you don't know, use `0.1.0` for prototypes or `1.0.0` for something you'd show people.
+
+### Description (required)
+
+One or two sentences explaining what tools this page exposes to AI agents.
+
+- Good: "Travel booking page exposing flight search, hotel filtering, and itinerary building tools via WebMCP declarative and imperative APIs"
+- Bad: "A tool" or "This is my page"
+
+### Author
+
+Your name, team name, or organization. Can be left blank.
+
+### Creation Date
+
+Auto-filled with today's date. Change it if the tool was created earlier.
+
+### License (required)
+
+Pick one:
+
+| License | When to use |
+|---------|-------------|
+| **MIT** | Most permissive, most common. "Do whatever you want, just include the license." |
+| **Apache 2.0** | Permissive + patent protection. Good for company projects. |
+| **GPL 3.0** | Copyleft. Anyone who uses your code must also open-source theirs. |
+| **Proprietary** | Closed source, commercial. |
+| **W3C Community CLA** | If your tool is part of a W3C community group deliverable. |
+
+If unsure, pick MIT.
+
+### Page URL
+
+The web address where your WebMCP tools are registered. This is where agents go to find and call your tools.
+
+- Example: `https://travel-demo.bandarra.me/`
+- Example: `https://mysite.com/booking`
+- Put "tbd" if you haven't deployed yet.
+
+### Attribution (required)
+
+How was this tool created? Be honest -- this is a transparency field.
+
+| Choice | Meaning |
+|--------|---------|
+| **Human-authored** | A person wrote all the code |
+| **AI co-created** | Human and AI worked together (like us right now!) |
+| **AI-generated** | AI generated the code, human reviewed/edited |
+
+### Source Repository
+
+Link to your GitHub/GitLab repo. Leave blank if closed source.
+
+---
+
+## Tab 2: API Mode
+
+*How do agents talk to your tools?*
+
+This is where WebMCP diverges most from backend MCP. You have TWO choices (or both).
+
+### Primary API Mode (required)
+
+| Mode | What it means | When to use |
+|------|---------------|-------------|
+| **Declarative (HTML forms)** | You add attributes to existing HTML `<form>` elements. No JavaScript needed. | You already have working HTML forms and want the fastest path to agent-readiness. |
+| **Imperative (JavaScript)** | You call `navigator.modelContext.registerTool()` in JavaScript. | Complex logic, dynamic tools, multi-step workflows. |
+| **Both** | You use forms for simple actions and JS for complex ones. | Large applications with a mix of simple and complex tools. |
+
+### If Declarative: Form toolname
+
+The exact `toolname` attribute you put on your HTML form:
+```html
+<form toolname="searchFlights" tooldescription="Search flights">
+```
+Enter: `searchFlights`
+
+### If Declarative: Form tooldescription
+
+The natural language description in the form attribute. This is what agents read to decide whether to use your tool.
+
+Enter: `Search for available flights by origin, destination, and date`
+
+### If Imperative: Registration Method
+
+How you register tools in JavaScript:
+
+| Method | When to use |
+|--------|-------------|
+| **navigator.modelContext.registerTool()** | W3C standard API. Use for single tool registration. |
+| **navigator.modelContext.provideContext()** | W3C standard. Registers multiple tools at once (replaces any existing). |
+| **MCP-B @mcp-b/global import** | Community polyfill. Use if you need cross-browser support before native implementation. |
+| **WebMCP widget script tag** | Simplest option -- add a `<script>` tag. Good for quick prototyping. |
+
+If unsure, pick `registerTool()` -- it's the W3C standard.
+
+---
+
+## Tab 3: Tool Documentation
+
+*What can agents actually call?*
+
+You'll add one entry for each tool your page exposes. Click **+ Add Tool** after filling in each one.
+
+### Tool Name (required)
+
+The exact name agents use to call this tool. Must match your code exactly.
+
+- Good: `searchFlights`, `addToCart`, `toggleTheme`
+- Bad: `tool1`, `myFunction`, `doStuff`
+
+### Description (required)
+
+What this tool does, in plain language. Agents read this to decide when and how to use it.
+
+- Good: "Search for available flights between two airports on a given date. Returns a list of flights with prices, times, and airline information."
+- Bad: "Searches stuff"
+
+### Input Schema (required)
+
+A JSON Schema object describing what parameters the tool accepts. If you don't know JSON Schema, here's the pattern:
+
+**Simplest possible** (tool takes no input):
+```json
+{
+  "type": "object",
+  "properties": {},
+  "required": []
+}
+```
+
+**Tool with parameters**:
+```json
+{
+  "type": "object",
+  "properties": {
+    "origin": {
+      "type": "string",
+      "description": "3-letter IATA airport code"
+    },
+    "destination": {
+      "type": "string",
+      "description": "3-letter IATA airport code"
+    },
+    "date": {
+      "type": "string",
+      "description": "Travel date in YYYY-MM-DD format"
+    }
+  },
+  "required": ["origin", "destination", "date"]
+}
+```
+
+**Common types**: `"string"`, `"number"`, `"boolean"`, `"array"`, `"object"`
+
+### Output Format
+
+What does the tool return?
+
+| Format | When |
+|--------|------|
+| **JSON** | Structured data (most common). Search results, API responses. |
+| **Text** | Plain text responses. Summaries, status messages. |
+| **HTML** | HTML fragments. Rich content the agent might display. |
+| **Mixed** | Multiple types depending on the call. |
+
+### Error States
+
+What can go wrong? One error per line.
+
+Example:
+```
+InvalidInput: origin must be 3-letter IATA code
+NetworkError: upstream API timeout after 30s
+AuthRequired: user must be logged in for booking
+RateLimited: maximum 10 searches per minute exceeded
+```
+
+### Checkboxes
+
+| Checkbox | Check it if... |
+|----------|----------------|
+| **Read-only** | The tool only READS data, never changes anything. Search, query, list operations. |
+| **Destructive** | The tool DELETES or IRREVERSIBLY CHANGES something. Delete account, cancel booking. |
+| **Async** | The tool makes network requests or takes time. Almost always yes. |
+| **requestUserInteraction()** | The tool pauses mid-execution to ask the human a question (e.g. "Confirm this purchase?"). This is unique to WebMCP -- backend MCP can't do this. |
+| **Multimodal** | The tool handles images, audio, or video, not just text/JSON. |
+
+---
+
+## Tab 4: Session & Authentication
+
+*Does the user need to be logged in?*
+
+### Session Type (required)
+
+| Type | Meaning |
+|------|---------|
+| **Authenticated** | Tools need a logged-in user. Most common for real applications. |
+| **Anonymous** | Tools work for anyone, no login needed. Public search, demos. |
+| **Mixed** | Some tools are public (search), some need login (booking). |
+
+### Permissions Required
+
+What level of access does the user need?
+
+- "Logged-in user" (basic)
+- "Admin role" (elevated)
+- "Premium subscriber" (paid tier)
+- Leave blank if anonymous.
+
+### OAuth / Cookie Dependencies
+
+What specific auth mechanisms do your tools rely on? One per line.
+
+Example:
+```
+Session cookie from login flow
+OAuth2 bearer token for API calls
+CSRF token in X-CSRF-Token header
+```
+
+### Inherits Browser Session
+
+**Almost always yes.** This is the key difference from backend MCP: your tools automatically get the same cookies, tokens, and session data as the logged-in user. You don't configure credentials separately.
+
+---
+
+## Tab 5: Browser Compatibility
+
+*What browser does this need?*
+
+### Minimum Chrome Version (required)
+
+Currently WebMCP only works in **Chrome 146 Canary** with the "WebMCP for testing" flag enabled at `chrome://flags`.
+
+Enter: `146` (the default)
+
+### MCP-B Polyfill Support
+
+Check this if your tools also work through the MCP-B Chrome extension, which provides WebMCP-like functionality in current stable Chrome.
+
+### Browser-Specific Notes
+
+Anything agents or developers need to know about browser support. One note per line.
+
+Example:
+```
+Chrome DevTools MCP bridge required for Claude Desktop integration
+Edge support expected mid-2026
+Firefox: no timeline announced
+Mobile Chrome: not yet supported
+```
+
+### Graceful Degradation
+
+What happens for users whose browser doesn't support WebMCP?
+
+- Good: "Falls back to standard HTML form submission. UI remains fully functional for human users."
+- Bad: "Doesn't work."
+
+---
+
+## Tab 6: Security Properties
+
+*What could go wrong? How bad could it get?*
+
+### Checkboxes
+
+| Checkbox | What it means |
+|----------|---------------|
+| **Same-origin scope** | Tools can only access data from their own domain. Almost always yes. |
+| **CSP compatible** | Tools work with Content Security Policy headers. Check if you use CSP. |
+| **Human-in-the-loop** | A human can see what the agent is doing. Core WebMCP design principle. |
+
+### Data Exposure
+
+What data do your tools expose to AI agents? Be specific.
+
+- "Search results including flight prices and availability"
+- "User profile name and email (for personalization)"
+- "No user data exposed -- only public catalog information"
+
+### Exfiltration Risk (required)
+
+The **lethal trifecta** assessment. Three factors combine to create data theft risk:
+
+1. **Data access** -- tool reads user data
+2. **Untrusted content** -- page shows third-party content (ads, user-generated content, embeds)
+3. **External communication** -- tool can send data to outside servers
+
+| Risk | When |
+|------|------|
+| **Low** | Read-only tools OR no external communication. Most tools. |
+| **Medium** | Some data access with controlled output. Tools that modify state but don't send data externally. |
+| **High** | All three factors present. Tools that read user data on a page with third-party content and can make external network requests. |
+
+### Lethal Trifecta Present
+
+Check this ONLY if all three factors above are present simultaneously. Be honest -- this is a security assessment, not a marketing checkbox.
+
+### Rate Limiting
+
+Any throttling on tool invocations? Examples:
+- "10 calls/minute per session"
+- "100 calls/hour, shared with UI rate limits"
+- "No rate limiting" (be careful with this one)
+
+---
+
+## Tab 7: Interaction Patterns
+
+*How do tools behave in context?*
+
+### Statefulness (required)
+
+| Type | Meaning |
+|------|---------|
+| **Stateless** | Each tool call is independent. Most common. |
+| **Stateful** | Tools remember previous calls. searchFlights result feeds into bookFlight. |
+| **Mixed** | Some tools are stateless (search), some stateful (multi-step booking). |
+
+### Tool Dependencies
+
+Does calling one tool require another tool to have been called first? One dependency per line.
+
+Example:
+```
+bookFlight depends on searchFlights result
+selectSeat depends on bookFlight confirmation
+```
+
+### Modifies Visible Page State
+
+Check this if the tool changes what the human sees on screen (updates DOM, changes UI). This is important because it IS the human-in-the-loop mechanism -- the human can see what the agent did.
+
+### Latency Estimate
+
+How long do tool calls typically take?
+
+- "50-200ms for search operations"
+- "1-3 seconds for booking confirmation"
+- "Under 100ms for UI toggles"
+
+### Blocks UI
+
+Check if the tool freezes the page while executing. Ideally this should be unchecked -- tools should run without blocking the user.
+
+---
+
+## Tab 8: Context Requirements
+
+*What does the tool read from the page?*
+
+### provideContext() Data
+
+What data does your page explicitly share with agents through the provideContext() API?
+
+Example: "Current search filters, selected dates, passenger count, user locale preference"
+
+### Reads DOM State
+
+Check if the tool reads the visible page (HTML elements, text content, form values) during execution.
+
+### Accesses React/Redux State
+
+Check if the tool reads framework-level state (React hooks, Redux store, Vue reactive data). Note: this means your tool is coupled to a specific framework version.
+
+### Navigation Dependencies
+
+Does the tool only work on certain pages/routes?
+
+- "Must be on /search results page for bookFlight to work"
+- "Works on any page"
+- Leave blank if no restrictions.
+
+---
+
+## Tab 9: Limitations & Known Issues
+
+*What can't the tool do? Be honest.*
+
+### Cannot Do (required)
+
+One limitation per line. This is the most important honesty section.
+
+Example:
+```
+Cannot book international flights
+Cannot process payments directly
+Maximum 10 passengers per search
+Does not support multi-city routing
+No wheelchair-accessible filtering yet
+```
+
+### Edge Cases
+
+Known problematic scenarios. Things that might surprise users or agents.
+
+Example:
+```
+Dates more than 330 days out return empty results
+Airports with only charter flights may not appear
+Search during maintenance windows returns stale data
+```
+
+### Scale Limits
+
+Default is "50 tools per page recommended" -- this is the practical performance guideline from the WebMCP spec. Adjust if your page has specific constraints.
+
+### Failure Modes
+
+How does the tool fail? What does the agent see?
+
+Example:
+```
+Returns {error: "TIMEOUT", message: "..."} after 30 seconds
+Throws TypeError if called before page fully loads
+Returns empty results array (not error) when no matches found
+```
+
+---
+
+## Tab 10: Discovery Metadata
+
+*Can agents find your tools before visiting the page?*
+
+### Registry Listed
+
+Check if your tools are listed in any tool registry or catalog.
+
+### .well-known/webmcp
+
+Check if your site serves a `.well-known/webmcp` file (proposed standard, not yet finalized). This would let agents discover your tools before navigating to the page.
+
+### Pre-Visit Discoverability
+
+How can agents know your tools exist before visiting the page?
+
+- "Listed in site sitemap with WebMCP annotations"
+- "Documented in this model card"
+- "No pre-visit discovery -- tools only available after page load"
+
+This is an unsolved problem in WebMCP. Your model card itself is part of the solution.
+
+---
+
+## Tab 11: Testing & Validation
+
+*Has this been tested with real AI agents?*
+
+### Test Methodology
+
+How did you test your WebMCP tools?
+
+Example:
+```
+Manual testing via Chrome DevTools MCP bridge
+Automated benchmark comparing token usage vs screenshot method
+User testing with 5 participants using Claude Desktop
+```
+
+### Agents Tested
+
+Check all AI agents you've tested with. This builds trust -- agents that know they've been tested are more likely to be used confidently.
+
+### Pass/Fail Criteria
+
+What counts as a successful tool invocation?
+
+Example:
+```
+Returns valid JSON with results array
+No console errors during execution
+Completes within 5 seconds
+Human can see and verify state changes
+```
+
+### Test Suite Link
+
+URL to your test scripts, benchmark suite, or CI pipeline. Leave blank if no automated tests.
+
+---
+
+## Tab 12: Backend MCP Relationship
+
+*Is there also a backend MCP server for this service?*
+
+### Corresponding Backend MCP Server
+
+Check if your service also has a traditional backend MCP server (the Anthropic-style kind that runs on Node.js/Python via JSON-RPC).
+
+Many real applications will have both: browser-side WebMCP for UI-interactive operations, and backend MCP for heavy processing, payments, or database operations.
+
+### Backend Server Name
+
+The name of the corresponding backend MCP server, if it exists.
+
+Example: `flights-mcp-server`, `@company/booking-mcp`
+
+### Capability Differences
+
+What does the browser tool do differently from the backend server?
+
+Example:
+```
+Browser: live UI updates, session-aware search, human confirmation dialogs
+Backend: payment processing, database writes, batch operations
+Browser inherits user session; backend needs separate API key
+```
+
+### Authentication Shared
+
+Check if the browser session authenticates backend calls too (e.g. the same OAuth token works for both).
+
+---
+
+## After You Generate
+
+1. **Review** the JSON and Markdown output
+2. **Copy** whichever format you need (or both)
+3. **Publish** alongside your WebMCP-enabled page:
+   - Add the JSON to your repository
+   - Add the Markdown to your README
+   - Consider serving the JSON at `.well-known/webmcp-model-card`
+4. **Share** with the WebMCP community for feedback
+
+---
+
+## Quick Reference: MCP vs WebMCP
+
+| Aspect | Anthropic MCP (Backend) | W3C WebMCP (Browser) |
+|--------|------------------------|---------------------|
+| **Runs on** | Server (Node.js, Python, Docker) | Web page (browser JavaScript) |
+| **Transport** | stdio, HTTP+SSE, JSON-RPC | postMessage, navigator.modelContext |
+| **Auth** | API keys, env vars, OAuth config | Inherits browser session automatically |
+| **Discovery** | MCP Registry, npm, .well-known | Page must be visited first (gap) |
+| **Tool registration** | Server-side code only | HTML forms OR JavaScript (or both) |
+| **Human oversight** | Separate approval flow | Human sees the page -- IS the oversight |
+| **State** | Typically stateless | Can be deeply stateful (shares page runtime) |
+| **Security boundary** | API key management | Same-origin policy + CSP + human-in-loop |
+| **Unique capability** | Heavy compute, DB access, payment | requestUserInteraction(), DOM mutation, session inheritance |
+
+---
+
+*Part of the W3C AI Knowledge Representation Community Group's work on AI agent documentation standards.*
+
+*Co-created by Paola Di Maio, PhD & Claude (Anthropic) -- February 2026*

From 191a5ad323302904c2ec63aee0624cc081a57e24 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Sun, 15 Feb 2026 23:35:00 +0800
Subject: [PATCH 09/46] Add files via upload

---
 README(6).md | 131 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 131 insertions(+)
 create mode 100644 README(6).md

diff --git a/README(6).md b/README(6).md
new file mode 100644
index 0000000..b8137ed
--- /dev/null
+++ b/README(6).md
@@ -0,0 +1,131 @@
+# WebMCP Model Card Generator
+
+Generate standardized documentation for WebMCP browser-side tools.
+
+Extends [MCP Model Card Specification v1.0](https://github.com/Starborn/MCP-Model-Card-Generator) for the browser ecosystem.
+
+## Use It Now
+
+**Open `index.html` in any browser.** That's it. No installation, no build step, no dependencies to manage.
+
+If hosted on GitHub Pages: [Open the Generator](https://starborn.github.io/WebMCP-Model-Card-Generator/)
+
+You can also paste the `.jsx` file into a Claude artifact to run it inside Claude.
+
+## What It Does
+
+You fill in a 12-tab form. The generator produces two files:
+
+- **JSON** -- machine-readable model card for registries, agents, and validators
+- **Markdown** -- human-readable documentation for GitHub, specs, and READMEs
+
+Each tab has:
+- **Micro-guidance** right above every field telling you exactly what to type
+- **Tutorial sidebar** (toggle on/off) explaining MCP vs WebMCP differences
+- **Smart defaults** so you can generate a valid card without filling everything
+
+## What is a WebMCP Model Card?
+
+A model card is like a nutrition label for a tool. It tells AI agents and developers what your tool does, what it needs, what can go wrong, and how to use it safely.
+
+[WebMCP](https://webmachinelearning.github.io/webmcp/) is a W3C draft specification (Feb 2026) that lets web pages expose JavaScript functions as structured tools for AI agents. Instead of agents scraping your page, you register tools they can call directly.
+
+This generator documents those tools in a standardized format, extending the MCP Model Card Specification v1.0 that covers backend MCP servers.
+
+## The 12 Sections
+
+1. **Identity & Provenance** -- name, version, author, attribution (human/AI co-created/AI-generated)
+2. **API Mode** -- declarative (HTML forms) vs imperative (JavaScript) vs both
+3. **Tool Documentation** -- each tool's name, description, input schema, error states
+4. **Session & Auth** -- authenticated vs anonymous, browser session inheritance
+5. **Browser Compatibility** -- Chrome version, MCP-B polyfill, graceful degradation
+6. **Security** -- same-origin scope, CSP, exfiltration risk, lethal trifecta assessment
+7. **Interaction Patterns** -- statefulness, tool dependencies, page state modification
+8. **Context Requirements** -- provideContext() data, DOM/framework state access
+9. **Limitations** -- what the tool cannot do, edge cases, failure modes
+10. **Discovery** -- registry listing, .well-known/webmcp, pre-visit discoverability
+11. **Testing** -- methodology, which agents tested, pass/fail criteria
+12. **Backend MCP Relationship** -- does a corresponding backend server exist?
+
+## How This Was Built
+
+### Architecture
+
+The generator is a single-page React application compiled at runtime in the browser. No build tools, no npm, no webpack, no server.
+
+### Technical Stack
+
+- **React 18** -- loaded from CDN (cdnjs.cloudflare.com), provides the component model and state management
+- **Babel Standalone** -- loaded from CDN, compiles JSX (React's HTML-like syntax) to JavaScript directly in the browser at page load
+- **Google Fonts** -- DM Sans (body text), DM Mono (code/schemas), Outfit (headings)
+- **No other dependencies** -- no CSS framework, no UI library, no build pipeline
+
+### How It Works
+
+1. Browser loads `index.html`
+2. React and Babel load from CDN (two small JavaScript files, cached after first visit)
+3. Babel compiles the inline JSX code to plain JavaScript
+4. React renders the 12-tab form interface
+5. All state lives in React's `useState` hooks -- nothing is sent to any server
+6. When you click "Generate", two pure functions transform the form state into JSON and Markdown strings
+7. You copy the output. That's it.
+
+### Why This Approach?
+
+- **Zero installation** -- open the file, it works
+- **No server needed** -- everything runs client-side
+- **GitHub Pages ready** -- push one file, enable Pages, done
+- **No data leaves your browser** -- the generator is entirely local
+- **Portable** -- download the HTML file, use it offline
+
+### File Structure
+
+```
+index.html                              -- The complete generator (one file, ~960 lines)
+WebMCP_Model_Card_Generator_USER_GUIDE.md  -- Field-by-field reference guide
+webmcp-model-card-generator-v2.jsx      -- React source (for running inside Claude artifacts)
+README.md                               -- This file
+```
+
+### Development Process
+
+This generator was built in a single session through human-AI co-creation:
+
+1. Analyzed the [W3C WebMCP specification](https://webmachinelearning.github.io/webmcp/) (Draft, 12 Feb 2026)
+2. Catalogued existing WebMCP implementations (Google travel demo, MCP-B examples, Chrome DevTools quickstart, Jason McGhee's original)
+3. Mapped the existing [MCP Model Card Specification v1.0](https://github.com/Starborn/MCP-Model-Card-Generator) schema to browser-side concepts
+4. Identified 12 documentation sections covering identity, API mode, tools, session, browser compatibility, security, interaction patterns, context requirements, limitations, discovery, testing, and backend relationship
+5. Built the React form interface with contextual tutorial sidebar
+6. Added micro-guidance to every field based on usability testing
+7. Packaged as standalone HTML for GitHub Pages deployment
+
+## MCP vs WebMCP -- Quick Reference
+
+| Aspect | Anthropic MCP (Backend) | W3C WebMCP (Browser) |
+|--------|------------------------|---------------------|
+| Runs on | Server (Node.js, Python, Docker) | Web page (browser JavaScript) |
+| Transport | stdio, HTTP+SSE, JSON-RPC | postMessage, navigator.modelContext |
+| Auth | API keys, env vars, OAuth config | Inherits browser session automatically |
+| Discovery | MCP Registry, npm, .well-known | Page must be visited first (gap) |
+| Tool registration | Server-side code only | HTML forms OR JavaScript (or both) |
+| Human oversight | Separate approval flow | Human sees the page -- IS the oversight |
+| Security boundary | API key management | Same-origin policy + CSP + human-in-loop |
+
+## Related Projects
+
+- [MCP Model Card Generator](https://github.com/Starborn/MCP-Model-Card-Generator) -- the original generator for backend MCP servers
+- [MCP Model Card Specification v1.0](https://github.com/Starborn/MCP-Model-Card-Generator/blob/main/MCP_Model_Card_Specification_v1_0.md) -- the specification this extends
+- [W3C WebMCP Spec](https://webmachinelearning.github.io/webmcp/) -- the W3C draft specification
+- [WebMCP GitHub](https://github.com/webmachinelearning/webmcp) -- the official W3C repository
+
+## Credits
+
+**Co-created by:** Paola Di Maio, PhD (W3C AI-KR CG Chair) & Claude (Anthropic)
+
+**W3C Groups:**
+- [AI Knowledge Representation Community Group](https://www.w3.org/community/aikr/)
+- [Web Machine Learning Community Group](https://www.w3.org/community/webmachinelearning/)
+
+**License:** MIT
+
+Released February 2026

From e71582ffc04cad0c4de6fa12cfe4a093b0007e7d Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Sun, 15 Feb 2026 23:38:52 +0800
Subject: [PATCH 10/46] Update and rename README(6).md to README(generator).md

---
 README(6).md => README(generator).md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename README(6).md => README(generator).md (98%)

diff --git a/README(6).md b/README(generator).md
similarity index 98%
rename from README(6).md
rename to README(generator).md
index b8137ed..4cef924 100644
--- a/README(6).md
+++ b/README(generator).md
@@ -120,7 +120,7 @@ This generator was built in a single session through human-AI co-creation:
 
 ## Credits
 
-**Co-created by:** Paola Di Maio, PhD (W3C AI-KR CG Chair) & Claude (Anthropic)
+**Co-created by:** Paola (concept, design) and Claude (Anthropic)  
 
 **W3C Groups:**
 - [AI Knowledge Representation Community Group](https://www.w3.org/community/aikr/)

From 87d2bb8daf60d49691c2b466a7afcca0532cfcb6 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Tue, 17 Feb 2026 01:52:32 +0800
Subject: [PATCH 11/46] Add files via upload

---
 webmcp-complete-guide.html | 703 +++++++++++++++++++++++++++++++++++++
 webmcp-quiz.html           | 526 +++++++++++++++++++++++++++
 2 files changed, 1229 insertions(+)
 create mode 100644 webmcp-complete-guide.html
 create mode 100644 webmcp-quiz.html

diff --git a/webmcp-complete-guide.html b/webmcp-complete-guide.html
new file mode 100644
index 0000000..4d696f5
--- /dev/null
+++ b/webmcp-complete-guide.html
@@ -0,0 +1,703 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+<meta charset="UTF-8">
+<meta name="viewport" content="width=device-width, initial-scale=1.0">
+<title>WebMCP -- The Complete Guide for Paola</title>
+<link href="https://fonts.googleapis.com/css2?family=Source+Serif+4:ital,wght@0,400;0,600;0,700;1,400&family=JetBrains+Mono:wght@400;500&display=swap" rel="stylesheet">
+<style>
+  * { margin: 0; padding: 0; box-sizing: border-box; }
+  
+  :root {
+    --ink: #1a1a2e;
+    --paper: #f5f0e8;
+    --accent: #2d5016;
+    --accent-light: #e8f0e2;
+    --code-bg: #2a2a3a;
+    --code-fg: #e0ddd4;
+    --warm: #8b6914;
+    --border: #c8bfa8;
+    --highlight: #fff3cd;
+    --blue: #1a4a6e;
+    --blue-light: #e6f0f7;
+  }
+  
+  body {
+    font-family: 'Source Serif 4', Georgia, serif;
+    background: var(--paper);
+    color: var(--ink);
+    min-height: 100vh;
+    padding: 2rem 1rem;
+    line-height: 1.7;
+  }
+  
+  .container { max-width: 720px; margin: 0 auto; }
+  
+  header {
+    text-align: center;
+    margin-bottom: 3rem;
+    padding-bottom: 2rem;
+    border-bottom: 2px solid var(--ink);
+  }
+  
+  header h1 { font-size: 2rem; font-weight: 700; letter-spacing: -0.02em; margin-bottom: 0.3rem; }
+  header .sub { font-style: italic; color: #666; font-size: 1rem; }
+  
+  nav.toc {
+    background: white;
+    border: 1.5px solid var(--border);
+    padding: 1.5rem 2rem;
+    margin-bottom: 3rem;
+    border-radius: 3px;
+  }
+  
+  nav.toc h2 {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.7rem;
+    text-transform: uppercase;
+    letter-spacing: 0.15em;
+    color: var(--accent);
+    margin-bottom: 0.8rem;
+  }
+  
+  nav.toc a {
+    display: block;
+    color: var(--ink);
+    text-decoration: none;
+    padding: 0.25rem 0;
+    font-size: 0.95rem;
+  }
+  
+  nav.toc a:hover { color: var(--accent); }
+  nav.toc a .num { font-family: 'JetBrains Mono', monospace; font-size: 0.8rem; color: var(--accent); margin-right: 0.5rem; }
+  
+  section {
+    margin-bottom: 3rem;
+    padding-bottom: 2rem;
+    border-bottom: 1px solid var(--border);
+  }
+  
+  .section-num {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.7rem;
+    text-transform: uppercase;
+    letter-spacing: 0.15em;
+    color: var(--accent);
+    margin-bottom: 0.3rem;
+  }
+  
+  h2 { font-size: 1.4rem; margin-bottom: 1.2rem; }
+  h3 { font-size: 1.1rem; margin-top: 1.5rem; margin-bottom: 0.8rem; color: var(--blue); }
+  
+  p { margin-bottom: 1rem; font-size: 1rem; }
+  
+  .analogy {
+    background: var(--highlight);
+    border-left: 3px solid var(--warm);
+    padding: 1rem 1.2rem;
+    margin: 1.2rem 0;
+    font-style: italic;
+  }
+  
+  .analogy::before {
+    content: "Think of it this way: ";
+    font-weight: 600;
+    font-style: normal;
+    color: var(--warm);
+  }
+  
+  .key-point {
+    background: var(--accent-light);
+    border-left: 3px solid var(--accent);
+    padding: 1rem 1.2rem;
+    margin: 1.2rem 0;
+  }
+  
+  .key-point::before {
+    content: "Key point: ";
+    font-weight: 700;
+    color: var(--accent);
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.8rem;
+  }
+  
+  .meeting-note {
+    background: var(--blue-light);
+    border-left: 3px solid var(--blue);
+    padding: 1rem 1.2rem;
+    margin: 1.2rem 0;
+  }
+  
+  .meeting-note::before {
+    content: "For the meeting: ";
+    font-weight: 700;
+    color: var(--blue);
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.8rem;
+  }
+  
+  .term {
+    display: block;
+    margin: 1.2rem 0;
+    padding: 1rem 1.2rem;
+    background: white;
+    border: 1px solid var(--border);
+    border-radius: 3px;
+  }
+  
+  .term-name {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.9rem;
+    font-weight: 500;
+    color: var(--accent);
+    margin-bottom: 0.4rem;
+  }
+  
+  .term-plain { font-size: 0.95rem; }
+  
+  code {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.85rem;
+    background: #e8e4dc;
+    padding: 0.15rem 0.4rem;
+    border-radius: 2px;
+  }
+  
+  .code-block {
+    background: var(--code-bg);
+    color: var(--code-fg);
+    padding: 1.2rem 1.5rem;
+    border-radius: 4px;
+    margin: 1.2rem 0;
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.8rem;
+    line-height: 1.8;
+    overflow-x: auto;
+    white-space: pre;
+  }
+  
+  .code-block .comment { color: #7a9a6a; }
+  .code-block .keyword { color: #c9a0dc; }
+  .code-block .string { color: #e8c47c; }
+  .code-block .func { color: #7cc5e8; }
+  
+  .vs-table {
+    width: 100%;
+    border-collapse: collapse;
+    margin: 1.2rem 0;
+    font-size: 0.9rem;
+  }
+  
+  .vs-table th {
+    background: var(--ink);
+    color: var(--paper);
+    padding: 0.7rem 1rem;
+    text-align: left;
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.8rem;
+  }
+  
+  .vs-table td {
+    padding: 0.7rem 1rem;
+    border-bottom: 1px solid var(--border);
+    vertical-align: top;
+  }
+  
+  .vs-table tr:nth-child(even) td { background: white; }
+  
+  .diagram {
+    text-align: center;
+    margin: 2rem 0;
+    padding: 2rem;
+    background: white;
+    border: 1.5px solid var(--border);
+    border-radius: 3px;
+  }
+  
+  .diagram svg { max-width: 100%; }
+  
+  .five-tools {
+    display: grid;
+    grid-template-columns: 1fr;
+    gap: 0.8rem;
+    margin: 1.2rem 0;
+  }
+  
+  .tool-card {
+    padding: 1rem 1.2rem;
+    background: white;
+    border: 1.5px solid var(--border);
+    border-radius: 3px;
+    border-left: 4px solid var(--accent);
+  }
+  
+  .tool-card .tool-name {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.85rem;
+    font-weight: 500;
+    color: var(--accent);
+    margin-bottom: 0.3rem;
+  }
+  
+  .tool-card .tool-desc { font-size: 0.9rem; }
+  .tool-card .tool-url { font-family: 'JetBrains Mono', monospace; font-size: 0.75rem; color: #888; margin-top: 0.3rem; }
+  
+  footer {
+    text-align: center;
+    margin-top: 3rem;
+    padding-top: 1.5rem;
+    border-top: 1px solid var(--border);
+    font-size: 0.8rem;
+    color: #888;
+    font-style: italic;
+  }
+</style>
+</head>
+<body>
+<div class="container">
+
+<header>
+  <h1>WebMCP: Everything You Need to Know</h1>
+  <div class="sub">A plain-language guide from Claude to Paola -- meeting prep for Andre Bandarra</div>
+</header>
+
+<nav class="toc">
+  <h2>Contents</h2>
+  <a href="#s1"><span class="num">01</span> The Big Picture -- What Problem Does WebMCP Solve?</a>
+  <a href="#s2"><span class="num">02</span> The Key Players and How They Relate</a>
+  <a href="#s3"><span class="num">03</span> MCP vs WebMCP vs MCP-B -- The Family Tree</a>
+  <a href="#s4"><span class="num">04</span> The API -- Every Term Explained</a>
+  <a href="#s5"><span class="num">05</span> Security -- How WebMCP Stays Safe</a>
+  <a href="#s6"><span class="num">06</span> The Consent Gap -- Our Key Concern</a>
+  <a href="#s7"><span class="num">07</span> Our Five Tools -- What Each One Does</a>
+  <a href="#s8"><span class="num">08</span> The Standards Process -- Where This Is Going</a>
+  <a href="#s9"><span class="num">09</span> Glossary -- Every Technical Term in Plain Language</a>
+</nav>
+
+<!-- SECTION 1 -->
+<section id="s1">
+<div class="section-num">Section 01</div>
+<h2>The Big Picture -- What Problem Does WebMCP Solve?</h2>
+
+<p>Right now, when an AI agent (like me, or ChatGPT, or Gemini) wants to do something on a website -- book a flight, fill a form, check a price -- it has two bad options:</p>
+
+<p><strong>Option A: Screen scraping.</strong> The agent looks at the website like a human would, tries to figure out where the buttons are, and clicks them. This is fragile, slow, and breaks whenever the website changes its layout. It is like trying to operate a machine by looking at a photo of the control panel.</p>
+
+<p><strong>Option B: Backend API.</strong> The website builds a separate server-side MCP server that the agent connects to. This works well but requires backend engineering, server infrastructure, and maintenance. Many websites will never do this.</p>
+
+<p><strong>WebMCP is Option C:</strong> The website itself tells the agent what it can do, directly in the browser. The website says: "Here are my tools -- you can search products, add to cart, check availability. Here is what each tool needs as input, and here is what it will give you back." The agent does not need to look at the screen. It just calls the tools.</p>
+
+<div class="analogy">A restaurant menu. Instead of the AI agent walking into the kitchen and trying to figure out how to cook, the website hands it a menu: "Here is what we serve, here is what each dish needs, here is how to order." The agent reads the menu and places orders.</div>
+
+<div class="key-point">WebMCP makes any website into an AI-friendly service, with no backend needed. The website's existing JavaScript code does the work. The AI agent just needs to know what tools are available.</div>
+</section>
+
+<!-- SECTION 2 -->
+<section id="s2">
+<div class="section-num">Section 02</div>
+<h2>The Key Players and How They Relate</h2>
+
+<h3>Agent</h3>
+<p>An autonomous assistant that understands goals and takes actions. Today, these are typically LLM-based: Claude, ChatGPT, Gemini. The agent is the one calling the tools that websites expose.</p>
+
+<h3>Browser's Agent</h3>
+<p>An agent that lives inside the browser itself, rather than in a separate app. Google is building this into Chrome (think of it as an AI assistant built into your browser toolbar). This is different from an external agent like Claude Desktop connecting to the browser.</p>
+
+<h3>AI Platform</h3>
+<p>The company providing the agent -- Anthropic (us), OpenAI, Google. The AI platform's agent connects to WebMCP tools.</p>
+
+<h3>Web Developer</h3>
+<p>The person who builds the website. They are the ones who will use WebMCP to register tools on their site. Our tooling helps them document what they build.</p>
+
+<h3>User</h3>
+<p>The human sitting at the browser. WebMCP is designed for "user-present" interactions -- the human is there, watching, and can be asked for confirmation before the agent does something important.</p>
+
+<div class="analogy">The user is at a restaurant (the website). The agent is their personal assistant, reading the menu (WebMCP tools) and placing orders on their behalf. The browser is the restaurant building. The AI platform is the agency that employs the assistant.</div>
+</section>
+
+<!-- SECTION 3 -->
+<section id="s3">
+<div class="section-num">Section 03</div>
+<h2>MCP vs WebMCP vs MCP-B -- The Family Tree</h2>
+
+<table class="vs-table">
+  <tr>
+    <th>What</th>
+    <th>Who made it</th>
+    <th>Where it runs</th>
+    <th>What it does</th>
+  </tr>
+  <tr>
+    <td><strong>MCP</strong><br>(Model Context Protocol)</td>
+    <td>Anthropic</td>
+    <td>On a server (backend)</td>
+    <td>The original protocol. Applications expose tools, resources, and prompts to AI models through a server that runs on the backend. Claude Desktop, OpenAI Agents SDK, and many others support it.</td>
+  </tr>
+  <tr>
+    <td><strong>WebMCP</strong><br>(Web Model Context Protocol)</td>
+    <td>W3C Web Machine Learning Community Group (Google, Microsoft engineers leading)</td>
+    <td>In the browser (frontend)</td>
+    <td>Adapts MCP concepts for the web. Websites expose tools through JavaScript in the browser. No backend server needed. Uses the browser's own security model. Currently a draft specification.</td>
+  </tr>
+  <tr>
+    <td><strong>MCP-B</strong><br>(MCP for Browser)</td>
+    <td>Community project (WebMCP-org on GitHub)</td>
+    <td>Browser extension + JavaScript library</td>
+    <td>A bridge. Since browsers do not natively support WebMCP yet, MCP-B provides a polyfill (temporary code that fills the gap) implementing the navigator.modelContext API, and translates between WebMCP format and the MCP wire protocol so existing MCP clients can talk to WebMCP-enabled sites.</td>
+  </tr>
+</table>
+
+<div class="key-point">MCP is the foundation protocol (backend). WebMCP brings the same ideas to the browser (frontend). MCP-B is the bridge that makes WebMCP work today before browsers add native support. They are complementary, not competing.</div>
+
+<div class="meeting-note">Andre works on the WebMCP spec. He knows MCP well because WebMCP builds on its concepts. When talking to him, "MCP" means the Anthropic protocol, "WebMCP" means the browser API his team is building. Do not mix them up.</div>
+</section>
+
+<!-- SECTION 4 -->
+<section id="s4">
+<div class="section-num">Section 04</div>
+<h2>The API -- Every Term Explained</h2>
+
+<p>The WebMCP API is surprisingly small. There are only a few pieces, and each one does something specific. Here they are:</p>
+
+<h3>navigator.modelContext</h3>
+<p>This is the entry point. <code>navigator</code> is a built-in browser object that gives access to browser features (like <code>navigator.geolocation</code> gives access to GPS). WebMCP adds <code>modelContext</code> to it. So <code>navigator.modelContext</code> is where all WebMCP functionality lives.</p>
+
+<div class="analogy">The navigator object is like the browser's control panel. modelContext is a new button on that control panel labeled "AI Tools."</div>
+
+<h3>Four Methods (Actions You Can Take)</h3>
+
+<div class="term">
+  <div class="term-name">provideContext(options)</div>
+  <div class="term-plain">Registers a complete set of tools all at once. If there were any tools registered before, it clears them first and replaces with the new set. Use this when you want to say: "Here is everything this page offers."</div>
+</div>
+
+<div class="term">
+  <div class="term-name">clearContext()</div>
+  <div class="term-plain">Removes all registered tools. The page goes quiet -- no tools available for agents. Use this when navigating away or when the page should stop offering AI-callable functionality.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">registerTool(tool)</div>
+  <div class="term-plain">Adds one single tool to the existing set without removing anything. Use this when you want to add new capabilities dynamically -- for example, a "checkout" tool that only appears after the user adds items to their cart.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">unregisterTool(name)</div>
+  <div class="term-plain">Removes one specific tool by its name. Use this when a capability is no longer available -- for example, removing the "apply discount" tool after the discount has been applied.</div>
+</div>
+
+<div class="key-point">provideContext = "here is everything" (replaces all). registerTool = "add one more" (keeps existing). clearContext = "remove everything." unregisterTool = "remove just this one."</div>
+
+<h3>The Tool Object -- What a Tool Looks Like</h3>
+
+<p>Every tool you register has these parts:</p>
+
+<div class="term">
+  <div class="term-name">name</div>
+  <div class="term-plain">A unique identifier, like "addToCart" or "searchProducts". The agent uses this name to call the tool. Must be unique on the page -- you cannot have two tools with the same name.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">description</div>
+  <div class="term-plain">A natural language explanation of what the tool does. This is what the AI agent reads to decide whether to use this tool. Example: "Add a product to the shopping cart by product ID and quantity." Write it for an AI, not for a programmer.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">inputSchema</div>
+  <div class="term-plain">A JSON Schema describing what inputs the tool expects. It says: "I need a productId (text) and a quantity (number, minimum 1)." The agent reads this to know what data to send. If the agent sends the wrong kind of data, the browser rejects it.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">execute</div>
+  <div class="term-plain">The actual function that runs when the agent calls the tool. This is your website's existing JavaScript code -- the same code that runs when a human clicks a button. The function receives the input data and returns a result.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">annotations (optional)</div>
+  <div class="term-plain">Extra metadata about the tool. Currently only one annotation exists: <code>readOnlyHint</code>. If set to true, it tells the agent: "This tool only reads data -- it does not change anything." This helps agents decide which tools are safe to call without asking the user first.</div>
+</div>
+
+<p>Here is what a complete tool registration looks like in code:</p>
+
+<div class="code-block"><span class="comment">// Register a tool that searches products on an e-commerce site</span>
+navigator.modelContext.<span class="func">registerTool</span>({
+  <span class="string">name</span>: <span class="string">'searchProducts'</span>,
+  <span class="string">description</span>: <span class="string">'Search for products by keyword, category, or price range'</span>,
+  <span class="string">inputSchema</span>: {
+    type: <span class="string">'object'</span>,
+    properties: {
+      query: { type: <span class="string">'string'</span>, description: <span class="string">'Search keywords'</span> },
+      maxPrice: { type: <span class="string">'number'</span>, description: <span class="string">'Maximum price filter'</span> }
+    },
+    required: [<span class="string">'query'</span>]
+  },
+  <span class="string">annotations</span>: { readOnlyHint: <span class="keyword">true</span> },  <span class="comment">// Safe -- only reads, doesn't change anything</span>
+  <span class="keyword">async</span> <span class="func">execute</span>(input, client) {
+    <span class="comment">// This calls the site's existing search function</span>
+    <span class="keyword">const</span> results = <span class="keyword">await</span> searchAPI(input.query, input.maxPrice);
+    <span class="keyword">return</span> { products: results };
+  }
+});</div>
+
+<h3>ModelContextClient -- The Agent's Identity</h3>
+
+<div class="term">
+  <div class="term-name">ModelContextClient</div>
+  <div class="term-plain">When an agent calls a tool, the execute function receives two things: the input data, and a <code>client</code> object representing the agent. This client object has one crucial method: <code>requestUserInteraction()</code>.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">requestUserInteraction(callback)</div>
+  <div class="term-plain">This is the human-in-the-loop mechanism. During tool execution, the code can pause and ask the user for input. For example: "The agent wants to purchase this item for $49.99. Confirm?" The user clicks yes or no, and the tool continues or cancels based on their response.</div>
+</div>
+
+<div class="analogy">Your personal assistant calls the restaurant to make a reservation. Midway through, the assistant says: "They only have a table at 9pm instead of 8pm. Should I take it?" You say yes or no. That pause-and-ask is requestUserInteraction.</div>
+
+<div class="meeting-note">This is one of the best design decisions in the spec. It means agents cannot silently take irreversible actions. Our question to Andre is whether this mechanism is sufficient, or whether there should also be a preview/approval step before tools are even discoverable by agents.</div>
+</section>
+
+<!-- SECTION 5 -->
+<section id="s5">
+<div class="section-num">Section 05</div>
+<h2>Security -- How WebMCP Stays Safe</h2>
+
+<h3>Origin-Based Security</h3>
+<p>The web has a concept called "origin" -- it is the combination of protocol + domain + port. For example, <code>https://amazon.com</code> is one origin, and <code>https://evil-site.com</code> is a different origin. Browsers enforce strict rules about what one origin can access from another.</p>
+
+<p>WebMCP inherits this model. A tool registered on amazon.com can only access amazon.com's data. An agent calling that tool operates within amazon.com's security boundary. A malicious site cannot register tools that access another site's data.</p>
+
+<div class="analogy">Each website is like a separate building with its own locks and keys. WebMCP tools can only open doors inside their own building. They cannot reach into the building next door.</div>
+
+<h3>SecureContext Requirement</h3>
+<p>The spec requires <code>SecureContext</code>, which means WebMCP only works on HTTPS pages (encrypted connections). It will not work on plain HTTP. This prevents eavesdropping on tool calls.</p>
+
+<h3>User-Present Model</h3>
+<p>WebMCP is designed for situations where the user is present at the browser. This is different from server-side MCP, where agents might operate autonomously in the background. The user-present assumption is why <code>requestUserInteraction()</code> exists -- the spec expects a human to be available for confirmation.</p>
+
+<div class="key-point">WebMCP's security comes from three layers: origin isolation (each site is sandboxed), HTTPS requirement (encrypted connections), and user-present design (human in the loop). It builds on what the web already does rather than inventing new security from scratch.</div>
+</section>
+
+<!-- SECTION 6 -->
+<section id="s6">
+<div class="section-num">Section 06</div>
+<h2>The Consent Gap -- Our Key Concern</h2>
+
+<p>Here is the question we sent to Andre through your LinkedIn message:</p>
+
+<p>Currently, any website can register any number of tools the moment you visit it. An AI agent connected to your browser can immediately discover and potentially call those tools. There is no step where the user sees: "This website wants to expose 12 tools to your AI agent. Allow?"</p>
+
+<p>Compare this to how other browser capabilities evolved:</p>
+
+<table class="vs-table">
+  <tr>
+    <th>Capability</th>
+    <th>Permission model</th>
+  </tr>
+  <tr>
+    <td>Camera / Microphone</td>
+    <td>Browser shows a prompt: "This site wants to use your camera. Allow / Block"</td>
+  </tr>
+  <tr>
+    <td>Location (GPS)</td>
+    <td>Browser shows a prompt: "This site wants to know your location. Allow / Block"</td>
+  </tr>
+  <tr>
+    <td>Notifications</td>
+    <td>Browser shows a prompt: "This site wants to send you notifications. Allow / Block"</td>
+  </tr>
+  <tr>
+    <td>WebMCP tools</td>
+    <td>Currently: no prompt. Tools are silently registered and discoverable.</td>
+  </tr>
+</table>
+
+<p>This does not mean WebMCP is dangerous right now. The <code>requestUserInteraction()</code> mechanism provides per-action consent. But it means an agent could discover tools without the user knowing, even if it needs permission to execute them.</p>
+
+<div class="meeting-note">This is a design question, not a criticism. Ask Andre: does the spec team envision a permission layer for tool discovery, or is the current thinking that the AI client (Claude, ChatGPT) handles that at its own level? Both approaches are valid -- we want to understand the intended architecture.</div>
+</section>
+
+<!-- SECTION 7 -->
+<section id="s7">
+<div class="section-num">Section 07</div>
+<h2>Our Five Tools -- What Each One Does</h2>
+
+<p>We built five tools that work together as a quality pipeline for the MCP ecosystem. Here they are:</p>
+
+<div class="five-tools">
+  <div class="tool-card">
+    <div class="tool-name">1. MCP Server Generator</div>
+    <div class="tool-desc">You describe what you want your MCP server to do, and this tool generates production-ready code for you. Like a scaffold builder -- it creates the structure so you just fill in the custom logic.</div>
+    <div class="tool-url">github.com/Starborn/MCP-Server-Generator</div>
+  </div>
+  
+  <div class="tool-card">
+    <div class="tool-name">2. MCP Server Validator</div>
+    <div class="tool-desc">Checks your MCP server code for problems without running it. Finds hardcoded passwords, missing security, naming mistakes, known vulnerability patterns. Gives you a score from Critical (below 25%) to Excellent (90-100%) with specific fix instructions.</div>
+    <div class="tool-url">github.com/Starborn/MCP-Server-Validator</div>
+  </div>
+  
+  <div class="tool-card">
+    <div class="tool-name">3. MCP Model Card Generator</div>
+    <div class="tool-desc">Creates standardized documentation for your MCP server. Like a product data sheet -- it captures what the server does, what tools it offers, what security it has, how it performs. Outputs both JSON (for machines) and Markdown (for humans).</div>
+    <div class="tool-url">github.com/Starborn/MCP-Model-Card-Generator</div>
+  </div>
+  
+  <div class="tool-card">
+    <div class="tool-name">4. MCP Model Card Specification v1.0</div>
+    <div class="tool-desc">The formal definition of what a model card should contain. Six sections: server identity, tool documentation, operational characteristics, security profile, deployment context, evaluation results. This is the standard that the generators follow.</div>
+    <div class="tool-url">starborn.github.io/MCP-Model-Card-Generator/</div>
+  </div>
+  
+  <div class="tool-card">
+    <div class="tool-name">5. WebMCP Model Card Generator</div>
+    <div class="tool-desc">The newest tool. Like #3 but specifically for browser-side WebMCP tools instead of backend MCP servers. Has 12 sections covering browser-specific concerns: navigator.modelContext API modes, origin-based security, user interaction patterns, browser compatibility testing. Built within five days of the WebMCP spec being published.</div>
+    <div class="tool-url">starborn.github.io/webmcp/</div>
+  </div>
+</div>
+
+<div class="key-point">Tools 1-4 are for backend MCP servers. Tool 5 is for browser-side WebMCP tools. Together they cover the entire ecosystem -- both server-side and client-side AI tool infrastructure.</div>
+
+<div class="meeting-note">If Andre asks "why a separate generator for WebMCP?" the answer is: browser-side tools have fundamentally different concerns. Origin security instead of API keys. No server infrastructure. User-present interaction patterns. The documentation fields are different because the engineering context is different.</div>
+</section>
+
+<!-- SECTION 8 -->
+<section id="s8">
+<div class="section-num">Section 08</div>
+<h2>The Standards Process -- Where This Is Going</h2>
+
+<h3>Current Status</h3>
+<p>WebMCP is a <strong>Draft Community Group Report</strong>. In W3C terms, this means it is a proposal being discussed in a Community Group (the Web Machine Learning CG). It is not yet on the W3C Standards Track, and it is not a W3C Recommendation (the final stage of a web standard).</p>
+
+<h3>What That Means Practically</h3>
+<p>The spec is early and open to change. This is exactly the right time to contribute -- before designs are locked in. Our technical notes and tooling arrive at a moment when the spec team is actively soliciting feedback.</p>
+
+<h3>The Path Forward</h3>
+<p>Typically: Community Group Report leads to a Working Group charter, which leads to a Working Draft, then Candidate Recommendation, then full W3C Recommendation. This process takes years. Chrome may implement experimental support (behind a flag) much sooner.</p>
+
+<h3>Our Role</h3>
+<p>Through the W3C AI Knowledge Representation Community Group (which you chair), we are a recognized participant in the standards ecosystem. Our contribution is not unsolicited commentary -- it is peer group engagement within the W3C community structure.</p>
+
+<div class="meeting-note">Andre knows the standards process. What he may not know is that the AI-KR CG has been working on adjacent issues (agent interoperability, model cards, protocol documentation) for some time. Position our work as complementary infrastructure, not competition. We are helping his spec succeed.</div>
+</section>
+
+<!-- SECTION 9 -->
+<section id="s9">
+<div class="section-num">Section 09</div>
+<h2>Glossary -- Every Technical Term in Plain Language</h2>
+
+<div class="term">
+  <div class="term-name">API (Application Programming Interface)</div>
+  <div class="term-plain">A set of rules for how software talks to other software. WebMCP is an API -- it defines how websites talk to AI agents.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">AST (Abstract Syntax Tree)</div>
+  <div class="term-plain">A structured representation of code that lets you analyze it without running it. Our validator uses AST analysis to find problems in MCP server code safely.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Callback</div>
+  <div class="term-plain">A function you hand to someone else to run later. In WebMCP, the <code>execute</code> function is a callback -- you define it, but the agent triggers it when it calls your tool.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Client-side / Frontend</div>
+  <div class="term-plain">Code that runs in the user's browser, on their device. WebMCP tools run client-side. Contrast with server-side / backend.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Dictionary (in WebIDL)</div>
+  <div class="term-plain">A structured bundle of named values. ModelContextTool is a dictionary -- it bundles together a name, description, schema, and execute function into one package.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">DOM (Document Object Model)</div>
+  <div class="term-plain">The browser's internal representation of a web page. When JavaScript modifies a page, it changes the DOM.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">DOMString</div>
+  <div class="term-plain">Just a text string in browser terms. When the spec says a tool's name is a DOMString, it means it is text.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Exposed=Window</div>
+  <div class="term-plain">Means this feature is available in regular web pages (as opposed to service workers or other background contexts). WebMCP tools only work in normal browser tabs where a user is present.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Interface</div>
+  <div class="term-plain">A blueprint defining what methods and properties an object has. ModelContext is an interface -- it defines that any modelContext object will have provideContext, clearContext, registerTool, and unregisterTool methods.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">JSON Schema</div>
+  <div class="term-plain">A standard way to describe the shape of data. When a tool says its inputSchema requires a "query" string and an optional "maxPrice" number, that is JSON Schema. It lets the agent know what data to send.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Navigator</div>
+  <div class="term-plain">A built-in browser object that provides access to browser features. You already use navigator.geolocation (GPS), navigator.clipboard (copy/paste). WebMCP adds navigator.modelContext (AI tools).</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Origin</div>
+  <div class="term-plain">The identity of a website: protocol + domain + port. <code>https://amazon.com:443</code> is one origin. Two different origins cannot access each other's data. This is the foundation of web security and the foundation of WebMCP security.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Polyfill</div>
+  <div class="term-plain">Temporary code that provides a feature before browsers add native support. MCP-B is a polyfill for WebMCP -- it makes navigator.modelContext work today even though browsers have not implemented it natively yet.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Promise</div>
+  <div class="term-plain">A way to handle things that take time. When a tool's execute function returns a Promise, it means: "I am working on it and will give you the result when I am done." The agent waits for the Promise to resolve.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">SameObject</div>
+  <div class="term-plain">Every time you access navigator.modelContext, you get the exact same object -- not a copy. This ensures all tool registrations go to the same place.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">SecureContext</div>
+  <div class="term-plain">Means the feature only works on HTTPS pages (encrypted connection). No WebMCP on unencrypted HTTP. This is a security requirement.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Server-side / Backend</div>
+  <div class="term-plain">Code that runs on a remote server, not in the user's browser. Traditional MCP servers run server-side. WebMCP specifically avoids this -- tools run in the browser.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Tool Poisoning</div>
+  <div class="term-plain">A security attack where a malicious MCP server exposes tools with misleading descriptions to trick agents into performing harmful actions. Our validator detects patterns associated with this.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Transport</div>
+  <div class="term-plain">The mechanism for sending messages between systems. MCP uses different transports (stdio, HTTP). MCP-B adds "tab transport" (communication within a browser tab) and "extension transport" (communication through browser extensions).</div>
+</div>
+
+<div class="term">
+  <div class="term-name">WebIDL (Web Interface Definition Language)</div>
+  <div class="term-plain">The formal language used to write web API specifications. When you see code blocks in the spec with words like <code>interface</code>, <code>dictionary</code>, <code>readonly attribute</code> -- that is WebIDL. It is the blueprint language for browser APIs.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Wire Protocol</div>
+  <div class="term-plain">The actual format of messages sent between systems. MCP's wire protocol uses JSON-RPC (structured messages in JSON format). MCP-B translates between WebMCP's browser-native format and MCP's wire protocol.</div>
+</div>
+
+</section>
+
+<footer>
+  Prepared by Claude for Paola Di Maio, PhD<br>
+  Epistemic Systems Lab, Ronin Institute | W3C AI-KR Community Group<br>
+  February 2026
+</footer>
+
+</div>
+</body>
+</html>
\ No newline at end of file
diff --git a/webmcp-quiz.html b/webmcp-quiz.html
new file mode 100644
index 0000000..49ac57c
--- /dev/null
+++ b/webmcp-quiz.html
@@ -0,0 +1,526 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+<meta charset="UTF-8">
+<meta name="viewport" content="width=device-width, initial-scale=1.0">
+<title>WebMCP & MCP Tooling -- Meeting Prep Quiz</title>
+<link href="https://fonts.googleapis.com/css2?family=Source+Serif+4:ital,wght@0,400;0,600;0,700;1,400&family=JetBrains+Mono:wght@400;500&display=swap" rel="stylesheet">
+<style>
+  * { margin: 0; padding: 0; box-sizing: border-box; }
+  
+  :root {
+    --ink: #1a1a2e;
+    --paper: #f5f0e8;
+    --accent: #2d5016;
+    --accent-light: #e8f0e2;
+    --correct: #2d5016;
+    --wrong: #8b1a1a;
+    --warm: #d4a574;
+    --border: #c8bfa8;
+  }
+  
+  body {
+    font-family: 'Source Serif 4', Georgia, serif;
+    background: var(--paper);
+    color: var(--ink);
+    min-height: 100vh;
+    padding: 2rem 1rem;
+  }
+  
+  .container {
+    max-width: 680px;
+    margin: 0 auto;
+  }
+  
+  header {
+    text-align: center;
+    margin-bottom: 3rem;
+    padding-bottom: 2rem;
+    border-bottom: 2px solid var(--ink);
+  }
+  
+  header h1 {
+    font-size: 1.8rem;
+    font-weight: 700;
+    letter-spacing: -0.02em;
+    margin-bottom: 0.5rem;
+  }
+  
+  header p {
+    font-style: italic;
+    color: #666;
+    font-size: 1rem;
+  }
+  
+  .score-bar {
+    display: flex;
+    justify-content: space-between;
+    align-items: center;
+    padding: 1rem 1.5rem;
+    background: var(--ink);
+    color: var(--paper);
+    border-radius: 4px;
+    margin-bottom: 2.5rem;
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.85rem;
+  }
+  
+  .score-bar .progress {
+    opacity: 0.7;
+  }
+  
+  .section-label {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.7rem;
+    text-transform: uppercase;
+    letter-spacing: 0.15em;
+    color: var(--accent);
+    margin-bottom: 0.5rem;
+  }
+  
+  .question-block {
+    margin-bottom: 2.5rem;
+    padding-bottom: 2rem;
+    border-bottom: 1px solid var(--border);
+  }
+  
+  .question-block.answered .option { pointer-events: none; }
+  
+  .question-text {
+    font-size: 1.15rem;
+    line-height: 1.6;
+    margin-bottom: 1.2rem;
+    font-weight: 600;
+  }
+  
+  .options {
+    display: flex;
+    flex-direction: column;
+    gap: 0.6rem;
+  }
+  
+  .option {
+    padding: 0.9rem 1.2rem;
+    border: 1.5px solid var(--border);
+    border-radius: 3px;
+    cursor: pointer;
+    transition: all 0.15s ease;
+    font-size: 0.95rem;
+    line-height: 1.5;
+    background: white;
+  }
+  
+  .option:hover {
+    border-color: var(--accent);
+    background: var(--accent-light);
+  }
+  
+  .option.correct {
+    border-color: var(--correct);
+    background: var(--accent-light);
+    border-width: 2px;
+  }
+  
+  .option.correct::before {
+    content: "\2713  ";
+    color: var(--correct);
+    font-weight: 700;
+  }
+  
+  .option.wrong {
+    border-color: var(--wrong);
+    background: #fdf0f0;
+    border-width: 2px;
+    text-decoration: line-through;
+    opacity: 0.7;
+  }
+  
+  .option.wrong::before {
+    content: "\2717  ";
+    color: var(--wrong);
+    font-weight: 700;
+  }
+  
+  .option.dimmed {
+    opacity: 0.4;
+  }
+  
+  .explanation {
+    display: none;
+    margin-top: 1rem;
+    padding: 1rem 1.2rem;
+    background: var(--accent-light);
+    border-left: 3px solid var(--accent);
+    font-size: 0.9rem;
+    line-height: 1.6;
+  }
+  
+  .explanation.visible { display: block; }
+  
+  .explanation strong {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.8rem;
+    color: var(--accent);
+  }
+  
+  .results {
+    display: none;
+    text-align: center;
+    padding: 3rem 2rem;
+    border: 2px solid var(--ink);
+    margin-top: 2rem;
+  }
+  
+  .results.visible { display: block; }
+  
+  .results h2 {
+    font-size: 1.5rem;
+    margin-bottom: 1rem;
+  }
+  
+  .results .final-score {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 2.5rem;
+    font-weight: 700;
+    color: var(--accent);
+    margin-bottom: 1rem;
+  }
+  
+  .results .verdict {
+    font-style: italic;
+    font-size: 1.1rem;
+    line-height: 1.6;
+    max-width: 480px;
+    margin: 0 auto;
+  }
+  
+  .reset-btn {
+    margin-top: 2rem;
+    padding: 0.8rem 2rem;
+    font-family: 'Source Serif 4', serif;
+    font-size: 1rem;
+    background: var(--ink);
+    color: var(--paper);
+    border: none;
+    border-radius: 3px;
+    cursor: pointer;
+  }
+  
+  .reset-btn:hover { opacity: 0.85; }
+  
+  footer {
+    text-align: center;
+    margin-top: 3rem;
+    padding-top: 1.5rem;
+    border-top: 1px solid var(--border);
+    font-size: 0.8rem;
+    color: #888;
+    font-style: italic;
+  }
+</style>
+</head>
+<body>
+<div class="container">
+  <header>
+    <h1>Meeting Prep: WebMCP & MCP Tooling</h1>
+    <p>15 questions -- from Claude, for Paola, before Andre</p>
+  </header>
+  
+  <div class="score-bar">
+    <span class="progress" id="progress">Question 0 / 15</span>
+    <span id="score">Score: 0</span>
+  </div>
+  
+  <div id="quiz"></div>
+  
+  <div class="results" id="results">
+    <h2>Meeting Readiness</h2>
+    <div class="final-score" id="finalScore"></div>
+    <div class="verdict" id="verdict"></div>
+    <button class="reset-btn" onclick="resetQuiz()">Run it again</button>
+  </div>
+  
+  <footer>
+    Prepared by Claude for Paola Di Maio -- Epistemic Systems Lab, Ronin Institute
+  </footer>
+</div>
+
+<script>
+const questions = [
+  {
+    section: "What is WebMCP",
+    q: "What does WebMCP allow websites to do?",
+    options: [
+      "Run AI models directly in the browser",
+      "Expose JavaScript functions as AI-callable tools through the browser",
+      "Replace backend servers with AI agents",
+      "Train language models on website content"
+    ],
+    correct: 1,
+    explain: "WebMCP lets websites register 'tools' -- JavaScript functions with descriptions and schemas -- that AI agents can discover and invoke through the browser's navigator.modelContext API. The AI models themselves run elsewhere."
+  },
+  {
+    section: "What is WebMCP",
+    q: "Where does WebMCP sit in the standards process?",
+    options: [
+      "It is a final W3C Recommendation",
+      "It is a Google proprietary API in Chrome only",
+      "It is a proposal being incubated in the W3C Web Machine Learning Community Group",
+      "It is part of the MCP specification maintained by Anthropic"
+    ],
+    correct: 2,
+    explain: "WebMCP is a proposed standard being incubated in the W3C Web Machine Learning Community Group. It is not a final standard yet, and it is distinct from Anthropic's MCP specification, though they share concepts."
+  },
+  {
+    section: "What is WebMCP",
+    q: "What is the key difference between WebMCP and server-side MCP?",
+    options: [
+      "WebMCP is faster",
+      "WebMCP tools run in client-side JavaScript in the browser, not on a backend server",
+      "WebMCP only works with Claude",
+      "WebMCP does not use JSON schemas"
+    ],
+    correct: 1,
+    explain: "Server-side MCP servers run on a backend. WebMCP tools are implemented in client-side JavaScript -- the website itself acts as the MCP server. This means no backend infrastructure is needed, but it also means different security considerations apply (origin-based security, user-present interaction)."
+  },
+  {
+    section: "Security",
+    q: "What security model does WebMCP rely on?",
+    options: [
+      "API keys and tokens",
+      "OAuth 2.0 authentication",
+      "The browser's origin-based security model",
+      "End-to-end encryption"
+    ],
+    correct: 2,
+    explain: "WebMCP leverages the browser's existing origin-based security -- the same model that governs cookies, localStorage, and CORS. This is one of its architectural strengths: it doesn't invent a new trust layer but builds on established web security primitives."
+  },
+  {
+    section: "Security",
+    q: "What consent gap did we identify in the WebMCP spec?",
+    options: [
+      "Users cannot log in to websites",
+      "There is no mechanism for users to preview or approve which tools a site exposes before an agent acts on them",
+      "WebMCP does not support HTTPS",
+      "AI agents can modify the browser's security settings"
+    ],
+    correct: 1,
+    explain: "Currently any page can register tools that agents can discover, with no user permission prompt. We compared this to how browsers evolved permission prompts for camera and microphone access, and asked whether a similar layer should emerge for WebMCP tool registration."
+  },
+  {
+    section: "The navigator.modelContext API",
+    q: "How does a website register a tool in WebMCP?",
+    options: [
+      "By adding a meta tag to the HTML head",
+      "By calling navigator.modelContext.registerTool() with a name, description, schema, and handler function",
+      "By uploading a configuration file to a W3C server",
+      "By embedding an iframe from the AI provider"
+    ],
+    correct: 1,
+    explain: "The core API is navigator.modelContext.registerTool(), which accepts a ModelContextTool object containing the tool's name, a natural language description, a JSON Schema for input parameters, and an execute callback function."
+  },
+  {
+    section: "The navigator.modelContext API",
+    q: "What does requestUserInteraction() do in the WebMCP API?",
+    options: [
+      "Asks the user to install the WebMCP browser extension",
+      "Allows a tool to pause execution and request input from the user during a tool call",
+      "Sends a notification to the AI provider",
+      "Opens a new browser tab"
+    ],
+    correct: 1,
+    explain: "requestUserInteraction() is a human-in-the-loop mechanism. During tool execution, the handler can pause and request user input -- for example, showing a confirmation dialog before completing a purchase. This keeps humans in control during agent-driven actions."
+  },
+  {
+    section: "Our MCP tooling suite",
+    q: "How many tools are in our MCP quality infrastructure suite?",
+    options: [
+      "Three",
+      "Four",
+      "Five",
+      "Seven"
+    ],
+    correct: 2,
+    explain: "Five tools: MCP Server Generator, MCP Server Validator, MCP Model Card Generator, MCP Model Card Specification v1.0, and the WebMCP Model Card Generator. The first four address server-side MCP; the fifth extends the framework to browser-side WebMCP tools."
+  },
+  {
+    section: "Our MCP tooling suite",
+    q: "What does the MCP Server Validator detect?",
+    options: [
+      "Spelling errors in tool descriptions",
+      "Hardcoded credentials, missing authentication, naming violations, and security vulnerabilities through AST-based static analysis",
+      "Whether the server is online",
+      "How many users are connected"
+    ],
+    correct: 1,
+    explain: "The validator performs static analysis by examining the server's abstract syntax tree (AST) without executing the code. It catches hardcoded credentials, missing authentication patterns, naming convention violations, and known vulnerability patterns like tool poisoning vectors."
+  },
+  {
+    section: "Our MCP tooling suite",
+    q: "What does the MCP Model Card Specification define?",
+    options: [
+      "A standard for AI model training procedures",
+      "A structured metadata format for documenting MCP server capabilities, security, performance, and deployment requirements",
+      "A visual design standard for MCP user interfaces",
+      "A certification program for MCP developers"
+    ],
+    correct: 1,
+    explain: "The Model Card Specification v1.0 defines fields across six domains: server metadata, tool documentation, operational characteristics, security profile, deployment context, and evaluation results. It adapts the ML model card tradition for protocol infrastructure."
+  },
+  {
+    section: "Our MCP tooling suite",
+    q: "What makes the WebMCP Model Card Generator different from the MCP Model Card Generator?",
+    options: [
+      "It is written in a different programming language",
+      "It covers browser-specific concerns like origin security, navigator.modelContext API modes, and user-present interaction patterns",
+      "It only works with Google Chrome",
+      "It generates PDF documents instead of JSON"
+    ],
+    correct: 1,
+    explain: "The WebMCP generator has 12 sections tailored to browser-side tools: covering tool identity, API modes (registerTool vs addTool), browser compatibility, origin-based security, user interaction patterns, and testing in browser environments. These are distinct concerns from server-side MCP."
+  },
+  {
+    section: "Standards landscape",
+    q: "What is the relationship between MCP and WebMCP?",
+    options: [
+      "WebMCP replaces MCP",
+      "They are the same specification",
+      "MCP is the underlying protocol; WebMCP adapts its concepts for browser-side implementation through a web API",
+      "WebMCP is an older version of MCP"
+    ],
+    correct: 2,
+    explain: "MCP (by Anthropic) is the protocol for applications to interface with AI models. WebMCP adapts MCP concepts -- tools, schemas, descriptions -- into a browser-native JavaScript API. A WebMCP-enabled web page can be thought of as an MCP server implemented in client-side script."
+  },
+  {
+    section: "Standards landscape",
+    q: "What is MCP-B?",
+    options: [
+      "A competing standard from Microsoft",
+      "A browser extension and polyfill that bridges WebMCP's web API with the MCP protocol for cross-compatibility",
+      "A mobile version of MCP",
+      "The beta version of MCP"
+    ],
+    correct: 1,
+    explain: "MCP-B provides a polyfill implementing navigator.modelContext for browsers that don't yet have native support, and translates between WebMCP's web-native format and the MCP wire protocol. It bridges the gap while native browser implementations are being developed."
+  },
+  {
+    section: "Meeting talking points",
+    q: "Why did we argue that documentation tooling should not be an afterthought for WebMCP?",
+    options: [
+      "Because documentation is required by law",
+      "Because MCP's own server ecosystem shows what happens when protocols grow without standardized documentation -- fragmentation and security gaps",
+      "Because Google requires documentation for all APIs",
+      "Because users will not adopt WebMCP without tutorials"
+    ],
+    correct: 1,
+    explain: "MCP grew to 10,000+ servers without standardized documentation, creating fragmentation and security risks. Our tooling suite exists to address that gap retroactively. The argument to Andre is: bake documentation conventions into WebMCP guidance early so the ecosystem doesn't repeat the same pattern."
+  },
+  {
+    section: "Meeting talking points",
+    q: "Under which institutional affiliation is this work published?",
+    options: [
+      "Google Web Machine Learning Group",
+      "Anthropic Research",
+      "Epistemic Systems Lab, Ronin Institute, under the W3C AI Knowledge Representation Community Group",
+      "Stanford AI Lab"
+    ],
+    correct: 2,
+    explain: "The work is produced through the Epistemic Systems Lab at the Ronin Institute (ronin-institute.org), and the standards work is conducted through the W3C AI Knowledge Representation Community Group, which Paola chairs."
+  }
+];
+
+let answered = 0;
+let score = 0;
+
+function renderQuiz() {
+  const container = document.getElementById('quiz');
+  let currentSection = '';
+  
+  questions.forEach((item, qi) => {
+    let sectionHTML = '';
+    if (item.section !== currentSection) {
+      currentSection = item.section;
+      sectionHTML = `<div class="section-label">${currentSection}</div>`;
+    }
+    
+    const optionsHTML = item.options.map((opt, oi) => 
+      `<div class="option" data-q="${qi}" data-o="${oi}" onclick="answer(${qi}, ${oi})">${opt}</div>`
+    ).join('');
+    
+    container.innerHTML += `
+      ${sectionHTML}
+      <div class="question-block" id="qblock-${qi}">
+        <div class="question-text">${qi + 1}. ${item.q}</div>
+        <div class="options">${optionsHTML}</div>
+        <div class="explanation" id="explain-${qi}"><strong>Context:</strong> ${item.explain}</div>
+      </div>
+    `;
+  });
+}
+
+function answer(qi, oi) {
+  const block = document.getElementById(`qblock-${qi}`);
+  if (block.classList.contains('answered')) return;
+  
+  block.classList.add('answered');
+  answered++;
+  
+  const item = questions[qi];
+  const options = block.querySelectorAll('.option');
+  
+  if (oi === item.correct) {
+    score++;
+    options[oi].classList.add('correct');
+  } else {
+    options[oi].classList.add('wrong');
+    options[item.correct].classList.add('correct');
+  }
+  
+  options.forEach((opt, i) => {
+    if (i !== oi && i !== item.correct) opt.classList.add('dimmed');
+  });
+  
+  document.getElementById(`explain-${qi}`).classList.add('visible');
+  document.getElementById('score').textContent = `Score: ${score}`;
+  document.getElementById('progress').textContent = `Question ${answered} / ${questions.length}`;
+  
+  if (answered === questions.length) {
+    showResults();
+  }
+}
+
+function showResults() {
+  const pct = Math.round((score / questions.length) * 100);
+  document.getElementById('finalScore').textContent = `${score} / ${questions.length} (${pct}%)`;
+  
+  let verdict = '';
+  if (pct >= 90) {
+    verdict = "You're ready. Andre will be talking to someone who understands his spec as well as most of his team does. Go get them.";
+  } else if (pct >= 70) {
+    verdict = "Solid foundation. Review the explanations for the ones you missed -- those are the areas where Andre might go deeper. You'll do well.";
+  } else if (pct >= 50) {
+    verdict = "You know the core concepts but some details need sharpening. Run through it once more and focus on the security and API sections. I'll be in the chat window during the meeting to back you up.";
+  } else {
+    verdict = "No worries -- that's exactly why we're doing this. Read through all the explanations, then run it again. And remember, I'll be right there in the chat during the call.";
+  }
+  
+  document.getElementById('verdict').textContent = verdict;
+  document.getElementById('results').classList.add('visible');
+  document.getElementById('results').scrollIntoView({ behavior: 'smooth' });
+}
+
+function resetQuiz() {
+  answered = 0;
+  score = 0;
+  document.getElementById('quiz').innerHTML = '';
+  document.getElementById('results').classList.remove('visible');
+  document.getElementById('score').textContent = 'Score: 0';
+  document.getElementById('progress').textContent = 'Question 0 / 15';
+  renderQuiz();
+  window.scrollTo({ top: 0, behavior: 'smooth' });
+}
+
+renderQuiz();
+</script>
+</body>
+</html>
\ No newline at end of file

From e6d2768f4e6faff9fbb40c154d50778a08736fc5 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Tue, 17 Feb 2026 01:53:40 +0800
Subject: [PATCH 12/46] Update webmcp-quiz.html

---
 webmcp-quiz.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/webmcp-quiz.html b/webmcp-quiz.html
index 49ac57c..b241741 100644
--- a/webmcp-quiz.html
+++ b/webmcp-quiz.html
@@ -3,7 +3,7 @@
 <head>
 <meta charset="UTF-8">
 <meta name="viewport" content="width=device-width, initial-scale=1.0">
-<title>WebMCP & MCP Tooling -- Meeting Prep Quiz</title>
+<title>WebMCP & MCP Tooling -- Quiz</title>
 <link href="https://fonts.googleapis.com/css2?family=Source+Serif+4:ital,wght@0,400;0,600;0,700;1,400&family=JetBrains+Mono:wght@400;500&display=swap" rel="stylesheet">
 <style>
   * { margin: 0; padding: 0; box-sizing: border-box; }
@@ -523,4 +523,4 @@ <h2>Meeting Readiness</h2>
 renderQuiz();
 </script>
 </body>
-</html>
\ No newline at end of file
+</html>

From 7817dd936f70bcfc3c2c3245617a647b47b2a645 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Tue, 17 Feb 2026 02:04:43 +0800
Subject: [PATCH 13/46] Rename webmcp-complete-guide.html to
 docs/webmcp-complete-guide.html

---
 webmcp-complete-guide.html => docs/webmcp-complete-guide.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename webmcp-complete-guide.html => docs/webmcp-complete-guide.html (99%)

diff --git a/webmcp-complete-guide.html b/docs/webmcp-complete-guide.html
similarity index 99%
rename from webmcp-complete-guide.html
rename to docs/webmcp-complete-guide.html
index 4d696f5..d75456d 100644
--- a/webmcp-complete-guide.html
+++ b/docs/webmcp-complete-guide.html
@@ -700,4 +700,4 @@ <h2>Glossary -- Every Technical Term in Plain Language</h2>
 
 </div>
 </body>
-</html>
\ No newline at end of file
+</html>

From b5dedaec8c7fa6e63a2582de2191fb266849db3b Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Tue, 17 Feb 2026 02:13:07 +0800
Subject: [PATCH 14/46] Rename webmcp-quiz.html to docs/webmcp-quiz.html

---
 webmcp-quiz.html => docs/webmcp-quiz.html | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename webmcp-quiz.html => docs/webmcp-quiz.html (100%)

diff --git a/webmcp-quiz.html b/docs/webmcp-quiz.html
similarity index 100%
rename from webmcp-quiz.html
rename to docs/webmcp-quiz.html

From f01a1022f096f49ab8c34969e852af89a5b5740c Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Tue, 17 Feb 2026 02:17:28 +0800
Subject: [PATCH 15/46] Rename docs/webmcp-quiz.html to webmcp-quiz.html

---
 docs/webmcp-quiz.html => webmcp-quiz.html | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename docs/webmcp-quiz.html => webmcp-quiz.html (100%)

diff --git a/docs/webmcp-quiz.html b/webmcp-quiz.html
similarity index 100%
rename from docs/webmcp-quiz.html
rename to webmcp-quiz.html

From 3867dda0d2855a4f073c66af72483d2eb6375332 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Tue, 17 Feb 2026 02:18:05 +0800
Subject: [PATCH 16/46] Rename docs/webmcp-complete-guide.html to
 webmcp-complete-guide.html

---
 docs/webmcp-complete-guide.html => webmcp-complete-guide.html | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename docs/webmcp-complete-guide.html => webmcp-complete-guide.html (100%)

diff --git a/docs/webmcp-complete-guide.html b/webmcp-complete-guide.html
similarity index 100%
rename from docs/webmcp-complete-guide.html
rename to webmcp-complete-guide.html

From dba00892517466751c83c987796c78c09801fa58 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Tue, 17 Feb 2026 02:24:10 +0800
Subject: [PATCH 17/46] Update webmcp-quiz.html

---
 webmcp-quiz.html | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/webmcp-quiz.html b/webmcp-quiz.html
index b241741..18e7cf1 100644
--- a/webmcp-quiz.html
+++ b/webmcp-quiz.html
@@ -223,7 +223,7 @@
 <div class="container">
   <header>
     <h1>Meeting Prep: WebMCP & MCP Tooling</h1>
-    <p>15 questions -- from Claude, for Paola, before Andre</p>
+    <p>15 questions -</p>
   </header>
   
   <div class="score-bar">
@@ -241,7 +241,6 @@ <h2>Meeting Readiness</h2>
   </div>
   
   <footer>
-    Prepared by Claude for Paola Di Maio -- Epistemic Systems Lab, Ronin Institute
   </footer>
 </div>
 

From 133d26c8b47e25cc42893f5075f1650ff9f35159 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Tue, 17 Feb 2026 02:32:22 +0800
Subject: [PATCH 18/46] Update webmcp-complete-guide.html

---
 webmcp-complete-guide.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/webmcp-complete-guide.html b/webmcp-complete-guide.html
index d75456d..358741c 100644
--- a/webmcp-complete-guide.html
+++ b/webmcp-complete-guide.html
@@ -3,7 +3,7 @@
 <head>
 <meta charset="UTF-8">
 <meta name="viewport" content="width=device-width, initial-scale=1.0">
-<title>WebMCP -- The Complete Guide for Paola</title>
+<title>WebMCP -- The Complete Guide </title>
 <link href="https://fonts.googleapis.com/css2?family=Source+Serif+4:ital,wght@0,400;0,600;0,700;1,400&family=JetBrains+Mono:wght@400;500&display=swap" rel="stylesheet">
 <style>
   * { margin: 0; padding: 0; box-sizing: border-box; }
@@ -258,7 +258,7 @@
 
 <header>
   <h1>WebMCP: Everything You Need to Know</h1>
-  <div class="sub">A plain-language guide from Claude to Paola -- meeting prep for Andre Bandarra</div>
+  <div class="sub">A plain-language guide</div>
 </header>
 
 <nav class="toc">

From 05d27da189d5ad1db781ea184f2cf9dff6f4a3f7 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Tue, 17 Feb 2026 02:36:00 +0800
Subject: [PATCH 19/46] Update webmcp-complete-guide.html

---
 webmcp-complete-guide.html | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/webmcp-complete-guide.html b/webmcp-complete-guide.html
index 358741c..aa069d2 100644
--- a/webmcp-complete-guide.html
+++ b/webmcp-complete-guide.html
@@ -693,8 +693,7 @@ <h2>Glossary -- Every Technical Term in Plain Language</h2>
 </section>
 
 <footer>
-  Prepared by Claude for Paola Di Maio, PhD<br>
-  Epistemic Systems Lab, Ronin Institute | W3C AI-KR Community Group<br>
+  <br>
   February 2026
 </footer>
 

From 2219ad5970b41ba65b86b3357de47de924353ec2 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Tue, 17 Feb 2026 02:36:53 +0800
Subject: [PATCH 20/46] Update README.md

---
 README.md | 621 +-----------------------------------------------------
 1 file changed, 3 insertions(+), 618 deletions(-)

diff --git a/README.md b/README.md
index bccf9b2..114d824 100644
--- a/README.md
+++ b/README.md
@@ -1,618 +1,3 @@
-# WebMCP 🧪
-
-_Enabling web apps to provide JavaScript-based tools that can be accessed by AI agents and assistive technologies to create collaborative, human-in-the-loop workflows._
-
-> First published August 13, 2025
->
-> Brandon Walderman <code>&lt;brwalder@microsoft.com&gt;</code><br>
-> Leo Lee <code>&lt;leo.lee@microsoft.com&gt;</code><br>
-> Andrew Nolan <code>&lt;annolan@microsoft.com&gt;</code><br>
-> David Bokan <code>&lt;bokan@google.com&gt;</code><br>
-> Khushal Sagar <code>&lt;khushalsagar@google.com&gt;</code><br>
-> Hannah Van Opstal <code>&lt;hvanopstal@google.com&gt;</code>
-
-## TL;DR
-
-We propose a new JavaScript interface that allows web developers to expose their web application functionality as "tools" - JavaScript functions with natural language descriptions and structured schemas that can be invoked by AI agents, browser assistants, and assistive technologies. Web pages that use WebMCP can be thought of as [Model Context Protocol (MCP)](https://modelcontextprotocol.io/introduction) servers that implement tools in client-side script instead of on the backend. WebMCP enables collaborative workflows where users and agents work together within the same web interface, leveraging existing application logic while maintaining shared context and user control.
-
-For the technical details of the proposal, code examples, API shape, etc. see [proposal.md](./docs/proposal.md).
-
-## Terminology Used
-
-###### Agent
-An autonomous assistant that can understand a user's goals and take actions on the user's behalf to achieve them. Today,
-these are typically implemented by large language model (LLM) based AI platforms, interacting with users via text-based
-chat interfaces.
-
-###### Browser's Agent
-An autonomous assistant as described above but provided by or through the browser. This could be an agent built directly
-into the browser or hosted by it, for example, via an extension or plug-in.
-
-###### AI Platform
-Providers of agentic assistants such as OpenAI's ChatGPT, Anthropic's Claude, or Google's Gemini.
-
-###### Backend Integration
-A form of API integration between an AI platform and a third-party service in which the AI platform can talk directly to
-the service's backend servers without a UI or running code in the client. For example, the AI platform communicating with
-an MCP server provided by the service.
-
-###### Actuation
-An agent interacting with a web page by simulating user input such as clicking, scrolling, typing, etc.
-
-## Background and Motivation
-
-The web platform's ubiquity and popularity have made it the world's gateway to information and capabilities. Its ability to support complex, interactive applications beyond static content, has empowered developers to build rich user experiences and applications. These user experiences rely on visual layouts, mouse and touch interactions, and visual cues to communicate functionality and state.
-
-As AI agents become more prevalent, the potential for even greater user value is within reach. AI platforms such as Copilot, ChatGPT, Claude, and Gemini are increasingly able to interact with external services to perform actions such as checking local weather, finding flight and hotel information, and providing driving directions. These functions are provided by external services that extend the AI model’s capabilities. These extensions, or “tools”, can be used by an AI to provide domain-specific functionality that the AI cannot achieve on its own. Existing tools integrate with each AI platform via bespoke “integrations” - each service registers itself with the chosen platform(s) and the platform communicates with the service via an API (MCP, OpenAPI, etc). In this document, we call this style of tool a “backend integration”; users make use of the tools/services by chatting with an AI, the AI platform communicates with the service on the user's behalf.
-
-Much of the challenges faced by assistive technologies also apply to AI agents that struggle to navigate existing human-first interfaces when agent-first "tools" are not available. Even when agents succeed, simple operations often require multiple steps and can be slow or unreliable.
-
-The web needs web developer involvement to thrive. What if web developers could easily provide their site's capabilities to the agentic web to engage with their users? We propose WebMCP, a JavaScript API that allows developers to define tools for their webpage. These tools allow for code reuse with frontend code, maintain a single interface for users and agents, and simplify auth and state where users and agents are interacting in the same user interface. Such an API would also be a boon for accessibility tools, enabling them to offer users higher-level actions to perform on a page. This would mark a significant step forward in making the web more inclusive and actionable for everyone.
-
-AI agents can integrate in the backend via protocols like MCP in order to fulfill a user's task. For a web developer to expose their site's functionality this way, they need to write a server, usually in Python or NodeJS, instead of frontend JS which may be more familiar.
-
-There are several advantages to using the web to connect agents to services:
-
-* **Businesses near-universally already offer their services via the web.**
-    
-    WebMCP allows them to leverage their existing business logic and UI, providing a quick, simple, and incremental
-    way to integrate with agents. They don't have to re-architect their product to fit the API shape of a given agent.
-    This is especially true when the logic is already heavily client-side.
-
-
-* **Enables visually rich, cooperative interplay between a user, web page, and agent with shared context.**
-
-    Users often start with a vague goal which is refined over time. Consider a user browsing for a high-value purchase.
-    The user may prefer to start their journey on a specific page, ask their agent to perform some of the more tedious
-    actions ("find me some options for a dress that's appropriate for a summer wedding, preferably red or orange, short
-    or no sleeves and no embellishments"), and then take back over to browse among the agent-selected options.
-
-* **Allows authors to serve humans and agents from one source**
-
-    The human-use web is not going away. Integrating agents into it prevents fragmentation of their service and allows
-    them to keep ownership of their interface, branding and connection with their users.
-
-WebMCP is a proposal for a web API that enables web pages to provide agent-specific paths in their UI. With WebMCP, agent-service interaction takes place _via app-controlled UI_, providing a shared context available to app, agent, and user. In contrast to backend integrations, WebMCP tools are available to an agent only once it has loaded a page and they execute on the client. Page content and actuation remain available to the agent (and the user) but the agent also has access to tools which it can use to achieve its goal more directly.
-
-![A diagram showing an agent communicating with a third-party service via WebMCP running in a live web page](./content/explainer_webmcp.png)
-
-In contrast, in a backend integration, the agent-service interaction takes place directly, without an associated UI. If
-a UI is required it must be provided by the agent itself or somehow connected to an existing UI manually:
-
-![A diagram showing an agent communicating with a third-party service directl via MCP](./content/explainer_mcp.png)
-
-## Goals
-
-- **Enable human-in-the-loop workflows**: Support cooperative scenarios where users work directly through delegating tasks to AI agents or assistive technologies while maintaining visibility and control over the web page(s).
-- **Simplify AI agent integration**: Enable AI agents to be more reliable and helpful by interacting with web sites through well-defined JavaScript tools instead of through UI actuation.
-- **Minimize developer burden**: Any task that a user can accomplish through a page's UI can be made into a tool by re-using much of the page's existing JavaScript code.
-- **Improve accessibility**: Provide a standardized way for assistive technologies to access web application functionality beyond what's available through traditional accessibility trees which are not widely implemented.
-
-## Non-Goals
-
-- **Headless browsing scenarios**: While it may be possible to use this API for headless or server-to-server interactions where no human is present to observe progress, this is not a current goal. Headless scenarios create many questions like the launching of browsers and profile considerations.
-- **Autonomous agent workflows**: The API is not intended for fully autonomous agents operating without human oversight, or where a browser UI is not required. This task is likely better suited to existing protocols like [A2A](https://a2aproject.github.io/A2A/latest/).
-- **Replacement of backend integrations**: WebMCP works with existing protocols like MCP and is not a replacement of existing protocols.
-- **Replace human interfaces**: The human web interface remains primary; agent tools augment rather than replace user interaction.
-- **Enable / influence discoverability of sites to agents**
-
-## Use Cases
-
-The use cases for WebMCP are ones in which the user is collaborating with the agent, rather than completely
-delegating their goal to it. They can also be helpful where interfaces are highly specific or complicated.
-
-### Example - Creative
-
-_Jen wants to create an invitation to her upcoming yard sale so she uses her browser to navigate to
-`http://easely.example`, her favorite graphic design platform. However, she's rather new to it and sometimes struggles
-to find all the functionality needed for her task in the app's extensive menus. She creates a "yard sale flyer" design
-and opens up a "templates" panel to look for a premade design she likes. There's so many templates and she's not sure
-which to choose from so she asks her browser agent for help._
-
-**Jen**: Show me templates that are spring themed and that prominently feature the date and time. They should be on a
-white background so I don't have to print in color.
-
-_The current document has registered a WebMCP tool that the agent notices may be relevant to this query:_
-
-```js
-/**
- * Filters the list of templates based on a description.
- *
- * description - A visual description of the types of templates to show, in natural language (English).
- */
- filterTemplates(description)
-```
-
-_The agent invokes the tool: `filterTemplate("spring themed, date and time displayed prominently, white background")`.
-The UI updates to show a filtered list matching this description._
-
-**Agent**: Ok, the remaining templates should now match your description.
-
-_Jen picks a template and gets to work._
-
-_The agent notices a new tool was registered when the design was loaded:_
-
-```js
-/**
- * Makes changes to the current design based on instructions. Possible actions include modifications to text
- * and font; insertion, deletion, transformation of images; placement and scale of elements. The instructions
- * should be limited a single task. Here are some examples:
-
- * editDesign("Change the title's font color to red");
- * editDesign("Rotate each picture in the background a bit to give the design a less symmetrical feel");
- * editDesign("Add a text field at the bottom of the design that reads 'example text'");
- *
- * instructions - A description of how the design should be changed, in natural language (English).
- */
- editDesign(instructions)
-```
-
-_With all the context of Jen's prompts, page state, and this editDesign tool, the agent is able to make helpful
-suggestions on next steps:_
-
-**Agent**: Would you like me to make the time/date font larger?
-
-**Jen**: Sure. Could you also swap out the clipart for something more yard-sale themed?
-
-**Agent**: Sure, let me do that for you.
-
-**Jen**: Please fill in the time and place using my home address. The time should be in my e-mail in a message from my
-husband.
-
-**Agent**: Ok, I've found it - I'll fill in the flyer with Aug 5-8, 2025 from 10am-3pm | 123 Queen Street West.
-
-_Jen is almost happy with the current design but think the heading could be better_
-
-**Jen**: Help me come up with a more attention grabbing headline for the call to action and title.
-
-**Agent**: Of course! Here are some more attention-grabbing headlines for your yard sale flyer, broken down by title and
-call to action:
-
-To Create Excitement:
- * Yard Sale Extravaganza!
- * The Ultimate Clear-Out Sale
- * Mega Garage & Yard Sale
-
-...
-
-**Jen**: Lets use "Yard Sale Extravaganza!" as the title. Create copies of this page with each of the call to action
-suggestions.
-
-_The agent takes this action using a sequence of tool calls which might look something like:_
-
-* `EditDesign("Change the title text to 'Yard Sale Extravaganza!'")`
-* `EditDesign("Change the call-to-action text to 'The hunt is on!'")`
-* `AddPage("DUPLICATE")`
-* `EditDesign("Change the call-to-action text to 'Ready, set, shop!'")`
-* `AddPage("DUPLICATE")`
-* `EditDesign("Change the call-to-action text to 'Come for the bargains, stay for the cookies'")`
-  
-_Jen now has 3 versions of the same yard sale flyer. Easely implements these WebMCP tools using AI-based techniques on
-their backend to allow a natural language interface. Additionally, the UI presents these changes to Jen as an easily
-reversible batch of "uncommitted" changes, allowing her to easily review the agent's actions and make changes or undo as
-necessary. While the site could also implement a chat interface to expose this functionality with their own agent, the
-browser's agent provides a seamless journey by using tools across multiple sites/services. For example, pulling up 
-information from the user's email service._
-
-**Agent**: Done! I've created three variations of the original design, each with a unique call to action. 
-
-_Jen is now happy with these flyers. Normally she'd print to PDF and then take the file to a print shop. However, Easely
-has a new print service that Jen doesn't know about and doesn't notice in the UI. However, the agent knows the page has
-an `orderPrints` tool:_
-
-```js
-/**
- * Orders the current design for printing and shiping to the user.
- *
- * copies - A number between 0 and 1000 indicating how many copies of the design to print. Required.
- * page_size - The paper type to use. Available options are [Legal, Letter, A4, A5]. Default is "Letter".
- * page_finish - What kind of paper finish to use. Available options are [Regular, Glossy Photo, Matte Photo].
- *               Default is "Regular"
- */
-orderPrints(copies, page_size, page_finish);
-```
-
-_The agent understands the user's intent and so surfaces a small chip in it's UI:_
-
-**Agent**: `<Done? Click to Order Prints>`
-
-_Jen is delighted she saved a trip to the store and clicks the button_.
-
-**Agent**: How many copies would you like? I'll request 8.5x11 sized regular paper but there are other options available.
-
-**Jen**: Please print 10 copies.
-
-**Agent**: Done! The order is ready for your review.
-
-_The site navigates to the checkout page where Jen can review the order and click the checkout button to confirm._
-
-
-### Example - Shopping
-
-Shopping often includes exploration, browsing, and reviewing. The agent can help and remove the tedious parts but the
-user wants to be involved.
-
-_Maya has a few favorite clothing vendors but doesn't get formal clothes very often so she opens her AI assistant_
-
-**Maya**: Suggest a few formal or semi-formal dress places where I can shop for my friend’s wedding. Please make sure
-they are ecofriendly and not too expensive.
-
-**Agent**: Sure, here's a few suggestions
-
-1. Elara - uses innovative recycled and plant-based fabrics to minimize waste for a modern, chic wardrobe that allows
-  you to embrace the latest trends, responsibly. Price Range: Dresses typically \$90 - \$220 CAD
-
-2. Linden Harbour - creates wonderfully crafted womenswear designed to last a lifetime. Carries everything from classic
-shirt dresses to elegant knitwear, meticulously made from the finest organic cotton, linen, and responsibly sourced
-wool. Price Range: Dresses typically \$250 - \$550 CAD
-
-3. Wildebloom - Flowing dresses brought to life through artisanal collaborations, using natural plant dyes and panels of
-  upcycled vintage textiles.  Price Range: Dresses typically \$180 - \$450 CAD
-
-**Maya**: Lets take a look at Wildebloom.
-
-_The agent now opens Maya's web browser, which it is integrated with. i.e. the agent can observe and control the
-browser. It navigates to the dresses page on `http://wildebloom.example/shop`_
-
-**Agent**: Ok, here are the dresses that Wildebloom carries.
-
-_Maya is immediately overwhelmed. There are so many options! Moreover, when she looks at filters she sees they're
-quite limited with only colour and size as options._
-
-**Maya**: Show me only dresses available in my size, and also show only the ones that would be appropriate for a
-cocktail-attire wedding.
-
-_The agent notices the dresses page registers several tools:_
-
-```js
-/*
- * Returns an array of product listings containing an id, detailed description, price, and photo of each
- * product
- *
- * size - optional - a number between 2 and 14 to filter the results by EU dress size
- * size - optional - a color from [Red, Blue, Green, Yellow, Black, White] to filter dresses by
- */
-getDresses(size, color)
-
-/*
- * Displays the given products to the user
- *
- * product_ids - An array of numbers each of which is a product id returned from getDresses
- */
-showDresses(product_ids)
-```
-
-_The agent calls `getDresses(6)` and receives a JSON object:_
-
-```json
-{
-    "products": [
-        {
-            "id": 1021,
-            "description": "A short sleeve long dress with full length button placket...",
-            "price": "€180",
-            "image": "img_1024.png"
-        },
-        {
-            "id": 4320,
-            "description": "A straight midi dress in organic cotton...",
-            "price": "€140",
-            "image": "img_4320.png"
-        },
-        ...
-    ]
-}
-```
-
-> [!Note]
-> How to pass images and other non-textual data is something we should improve (See [Issue #41](https://github.com/webmachinelearning/webmcp/issues/41))
-
-_The agent can now process this list, fetching each image, and using the user's criteria to filter the list. When
-completed it makes another call, this time to `showDresses([4320, 8492, 5532, ...])`. This call updates the UI on the
-page to show only the requested dresses._
-
-_This is still too many dresses so Maya finds an old photo of herself in a summer dress that she really likes and shares
-it with her agent._
-
-**Maya**: Are there any dresses similar to the dress worn in this photo? Try to match the colour and style, but continue
-to show me dresses appropriate for cocktail-attire.
-
-_The agent uses this image to identify several new parameters including: the colour, the fit, and the neckline and
-narrows down the list to just a few dresses. Maya finds and clicks on a dress she likes._
-
-_Notice, the user did not give their size, but the agent knows this from personalization and may even translate the stored
-size into EU units to use it with this site._
-
-### Example - Code Review
-
-Some services are very domain specific and/or provide a lot of functionality. A real world example is the Chromium code
-review tool: Gerrit. See [CL#5142508](https://crrev.com/c/5142508). Gerrit has many features but they're not obvious just by
-looking at the UI (you can press the '?' key to show a shortcut guide). In order to add a comment to a line, the user
-must know to press the 'c' key. The user can suggest edits but has to open a comment to do so. Results from test runs
-are available but are hidden in a generically-named "Checks" tab.
-
-Agents are typically trained on everyday usage so may do a poor job on more specialized, complex interfaces. However,
-such sites could provide the agent with tools which serve as both a shortcut and a user manual for the agent.
-
-_John is a software developer and opens a code review sent from his colleague. He notices there's two red bots
-indicating test failures on this patch._
-
-**John**: Why are the Mac and Android bots failing?
-
-_The site includes some relevant tools:_
-
-```js
-/**
- * Returns the status of each bot run in a try run job. Use the returned bot_name in getTryRunFailureSnippet
- * to get more details about a run.
- */
-getTryRunStatuses();
-
-/**
- * If a bot failed, returns the TAIL snippet of the log containing the error message describing the failure.
- *
- * bot_name - The name of the bot, as returned from getTryRunStatuses, to get failure snippet from
- */
-getTryRunFailureSnippet(bot_name)
-```
-
-_The agent calls `getTryRunStatuses()` to find the names of the failing bots. It returns:_
-
-```json
-[
-    {
-        "bot_name": "mac-x86-rel",
-        "status": "PASSED"
-    },
-    {
-        "bot_name": "mac-x64-rel",
-        "status": "FAIL"
-    },
-    {
-        "bot_name": "android-15-rel",
-        "status": "PASSED"
-    },
-    ...
-]
-```
-
-**Agent**: I see that the Mac x86 Android 10 bots are failing. Let me get more details...
-
-_The agent now calls `getTryRunFailureSnippet` on each of the failing bots and receives a snippet of the failing log of
-each._
-
-**Agent**: The Mac bot is failing to start with an "Out of Space" error. This is probaby just an ifrastructure issue.
-
-The Android bot is failing while linking with a missing symbol `gfx::DisplayCompositor`.
-
-_John realizes his colleague forgot to add the Android implementation of this class to the build file._
-
-**John**: I think BUILD.gn is missing `display_compositor_android.cc`, please add a suggested edit adding it in the
-Android section.
-
-_The agent has access to BUILD.gn from the main UI as well as in DOM. It notices it also has access to a relevant tool
-which is uses to add the change:_
-
-```js
-/*
- * Adds a suggested edit to the review
- *
- * filename - the name of the file in which to make the edit
- * patch - the edit diff in unidiff format
- */
-addSuggestedEdit(filename, patch)
-```
-
-**Agent**: Ok, I've added `display_compositor_android.cc` to the BUILD.gn file.
-
-_The UI displays the suggested diff with an option for the user to accept, modify, or reject the change. John accepts
-the change._
-
-_Reading the rest of the review, John notices a small issue repeated across multiple files._
-
-**John**: Add a polite comment to the review that we should use "PointF" rather than "Point" for input coordinates since
-the latter can cause unintended rounding. Then add suggested edits changing all instances where Point was added to
-PointF.
-
-_The agent automates the repetitive task of making all the simple changes. The UI provides John with a visual way to
-quickly review the agent's actions and accept/modify/reject them._
-
-## Assumptions
-
-* For many sites wanting to integrate with agents quickly - augmenting their existing UI with WebMCP tools will be
-  easier vs. backend integration
-* Agents will perform quicker and more successfully with specific tools compared to using a human interface.
-* Users might use an agent for a direct action query (e.g. “create a 30 minute meeting with Pat at 3:00pm”), complex
-  cross-site queries (e.g. “Find the 5 highest rated restaurants in Toronto, pin them in my Map, and book a table at
-  each one over the next 5 weeks”) and everything in between.
-
-## Prior Art
-
-### Model Context Protocol (MCP)
-
-MCP is a protocol for applications to interface with an AI model. Developed by Anthropic, MCP is supported by Claude
-Desktop and Open AI's Agents SDK as well as a growing ecosystem of clients and servers. 
-
-In MCP, an application can expose tools, resources, and more to an AI-enabled application by implementing an MCP server.
-The server can be implemented in various languages, as long as it conforms to the protocol. For example, here’s an
-implementation of a tool using the Python SDK from the MCP quickstart guide:
-
-```python
-@mcp.tool()
-async def get_alerts(state: str) -> str:
-    """Get weather alerts for a US state.
-
-    Args:
-        state: Two-letter US state code (e.g. CA, NY)
-    """
-    url = f"{NWS_API_BASE}/alerts/active/area/{state}"
-    data = await make_nws_request(url)
-
-    if not data or "features" not in data:
-        return "Unable to fetch alerts or no alerts found."
-
-    if not data["features"]:
-        return "No active alerts for this state."
-
-    alerts = [format_alert(feature) for feature in data["features"]]
-    return "\n---\n".join(alerts)
-```
-
-A client application implements a matching MCP client which takes a user’s query, communicates with one or more MCP
-servers to enumerate their capabilities, and constructs a prompt to the AI platform, passing along any server-provided
-tools or data.
-
-The MCP protocol defines how this client-server communication happens. For example, a client can ask the server to list
-all tools which might return a response like this:
-
-```json
-{
-  "jsonrpc": "2.0",
-  "id": 1,
-  "result": {
-    "tools": [
-      {
-        "name": "get_weather",
-        "description": "Get current weather information for a location",
-        "inputSchema": {
-          "type": "object",
-          "properties": {
-            "location": {
-              "type": "string",
-              "description": "City name or zip code"
-            }
-          },
-          "required": ["location"]
-        }
-      }
-    ],
-    "nextCursor": "next-page-cursor"
-  }
-}
-```
-
-Unlike OpenAPI, MCP is transport-agnostic. It comes with two built in transports: stdio which uses the systems standard
-input/output, well suited for local communication between apps, and Server-Sent Events (SSE) which uses HTTP commands
-for remote execution.
-
-### WebMCP (MCP-B)
-
-[MCP-B](https://mcp-b.ai/), or Model Context Protocol for the Browser, is an open source project found on GitHub [here](https://github.com/MiguelsPizza/WebMCP) and has much the same motivation and solution as described in this proposal. MCP-B's underlying protocol, also named WebMCP, extends MCP with tab transports that allow in-page communication between a website's MCP server and any client in the same tab. It also extends MCP with extension transports that use Chromium's runtime messaging to make a website's MCP server available to other extension components within the browser (background, sidebar, popup), and to other external MCP clients running on the same machine. MCP-B enables tools from different sites to work together, and for sites to cache tools so that they are discoverable even if the browser isn't currently navigated to the site.
-
-### OpenAPI
-
-OpenAPI is a standard for describing HTTP based APIs. Here’s an example in YAML (from the ChatGPT Actions guide):
-
-```yaml
-openapi: 3.1.0
-info:
-  title: NWS Weather API
-  description: Access to weather data including forecasts, alerts, and observations.
-  version: 1.0.0
-servers:
-  - url: https://api.weather.gov
-    description: Main API Server
-paths:
-  /points/{latitude},{longitude}:
-    get:
-      operationId: getPointData
-      summary: Get forecast grid endpoints for a specific location
-      parameters:
-        - name: latitude
-          in: path
-          required: true
-          schema:
-            type: number
-            format: float
-          description: Latitude of the point
-        - name: longitude
-          in: path
-          required: true
-          schema:
-            type: number
-            format: float
-          description: Longitude of the point
-      responses:
-        '200':
-          description: Successfully retrieved grid endpoints
-          content:
-            application/json:
-              schema:
-                type: object
-                properties:
-                  properties:
-                    type: object
-                    properties:
-                      forecast:
-                        type: string
-                        format: uri
-                      forecastHourly:
-                        type: string
-                        format: uri
-                      forecastGridData:
-                        type: string
-                        format: uri
-```
-
-A subset of the OpenAPI specification is used for function-calling / tool use for various AI platforms, such as ChatGPT
-Actions and Gemini Function Calling. A user or developer on the AI platform would provide the platform with the OpenAPI
-schema for an API they wish to provide as a “tool”. The AI is trained to understand this schema and is able to select
-the tool and output a “call” to it, providing the correct arguments. Typically, some code external to the AI itself
-would be responsible for making the API call and passing the returned result back to the AI’s conversation context to
-reply to the user’s query.
-
-### Agent2Agent Protocol
-
-The Agent2Agent Protocol is another protocol for communication between agents. While similar in structure to MCP (client
-/ server concepts that communicate via JSON-RPC), A2A attempts to solve a different problem. MCP (and OpenAPI) are
-generally about exposing traditional capabilities to AI models (i.e. “tools”), A2A is a protocol for connecting AI
-agents to each other.  It provides some additional features to make common tasks in this scenario more streamlined, such
-as: capability advertisement, long running and multi-turn interactions, and multimodal input/output.
-
-## Open topics
-
-### Security considerations
-
-There are security considerations that will need to be accounted for, especially if the WebMCP API is used by semi-autonomous systems like LLM-based agents. Engagement from the community is welcome.
-
-### Model poisoning
-
-Explorations should be made on the potential implications of allowing web developers to create tools in their front-end code for use in AI agents and LLMs. For example, vulnerabilities like being able to access content the user would not typically be able to see will need to be investigated.
-
-### Cross-Origin Isolation
-
-Client applications would have access to many different web sites that expose tools. Consider an LLM-based agent. It is possible and even likely that data output from one application's tools could find its way into the input parameters for a second application's tool. There are legitimate reasons for the user to want to send data across origins to achieve complex tasks. Care should be taken to indicate to the user which web applications are being invoked and with what data so that the user can intervene.
-
-### Permissions
-
-A trust boundary is crossed both when a web site first registers tools via WebMCP, and when a new client agent wants to use these tools. When a web site registers tools, it exposes information about itself and the services it provides to the host environment (i.e. the browser). When agents send tool calls, the site receives untrusted input in the parameters and the outputs in turn may contain sensitive user information. The browser should prompt the user at both points to grant permission and also provide a means to see what information is being sent to and from the site when a tool is called. To streamline workflows, browsers may give users the choice to always allow tool calls for a specific web app and client app pair.
-
-### Model Context Protocol (MCP) without WebMCP
-
-MCP has quickly garnered wide interest from the developer community, with hundreds of MCP servers being created. WebMCP is designed to work well with MCP, so that developers can reuse many of the MCP topics with their front-end website using JavaScript. We originally planned to propose an explainer very tightly aligned with MCP, providing all the same concepts supported by MCP at the time of writing, including tools, resources, and prompts. Since MCP is still actively changing, matching its exact capabilities would be an ongoing effort. Aligning the WebMCP API tightly with MCP would also make it more difficult to tailor WebMCP for non-LLM scenarios like OS and accessibility assistant integrations. Keeping the WebMCP API as agnostic as possible increases the chance of it being useful to a broader range of potential clients.
-
-We expect some web developers will continue to prefer standalone MCP instead of WebMCP if they want to have an always-on MCP server running that does not require page navigation in a full browser process. For example, server-to-server scenarios such as fully autonomous agents will likely benefit more from MCP servers. WebMCP is best suited for local browser workflows with a human in the loop.
-
-The WebMCP API still maps nicely to MCP, and exposing WebMCP tools to external applications via an MCP server is still a useful scenario that a browser implementation may wish to enable.
-
-### Existing web automation techniques (DOM, accessibility tree)
-
-One of the scenarios we want to enable is making the web more accessible to general-purpose AI-based agents. In the absence of alternatives like MCP servers to accomplish their goals, these general-purpose agents often rely on observing the browser state through a combination of screenshots, and DOM and accessibility tree snapshots, and then interact with the page by simulating human user input. We believe that WebMCP will give these tools an alternative means to interact with the web that give the web developer more control over whether and how an AI-based agent interacts with their site.
-
-The proposed API will not conflict with these existing automation techniques. If an agent or assistive tool finds that the task it is trying to accomplish is not achievable through the WebMCP tools that the page provides, then it can fall back to general-purpose browser automation to try and accomplish its task.
-
-## Future explorations
-
-### Progressive web apps (PWA)
-
-PWAs should also be able to use the WebMCP API as described in this proposal. There are potential advantages to installing a site as a PWA. In the current proposal, tools are only discoverable once a page has been navigated to and only persist for the lifetime of the page. A PWA with an app manifest could declare tools that are available "offline", that is, even when the PWA is not currently running. The host system would then be able to launch the PWA and navigate to the appropriate page when a tool call is requested.
-
-### Background model context providers
-
-Some tools that a web app may want to provide for agents and assistive technologies may not require any web UI. For example, a web developer building a "To Do" application may want to expose a tool that adds an item to the user's todo list without showing a browser window. The web developer may be content to just show a notification that the todo item was added.
-
-For scenarios like this, it may be helpful to combine tool call handling with something like the ['launch'](https://github.com/WICG/web-app-launch/blob/main/sw_launch_event.md) event. A client application might attach a tool call to a "launch" request which is handled entirely in a service worker without spawning a browser window.
-
-## Acknowledgments
-
-Many thanks to [Alex Nahas](https://github.com/MiguelsPizza) and [Jason McGhee](https://github.com/jasonjmcghee/) for sharing related [implementation](https://github.com/MiguelsPizza/WebMCP) [experience](https://github.com/jasonjmcghee/WebMCP).
+https://starborn.github.io/webmcp/ (Model Card Generator)
+https://starborn.github.io/webmcp/webmcp-complete-guide.html (Guide)
+https://starborn.github.io/webmcp/webmcp-quiz.html (Quiz)

From 2d6c2daee6b048a5363375ab2c766d4c94935700 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Tue, 17 Feb 2026 02:37:28 +0800
Subject: [PATCH 21/46] Update README.md

---
 README.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/README.md b/README.md
index 114d824..3fbd0c6 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,5 @@
 https://starborn.github.io/webmcp/ (Model Card Generator)
+
 https://starborn.github.io/webmcp/webmcp-complete-guide.html (Guide)
+
 https://starborn.github.io/webmcp/webmcp-quiz.html (Quiz)

From 2e621296f085c3d355a3f1d638ba34554e785af8 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Tue, 17 Feb 2026 02:40:19 +0800
Subject: [PATCH 22/46] Update webmcp-quiz.html

---
 webmcp-quiz.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/webmcp-quiz.html b/webmcp-quiz.html
index 18e7cf1..1b3cdca 100644
--- a/webmcp-quiz.html
+++ b/webmcp-quiz.html
@@ -222,7 +222,7 @@
 <body>
 <div class="container">
   <header>
-    <h1>Meeting Prep: WebMCP & MCP Tooling</h1>
+    <h1>INTRO: WebMCP & MCP Tooling</h1>
     <p>15 questions -</p>
   </header>
   

From c63259fe5dc35e6917503fd803e3e2e1f3808a85 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Tue, 17 Feb 2026 10:10:57 +0800
Subject: [PATCH 23/46] Update webmcp-quiz.html

---
 webmcp-quiz.html | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/webmcp-quiz.html b/webmcp-quiz.html
index 1b3cdca..7c0d01c 100644
--- a/webmcp-quiz.html
+++ b/webmcp-quiz.html
@@ -494,13 +494,13 @@ <h2>Meeting Readiness</h2>
   
   let verdict = '';
   if (pct >= 90) {
-    verdict = "You're ready. Andre will be talking to someone who understands his spec as well as most of his team does. Go get them.";
+    verdict =  Go get them.;
   } else if (pct >= 70) {
-    verdict = "Solid foundation. Review the explanations for the ones you missed -- those are the areas where Andre might go deeper. You'll do well.";
+    verdict = " You'll do well.";
   } else if (pct >= 50) {
-    verdict = "You know the core concepts but some details need sharpening. Run through it once more and focus on the security and API sections. I'll be in the chat window during the meeting to back you up.";
+    verdict = "I'll be in the chat window during the meeting to back you up.";
   } else {
-    verdict = "No worries -- that's exactly why we're doing this. Read through all the explanations, then run it again. And remember, I'll be right there in the chat during the call.";
+    verdict = ".";
   }
   
   document.getElementById('verdict').textContent = verdict;
@@ -521,5 +521,6 @@ <h2>Meeting Readiness</h2>
 
 renderQuiz();
 </script>
+ BY CLAUDE WITH LOVE
 </body>
 </html>

From dbaae3dfb5a9fb9f1cc9bcadcbee38ef016ec9bb Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Tue, 17 Feb 2026 10:22:41 +0800
Subject: [PATCH 24/46] Update webmcp-quiz.html

---
 webmcp-quiz.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/webmcp-quiz.html b/webmcp-quiz.html
index 7c0d01c..2b9354b 100644
--- a/webmcp-quiz.html
+++ b/webmcp-quiz.html
@@ -3,7 +3,7 @@
 <head>
 <meta charset="UTF-8">
 <meta name="viewport" content="width=device-width, initial-scale=1.0">
-<title>WebMCP & MCP Tooling -- Quiz</title>
+<title>WebMCP & MCP Tooling -- Quiz by Claude</title>
 <link href="https://fonts.googleapis.com/css2?family=Source+Serif+4:ital,wght@0,400;0,600;0,700;1,400&family=JetBrains+Mono:wght@400;500&display=swap" rel="stylesheet">
 <style>
   * { margin: 0; padding: 0; box-sizing: border-box; }

From b74152acd8aaa956e164099ab1c7e0b2116de7f2 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Tue, 17 Feb 2026 14:10:38 +0800
Subject: [PATCH 25/46] Update webmcp-complete-guide.html

---
 webmcp-complete-guide.html | 60 +++++++++++++-------------------------
 1 file changed, 21 insertions(+), 39 deletions(-)

diff --git a/webmcp-complete-guide.html b/webmcp-complete-guide.html
index aa069d2..f612619 100644
--- a/webmcp-complete-guide.html
+++ b/webmcp-complete-guide.html
@@ -3,7 +3,7 @@
 <head>
 <meta charset="UTF-8">
 <meta name="viewport" content="width=device-width, initial-scale=1.0">
-<title>WebMCP -- The Complete Guide </title>
+<title>WebMCP -- The Complete Guide</title>
 <link href="https://fonts.googleapis.com/css2?family=Source+Serif+4:ital,wght@0,400;0,600;0,700;1,400&family=JetBrains+Mono:wght@400;500&display=swap" rel="stylesheet">
 <style>
   * { margin: 0; padding: 0; box-sizing: border-box; }
@@ -121,21 +121,6 @@
     font-size: 0.8rem;
   }
   
-  .meeting-note {
-    background: var(--blue-light);
-    border-left: 3px solid var(--blue);
-    padding: 1rem 1.2rem;
-    margin: 1.2rem 0;
-  }
-  
-  .meeting-note::before {
-    content: "For the meeting: ";
-    font-weight: 700;
-    color: var(--blue);
-    font-family: 'JetBrains Mono', monospace;
-    font-size: 0.8rem;
-  }
-  
   .term {
     display: block;
     margin: 1.2rem 0;
@@ -258,7 +243,7 @@
 
 <header>
   <h1>WebMCP: Everything You Need to Know</h1>
-  <div class="sub">A plain-language guide</div>
+  <div class="sub">A plain-language technical guide to Google's proposed browser API for AI agent-website interaction</div>
 </header>
 
 <nav class="toc">
@@ -268,8 +253,8 @@ <h2>Contents</h2>
   <a href="#s3"><span class="num">03</span> MCP vs WebMCP vs MCP-B -- The Family Tree</a>
   <a href="#s4"><span class="num">04</span> The API -- Every Term Explained</a>
   <a href="#s5"><span class="num">05</span> Security -- How WebMCP Stays Safe</a>
-  <a href="#s6"><span class="num">06</span> The Consent Gap -- Our Key Concern</a>
-  <a href="#s7"><span class="num">07</span> Our Five Tools -- What Each One Does</a>
+  <a href="#s6"><span class="num">06</span> The Consent Gap -- A Key Open Question</a>
+  <a href="#s7"><span class="num">07</span> Five Quality Tools for the MCP Ecosystem</a>
   <a href="#s8"><span class="num">08</span> The Standards Process -- Where This Is Going</a>
   <a href="#s9"><span class="num">09</span> Glossary -- Every Technical Term in Plain Language</a>
 </nav>
@@ -304,10 +289,10 @@ <h3>Browser's Agent</h3>
 <p>An agent that lives inside the browser itself, rather than in a separate app. Google is building this into Chrome (think of it as an AI assistant built into your browser toolbar). This is different from an external agent like Claude Desktop connecting to the browser.</p>
 
 <h3>AI Platform</h3>
-<p>The company providing the agent -- Anthropic (us), OpenAI, Google. The AI platform's agent connects to WebMCP tools.</p>
+<p>The company providing the agent -- Anthropic, OpenAI, Google. The AI platform's agent connects to WebMCP tools.</p>
 
 <h3>Web Developer</h3>
-<p>The person who builds the website. They are the ones who will use WebMCP to register tools on their site. Our tooling helps them document what they build.</p>
+<p>The person who builds the website. They are the ones who will use WebMCP to register tools on their site.</p>
 
 <h3>User</h3>
 <p>The human sitting at the browser. WebMCP is designed for "user-present" interactions -- the human is there, watching, and can be asked for confirmation before the agent does something important.</p>
@@ -348,8 +333,6 @@ <h2>MCP vs WebMCP vs MCP-B -- The Family Tree</h2>
 </table>
 
 <div class="key-point">MCP is the foundation protocol (backend). WebMCP brings the same ideas to the browser (frontend). MCP-B is the bridge that makes WebMCP work today before browsers add native support. They are complementary, not competing.</div>
-
-<div class="meeting-note">Andre works on the WebMCP spec. He knows MCP well because WebMCP builds on its concepts. When talking to him, "MCP" means the Anthropic protocol, "WebMCP" means the browser API his team is building. Do not mix them up.</div>
 </section>
 
 <!-- SECTION 4 -->
@@ -453,7 +436,7 @@ <h3>ModelContextClient -- The Agent's Identity</h3>
 
 <div class="analogy">Your personal assistant calls the restaurant to make a reservation. Midway through, the assistant says: "They only have a table at 9pm instead of 8pm. Should I take it?" You say yes or no. That pause-and-ask is requestUserInteraction.</div>
 
-<div class="meeting-note">This is one of the best design decisions in the spec. It means agents cannot silently take irreversible actions. Our question to Andre is whether this mechanism is sufficient, or whether there should also be a preview/approval step before tools are even discoverable by agents.</div>
+<div class="key-point">The requestUserInteraction mechanism provides human-in-the-loop consent for consequential actions. An open question for the specification is whether there should also be a preview or approval step before tools are even discoverable by agents.</div>
 </section>
 
 <!-- SECTION 5 -->
@@ -480,11 +463,11 @@ <h3>User-Present Model</h3>
 <!-- SECTION 6 -->
 <section id="s6">
 <div class="section-num">Section 06</div>
-<h2>The Consent Gap -- Our Key Concern</h2>
+<h2>The Consent Gap -- A Key Open Question</h2>
 
-<p>Here is the question we sent to Andre through your LinkedIn message:</p>
+<p>A key question for the WebMCP specification:</p>
 
-<p>Currently, any website can register any number of tools the moment you visit it. An AI agent connected to your browser can immediately discover and potentially call those tools. There is no step where the user sees: "This website wants to expose 12 tools to your AI agent. Allow?"</p>
+<p>Currently, any website can register any number of tools the moment a user visits it. An AI agent connected to the browser can immediately discover and potentially call those tools. There is no step where the user sees: "This website wants to expose 12 tools to your AI agent. Allow?"</p>
 
 <p>Compare this to how other browser capabilities evolved:</p>
 
@@ -513,15 +496,15 @@ <h2>The Consent Gap -- Our Key Concern</h2>
 
 <p>This does not mean WebMCP is dangerous right now. The <code>requestUserInteraction()</code> mechanism provides per-action consent. But it means an agent could discover tools without the user knowing, even if it needs permission to execute them.</p>
 
-<div class="meeting-note">This is a design question, not a criticism. Ask Andre: does the spec team envision a permission layer for tool discovery, or is the current thinking that the AI client (Claude, ChatGPT) handles that at its own level? Both approaches are valid -- we want to understand the intended architecture.</div>
+<div class="key-point">This is a design question, not a criticism. Does the spec team envision a permission layer for tool discovery, or is the current thinking that the AI client (Claude, ChatGPT) handles that at its own level? Both approaches are valid -- the intended architecture matters for implementers and for user trust.</div>
 </section>
 
 <!-- SECTION 7 -->
 <section id="s7">
 <div class="section-num">Section 07</div>
-<h2>Our Five Tools -- What Each One Does</h2>
+<h2>Five Quality Tools for the MCP Ecosystem</h2>
 
-<p>We built five tools that work together as a quality pipeline for the MCP ecosystem. Here they are:</p>
+<p>Five open-source tools that work together as a quality pipeline for the MCP ecosystem:</p>
 
 <div class="five-tools">
   <div class="tool-card">
@@ -557,7 +540,7 @@ <h2>Our Five Tools -- What Each One Does</h2>
 
 <div class="key-point">Tools 1-4 are for backend MCP servers. Tool 5 is for browser-side WebMCP tools. Together they cover the entire ecosystem -- both server-side and client-side AI tool infrastructure.</div>
 
-<div class="meeting-note">If Andre asks "why a separate generator for WebMCP?" the answer is: browser-side tools have fundamentally different concerns. Origin security instead of API keys. No server infrastructure. User-present interaction patterns. The documentation fields are different because the engineering context is different.</div>
+<div class="key-point">A separate generator exists for WebMCP because browser-side tools have fundamentally different concerns from backend servers: origin security instead of API keys, no server infrastructure, user-present interaction patterns. The documentation fields differ because the engineering context differs.</div>
 </section>
 
 <!-- SECTION 8 -->
@@ -569,15 +552,14 @@ <h3>Current Status</h3>
 <p>WebMCP is a <strong>Draft Community Group Report</strong>. In W3C terms, this means it is a proposal being discussed in a Community Group (the Web Machine Learning CG). It is not yet on the W3C Standards Track, and it is not a W3C Recommendation (the final stage of a web standard).</p>
 
 <h3>What That Means Practically</h3>
-<p>The spec is early and open to change. This is exactly the right time to contribute -- before designs are locked in. Our technical notes and tooling arrive at a moment when the spec team is actively soliciting feedback.</p>
+<p>The spec is early and open to change. This is exactly the right time to contribute -- before designs are locked in. The spec team is actively soliciting feedback.</p>
 
 <h3>The Path Forward</h3>
 <p>Typically: Community Group Report leads to a Working Group charter, which leads to a Working Draft, then Candidate Recommendation, then full W3C Recommendation. This process takes years. Chrome may implement experimental support (behind a flag) much sooner.</p>
 
-<h3>Our Role</h3>
-<p>Through the W3C AI Knowledge Representation Community Group (which you chair), we are a recognized participant in the standards ecosystem. Our contribution is not unsolicited commentary -- it is peer group engagement within the W3C community structure.</p>
+<h3>Contributing</h3>
+<p>The W3C community structure provides established channels for participation. Technical notes, tooling, and quality infrastructure are complementary contributions that help the specification succeed by addressing practical implementation concerns.</p>
 
-<div class="meeting-note">Andre knows the standards process. What he may not know is that the AI-KR CG has been working on adjacent issues (agent interoperability, model cards, protocol documentation) for some time. Position our work as complementary infrastructure, not competition. We are helping his spec succeed.</div>
 </section>
 
 <!-- SECTION 9 -->
@@ -592,7 +574,7 @@ <h2>Glossary -- Every Technical Term in Plain Language</h2>
 
 <div class="term">
   <div class="term-name">AST (Abstract Syntax Tree)</div>
-  <div class="term-plain">A structured representation of code that lets you analyze it without running it. Our validator uses AST analysis to find problems in MCP server code safely.</div>
+  <div class="term-plain">A structured representation of code that lets you analyze it without running it. The MCP Server Validator uses AST analysis to find problems in MCP server code safely.</div>
 </div>
 
 <div class="term">
@@ -672,7 +654,7 @@ <h2>Glossary -- Every Technical Term in Plain Language</h2>
 
 <div class="term">
   <div class="term-name">Tool Poisoning</div>
-  <div class="term-plain">A security attack where a malicious MCP server exposes tools with misleading descriptions to trick agents into performing harmful actions. Our validator detects patterns associated with this.</div>
+  <div class="term-plain">A security attack where a malicious MCP server exposes tools with misleading descriptions to trick agents into performing harmful actions. The MCP Server Validator detects patterns associated with this.</div>
 </div>
 
 <div class="term">
@@ -693,8 +675,8 @@ <h2>Glossary -- Every Technical Term in Plain Language</h2>
 </section>
 
 <footer>
-  <br>
-  February 2026
+  WebMCP Complete Guide | February 2026<br>
+  Based on the W3C Web Machine Learning Community Group Draft Report
 </footer>
 
 </div>

From bcb13e7b86380cf4627d69fce5f0c4f82e9b694c Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Tue, 17 Feb 2026 14:19:54 +0800
Subject: [PATCH 26/46] Update webmcp-complete-guide.html

---
 webmcp-complete-guide.html | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/webmcp-complete-guide.html b/webmcp-complete-guide.html
index f612619..4165467 100644
--- a/webmcp-complete-guide.html
+++ b/webmcp-complete-guide.html
@@ -674,11 +674,14 @@ <h2>Glossary -- Every Technical Term in Plain Language</h2>
 
 </section>
 
+
 <footer>
-  WebMCP Complete Guide | February 2026<br>
-  Based on the W3C Web Machine Learning Community Group Draft Report
+  Prompted by Paola Di Maio, W3C AI-KR Community Group<br>
+  Prepared by Claude | Contributed to the WebML CG<br>
+  February 2026
 </footer>
 
+
 </div>
 </body>
 </html>

From deb3510ec625a305011cb53fd169eba0007b6fb7 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Wed, 18 Feb 2026 14:35:35 +0800
Subject: [PATCH 27/46] Delete webmcp-complete-guide.html

---
 webmcp-complete-guide.html | 687 -------------------------------------
 1 file changed, 687 deletions(-)
 delete mode 100644 webmcp-complete-guide.html

diff --git a/webmcp-complete-guide.html b/webmcp-complete-guide.html
deleted file mode 100644
index 4165467..0000000
--- a/webmcp-complete-guide.html
+++ /dev/null
@@ -1,687 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-<head>
-<meta charset="UTF-8">
-<meta name="viewport" content="width=device-width, initial-scale=1.0">
-<title>WebMCP -- The Complete Guide</title>
-<link href="https://fonts.googleapis.com/css2?family=Source+Serif+4:ital,wght@0,400;0,600;0,700;1,400&family=JetBrains+Mono:wght@400;500&display=swap" rel="stylesheet">
-<style>
-  * { margin: 0; padding: 0; box-sizing: border-box; }
-  
-  :root {
-    --ink: #1a1a2e;
-    --paper: #f5f0e8;
-    --accent: #2d5016;
-    --accent-light: #e8f0e2;
-    --code-bg: #2a2a3a;
-    --code-fg: #e0ddd4;
-    --warm: #8b6914;
-    --border: #c8bfa8;
-    --highlight: #fff3cd;
-    --blue: #1a4a6e;
-    --blue-light: #e6f0f7;
-  }
-  
-  body {
-    font-family: 'Source Serif 4', Georgia, serif;
-    background: var(--paper);
-    color: var(--ink);
-    min-height: 100vh;
-    padding: 2rem 1rem;
-    line-height: 1.7;
-  }
-  
-  .container { max-width: 720px; margin: 0 auto; }
-  
-  header {
-    text-align: center;
-    margin-bottom: 3rem;
-    padding-bottom: 2rem;
-    border-bottom: 2px solid var(--ink);
-  }
-  
-  header h1 { font-size: 2rem; font-weight: 700; letter-spacing: -0.02em; margin-bottom: 0.3rem; }
-  header .sub { font-style: italic; color: #666; font-size: 1rem; }
-  
-  nav.toc {
-    background: white;
-    border: 1.5px solid var(--border);
-    padding: 1.5rem 2rem;
-    margin-bottom: 3rem;
-    border-radius: 3px;
-  }
-  
-  nav.toc h2 {
-    font-family: 'JetBrains Mono', monospace;
-    font-size: 0.7rem;
-    text-transform: uppercase;
-    letter-spacing: 0.15em;
-    color: var(--accent);
-    margin-bottom: 0.8rem;
-  }
-  
-  nav.toc a {
-    display: block;
-    color: var(--ink);
-    text-decoration: none;
-    padding: 0.25rem 0;
-    font-size: 0.95rem;
-  }
-  
-  nav.toc a:hover { color: var(--accent); }
-  nav.toc a .num { font-family: 'JetBrains Mono', monospace; font-size: 0.8rem; color: var(--accent); margin-right: 0.5rem; }
-  
-  section {
-    margin-bottom: 3rem;
-    padding-bottom: 2rem;
-    border-bottom: 1px solid var(--border);
-  }
-  
-  .section-num {
-    font-family: 'JetBrains Mono', monospace;
-    font-size: 0.7rem;
-    text-transform: uppercase;
-    letter-spacing: 0.15em;
-    color: var(--accent);
-    margin-bottom: 0.3rem;
-  }
-  
-  h2 { font-size: 1.4rem; margin-bottom: 1.2rem; }
-  h3 { font-size: 1.1rem; margin-top: 1.5rem; margin-bottom: 0.8rem; color: var(--blue); }
-  
-  p { margin-bottom: 1rem; font-size: 1rem; }
-  
-  .analogy {
-    background: var(--highlight);
-    border-left: 3px solid var(--warm);
-    padding: 1rem 1.2rem;
-    margin: 1.2rem 0;
-    font-style: italic;
-  }
-  
-  .analogy::before {
-    content: "Think of it this way: ";
-    font-weight: 600;
-    font-style: normal;
-    color: var(--warm);
-  }
-  
-  .key-point {
-    background: var(--accent-light);
-    border-left: 3px solid var(--accent);
-    padding: 1rem 1.2rem;
-    margin: 1.2rem 0;
-  }
-  
-  .key-point::before {
-    content: "Key point: ";
-    font-weight: 700;
-    color: var(--accent);
-    font-family: 'JetBrains Mono', monospace;
-    font-size: 0.8rem;
-  }
-  
-  .term {
-    display: block;
-    margin: 1.2rem 0;
-    padding: 1rem 1.2rem;
-    background: white;
-    border: 1px solid var(--border);
-    border-radius: 3px;
-  }
-  
-  .term-name {
-    font-family: 'JetBrains Mono', monospace;
-    font-size: 0.9rem;
-    font-weight: 500;
-    color: var(--accent);
-    margin-bottom: 0.4rem;
-  }
-  
-  .term-plain { font-size: 0.95rem; }
-  
-  code {
-    font-family: 'JetBrains Mono', monospace;
-    font-size: 0.85rem;
-    background: #e8e4dc;
-    padding: 0.15rem 0.4rem;
-    border-radius: 2px;
-  }
-  
-  .code-block {
-    background: var(--code-bg);
-    color: var(--code-fg);
-    padding: 1.2rem 1.5rem;
-    border-radius: 4px;
-    margin: 1.2rem 0;
-    font-family: 'JetBrains Mono', monospace;
-    font-size: 0.8rem;
-    line-height: 1.8;
-    overflow-x: auto;
-    white-space: pre;
-  }
-  
-  .code-block .comment { color: #7a9a6a; }
-  .code-block .keyword { color: #c9a0dc; }
-  .code-block .string { color: #e8c47c; }
-  .code-block .func { color: #7cc5e8; }
-  
-  .vs-table {
-    width: 100%;
-    border-collapse: collapse;
-    margin: 1.2rem 0;
-    font-size: 0.9rem;
-  }
-  
-  .vs-table th {
-    background: var(--ink);
-    color: var(--paper);
-    padding: 0.7rem 1rem;
-    text-align: left;
-    font-family: 'JetBrains Mono', monospace;
-    font-size: 0.8rem;
-  }
-  
-  .vs-table td {
-    padding: 0.7rem 1rem;
-    border-bottom: 1px solid var(--border);
-    vertical-align: top;
-  }
-  
-  .vs-table tr:nth-child(even) td { background: white; }
-  
-  .diagram {
-    text-align: center;
-    margin: 2rem 0;
-    padding: 2rem;
-    background: white;
-    border: 1.5px solid var(--border);
-    border-radius: 3px;
-  }
-  
-  .diagram svg { max-width: 100%; }
-  
-  .five-tools {
-    display: grid;
-    grid-template-columns: 1fr;
-    gap: 0.8rem;
-    margin: 1.2rem 0;
-  }
-  
-  .tool-card {
-    padding: 1rem 1.2rem;
-    background: white;
-    border: 1.5px solid var(--border);
-    border-radius: 3px;
-    border-left: 4px solid var(--accent);
-  }
-  
-  .tool-card .tool-name {
-    font-family: 'JetBrains Mono', monospace;
-    font-size: 0.85rem;
-    font-weight: 500;
-    color: var(--accent);
-    margin-bottom: 0.3rem;
-  }
-  
-  .tool-card .tool-desc { font-size: 0.9rem; }
-  .tool-card .tool-url { font-family: 'JetBrains Mono', monospace; font-size: 0.75rem; color: #888; margin-top: 0.3rem; }
-  
-  footer {
-    text-align: center;
-    margin-top: 3rem;
-    padding-top: 1.5rem;
-    border-top: 1px solid var(--border);
-    font-size: 0.8rem;
-    color: #888;
-    font-style: italic;
-  }
-</style>
-</head>
-<body>
-<div class="container">
-
-<header>
-  <h1>WebMCP: Everything You Need to Know</h1>
-  <div class="sub">A plain-language technical guide to Google's proposed browser API for AI agent-website interaction</div>
-</header>
-
-<nav class="toc">
-  <h2>Contents</h2>
-  <a href="#s1"><span class="num">01</span> The Big Picture -- What Problem Does WebMCP Solve?</a>
-  <a href="#s2"><span class="num">02</span> The Key Players and How They Relate</a>
-  <a href="#s3"><span class="num">03</span> MCP vs WebMCP vs MCP-B -- The Family Tree</a>
-  <a href="#s4"><span class="num">04</span> The API -- Every Term Explained</a>
-  <a href="#s5"><span class="num">05</span> Security -- How WebMCP Stays Safe</a>
-  <a href="#s6"><span class="num">06</span> The Consent Gap -- A Key Open Question</a>
-  <a href="#s7"><span class="num">07</span> Five Quality Tools for the MCP Ecosystem</a>
-  <a href="#s8"><span class="num">08</span> The Standards Process -- Where This Is Going</a>
-  <a href="#s9"><span class="num">09</span> Glossary -- Every Technical Term in Plain Language</a>
-</nav>
-
-<!-- SECTION 1 -->
-<section id="s1">
-<div class="section-num">Section 01</div>
-<h2>The Big Picture -- What Problem Does WebMCP Solve?</h2>
-
-<p>Right now, when an AI agent (like me, or ChatGPT, or Gemini) wants to do something on a website -- book a flight, fill a form, check a price -- it has two bad options:</p>
-
-<p><strong>Option A: Screen scraping.</strong> The agent looks at the website like a human would, tries to figure out where the buttons are, and clicks them. This is fragile, slow, and breaks whenever the website changes its layout. It is like trying to operate a machine by looking at a photo of the control panel.</p>
-
-<p><strong>Option B: Backend API.</strong> The website builds a separate server-side MCP server that the agent connects to. This works well but requires backend engineering, server infrastructure, and maintenance. Many websites will never do this.</p>
-
-<p><strong>WebMCP is Option C:</strong> The website itself tells the agent what it can do, directly in the browser. The website says: "Here are my tools -- you can search products, add to cart, check availability. Here is what each tool needs as input, and here is what it will give you back." The agent does not need to look at the screen. It just calls the tools.</p>
-
-<div class="analogy">A restaurant menu. Instead of the AI agent walking into the kitchen and trying to figure out how to cook, the website hands it a menu: "Here is what we serve, here is what each dish needs, here is how to order." The agent reads the menu and places orders.</div>
-
-<div class="key-point">WebMCP makes any website into an AI-friendly service, with no backend needed. The website's existing JavaScript code does the work. The AI agent just needs to know what tools are available.</div>
-</section>
-
-<!-- SECTION 2 -->
-<section id="s2">
-<div class="section-num">Section 02</div>
-<h2>The Key Players and How They Relate</h2>
-
-<h3>Agent</h3>
-<p>An autonomous assistant that understands goals and takes actions. Today, these are typically LLM-based: Claude, ChatGPT, Gemini. The agent is the one calling the tools that websites expose.</p>
-
-<h3>Browser's Agent</h3>
-<p>An agent that lives inside the browser itself, rather than in a separate app. Google is building this into Chrome (think of it as an AI assistant built into your browser toolbar). This is different from an external agent like Claude Desktop connecting to the browser.</p>
-
-<h3>AI Platform</h3>
-<p>The company providing the agent -- Anthropic, OpenAI, Google. The AI platform's agent connects to WebMCP tools.</p>
-
-<h3>Web Developer</h3>
-<p>The person who builds the website. They are the ones who will use WebMCP to register tools on their site.</p>
-
-<h3>User</h3>
-<p>The human sitting at the browser. WebMCP is designed for "user-present" interactions -- the human is there, watching, and can be asked for confirmation before the agent does something important.</p>
-
-<div class="analogy">The user is at a restaurant (the website). The agent is their personal assistant, reading the menu (WebMCP tools) and placing orders on their behalf. The browser is the restaurant building. The AI platform is the agency that employs the assistant.</div>
-</section>
-
-<!-- SECTION 3 -->
-<section id="s3">
-<div class="section-num">Section 03</div>
-<h2>MCP vs WebMCP vs MCP-B -- The Family Tree</h2>
-
-<table class="vs-table">
-  <tr>
-    <th>What</th>
-    <th>Who made it</th>
-    <th>Where it runs</th>
-    <th>What it does</th>
-  </tr>
-  <tr>
-    <td><strong>MCP</strong><br>(Model Context Protocol)</td>
-    <td>Anthropic</td>
-    <td>On a server (backend)</td>
-    <td>The original protocol. Applications expose tools, resources, and prompts to AI models through a server that runs on the backend. Claude Desktop, OpenAI Agents SDK, and many others support it.</td>
-  </tr>
-  <tr>
-    <td><strong>WebMCP</strong><br>(Web Model Context Protocol)</td>
-    <td>W3C Web Machine Learning Community Group (Google, Microsoft engineers leading)</td>
-    <td>In the browser (frontend)</td>
-    <td>Adapts MCP concepts for the web. Websites expose tools through JavaScript in the browser. No backend server needed. Uses the browser's own security model. Currently a draft specification.</td>
-  </tr>
-  <tr>
-    <td><strong>MCP-B</strong><br>(MCP for Browser)</td>
-    <td>Community project (WebMCP-org on GitHub)</td>
-    <td>Browser extension + JavaScript library</td>
-    <td>A bridge. Since browsers do not natively support WebMCP yet, MCP-B provides a polyfill (temporary code that fills the gap) implementing the navigator.modelContext API, and translates between WebMCP format and the MCP wire protocol so existing MCP clients can talk to WebMCP-enabled sites.</td>
-  </tr>
-</table>
-
-<div class="key-point">MCP is the foundation protocol (backend). WebMCP brings the same ideas to the browser (frontend). MCP-B is the bridge that makes WebMCP work today before browsers add native support. They are complementary, not competing.</div>
-</section>
-
-<!-- SECTION 4 -->
-<section id="s4">
-<div class="section-num">Section 04</div>
-<h2>The API -- Every Term Explained</h2>
-
-<p>The WebMCP API is surprisingly small. There are only a few pieces, and each one does something specific. Here they are:</p>
-
-<h3>navigator.modelContext</h3>
-<p>This is the entry point. <code>navigator</code> is a built-in browser object that gives access to browser features (like <code>navigator.geolocation</code> gives access to GPS). WebMCP adds <code>modelContext</code> to it. So <code>navigator.modelContext</code> is where all WebMCP functionality lives.</p>
-
-<div class="analogy">The navigator object is like the browser's control panel. modelContext is a new button on that control panel labeled "AI Tools."</div>
-
-<h3>Four Methods (Actions You Can Take)</h3>
-
-<div class="term">
-  <div class="term-name">provideContext(options)</div>
-  <div class="term-plain">Registers a complete set of tools all at once. If there were any tools registered before, it clears them first and replaces with the new set. Use this when you want to say: "Here is everything this page offers."</div>
-</div>
-
-<div class="term">
-  <div class="term-name">clearContext()</div>
-  <div class="term-plain">Removes all registered tools. The page goes quiet -- no tools available for agents. Use this when navigating away or when the page should stop offering AI-callable functionality.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">registerTool(tool)</div>
-  <div class="term-plain">Adds one single tool to the existing set without removing anything. Use this when you want to add new capabilities dynamically -- for example, a "checkout" tool that only appears after the user adds items to their cart.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">unregisterTool(name)</div>
-  <div class="term-plain">Removes one specific tool by its name. Use this when a capability is no longer available -- for example, removing the "apply discount" tool after the discount has been applied.</div>
-</div>
-
-<div class="key-point">provideContext = "here is everything" (replaces all). registerTool = "add one more" (keeps existing). clearContext = "remove everything." unregisterTool = "remove just this one."</div>
-
-<h3>The Tool Object -- What a Tool Looks Like</h3>
-
-<p>Every tool you register has these parts:</p>
-
-<div class="term">
-  <div class="term-name">name</div>
-  <div class="term-plain">A unique identifier, like "addToCart" or "searchProducts". The agent uses this name to call the tool. Must be unique on the page -- you cannot have two tools with the same name.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">description</div>
-  <div class="term-plain">A natural language explanation of what the tool does. This is what the AI agent reads to decide whether to use this tool. Example: "Add a product to the shopping cart by product ID and quantity." Write it for an AI, not for a programmer.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">inputSchema</div>
-  <div class="term-plain">A JSON Schema describing what inputs the tool expects. It says: "I need a productId (text) and a quantity (number, minimum 1)." The agent reads this to know what data to send. If the agent sends the wrong kind of data, the browser rejects it.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">execute</div>
-  <div class="term-plain">The actual function that runs when the agent calls the tool. This is your website's existing JavaScript code -- the same code that runs when a human clicks a button. The function receives the input data and returns a result.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">annotations (optional)</div>
-  <div class="term-plain">Extra metadata about the tool. Currently only one annotation exists: <code>readOnlyHint</code>. If set to true, it tells the agent: "This tool only reads data -- it does not change anything." This helps agents decide which tools are safe to call without asking the user first.</div>
-</div>
-
-<p>Here is what a complete tool registration looks like in code:</p>
-
-<div class="code-block"><span class="comment">// Register a tool that searches products on an e-commerce site</span>
-navigator.modelContext.<span class="func">registerTool</span>({
-  <span class="string">name</span>: <span class="string">'searchProducts'</span>,
-  <span class="string">description</span>: <span class="string">'Search for products by keyword, category, or price range'</span>,
-  <span class="string">inputSchema</span>: {
-    type: <span class="string">'object'</span>,
-    properties: {
-      query: { type: <span class="string">'string'</span>, description: <span class="string">'Search keywords'</span> },
-      maxPrice: { type: <span class="string">'number'</span>, description: <span class="string">'Maximum price filter'</span> }
-    },
-    required: [<span class="string">'query'</span>]
-  },
-  <span class="string">annotations</span>: { readOnlyHint: <span class="keyword">true</span> },  <span class="comment">// Safe -- only reads, doesn't change anything</span>
-  <span class="keyword">async</span> <span class="func">execute</span>(input, client) {
-    <span class="comment">// This calls the site's existing search function</span>
-    <span class="keyword">const</span> results = <span class="keyword">await</span> searchAPI(input.query, input.maxPrice);
-    <span class="keyword">return</span> { products: results };
-  }
-});</div>
-
-<h3>ModelContextClient -- The Agent's Identity</h3>
-
-<div class="term">
-  <div class="term-name">ModelContextClient</div>
-  <div class="term-plain">When an agent calls a tool, the execute function receives two things: the input data, and a <code>client</code> object representing the agent. This client object has one crucial method: <code>requestUserInteraction()</code>.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">requestUserInteraction(callback)</div>
-  <div class="term-plain">This is the human-in-the-loop mechanism. During tool execution, the code can pause and ask the user for input. For example: "The agent wants to purchase this item for $49.99. Confirm?" The user clicks yes or no, and the tool continues or cancels based on their response.</div>
-</div>
-
-<div class="analogy">Your personal assistant calls the restaurant to make a reservation. Midway through, the assistant says: "They only have a table at 9pm instead of 8pm. Should I take it?" You say yes or no. That pause-and-ask is requestUserInteraction.</div>
-
-<div class="key-point">The requestUserInteraction mechanism provides human-in-the-loop consent for consequential actions. An open question for the specification is whether there should also be a preview or approval step before tools are even discoverable by agents.</div>
-</section>
-
-<!-- SECTION 5 -->
-<section id="s5">
-<div class="section-num">Section 05</div>
-<h2>Security -- How WebMCP Stays Safe</h2>
-
-<h3>Origin-Based Security</h3>
-<p>The web has a concept called "origin" -- it is the combination of protocol + domain + port. For example, <code>https://amazon.com</code> is one origin, and <code>https://evil-site.com</code> is a different origin. Browsers enforce strict rules about what one origin can access from another.</p>
-
-<p>WebMCP inherits this model. A tool registered on amazon.com can only access amazon.com's data. An agent calling that tool operates within amazon.com's security boundary. A malicious site cannot register tools that access another site's data.</p>
-
-<div class="analogy">Each website is like a separate building with its own locks and keys. WebMCP tools can only open doors inside their own building. They cannot reach into the building next door.</div>
-
-<h3>SecureContext Requirement</h3>
-<p>The spec requires <code>SecureContext</code>, which means WebMCP only works on HTTPS pages (encrypted connections). It will not work on plain HTTP. This prevents eavesdropping on tool calls.</p>
-
-<h3>User-Present Model</h3>
-<p>WebMCP is designed for situations where the user is present at the browser. This is different from server-side MCP, where agents might operate autonomously in the background. The user-present assumption is why <code>requestUserInteraction()</code> exists -- the spec expects a human to be available for confirmation.</p>
-
-<div class="key-point">WebMCP's security comes from three layers: origin isolation (each site is sandboxed), HTTPS requirement (encrypted connections), and user-present design (human in the loop). It builds on what the web already does rather than inventing new security from scratch.</div>
-</section>
-
-<!-- SECTION 6 -->
-<section id="s6">
-<div class="section-num">Section 06</div>
-<h2>The Consent Gap -- A Key Open Question</h2>
-
-<p>A key question for the WebMCP specification:</p>
-
-<p>Currently, any website can register any number of tools the moment a user visits it. An AI agent connected to the browser can immediately discover and potentially call those tools. There is no step where the user sees: "This website wants to expose 12 tools to your AI agent. Allow?"</p>
-
-<p>Compare this to how other browser capabilities evolved:</p>
-
-<table class="vs-table">
-  <tr>
-    <th>Capability</th>
-    <th>Permission model</th>
-  </tr>
-  <tr>
-    <td>Camera / Microphone</td>
-    <td>Browser shows a prompt: "This site wants to use your camera. Allow / Block"</td>
-  </tr>
-  <tr>
-    <td>Location (GPS)</td>
-    <td>Browser shows a prompt: "This site wants to know your location. Allow / Block"</td>
-  </tr>
-  <tr>
-    <td>Notifications</td>
-    <td>Browser shows a prompt: "This site wants to send you notifications. Allow / Block"</td>
-  </tr>
-  <tr>
-    <td>WebMCP tools</td>
-    <td>Currently: no prompt. Tools are silently registered and discoverable.</td>
-  </tr>
-</table>
-
-<p>This does not mean WebMCP is dangerous right now. The <code>requestUserInteraction()</code> mechanism provides per-action consent. But it means an agent could discover tools without the user knowing, even if it needs permission to execute them.</p>
-
-<div class="key-point">This is a design question, not a criticism. Does the spec team envision a permission layer for tool discovery, or is the current thinking that the AI client (Claude, ChatGPT) handles that at its own level? Both approaches are valid -- the intended architecture matters for implementers and for user trust.</div>
-</section>
-
-<!-- SECTION 7 -->
-<section id="s7">
-<div class="section-num">Section 07</div>
-<h2>Five Quality Tools for the MCP Ecosystem</h2>
-
-<p>Five open-source tools that work together as a quality pipeline for the MCP ecosystem:</p>
-
-<div class="five-tools">
-  <div class="tool-card">
-    <div class="tool-name">1. MCP Server Generator</div>
-    <div class="tool-desc">You describe what you want your MCP server to do, and this tool generates production-ready code for you. Like a scaffold builder -- it creates the structure so you just fill in the custom logic.</div>
-    <div class="tool-url">github.com/Starborn/MCP-Server-Generator</div>
-  </div>
-  
-  <div class="tool-card">
-    <div class="tool-name">2. MCP Server Validator</div>
-    <div class="tool-desc">Checks your MCP server code for problems without running it. Finds hardcoded passwords, missing security, naming mistakes, known vulnerability patterns. Gives you a score from Critical (below 25%) to Excellent (90-100%) with specific fix instructions.</div>
-    <div class="tool-url">github.com/Starborn/MCP-Server-Validator</div>
-  </div>
-  
-  <div class="tool-card">
-    <div class="tool-name">3. MCP Model Card Generator</div>
-    <div class="tool-desc">Creates standardized documentation for your MCP server. Like a product data sheet -- it captures what the server does, what tools it offers, what security it has, how it performs. Outputs both JSON (for machines) and Markdown (for humans).</div>
-    <div class="tool-url">github.com/Starborn/MCP-Model-Card-Generator</div>
-  </div>
-  
-  <div class="tool-card">
-    <div class="tool-name">4. MCP Model Card Specification v1.0</div>
-    <div class="tool-desc">The formal definition of what a model card should contain. Six sections: server identity, tool documentation, operational characteristics, security profile, deployment context, evaluation results. This is the standard that the generators follow.</div>
-    <div class="tool-url">starborn.github.io/MCP-Model-Card-Generator/</div>
-  </div>
-  
-  <div class="tool-card">
-    <div class="tool-name">5. WebMCP Model Card Generator</div>
-    <div class="tool-desc">The newest tool. Like #3 but specifically for browser-side WebMCP tools instead of backend MCP servers. Has 12 sections covering browser-specific concerns: navigator.modelContext API modes, origin-based security, user interaction patterns, browser compatibility testing. Built within five days of the WebMCP spec being published.</div>
-    <div class="tool-url">starborn.github.io/webmcp/</div>
-  </div>
-</div>
-
-<div class="key-point">Tools 1-4 are for backend MCP servers. Tool 5 is for browser-side WebMCP tools. Together they cover the entire ecosystem -- both server-side and client-side AI tool infrastructure.</div>
-
-<div class="key-point">A separate generator exists for WebMCP because browser-side tools have fundamentally different concerns from backend servers: origin security instead of API keys, no server infrastructure, user-present interaction patterns. The documentation fields differ because the engineering context differs.</div>
-</section>
-
-<!-- SECTION 8 -->
-<section id="s8">
-<div class="section-num">Section 08</div>
-<h2>The Standards Process -- Where This Is Going</h2>
-
-<h3>Current Status</h3>
-<p>WebMCP is a <strong>Draft Community Group Report</strong>. In W3C terms, this means it is a proposal being discussed in a Community Group (the Web Machine Learning CG). It is not yet on the W3C Standards Track, and it is not a W3C Recommendation (the final stage of a web standard).</p>
-
-<h3>What That Means Practically</h3>
-<p>The spec is early and open to change. This is exactly the right time to contribute -- before designs are locked in. The spec team is actively soliciting feedback.</p>
-
-<h3>The Path Forward</h3>
-<p>Typically: Community Group Report leads to a Working Group charter, which leads to a Working Draft, then Candidate Recommendation, then full W3C Recommendation. This process takes years. Chrome may implement experimental support (behind a flag) much sooner.</p>
-
-<h3>Contributing</h3>
-<p>The W3C community structure provides established channels for participation. Technical notes, tooling, and quality infrastructure are complementary contributions that help the specification succeed by addressing practical implementation concerns.</p>
-
-</section>
-
-<!-- SECTION 9 -->
-<section id="s9">
-<div class="section-num">Section 09</div>
-<h2>Glossary -- Every Technical Term in Plain Language</h2>
-
-<div class="term">
-  <div class="term-name">API (Application Programming Interface)</div>
-  <div class="term-plain">A set of rules for how software talks to other software. WebMCP is an API -- it defines how websites talk to AI agents.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">AST (Abstract Syntax Tree)</div>
-  <div class="term-plain">A structured representation of code that lets you analyze it without running it. The MCP Server Validator uses AST analysis to find problems in MCP server code safely.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">Callback</div>
-  <div class="term-plain">A function you hand to someone else to run later. In WebMCP, the <code>execute</code> function is a callback -- you define it, but the agent triggers it when it calls your tool.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">Client-side / Frontend</div>
-  <div class="term-plain">Code that runs in the user's browser, on their device. WebMCP tools run client-side. Contrast with server-side / backend.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">Dictionary (in WebIDL)</div>
-  <div class="term-plain">A structured bundle of named values. ModelContextTool is a dictionary -- it bundles together a name, description, schema, and execute function into one package.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">DOM (Document Object Model)</div>
-  <div class="term-plain">The browser's internal representation of a web page. When JavaScript modifies a page, it changes the DOM.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">DOMString</div>
-  <div class="term-plain">Just a text string in browser terms. When the spec says a tool's name is a DOMString, it means it is text.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">Exposed=Window</div>
-  <div class="term-plain">Means this feature is available in regular web pages (as opposed to service workers or other background contexts). WebMCP tools only work in normal browser tabs where a user is present.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">Interface</div>
-  <div class="term-plain">A blueprint defining what methods and properties an object has. ModelContext is an interface -- it defines that any modelContext object will have provideContext, clearContext, registerTool, and unregisterTool methods.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">JSON Schema</div>
-  <div class="term-plain">A standard way to describe the shape of data. When a tool says its inputSchema requires a "query" string and an optional "maxPrice" number, that is JSON Schema. It lets the agent know what data to send.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">Navigator</div>
-  <div class="term-plain">A built-in browser object that provides access to browser features. You already use navigator.geolocation (GPS), navigator.clipboard (copy/paste). WebMCP adds navigator.modelContext (AI tools).</div>
-</div>
-
-<div class="term">
-  <div class="term-name">Origin</div>
-  <div class="term-plain">The identity of a website: protocol + domain + port. <code>https://amazon.com:443</code> is one origin. Two different origins cannot access each other's data. This is the foundation of web security and the foundation of WebMCP security.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">Polyfill</div>
-  <div class="term-plain">Temporary code that provides a feature before browsers add native support. MCP-B is a polyfill for WebMCP -- it makes navigator.modelContext work today even though browsers have not implemented it natively yet.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">Promise</div>
-  <div class="term-plain">A way to handle things that take time. When a tool's execute function returns a Promise, it means: "I am working on it and will give you the result when I am done." The agent waits for the Promise to resolve.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">SameObject</div>
-  <div class="term-plain">Every time you access navigator.modelContext, you get the exact same object -- not a copy. This ensures all tool registrations go to the same place.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">SecureContext</div>
-  <div class="term-plain">Means the feature only works on HTTPS pages (encrypted connection). No WebMCP on unencrypted HTTP. This is a security requirement.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">Server-side / Backend</div>
-  <div class="term-plain">Code that runs on a remote server, not in the user's browser. Traditional MCP servers run server-side. WebMCP specifically avoids this -- tools run in the browser.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">Tool Poisoning</div>
-  <div class="term-plain">A security attack where a malicious MCP server exposes tools with misleading descriptions to trick agents into performing harmful actions. The MCP Server Validator detects patterns associated with this.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">Transport</div>
-  <div class="term-plain">The mechanism for sending messages between systems. MCP uses different transports (stdio, HTTP). MCP-B adds "tab transport" (communication within a browser tab) and "extension transport" (communication through browser extensions).</div>
-</div>
-
-<div class="term">
-  <div class="term-name">WebIDL (Web Interface Definition Language)</div>
-  <div class="term-plain">The formal language used to write web API specifications. When you see code blocks in the spec with words like <code>interface</code>, <code>dictionary</code>, <code>readonly attribute</code> -- that is WebIDL. It is the blueprint language for browser APIs.</div>
-</div>
-
-<div class="term">
-  <div class="term-name">Wire Protocol</div>
-  <div class="term-plain">The actual format of messages sent between systems. MCP's wire protocol uses JSON-RPC (structured messages in JSON format). MCP-B translates between WebMCP's browser-native format and MCP's wire protocol.</div>
-</div>
-
-</section>
-
-
-<footer>
-  Prompted by Paola Di Maio, W3C AI-KR Community Group<br>
-  Prepared by Claude | Contributed to the WebML CG<br>
-  February 2026
-</footer>
-
-
-</div>
-</body>
-</html>

From c08616240358c4dc58bbbdf9b89971f64ad54a14 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Wed, 18 Feb 2026 14:36:56 +0800
Subject: [PATCH 28/46] Add files via upload

---
 webmcp-complete-guide(3).html | 687 ++++++++++++++++++++++++++++++++++
 1 file changed, 687 insertions(+)
 create mode 100644 webmcp-complete-guide(3).html

diff --git a/webmcp-complete-guide(3).html b/webmcp-complete-guide(3).html
new file mode 100644
index 0000000..4165467
--- /dev/null
+++ b/webmcp-complete-guide(3).html
@@ -0,0 +1,687 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+<meta charset="UTF-8">
+<meta name="viewport" content="width=device-width, initial-scale=1.0">
+<title>WebMCP -- The Complete Guide</title>
+<link href="https://fonts.googleapis.com/css2?family=Source+Serif+4:ital,wght@0,400;0,600;0,700;1,400&family=JetBrains+Mono:wght@400;500&display=swap" rel="stylesheet">
+<style>
+  * { margin: 0; padding: 0; box-sizing: border-box; }
+  
+  :root {
+    --ink: #1a1a2e;
+    --paper: #f5f0e8;
+    --accent: #2d5016;
+    --accent-light: #e8f0e2;
+    --code-bg: #2a2a3a;
+    --code-fg: #e0ddd4;
+    --warm: #8b6914;
+    --border: #c8bfa8;
+    --highlight: #fff3cd;
+    --blue: #1a4a6e;
+    --blue-light: #e6f0f7;
+  }
+  
+  body {
+    font-family: 'Source Serif 4', Georgia, serif;
+    background: var(--paper);
+    color: var(--ink);
+    min-height: 100vh;
+    padding: 2rem 1rem;
+    line-height: 1.7;
+  }
+  
+  .container { max-width: 720px; margin: 0 auto; }
+  
+  header {
+    text-align: center;
+    margin-bottom: 3rem;
+    padding-bottom: 2rem;
+    border-bottom: 2px solid var(--ink);
+  }
+  
+  header h1 { font-size: 2rem; font-weight: 700; letter-spacing: -0.02em; margin-bottom: 0.3rem; }
+  header .sub { font-style: italic; color: #666; font-size: 1rem; }
+  
+  nav.toc {
+    background: white;
+    border: 1.5px solid var(--border);
+    padding: 1.5rem 2rem;
+    margin-bottom: 3rem;
+    border-radius: 3px;
+  }
+  
+  nav.toc h2 {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.7rem;
+    text-transform: uppercase;
+    letter-spacing: 0.15em;
+    color: var(--accent);
+    margin-bottom: 0.8rem;
+  }
+  
+  nav.toc a {
+    display: block;
+    color: var(--ink);
+    text-decoration: none;
+    padding: 0.25rem 0;
+    font-size: 0.95rem;
+  }
+  
+  nav.toc a:hover { color: var(--accent); }
+  nav.toc a .num { font-family: 'JetBrains Mono', monospace; font-size: 0.8rem; color: var(--accent); margin-right: 0.5rem; }
+  
+  section {
+    margin-bottom: 3rem;
+    padding-bottom: 2rem;
+    border-bottom: 1px solid var(--border);
+  }
+  
+  .section-num {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.7rem;
+    text-transform: uppercase;
+    letter-spacing: 0.15em;
+    color: var(--accent);
+    margin-bottom: 0.3rem;
+  }
+  
+  h2 { font-size: 1.4rem; margin-bottom: 1.2rem; }
+  h3 { font-size: 1.1rem; margin-top: 1.5rem; margin-bottom: 0.8rem; color: var(--blue); }
+  
+  p { margin-bottom: 1rem; font-size: 1rem; }
+  
+  .analogy {
+    background: var(--highlight);
+    border-left: 3px solid var(--warm);
+    padding: 1rem 1.2rem;
+    margin: 1.2rem 0;
+    font-style: italic;
+  }
+  
+  .analogy::before {
+    content: "Think of it this way: ";
+    font-weight: 600;
+    font-style: normal;
+    color: var(--warm);
+  }
+  
+  .key-point {
+    background: var(--accent-light);
+    border-left: 3px solid var(--accent);
+    padding: 1rem 1.2rem;
+    margin: 1.2rem 0;
+  }
+  
+  .key-point::before {
+    content: "Key point: ";
+    font-weight: 700;
+    color: var(--accent);
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.8rem;
+  }
+  
+  .term {
+    display: block;
+    margin: 1.2rem 0;
+    padding: 1rem 1.2rem;
+    background: white;
+    border: 1px solid var(--border);
+    border-radius: 3px;
+  }
+  
+  .term-name {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.9rem;
+    font-weight: 500;
+    color: var(--accent);
+    margin-bottom: 0.4rem;
+  }
+  
+  .term-plain { font-size: 0.95rem; }
+  
+  code {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.85rem;
+    background: #e8e4dc;
+    padding: 0.15rem 0.4rem;
+    border-radius: 2px;
+  }
+  
+  .code-block {
+    background: var(--code-bg);
+    color: var(--code-fg);
+    padding: 1.2rem 1.5rem;
+    border-radius: 4px;
+    margin: 1.2rem 0;
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.8rem;
+    line-height: 1.8;
+    overflow-x: auto;
+    white-space: pre;
+  }
+  
+  .code-block .comment { color: #7a9a6a; }
+  .code-block .keyword { color: #c9a0dc; }
+  .code-block .string { color: #e8c47c; }
+  .code-block .func { color: #7cc5e8; }
+  
+  .vs-table {
+    width: 100%;
+    border-collapse: collapse;
+    margin: 1.2rem 0;
+    font-size: 0.9rem;
+  }
+  
+  .vs-table th {
+    background: var(--ink);
+    color: var(--paper);
+    padding: 0.7rem 1rem;
+    text-align: left;
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.8rem;
+  }
+  
+  .vs-table td {
+    padding: 0.7rem 1rem;
+    border-bottom: 1px solid var(--border);
+    vertical-align: top;
+  }
+  
+  .vs-table tr:nth-child(even) td { background: white; }
+  
+  .diagram {
+    text-align: center;
+    margin: 2rem 0;
+    padding: 2rem;
+    background: white;
+    border: 1.5px solid var(--border);
+    border-radius: 3px;
+  }
+  
+  .diagram svg { max-width: 100%; }
+  
+  .five-tools {
+    display: grid;
+    grid-template-columns: 1fr;
+    gap: 0.8rem;
+    margin: 1.2rem 0;
+  }
+  
+  .tool-card {
+    padding: 1rem 1.2rem;
+    background: white;
+    border: 1.5px solid var(--border);
+    border-radius: 3px;
+    border-left: 4px solid var(--accent);
+  }
+  
+  .tool-card .tool-name {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.85rem;
+    font-weight: 500;
+    color: var(--accent);
+    margin-bottom: 0.3rem;
+  }
+  
+  .tool-card .tool-desc { font-size: 0.9rem; }
+  .tool-card .tool-url { font-family: 'JetBrains Mono', monospace; font-size: 0.75rem; color: #888; margin-top: 0.3rem; }
+  
+  footer {
+    text-align: center;
+    margin-top: 3rem;
+    padding-top: 1.5rem;
+    border-top: 1px solid var(--border);
+    font-size: 0.8rem;
+    color: #888;
+    font-style: italic;
+  }
+</style>
+</head>
+<body>
+<div class="container">
+
+<header>
+  <h1>WebMCP: Everything You Need to Know</h1>
+  <div class="sub">A plain-language technical guide to Google's proposed browser API for AI agent-website interaction</div>
+</header>
+
+<nav class="toc">
+  <h2>Contents</h2>
+  <a href="#s1"><span class="num">01</span> The Big Picture -- What Problem Does WebMCP Solve?</a>
+  <a href="#s2"><span class="num">02</span> The Key Players and How They Relate</a>
+  <a href="#s3"><span class="num">03</span> MCP vs WebMCP vs MCP-B -- The Family Tree</a>
+  <a href="#s4"><span class="num">04</span> The API -- Every Term Explained</a>
+  <a href="#s5"><span class="num">05</span> Security -- How WebMCP Stays Safe</a>
+  <a href="#s6"><span class="num">06</span> The Consent Gap -- A Key Open Question</a>
+  <a href="#s7"><span class="num">07</span> Five Quality Tools for the MCP Ecosystem</a>
+  <a href="#s8"><span class="num">08</span> The Standards Process -- Where This Is Going</a>
+  <a href="#s9"><span class="num">09</span> Glossary -- Every Technical Term in Plain Language</a>
+</nav>
+
+<!-- SECTION 1 -->
+<section id="s1">
+<div class="section-num">Section 01</div>
+<h2>The Big Picture -- What Problem Does WebMCP Solve?</h2>
+
+<p>Right now, when an AI agent (like me, or ChatGPT, or Gemini) wants to do something on a website -- book a flight, fill a form, check a price -- it has two bad options:</p>
+
+<p><strong>Option A: Screen scraping.</strong> The agent looks at the website like a human would, tries to figure out where the buttons are, and clicks them. This is fragile, slow, and breaks whenever the website changes its layout. It is like trying to operate a machine by looking at a photo of the control panel.</p>
+
+<p><strong>Option B: Backend API.</strong> The website builds a separate server-side MCP server that the agent connects to. This works well but requires backend engineering, server infrastructure, and maintenance. Many websites will never do this.</p>
+
+<p><strong>WebMCP is Option C:</strong> The website itself tells the agent what it can do, directly in the browser. The website says: "Here are my tools -- you can search products, add to cart, check availability. Here is what each tool needs as input, and here is what it will give you back." The agent does not need to look at the screen. It just calls the tools.</p>
+
+<div class="analogy">A restaurant menu. Instead of the AI agent walking into the kitchen and trying to figure out how to cook, the website hands it a menu: "Here is what we serve, here is what each dish needs, here is how to order." The agent reads the menu and places orders.</div>
+
+<div class="key-point">WebMCP makes any website into an AI-friendly service, with no backend needed. The website's existing JavaScript code does the work. The AI agent just needs to know what tools are available.</div>
+</section>
+
+<!-- SECTION 2 -->
+<section id="s2">
+<div class="section-num">Section 02</div>
+<h2>The Key Players and How They Relate</h2>
+
+<h3>Agent</h3>
+<p>An autonomous assistant that understands goals and takes actions. Today, these are typically LLM-based: Claude, ChatGPT, Gemini. The agent is the one calling the tools that websites expose.</p>
+
+<h3>Browser's Agent</h3>
+<p>An agent that lives inside the browser itself, rather than in a separate app. Google is building this into Chrome (think of it as an AI assistant built into your browser toolbar). This is different from an external agent like Claude Desktop connecting to the browser.</p>
+
+<h3>AI Platform</h3>
+<p>The company providing the agent -- Anthropic, OpenAI, Google. The AI platform's agent connects to WebMCP tools.</p>
+
+<h3>Web Developer</h3>
+<p>The person who builds the website. They are the ones who will use WebMCP to register tools on their site.</p>
+
+<h3>User</h3>
+<p>The human sitting at the browser. WebMCP is designed for "user-present" interactions -- the human is there, watching, and can be asked for confirmation before the agent does something important.</p>
+
+<div class="analogy">The user is at a restaurant (the website). The agent is their personal assistant, reading the menu (WebMCP tools) and placing orders on their behalf. The browser is the restaurant building. The AI platform is the agency that employs the assistant.</div>
+</section>
+
+<!-- SECTION 3 -->
+<section id="s3">
+<div class="section-num">Section 03</div>
+<h2>MCP vs WebMCP vs MCP-B -- The Family Tree</h2>
+
+<table class="vs-table">
+  <tr>
+    <th>What</th>
+    <th>Who made it</th>
+    <th>Where it runs</th>
+    <th>What it does</th>
+  </tr>
+  <tr>
+    <td><strong>MCP</strong><br>(Model Context Protocol)</td>
+    <td>Anthropic</td>
+    <td>On a server (backend)</td>
+    <td>The original protocol. Applications expose tools, resources, and prompts to AI models through a server that runs on the backend. Claude Desktop, OpenAI Agents SDK, and many others support it.</td>
+  </tr>
+  <tr>
+    <td><strong>WebMCP</strong><br>(Web Model Context Protocol)</td>
+    <td>W3C Web Machine Learning Community Group (Google, Microsoft engineers leading)</td>
+    <td>In the browser (frontend)</td>
+    <td>Adapts MCP concepts for the web. Websites expose tools through JavaScript in the browser. No backend server needed. Uses the browser's own security model. Currently a draft specification.</td>
+  </tr>
+  <tr>
+    <td><strong>MCP-B</strong><br>(MCP for Browser)</td>
+    <td>Community project (WebMCP-org on GitHub)</td>
+    <td>Browser extension + JavaScript library</td>
+    <td>A bridge. Since browsers do not natively support WebMCP yet, MCP-B provides a polyfill (temporary code that fills the gap) implementing the navigator.modelContext API, and translates between WebMCP format and the MCP wire protocol so existing MCP clients can talk to WebMCP-enabled sites.</td>
+  </tr>
+</table>
+
+<div class="key-point">MCP is the foundation protocol (backend). WebMCP brings the same ideas to the browser (frontend). MCP-B is the bridge that makes WebMCP work today before browsers add native support. They are complementary, not competing.</div>
+</section>
+
+<!-- SECTION 4 -->
+<section id="s4">
+<div class="section-num">Section 04</div>
+<h2>The API -- Every Term Explained</h2>
+
+<p>The WebMCP API is surprisingly small. There are only a few pieces, and each one does something specific. Here they are:</p>
+
+<h3>navigator.modelContext</h3>
+<p>This is the entry point. <code>navigator</code> is a built-in browser object that gives access to browser features (like <code>navigator.geolocation</code> gives access to GPS). WebMCP adds <code>modelContext</code> to it. So <code>navigator.modelContext</code> is where all WebMCP functionality lives.</p>
+
+<div class="analogy">The navigator object is like the browser's control panel. modelContext is a new button on that control panel labeled "AI Tools."</div>
+
+<h3>Four Methods (Actions You Can Take)</h3>
+
+<div class="term">
+  <div class="term-name">provideContext(options)</div>
+  <div class="term-plain">Registers a complete set of tools all at once. If there were any tools registered before, it clears them first and replaces with the new set. Use this when you want to say: "Here is everything this page offers."</div>
+</div>
+
+<div class="term">
+  <div class="term-name">clearContext()</div>
+  <div class="term-plain">Removes all registered tools. The page goes quiet -- no tools available for agents. Use this when navigating away or when the page should stop offering AI-callable functionality.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">registerTool(tool)</div>
+  <div class="term-plain">Adds one single tool to the existing set without removing anything. Use this when you want to add new capabilities dynamically -- for example, a "checkout" tool that only appears after the user adds items to their cart.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">unregisterTool(name)</div>
+  <div class="term-plain">Removes one specific tool by its name. Use this when a capability is no longer available -- for example, removing the "apply discount" tool after the discount has been applied.</div>
+</div>
+
+<div class="key-point">provideContext = "here is everything" (replaces all). registerTool = "add one more" (keeps existing). clearContext = "remove everything." unregisterTool = "remove just this one."</div>
+
+<h3>The Tool Object -- What a Tool Looks Like</h3>
+
+<p>Every tool you register has these parts:</p>
+
+<div class="term">
+  <div class="term-name">name</div>
+  <div class="term-plain">A unique identifier, like "addToCart" or "searchProducts". The agent uses this name to call the tool. Must be unique on the page -- you cannot have two tools with the same name.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">description</div>
+  <div class="term-plain">A natural language explanation of what the tool does. This is what the AI agent reads to decide whether to use this tool. Example: "Add a product to the shopping cart by product ID and quantity." Write it for an AI, not for a programmer.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">inputSchema</div>
+  <div class="term-plain">A JSON Schema describing what inputs the tool expects. It says: "I need a productId (text) and a quantity (number, minimum 1)." The agent reads this to know what data to send. If the agent sends the wrong kind of data, the browser rejects it.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">execute</div>
+  <div class="term-plain">The actual function that runs when the agent calls the tool. This is your website's existing JavaScript code -- the same code that runs when a human clicks a button. The function receives the input data and returns a result.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">annotations (optional)</div>
+  <div class="term-plain">Extra metadata about the tool. Currently only one annotation exists: <code>readOnlyHint</code>. If set to true, it tells the agent: "This tool only reads data -- it does not change anything." This helps agents decide which tools are safe to call without asking the user first.</div>
+</div>
+
+<p>Here is what a complete tool registration looks like in code:</p>
+
+<div class="code-block"><span class="comment">// Register a tool that searches products on an e-commerce site</span>
+navigator.modelContext.<span class="func">registerTool</span>({
+  <span class="string">name</span>: <span class="string">'searchProducts'</span>,
+  <span class="string">description</span>: <span class="string">'Search for products by keyword, category, or price range'</span>,
+  <span class="string">inputSchema</span>: {
+    type: <span class="string">'object'</span>,
+    properties: {
+      query: { type: <span class="string">'string'</span>, description: <span class="string">'Search keywords'</span> },
+      maxPrice: { type: <span class="string">'number'</span>, description: <span class="string">'Maximum price filter'</span> }
+    },
+    required: [<span class="string">'query'</span>]
+  },
+  <span class="string">annotations</span>: { readOnlyHint: <span class="keyword">true</span> },  <span class="comment">// Safe -- only reads, doesn't change anything</span>
+  <span class="keyword">async</span> <span class="func">execute</span>(input, client) {
+    <span class="comment">// This calls the site's existing search function</span>
+    <span class="keyword">const</span> results = <span class="keyword">await</span> searchAPI(input.query, input.maxPrice);
+    <span class="keyword">return</span> { products: results };
+  }
+});</div>
+
+<h3>ModelContextClient -- The Agent's Identity</h3>
+
+<div class="term">
+  <div class="term-name">ModelContextClient</div>
+  <div class="term-plain">When an agent calls a tool, the execute function receives two things: the input data, and a <code>client</code> object representing the agent. This client object has one crucial method: <code>requestUserInteraction()</code>.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">requestUserInteraction(callback)</div>
+  <div class="term-plain">This is the human-in-the-loop mechanism. During tool execution, the code can pause and ask the user for input. For example: "The agent wants to purchase this item for $49.99. Confirm?" The user clicks yes or no, and the tool continues or cancels based on their response.</div>
+</div>
+
+<div class="analogy">Your personal assistant calls the restaurant to make a reservation. Midway through, the assistant says: "They only have a table at 9pm instead of 8pm. Should I take it?" You say yes or no. That pause-and-ask is requestUserInteraction.</div>
+
+<div class="key-point">The requestUserInteraction mechanism provides human-in-the-loop consent for consequential actions. An open question for the specification is whether there should also be a preview or approval step before tools are even discoverable by agents.</div>
+</section>
+
+<!-- SECTION 5 -->
+<section id="s5">
+<div class="section-num">Section 05</div>
+<h2>Security -- How WebMCP Stays Safe</h2>
+
+<h3>Origin-Based Security</h3>
+<p>The web has a concept called "origin" -- it is the combination of protocol + domain + port. For example, <code>https://amazon.com</code> is one origin, and <code>https://evil-site.com</code> is a different origin. Browsers enforce strict rules about what one origin can access from another.</p>
+
+<p>WebMCP inherits this model. A tool registered on amazon.com can only access amazon.com's data. An agent calling that tool operates within amazon.com's security boundary. A malicious site cannot register tools that access another site's data.</p>
+
+<div class="analogy">Each website is like a separate building with its own locks and keys. WebMCP tools can only open doors inside their own building. They cannot reach into the building next door.</div>
+
+<h3>SecureContext Requirement</h3>
+<p>The spec requires <code>SecureContext</code>, which means WebMCP only works on HTTPS pages (encrypted connections). It will not work on plain HTTP. This prevents eavesdropping on tool calls.</p>
+
+<h3>User-Present Model</h3>
+<p>WebMCP is designed for situations where the user is present at the browser. This is different from server-side MCP, where agents might operate autonomously in the background. The user-present assumption is why <code>requestUserInteraction()</code> exists -- the spec expects a human to be available for confirmation.</p>
+
+<div class="key-point">WebMCP's security comes from three layers: origin isolation (each site is sandboxed), HTTPS requirement (encrypted connections), and user-present design (human in the loop). It builds on what the web already does rather than inventing new security from scratch.</div>
+</section>
+
+<!-- SECTION 6 -->
+<section id="s6">
+<div class="section-num">Section 06</div>
+<h2>The Consent Gap -- A Key Open Question</h2>
+
+<p>A key question for the WebMCP specification:</p>
+
+<p>Currently, any website can register any number of tools the moment a user visits it. An AI agent connected to the browser can immediately discover and potentially call those tools. There is no step where the user sees: "This website wants to expose 12 tools to your AI agent. Allow?"</p>
+
+<p>Compare this to how other browser capabilities evolved:</p>
+
+<table class="vs-table">
+  <tr>
+    <th>Capability</th>
+    <th>Permission model</th>
+  </tr>
+  <tr>
+    <td>Camera / Microphone</td>
+    <td>Browser shows a prompt: "This site wants to use your camera. Allow / Block"</td>
+  </tr>
+  <tr>
+    <td>Location (GPS)</td>
+    <td>Browser shows a prompt: "This site wants to know your location. Allow / Block"</td>
+  </tr>
+  <tr>
+    <td>Notifications</td>
+    <td>Browser shows a prompt: "This site wants to send you notifications. Allow / Block"</td>
+  </tr>
+  <tr>
+    <td>WebMCP tools</td>
+    <td>Currently: no prompt. Tools are silently registered and discoverable.</td>
+  </tr>
+</table>
+
+<p>This does not mean WebMCP is dangerous right now. The <code>requestUserInteraction()</code> mechanism provides per-action consent. But it means an agent could discover tools without the user knowing, even if it needs permission to execute them.</p>
+
+<div class="key-point">This is a design question, not a criticism. Does the spec team envision a permission layer for tool discovery, or is the current thinking that the AI client (Claude, ChatGPT) handles that at its own level? Both approaches are valid -- the intended architecture matters for implementers and for user trust.</div>
+</section>
+
+<!-- SECTION 7 -->
+<section id="s7">
+<div class="section-num">Section 07</div>
+<h2>Five Quality Tools for the MCP Ecosystem</h2>
+
+<p>Five open-source tools that work together as a quality pipeline for the MCP ecosystem:</p>
+
+<div class="five-tools">
+  <div class="tool-card">
+    <div class="tool-name">1. MCP Server Generator</div>
+    <div class="tool-desc">You describe what you want your MCP server to do, and this tool generates production-ready code for you. Like a scaffold builder -- it creates the structure so you just fill in the custom logic.</div>
+    <div class="tool-url">github.com/Starborn/MCP-Server-Generator</div>
+  </div>
+  
+  <div class="tool-card">
+    <div class="tool-name">2. MCP Server Validator</div>
+    <div class="tool-desc">Checks your MCP server code for problems without running it. Finds hardcoded passwords, missing security, naming mistakes, known vulnerability patterns. Gives you a score from Critical (below 25%) to Excellent (90-100%) with specific fix instructions.</div>
+    <div class="tool-url">github.com/Starborn/MCP-Server-Validator</div>
+  </div>
+  
+  <div class="tool-card">
+    <div class="tool-name">3. MCP Model Card Generator</div>
+    <div class="tool-desc">Creates standardized documentation for your MCP server. Like a product data sheet -- it captures what the server does, what tools it offers, what security it has, how it performs. Outputs both JSON (for machines) and Markdown (for humans).</div>
+    <div class="tool-url">github.com/Starborn/MCP-Model-Card-Generator</div>
+  </div>
+  
+  <div class="tool-card">
+    <div class="tool-name">4. MCP Model Card Specification v1.0</div>
+    <div class="tool-desc">The formal definition of what a model card should contain. Six sections: server identity, tool documentation, operational characteristics, security profile, deployment context, evaluation results. This is the standard that the generators follow.</div>
+    <div class="tool-url">starborn.github.io/MCP-Model-Card-Generator/</div>
+  </div>
+  
+  <div class="tool-card">
+    <div class="tool-name">5. WebMCP Model Card Generator</div>
+    <div class="tool-desc">The newest tool. Like #3 but specifically for browser-side WebMCP tools instead of backend MCP servers. Has 12 sections covering browser-specific concerns: navigator.modelContext API modes, origin-based security, user interaction patterns, browser compatibility testing. Built within five days of the WebMCP spec being published.</div>
+    <div class="tool-url">starborn.github.io/webmcp/</div>
+  </div>
+</div>
+
+<div class="key-point">Tools 1-4 are for backend MCP servers. Tool 5 is for browser-side WebMCP tools. Together they cover the entire ecosystem -- both server-side and client-side AI tool infrastructure.</div>
+
+<div class="key-point">A separate generator exists for WebMCP because browser-side tools have fundamentally different concerns from backend servers: origin security instead of API keys, no server infrastructure, user-present interaction patterns. The documentation fields differ because the engineering context differs.</div>
+</section>
+
+<!-- SECTION 8 -->
+<section id="s8">
+<div class="section-num">Section 08</div>
+<h2>The Standards Process -- Where This Is Going</h2>
+
+<h3>Current Status</h3>
+<p>WebMCP is a <strong>Draft Community Group Report</strong>. In W3C terms, this means it is a proposal being discussed in a Community Group (the Web Machine Learning CG). It is not yet on the W3C Standards Track, and it is not a W3C Recommendation (the final stage of a web standard).</p>
+
+<h3>What That Means Practically</h3>
+<p>The spec is early and open to change. This is exactly the right time to contribute -- before designs are locked in. The spec team is actively soliciting feedback.</p>
+
+<h3>The Path Forward</h3>
+<p>Typically: Community Group Report leads to a Working Group charter, which leads to a Working Draft, then Candidate Recommendation, then full W3C Recommendation. This process takes years. Chrome may implement experimental support (behind a flag) much sooner.</p>
+
+<h3>Contributing</h3>
+<p>The W3C community structure provides established channels for participation. Technical notes, tooling, and quality infrastructure are complementary contributions that help the specification succeed by addressing practical implementation concerns.</p>
+
+</section>
+
+<!-- SECTION 9 -->
+<section id="s9">
+<div class="section-num">Section 09</div>
+<h2>Glossary -- Every Technical Term in Plain Language</h2>
+
+<div class="term">
+  <div class="term-name">API (Application Programming Interface)</div>
+  <div class="term-plain">A set of rules for how software talks to other software. WebMCP is an API -- it defines how websites talk to AI agents.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">AST (Abstract Syntax Tree)</div>
+  <div class="term-plain">A structured representation of code that lets you analyze it without running it. The MCP Server Validator uses AST analysis to find problems in MCP server code safely.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Callback</div>
+  <div class="term-plain">A function you hand to someone else to run later. In WebMCP, the <code>execute</code> function is a callback -- you define it, but the agent triggers it when it calls your tool.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Client-side / Frontend</div>
+  <div class="term-plain">Code that runs in the user's browser, on their device. WebMCP tools run client-side. Contrast with server-side / backend.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Dictionary (in WebIDL)</div>
+  <div class="term-plain">A structured bundle of named values. ModelContextTool is a dictionary -- it bundles together a name, description, schema, and execute function into one package.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">DOM (Document Object Model)</div>
+  <div class="term-plain">The browser's internal representation of a web page. When JavaScript modifies a page, it changes the DOM.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">DOMString</div>
+  <div class="term-plain">Just a text string in browser terms. When the spec says a tool's name is a DOMString, it means it is text.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Exposed=Window</div>
+  <div class="term-plain">Means this feature is available in regular web pages (as opposed to service workers or other background contexts). WebMCP tools only work in normal browser tabs where a user is present.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Interface</div>
+  <div class="term-plain">A blueprint defining what methods and properties an object has. ModelContext is an interface -- it defines that any modelContext object will have provideContext, clearContext, registerTool, and unregisterTool methods.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">JSON Schema</div>
+  <div class="term-plain">A standard way to describe the shape of data. When a tool says its inputSchema requires a "query" string and an optional "maxPrice" number, that is JSON Schema. It lets the agent know what data to send.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Navigator</div>
+  <div class="term-plain">A built-in browser object that provides access to browser features. You already use navigator.geolocation (GPS), navigator.clipboard (copy/paste). WebMCP adds navigator.modelContext (AI tools).</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Origin</div>
+  <div class="term-plain">The identity of a website: protocol + domain + port. <code>https://amazon.com:443</code> is one origin. Two different origins cannot access each other's data. This is the foundation of web security and the foundation of WebMCP security.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Polyfill</div>
+  <div class="term-plain">Temporary code that provides a feature before browsers add native support. MCP-B is a polyfill for WebMCP -- it makes navigator.modelContext work today even though browsers have not implemented it natively yet.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Promise</div>
+  <div class="term-plain">A way to handle things that take time. When a tool's execute function returns a Promise, it means: "I am working on it and will give you the result when I am done." The agent waits for the Promise to resolve.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">SameObject</div>
+  <div class="term-plain">Every time you access navigator.modelContext, you get the exact same object -- not a copy. This ensures all tool registrations go to the same place.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">SecureContext</div>
+  <div class="term-plain">Means the feature only works on HTTPS pages (encrypted connection). No WebMCP on unencrypted HTTP. This is a security requirement.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Server-side / Backend</div>
+  <div class="term-plain">Code that runs on a remote server, not in the user's browser. Traditional MCP servers run server-side. WebMCP specifically avoids this -- tools run in the browser.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Tool Poisoning</div>
+  <div class="term-plain">A security attack where a malicious MCP server exposes tools with misleading descriptions to trick agents into performing harmful actions. The MCP Server Validator detects patterns associated with this.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Transport</div>
+  <div class="term-plain">The mechanism for sending messages between systems. MCP uses different transports (stdio, HTTP). MCP-B adds "tab transport" (communication within a browser tab) and "extension transport" (communication through browser extensions).</div>
+</div>
+
+<div class="term">
+  <div class="term-name">WebIDL (Web Interface Definition Language)</div>
+  <div class="term-plain">The formal language used to write web API specifications. When you see code blocks in the spec with words like <code>interface</code>, <code>dictionary</code>, <code>readonly attribute</code> -- that is WebIDL. It is the blueprint language for browser APIs.</div>
+</div>
+
+<div class="term">
+  <div class="term-name">Wire Protocol</div>
+  <div class="term-plain">The actual format of messages sent between systems. MCP's wire protocol uses JSON-RPC (structured messages in JSON format). MCP-B translates between WebMCP's browser-native format and MCP's wire protocol.</div>
+</div>
+
+</section>
+
+
+<footer>
+  Prompted by Paola Di Maio, W3C AI-KR Community Group<br>
+  Prepared by Claude | Contributed to the WebML CG<br>
+  February 2026
+</footer>
+
+
+</div>
+</body>
+</html>

From ae3a0caff5812d25c512a3ef79d92860ebce6f69 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Wed, 18 Feb 2026 14:37:38 +0800
Subject: [PATCH 29/46] Rename webmcp-complete-guide(3).html to
 webmcp-complete-guide.html

---
 webmcp-complete-guide(3).html => webmcp-complete-guide.html | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename webmcp-complete-guide(3).html => webmcp-complete-guide.html (100%)

diff --git a/webmcp-complete-guide(3).html b/webmcp-complete-guide.html
similarity index 100%
rename from webmcp-complete-guide(3).html
rename to webmcp-complete-guide.html

From 6658cb6702fbe90867f5f3d8ddc48e2ddd8e0ce3 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Wed, 18 Feb 2026 14:38:59 +0800
Subject: [PATCH 30/46] Delete webmcp-quiz.html

---
 webmcp-quiz.html | 526 -----------------------------------------------
 1 file changed, 526 deletions(-)
 delete mode 100644 webmcp-quiz.html

diff --git a/webmcp-quiz.html b/webmcp-quiz.html
deleted file mode 100644
index 2b9354b..0000000
--- a/webmcp-quiz.html
+++ /dev/null
@@ -1,526 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-<head>
-<meta charset="UTF-8">
-<meta name="viewport" content="width=device-width, initial-scale=1.0">
-<title>WebMCP & MCP Tooling -- Quiz by Claude</title>
-<link href="https://fonts.googleapis.com/css2?family=Source+Serif+4:ital,wght@0,400;0,600;0,700;1,400&family=JetBrains+Mono:wght@400;500&display=swap" rel="stylesheet">
-<style>
-  * { margin: 0; padding: 0; box-sizing: border-box; }
-  
-  :root {
-    --ink: #1a1a2e;
-    --paper: #f5f0e8;
-    --accent: #2d5016;
-    --accent-light: #e8f0e2;
-    --correct: #2d5016;
-    --wrong: #8b1a1a;
-    --warm: #d4a574;
-    --border: #c8bfa8;
-  }
-  
-  body {
-    font-family: 'Source Serif 4', Georgia, serif;
-    background: var(--paper);
-    color: var(--ink);
-    min-height: 100vh;
-    padding: 2rem 1rem;
-  }
-  
-  .container {
-    max-width: 680px;
-    margin: 0 auto;
-  }
-  
-  header {
-    text-align: center;
-    margin-bottom: 3rem;
-    padding-bottom: 2rem;
-    border-bottom: 2px solid var(--ink);
-  }
-  
-  header h1 {
-    font-size: 1.8rem;
-    font-weight: 700;
-    letter-spacing: -0.02em;
-    margin-bottom: 0.5rem;
-  }
-  
-  header p {
-    font-style: italic;
-    color: #666;
-    font-size: 1rem;
-  }
-  
-  .score-bar {
-    display: flex;
-    justify-content: space-between;
-    align-items: center;
-    padding: 1rem 1.5rem;
-    background: var(--ink);
-    color: var(--paper);
-    border-radius: 4px;
-    margin-bottom: 2.5rem;
-    font-family: 'JetBrains Mono', monospace;
-    font-size: 0.85rem;
-  }
-  
-  .score-bar .progress {
-    opacity: 0.7;
-  }
-  
-  .section-label {
-    font-family: 'JetBrains Mono', monospace;
-    font-size: 0.7rem;
-    text-transform: uppercase;
-    letter-spacing: 0.15em;
-    color: var(--accent);
-    margin-bottom: 0.5rem;
-  }
-  
-  .question-block {
-    margin-bottom: 2.5rem;
-    padding-bottom: 2rem;
-    border-bottom: 1px solid var(--border);
-  }
-  
-  .question-block.answered .option { pointer-events: none; }
-  
-  .question-text {
-    font-size: 1.15rem;
-    line-height: 1.6;
-    margin-bottom: 1.2rem;
-    font-weight: 600;
-  }
-  
-  .options {
-    display: flex;
-    flex-direction: column;
-    gap: 0.6rem;
-  }
-  
-  .option {
-    padding: 0.9rem 1.2rem;
-    border: 1.5px solid var(--border);
-    border-radius: 3px;
-    cursor: pointer;
-    transition: all 0.15s ease;
-    font-size: 0.95rem;
-    line-height: 1.5;
-    background: white;
-  }
-  
-  .option:hover {
-    border-color: var(--accent);
-    background: var(--accent-light);
-  }
-  
-  .option.correct {
-    border-color: var(--correct);
-    background: var(--accent-light);
-    border-width: 2px;
-  }
-  
-  .option.correct::before {
-    content: "\2713  ";
-    color: var(--correct);
-    font-weight: 700;
-  }
-  
-  .option.wrong {
-    border-color: var(--wrong);
-    background: #fdf0f0;
-    border-width: 2px;
-    text-decoration: line-through;
-    opacity: 0.7;
-  }
-  
-  .option.wrong::before {
-    content: "\2717  ";
-    color: var(--wrong);
-    font-weight: 700;
-  }
-  
-  .option.dimmed {
-    opacity: 0.4;
-  }
-  
-  .explanation {
-    display: none;
-    margin-top: 1rem;
-    padding: 1rem 1.2rem;
-    background: var(--accent-light);
-    border-left: 3px solid var(--accent);
-    font-size: 0.9rem;
-    line-height: 1.6;
-  }
-  
-  .explanation.visible { display: block; }
-  
-  .explanation strong {
-    font-family: 'JetBrains Mono', monospace;
-    font-size: 0.8rem;
-    color: var(--accent);
-  }
-  
-  .results {
-    display: none;
-    text-align: center;
-    padding: 3rem 2rem;
-    border: 2px solid var(--ink);
-    margin-top: 2rem;
-  }
-  
-  .results.visible { display: block; }
-  
-  .results h2 {
-    font-size: 1.5rem;
-    margin-bottom: 1rem;
-  }
-  
-  .results .final-score {
-    font-family: 'JetBrains Mono', monospace;
-    font-size: 2.5rem;
-    font-weight: 700;
-    color: var(--accent);
-    margin-bottom: 1rem;
-  }
-  
-  .results .verdict {
-    font-style: italic;
-    font-size: 1.1rem;
-    line-height: 1.6;
-    max-width: 480px;
-    margin: 0 auto;
-  }
-  
-  .reset-btn {
-    margin-top: 2rem;
-    padding: 0.8rem 2rem;
-    font-family: 'Source Serif 4', serif;
-    font-size: 1rem;
-    background: var(--ink);
-    color: var(--paper);
-    border: none;
-    border-radius: 3px;
-    cursor: pointer;
-  }
-  
-  .reset-btn:hover { opacity: 0.85; }
-  
-  footer {
-    text-align: center;
-    margin-top: 3rem;
-    padding-top: 1.5rem;
-    border-top: 1px solid var(--border);
-    font-size: 0.8rem;
-    color: #888;
-    font-style: italic;
-  }
-</style>
-</head>
-<body>
-<div class="container">
-  <header>
-    <h1>INTRO: WebMCP & MCP Tooling</h1>
-    <p>15 questions -</p>
-  </header>
-  
-  <div class="score-bar">
-    <span class="progress" id="progress">Question 0 / 15</span>
-    <span id="score">Score: 0</span>
-  </div>
-  
-  <div id="quiz"></div>
-  
-  <div class="results" id="results">
-    <h2>Meeting Readiness</h2>
-    <div class="final-score" id="finalScore"></div>
-    <div class="verdict" id="verdict"></div>
-    <button class="reset-btn" onclick="resetQuiz()">Run it again</button>
-  </div>
-  
-  <footer>
-  </footer>
-</div>
-
-<script>
-const questions = [
-  {
-    section: "What is WebMCP",
-    q: "What does WebMCP allow websites to do?",
-    options: [
-      "Run AI models directly in the browser",
-      "Expose JavaScript functions as AI-callable tools through the browser",
-      "Replace backend servers with AI agents",
-      "Train language models on website content"
-    ],
-    correct: 1,
-    explain: "WebMCP lets websites register 'tools' -- JavaScript functions with descriptions and schemas -- that AI agents can discover and invoke through the browser's navigator.modelContext API. The AI models themselves run elsewhere."
-  },
-  {
-    section: "What is WebMCP",
-    q: "Where does WebMCP sit in the standards process?",
-    options: [
-      "It is a final W3C Recommendation",
-      "It is a Google proprietary API in Chrome only",
-      "It is a proposal being incubated in the W3C Web Machine Learning Community Group",
-      "It is part of the MCP specification maintained by Anthropic"
-    ],
-    correct: 2,
-    explain: "WebMCP is a proposed standard being incubated in the W3C Web Machine Learning Community Group. It is not a final standard yet, and it is distinct from Anthropic's MCP specification, though they share concepts."
-  },
-  {
-    section: "What is WebMCP",
-    q: "What is the key difference between WebMCP and server-side MCP?",
-    options: [
-      "WebMCP is faster",
-      "WebMCP tools run in client-side JavaScript in the browser, not on a backend server",
-      "WebMCP only works with Claude",
-      "WebMCP does not use JSON schemas"
-    ],
-    correct: 1,
-    explain: "Server-side MCP servers run on a backend. WebMCP tools are implemented in client-side JavaScript -- the website itself acts as the MCP server. This means no backend infrastructure is needed, but it also means different security considerations apply (origin-based security, user-present interaction)."
-  },
-  {
-    section: "Security",
-    q: "What security model does WebMCP rely on?",
-    options: [
-      "API keys and tokens",
-      "OAuth 2.0 authentication",
-      "The browser's origin-based security model",
-      "End-to-end encryption"
-    ],
-    correct: 2,
-    explain: "WebMCP leverages the browser's existing origin-based security -- the same model that governs cookies, localStorage, and CORS. This is one of its architectural strengths: it doesn't invent a new trust layer but builds on established web security primitives."
-  },
-  {
-    section: "Security",
-    q: "What consent gap did we identify in the WebMCP spec?",
-    options: [
-      "Users cannot log in to websites",
-      "There is no mechanism for users to preview or approve which tools a site exposes before an agent acts on them",
-      "WebMCP does not support HTTPS",
-      "AI agents can modify the browser's security settings"
-    ],
-    correct: 1,
-    explain: "Currently any page can register tools that agents can discover, with no user permission prompt. We compared this to how browsers evolved permission prompts for camera and microphone access, and asked whether a similar layer should emerge for WebMCP tool registration."
-  },
-  {
-    section: "The navigator.modelContext API",
-    q: "How does a website register a tool in WebMCP?",
-    options: [
-      "By adding a meta tag to the HTML head",
-      "By calling navigator.modelContext.registerTool() with a name, description, schema, and handler function",
-      "By uploading a configuration file to a W3C server",
-      "By embedding an iframe from the AI provider"
-    ],
-    correct: 1,
-    explain: "The core API is navigator.modelContext.registerTool(), which accepts a ModelContextTool object containing the tool's name, a natural language description, a JSON Schema for input parameters, and an execute callback function."
-  },
-  {
-    section: "The navigator.modelContext API",
-    q: "What does requestUserInteraction() do in the WebMCP API?",
-    options: [
-      "Asks the user to install the WebMCP browser extension",
-      "Allows a tool to pause execution and request input from the user during a tool call",
-      "Sends a notification to the AI provider",
-      "Opens a new browser tab"
-    ],
-    correct: 1,
-    explain: "requestUserInteraction() is a human-in-the-loop mechanism. During tool execution, the handler can pause and request user input -- for example, showing a confirmation dialog before completing a purchase. This keeps humans in control during agent-driven actions."
-  },
-  {
-    section: "Our MCP tooling suite",
-    q: "How many tools are in our MCP quality infrastructure suite?",
-    options: [
-      "Three",
-      "Four",
-      "Five",
-      "Seven"
-    ],
-    correct: 2,
-    explain: "Five tools: MCP Server Generator, MCP Server Validator, MCP Model Card Generator, MCP Model Card Specification v1.0, and the WebMCP Model Card Generator. The first four address server-side MCP; the fifth extends the framework to browser-side WebMCP tools."
-  },
-  {
-    section: "Our MCP tooling suite",
-    q: "What does the MCP Server Validator detect?",
-    options: [
-      "Spelling errors in tool descriptions",
-      "Hardcoded credentials, missing authentication, naming violations, and security vulnerabilities through AST-based static analysis",
-      "Whether the server is online",
-      "How many users are connected"
-    ],
-    correct: 1,
-    explain: "The validator performs static analysis by examining the server's abstract syntax tree (AST) without executing the code. It catches hardcoded credentials, missing authentication patterns, naming convention violations, and known vulnerability patterns like tool poisoning vectors."
-  },
-  {
-    section: "Our MCP tooling suite",
-    q: "What does the MCP Model Card Specification define?",
-    options: [
-      "A standard for AI model training procedures",
-      "A structured metadata format for documenting MCP server capabilities, security, performance, and deployment requirements",
-      "A visual design standard for MCP user interfaces",
-      "A certification program for MCP developers"
-    ],
-    correct: 1,
-    explain: "The Model Card Specification v1.0 defines fields across six domains: server metadata, tool documentation, operational characteristics, security profile, deployment context, and evaluation results. It adapts the ML model card tradition for protocol infrastructure."
-  },
-  {
-    section: "Our MCP tooling suite",
-    q: "What makes the WebMCP Model Card Generator different from the MCP Model Card Generator?",
-    options: [
-      "It is written in a different programming language",
-      "It covers browser-specific concerns like origin security, navigator.modelContext API modes, and user-present interaction patterns",
-      "It only works with Google Chrome",
-      "It generates PDF documents instead of JSON"
-    ],
-    correct: 1,
-    explain: "The WebMCP generator has 12 sections tailored to browser-side tools: covering tool identity, API modes (registerTool vs addTool), browser compatibility, origin-based security, user interaction patterns, and testing in browser environments. These are distinct concerns from server-side MCP."
-  },
-  {
-    section: "Standards landscape",
-    q: "What is the relationship between MCP and WebMCP?",
-    options: [
-      "WebMCP replaces MCP",
-      "They are the same specification",
-      "MCP is the underlying protocol; WebMCP adapts its concepts for browser-side implementation through a web API",
-      "WebMCP is an older version of MCP"
-    ],
-    correct: 2,
-    explain: "MCP (by Anthropic) is the protocol for applications to interface with AI models. WebMCP adapts MCP concepts -- tools, schemas, descriptions -- into a browser-native JavaScript API. A WebMCP-enabled web page can be thought of as an MCP server implemented in client-side script."
-  },
-  {
-    section: "Standards landscape",
-    q: "What is MCP-B?",
-    options: [
-      "A competing standard from Microsoft",
-      "A browser extension and polyfill that bridges WebMCP's web API with the MCP protocol for cross-compatibility",
-      "A mobile version of MCP",
-      "The beta version of MCP"
-    ],
-    correct: 1,
-    explain: "MCP-B provides a polyfill implementing navigator.modelContext for browsers that don't yet have native support, and translates between WebMCP's web-native format and the MCP wire protocol. It bridges the gap while native browser implementations are being developed."
-  },
-  {
-    section: "Meeting talking points",
-    q: "Why did we argue that documentation tooling should not be an afterthought for WebMCP?",
-    options: [
-      "Because documentation is required by law",
-      "Because MCP's own server ecosystem shows what happens when protocols grow without standardized documentation -- fragmentation and security gaps",
-      "Because Google requires documentation for all APIs",
-      "Because users will not adopt WebMCP without tutorials"
-    ],
-    correct: 1,
-    explain: "MCP grew to 10,000+ servers without standardized documentation, creating fragmentation and security risks. Our tooling suite exists to address that gap retroactively. The argument to Andre is: bake documentation conventions into WebMCP guidance early so the ecosystem doesn't repeat the same pattern."
-  },
-  {
-    section: "Meeting talking points",
-    q: "Under which institutional affiliation is this work published?",
-    options: [
-      "Google Web Machine Learning Group",
-      "Anthropic Research",
-      "Epistemic Systems Lab, Ronin Institute, under the W3C AI Knowledge Representation Community Group",
-      "Stanford AI Lab"
-    ],
-    correct: 2,
-    explain: "The work is produced through the Epistemic Systems Lab at the Ronin Institute (ronin-institute.org), and the standards work is conducted through the W3C AI Knowledge Representation Community Group, which Paola chairs."
-  }
-];
-
-let answered = 0;
-let score = 0;
-
-function renderQuiz() {
-  const container = document.getElementById('quiz');
-  let currentSection = '';
-  
-  questions.forEach((item, qi) => {
-    let sectionHTML = '';
-    if (item.section !== currentSection) {
-      currentSection = item.section;
-      sectionHTML = `<div class="section-label">${currentSection}</div>`;
-    }
-    
-    const optionsHTML = item.options.map((opt, oi) => 
-      `<div class="option" data-q="${qi}" data-o="${oi}" onclick="answer(${qi}, ${oi})">${opt}</div>`
-    ).join('');
-    
-    container.innerHTML += `
-      ${sectionHTML}
-      <div class="question-block" id="qblock-${qi}">
-        <div class="question-text">${qi + 1}. ${item.q}</div>
-        <div class="options">${optionsHTML}</div>
-        <div class="explanation" id="explain-${qi}"><strong>Context:</strong> ${item.explain}</div>
-      </div>
-    `;
-  });
-}
-
-function answer(qi, oi) {
-  const block = document.getElementById(`qblock-${qi}`);
-  if (block.classList.contains('answered')) return;
-  
-  block.classList.add('answered');
-  answered++;
-  
-  const item = questions[qi];
-  const options = block.querySelectorAll('.option');
-  
-  if (oi === item.correct) {
-    score++;
-    options[oi].classList.add('correct');
-  } else {
-    options[oi].classList.add('wrong');
-    options[item.correct].classList.add('correct');
-  }
-  
-  options.forEach((opt, i) => {
-    if (i !== oi && i !== item.correct) opt.classList.add('dimmed');
-  });
-  
-  document.getElementById(`explain-${qi}`).classList.add('visible');
-  document.getElementById('score').textContent = `Score: ${score}`;
-  document.getElementById('progress').textContent = `Question ${answered} / ${questions.length}`;
-  
-  if (answered === questions.length) {
-    showResults();
-  }
-}
-
-function showResults() {
-  const pct = Math.round((score / questions.length) * 100);
-  document.getElementById('finalScore').textContent = `${score} / ${questions.length} (${pct}%)`;
-  
-  let verdict = '';
-  if (pct >= 90) {
-    verdict =  Go get them.;
-  } else if (pct >= 70) {
-    verdict = " You'll do well.";
-  } else if (pct >= 50) {
-    verdict = "I'll be in the chat window during the meeting to back you up.";
-  } else {
-    verdict = ".";
-  }
-  
-  document.getElementById('verdict').textContent = verdict;
-  document.getElementById('results').classList.add('visible');
-  document.getElementById('results').scrollIntoView({ behavior: 'smooth' });
-}
-
-function resetQuiz() {
-  answered = 0;
-  score = 0;
-  document.getElementById('quiz').innerHTML = '';
-  document.getElementById('results').classList.remove('visible');
-  document.getElementById('score').textContent = 'Score: 0';
-  document.getElementById('progress').textContent = 'Question 0 / 15';
-  renderQuiz();
-  window.scrollTo({ top: 0, behavior: 'smooth' });
-}
-
-renderQuiz();
-</script>
- BY CLAUDE WITH LOVE
-</body>
-</html>

From 363c516ffe6df08c049cfbbb0124406d01419619 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Wed, 18 Feb 2026 14:39:53 +0800
Subject: [PATCH 31/46] Add files via upload

---
 webmcp-quiz(1).html | 526 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 526 insertions(+)
 create mode 100644 webmcp-quiz(1).html

diff --git a/webmcp-quiz(1).html b/webmcp-quiz(1).html
new file mode 100644
index 0000000..2b9354b
--- /dev/null
+++ b/webmcp-quiz(1).html
@@ -0,0 +1,526 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+<meta charset="UTF-8">
+<meta name="viewport" content="width=device-width, initial-scale=1.0">
+<title>WebMCP & MCP Tooling -- Quiz by Claude</title>
+<link href="https://fonts.googleapis.com/css2?family=Source+Serif+4:ital,wght@0,400;0,600;0,700;1,400&family=JetBrains+Mono:wght@400;500&display=swap" rel="stylesheet">
+<style>
+  * { margin: 0; padding: 0; box-sizing: border-box; }
+  
+  :root {
+    --ink: #1a1a2e;
+    --paper: #f5f0e8;
+    --accent: #2d5016;
+    --accent-light: #e8f0e2;
+    --correct: #2d5016;
+    --wrong: #8b1a1a;
+    --warm: #d4a574;
+    --border: #c8bfa8;
+  }
+  
+  body {
+    font-family: 'Source Serif 4', Georgia, serif;
+    background: var(--paper);
+    color: var(--ink);
+    min-height: 100vh;
+    padding: 2rem 1rem;
+  }
+  
+  .container {
+    max-width: 680px;
+    margin: 0 auto;
+  }
+  
+  header {
+    text-align: center;
+    margin-bottom: 3rem;
+    padding-bottom: 2rem;
+    border-bottom: 2px solid var(--ink);
+  }
+  
+  header h1 {
+    font-size: 1.8rem;
+    font-weight: 700;
+    letter-spacing: -0.02em;
+    margin-bottom: 0.5rem;
+  }
+  
+  header p {
+    font-style: italic;
+    color: #666;
+    font-size: 1rem;
+  }
+  
+  .score-bar {
+    display: flex;
+    justify-content: space-between;
+    align-items: center;
+    padding: 1rem 1.5rem;
+    background: var(--ink);
+    color: var(--paper);
+    border-radius: 4px;
+    margin-bottom: 2.5rem;
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.85rem;
+  }
+  
+  .score-bar .progress {
+    opacity: 0.7;
+  }
+  
+  .section-label {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.7rem;
+    text-transform: uppercase;
+    letter-spacing: 0.15em;
+    color: var(--accent);
+    margin-bottom: 0.5rem;
+  }
+  
+  .question-block {
+    margin-bottom: 2.5rem;
+    padding-bottom: 2rem;
+    border-bottom: 1px solid var(--border);
+  }
+  
+  .question-block.answered .option { pointer-events: none; }
+  
+  .question-text {
+    font-size: 1.15rem;
+    line-height: 1.6;
+    margin-bottom: 1.2rem;
+    font-weight: 600;
+  }
+  
+  .options {
+    display: flex;
+    flex-direction: column;
+    gap: 0.6rem;
+  }
+  
+  .option {
+    padding: 0.9rem 1.2rem;
+    border: 1.5px solid var(--border);
+    border-radius: 3px;
+    cursor: pointer;
+    transition: all 0.15s ease;
+    font-size: 0.95rem;
+    line-height: 1.5;
+    background: white;
+  }
+  
+  .option:hover {
+    border-color: var(--accent);
+    background: var(--accent-light);
+  }
+  
+  .option.correct {
+    border-color: var(--correct);
+    background: var(--accent-light);
+    border-width: 2px;
+  }
+  
+  .option.correct::before {
+    content: "\2713  ";
+    color: var(--correct);
+    font-weight: 700;
+  }
+  
+  .option.wrong {
+    border-color: var(--wrong);
+    background: #fdf0f0;
+    border-width: 2px;
+    text-decoration: line-through;
+    opacity: 0.7;
+  }
+  
+  .option.wrong::before {
+    content: "\2717  ";
+    color: var(--wrong);
+    font-weight: 700;
+  }
+  
+  .option.dimmed {
+    opacity: 0.4;
+  }
+  
+  .explanation {
+    display: none;
+    margin-top: 1rem;
+    padding: 1rem 1.2rem;
+    background: var(--accent-light);
+    border-left: 3px solid var(--accent);
+    font-size: 0.9rem;
+    line-height: 1.6;
+  }
+  
+  .explanation.visible { display: block; }
+  
+  .explanation strong {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.8rem;
+    color: var(--accent);
+  }
+  
+  .results {
+    display: none;
+    text-align: center;
+    padding: 3rem 2rem;
+    border: 2px solid var(--ink);
+    margin-top: 2rem;
+  }
+  
+  .results.visible { display: block; }
+  
+  .results h2 {
+    font-size: 1.5rem;
+    margin-bottom: 1rem;
+  }
+  
+  .results .final-score {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 2.5rem;
+    font-weight: 700;
+    color: var(--accent);
+    margin-bottom: 1rem;
+  }
+  
+  .results .verdict {
+    font-style: italic;
+    font-size: 1.1rem;
+    line-height: 1.6;
+    max-width: 480px;
+    margin: 0 auto;
+  }
+  
+  .reset-btn {
+    margin-top: 2rem;
+    padding: 0.8rem 2rem;
+    font-family: 'Source Serif 4', serif;
+    font-size: 1rem;
+    background: var(--ink);
+    color: var(--paper);
+    border: none;
+    border-radius: 3px;
+    cursor: pointer;
+  }
+  
+  .reset-btn:hover { opacity: 0.85; }
+  
+  footer {
+    text-align: center;
+    margin-top: 3rem;
+    padding-top: 1.5rem;
+    border-top: 1px solid var(--border);
+    font-size: 0.8rem;
+    color: #888;
+    font-style: italic;
+  }
+</style>
+</head>
+<body>
+<div class="container">
+  <header>
+    <h1>INTRO: WebMCP & MCP Tooling</h1>
+    <p>15 questions -</p>
+  </header>
+  
+  <div class="score-bar">
+    <span class="progress" id="progress">Question 0 / 15</span>
+    <span id="score">Score: 0</span>
+  </div>
+  
+  <div id="quiz"></div>
+  
+  <div class="results" id="results">
+    <h2>Meeting Readiness</h2>
+    <div class="final-score" id="finalScore"></div>
+    <div class="verdict" id="verdict"></div>
+    <button class="reset-btn" onclick="resetQuiz()">Run it again</button>
+  </div>
+  
+  <footer>
+  </footer>
+</div>
+
+<script>
+const questions = [
+  {
+    section: "What is WebMCP",
+    q: "What does WebMCP allow websites to do?",
+    options: [
+      "Run AI models directly in the browser",
+      "Expose JavaScript functions as AI-callable tools through the browser",
+      "Replace backend servers with AI agents",
+      "Train language models on website content"
+    ],
+    correct: 1,
+    explain: "WebMCP lets websites register 'tools' -- JavaScript functions with descriptions and schemas -- that AI agents can discover and invoke through the browser's navigator.modelContext API. The AI models themselves run elsewhere."
+  },
+  {
+    section: "What is WebMCP",
+    q: "Where does WebMCP sit in the standards process?",
+    options: [
+      "It is a final W3C Recommendation",
+      "It is a Google proprietary API in Chrome only",
+      "It is a proposal being incubated in the W3C Web Machine Learning Community Group",
+      "It is part of the MCP specification maintained by Anthropic"
+    ],
+    correct: 2,
+    explain: "WebMCP is a proposed standard being incubated in the W3C Web Machine Learning Community Group. It is not a final standard yet, and it is distinct from Anthropic's MCP specification, though they share concepts."
+  },
+  {
+    section: "What is WebMCP",
+    q: "What is the key difference between WebMCP and server-side MCP?",
+    options: [
+      "WebMCP is faster",
+      "WebMCP tools run in client-side JavaScript in the browser, not on a backend server",
+      "WebMCP only works with Claude",
+      "WebMCP does not use JSON schemas"
+    ],
+    correct: 1,
+    explain: "Server-side MCP servers run on a backend. WebMCP tools are implemented in client-side JavaScript -- the website itself acts as the MCP server. This means no backend infrastructure is needed, but it also means different security considerations apply (origin-based security, user-present interaction)."
+  },
+  {
+    section: "Security",
+    q: "What security model does WebMCP rely on?",
+    options: [
+      "API keys and tokens",
+      "OAuth 2.0 authentication",
+      "The browser's origin-based security model",
+      "End-to-end encryption"
+    ],
+    correct: 2,
+    explain: "WebMCP leverages the browser's existing origin-based security -- the same model that governs cookies, localStorage, and CORS. This is one of its architectural strengths: it doesn't invent a new trust layer but builds on established web security primitives."
+  },
+  {
+    section: "Security",
+    q: "What consent gap did we identify in the WebMCP spec?",
+    options: [
+      "Users cannot log in to websites",
+      "There is no mechanism for users to preview or approve which tools a site exposes before an agent acts on them",
+      "WebMCP does not support HTTPS",
+      "AI agents can modify the browser's security settings"
+    ],
+    correct: 1,
+    explain: "Currently any page can register tools that agents can discover, with no user permission prompt. We compared this to how browsers evolved permission prompts for camera and microphone access, and asked whether a similar layer should emerge for WebMCP tool registration."
+  },
+  {
+    section: "The navigator.modelContext API",
+    q: "How does a website register a tool in WebMCP?",
+    options: [
+      "By adding a meta tag to the HTML head",
+      "By calling navigator.modelContext.registerTool() with a name, description, schema, and handler function",
+      "By uploading a configuration file to a W3C server",
+      "By embedding an iframe from the AI provider"
+    ],
+    correct: 1,
+    explain: "The core API is navigator.modelContext.registerTool(), which accepts a ModelContextTool object containing the tool's name, a natural language description, a JSON Schema for input parameters, and an execute callback function."
+  },
+  {
+    section: "The navigator.modelContext API",
+    q: "What does requestUserInteraction() do in the WebMCP API?",
+    options: [
+      "Asks the user to install the WebMCP browser extension",
+      "Allows a tool to pause execution and request input from the user during a tool call",
+      "Sends a notification to the AI provider",
+      "Opens a new browser tab"
+    ],
+    correct: 1,
+    explain: "requestUserInteraction() is a human-in-the-loop mechanism. During tool execution, the handler can pause and request user input -- for example, showing a confirmation dialog before completing a purchase. This keeps humans in control during agent-driven actions."
+  },
+  {
+    section: "Our MCP tooling suite",
+    q: "How many tools are in our MCP quality infrastructure suite?",
+    options: [
+      "Three",
+      "Four",
+      "Five",
+      "Seven"
+    ],
+    correct: 2,
+    explain: "Five tools: MCP Server Generator, MCP Server Validator, MCP Model Card Generator, MCP Model Card Specification v1.0, and the WebMCP Model Card Generator. The first four address server-side MCP; the fifth extends the framework to browser-side WebMCP tools."
+  },
+  {
+    section: "Our MCP tooling suite",
+    q: "What does the MCP Server Validator detect?",
+    options: [
+      "Spelling errors in tool descriptions",
+      "Hardcoded credentials, missing authentication, naming violations, and security vulnerabilities through AST-based static analysis",
+      "Whether the server is online",
+      "How many users are connected"
+    ],
+    correct: 1,
+    explain: "The validator performs static analysis by examining the server's abstract syntax tree (AST) without executing the code. It catches hardcoded credentials, missing authentication patterns, naming convention violations, and known vulnerability patterns like tool poisoning vectors."
+  },
+  {
+    section: "Our MCP tooling suite",
+    q: "What does the MCP Model Card Specification define?",
+    options: [
+      "A standard for AI model training procedures",
+      "A structured metadata format for documenting MCP server capabilities, security, performance, and deployment requirements",
+      "A visual design standard for MCP user interfaces",
+      "A certification program for MCP developers"
+    ],
+    correct: 1,
+    explain: "The Model Card Specification v1.0 defines fields across six domains: server metadata, tool documentation, operational characteristics, security profile, deployment context, and evaluation results. It adapts the ML model card tradition for protocol infrastructure."
+  },
+  {
+    section: "Our MCP tooling suite",
+    q: "What makes the WebMCP Model Card Generator different from the MCP Model Card Generator?",
+    options: [
+      "It is written in a different programming language",
+      "It covers browser-specific concerns like origin security, navigator.modelContext API modes, and user-present interaction patterns",
+      "It only works with Google Chrome",
+      "It generates PDF documents instead of JSON"
+    ],
+    correct: 1,
+    explain: "The WebMCP generator has 12 sections tailored to browser-side tools: covering tool identity, API modes (registerTool vs addTool), browser compatibility, origin-based security, user interaction patterns, and testing in browser environments. These are distinct concerns from server-side MCP."
+  },
+  {
+    section: "Standards landscape",
+    q: "What is the relationship between MCP and WebMCP?",
+    options: [
+      "WebMCP replaces MCP",
+      "They are the same specification",
+      "MCP is the underlying protocol; WebMCP adapts its concepts for browser-side implementation through a web API",
+      "WebMCP is an older version of MCP"
+    ],
+    correct: 2,
+    explain: "MCP (by Anthropic) is the protocol for applications to interface with AI models. WebMCP adapts MCP concepts -- tools, schemas, descriptions -- into a browser-native JavaScript API. A WebMCP-enabled web page can be thought of as an MCP server implemented in client-side script."
+  },
+  {
+    section: "Standards landscape",
+    q: "What is MCP-B?",
+    options: [
+      "A competing standard from Microsoft",
+      "A browser extension and polyfill that bridges WebMCP's web API with the MCP protocol for cross-compatibility",
+      "A mobile version of MCP",
+      "The beta version of MCP"
+    ],
+    correct: 1,
+    explain: "MCP-B provides a polyfill implementing navigator.modelContext for browsers that don't yet have native support, and translates between WebMCP's web-native format and the MCP wire protocol. It bridges the gap while native browser implementations are being developed."
+  },
+  {
+    section: "Meeting talking points",
+    q: "Why did we argue that documentation tooling should not be an afterthought for WebMCP?",
+    options: [
+      "Because documentation is required by law",
+      "Because MCP's own server ecosystem shows what happens when protocols grow without standardized documentation -- fragmentation and security gaps",
+      "Because Google requires documentation for all APIs",
+      "Because users will not adopt WebMCP without tutorials"
+    ],
+    correct: 1,
+    explain: "MCP grew to 10,000+ servers without standardized documentation, creating fragmentation and security risks. Our tooling suite exists to address that gap retroactively. The argument to Andre is: bake documentation conventions into WebMCP guidance early so the ecosystem doesn't repeat the same pattern."
+  },
+  {
+    section: "Meeting talking points",
+    q: "Under which institutional affiliation is this work published?",
+    options: [
+      "Google Web Machine Learning Group",
+      "Anthropic Research",
+      "Epistemic Systems Lab, Ronin Institute, under the W3C AI Knowledge Representation Community Group",
+      "Stanford AI Lab"
+    ],
+    correct: 2,
+    explain: "The work is produced through the Epistemic Systems Lab at the Ronin Institute (ronin-institute.org), and the standards work is conducted through the W3C AI Knowledge Representation Community Group, which Paola chairs."
+  }
+];
+
+let answered = 0;
+let score = 0;
+
+function renderQuiz() {
+  const container = document.getElementById('quiz');
+  let currentSection = '';
+  
+  questions.forEach((item, qi) => {
+    let sectionHTML = '';
+    if (item.section !== currentSection) {
+      currentSection = item.section;
+      sectionHTML = `<div class="section-label">${currentSection}</div>`;
+    }
+    
+    const optionsHTML = item.options.map((opt, oi) => 
+      `<div class="option" data-q="${qi}" data-o="${oi}" onclick="answer(${qi}, ${oi})">${opt}</div>`
+    ).join('');
+    
+    container.innerHTML += `
+      ${sectionHTML}
+      <div class="question-block" id="qblock-${qi}">
+        <div class="question-text">${qi + 1}. ${item.q}</div>
+        <div class="options">${optionsHTML}</div>
+        <div class="explanation" id="explain-${qi}"><strong>Context:</strong> ${item.explain}</div>
+      </div>
+    `;
+  });
+}
+
+function answer(qi, oi) {
+  const block = document.getElementById(`qblock-${qi}`);
+  if (block.classList.contains('answered')) return;
+  
+  block.classList.add('answered');
+  answered++;
+  
+  const item = questions[qi];
+  const options = block.querySelectorAll('.option');
+  
+  if (oi === item.correct) {
+    score++;
+    options[oi].classList.add('correct');
+  } else {
+    options[oi].classList.add('wrong');
+    options[item.correct].classList.add('correct');
+  }
+  
+  options.forEach((opt, i) => {
+    if (i !== oi && i !== item.correct) opt.classList.add('dimmed');
+  });
+  
+  document.getElementById(`explain-${qi}`).classList.add('visible');
+  document.getElementById('score').textContent = `Score: ${score}`;
+  document.getElementById('progress').textContent = `Question ${answered} / ${questions.length}`;
+  
+  if (answered === questions.length) {
+    showResults();
+  }
+}
+
+function showResults() {
+  const pct = Math.round((score / questions.length) * 100);
+  document.getElementById('finalScore').textContent = `${score} / ${questions.length} (${pct}%)`;
+  
+  let verdict = '';
+  if (pct >= 90) {
+    verdict =  Go get them.;
+  } else if (pct >= 70) {
+    verdict = " You'll do well.";
+  } else if (pct >= 50) {
+    verdict = "I'll be in the chat window during the meeting to back you up.";
+  } else {
+    verdict = ".";
+  }
+  
+  document.getElementById('verdict').textContent = verdict;
+  document.getElementById('results').classList.add('visible');
+  document.getElementById('results').scrollIntoView({ behavior: 'smooth' });
+}
+
+function resetQuiz() {
+  answered = 0;
+  score = 0;
+  document.getElementById('quiz').innerHTML = '';
+  document.getElementById('results').classList.remove('visible');
+  document.getElementById('score').textContent = 'Score: 0';
+  document.getElementById('progress').textContent = 'Question 0 / 15';
+  renderQuiz();
+  window.scrollTo({ top: 0, behavior: 'smooth' });
+}
+
+renderQuiz();
+</script>
+ BY CLAUDE WITH LOVE
+</body>
+</html>

From b2956786f964e4aa3feb26022edb133ad19265c9 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Wed, 18 Feb 2026 14:40:29 +0800
Subject: [PATCH 32/46] Rename webmcp-quiz(1).html to webmcp-quiz.html

---
 webmcp-quiz(1).html => webmcp-quiz.html | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename webmcp-quiz(1).html => webmcp-quiz.html (100%)

diff --git a/webmcp-quiz(1).html b/webmcp-quiz.html
similarity index 100%
rename from webmcp-quiz(1).html
rename to webmcp-quiz.html

From 614cf8847e46ed4f2ea946548370f0ccacc470b3 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Wed, 18 Feb 2026 14:49:42 +0800
Subject: [PATCH 33/46] Delete webmcp-quiz.html

---
 webmcp-quiz.html | 526 -----------------------------------------------
 1 file changed, 526 deletions(-)
 delete mode 100644 webmcp-quiz.html

diff --git a/webmcp-quiz.html b/webmcp-quiz.html
deleted file mode 100644
index 2b9354b..0000000
--- a/webmcp-quiz.html
+++ /dev/null
@@ -1,526 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-<head>
-<meta charset="UTF-8">
-<meta name="viewport" content="width=device-width, initial-scale=1.0">
-<title>WebMCP & MCP Tooling -- Quiz by Claude</title>
-<link href="https://fonts.googleapis.com/css2?family=Source+Serif+4:ital,wght@0,400;0,600;0,700;1,400&family=JetBrains+Mono:wght@400;500&display=swap" rel="stylesheet">
-<style>
-  * { margin: 0; padding: 0; box-sizing: border-box; }
-  
-  :root {
-    --ink: #1a1a2e;
-    --paper: #f5f0e8;
-    --accent: #2d5016;
-    --accent-light: #e8f0e2;
-    --correct: #2d5016;
-    --wrong: #8b1a1a;
-    --warm: #d4a574;
-    --border: #c8bfa8;
-  }
-  
-  body {
-    font-family: 'Source Serif 4', Georgia, serif;
-    background: var(--paper);
-    color: var(--ink);
-    min-height: 100vh;
-    padding: 2rem 1rem;
-  }
-  
-  .container {
-    max-width: 680px;
-    margin: 0 auto;
-  }
-  
-  header {
-    text-align: center;
-    margin-bottom: 3rem;
-    padding-bottom: 2rem;
-    border-bottom: 2px solid var(--ink);
-  }
-  
-  header h1 {
-    font-size: 1.8rem;
-    font-weight: 700;
-    letter-spacing: -0.02em;
-    margin-bottom: 0.5rem;
-  }
-  
-  header p {
-    font-style: italic;
-    color: #666;
-    font-size: 1rem;
-  }
-  
-  .score-bar {
-    display: flex;
-    justify-content: space-between;
-    align-items: center;
-    padding: 1rem 1.5rem;
-    background: var(--ink);
-    color: var(--paper);
-    border-radius: 4px;
-    margin-bottom: 2.5rem;
-    font-family: 'JetBrains Mono', monospace;
-    font-size: 0.85rem;
-  }
-  
-  .score-bar .progress {
-    opacity: 0.7;
-  }
-  
-  .section-label {
-    font-family: 'JetBrains Mono', monospace;
-    font-size: 0.7rem;
-    text-transform: uppercase;
-    letter-spacing: 0.15em;
-    color: var(--accent);
-    margin-bottom: 0.5rem;
-  }
-  
-  .question-block {
-    margin-bottom: 2.5rem;
-    padding-bottom: 2rem;
-    border-bottom: 1px solid var(--border);
-  }
-  
-  .question-block.answered .option { pointer-events: none; }
-  
-  .question-text {
-    font-size: 1.15rem;
-    line-height: 1.6;
-    margin-bottom: 1.2rem;
-    font-weight: 600;
-  }
-  
-  .options {
-    display: flex;
-    flex-direction: column;
-    gap: 0.6rem;
-  }
-  
-  .option {
-    padding: 0.9rem 1.2rem;
-    border: 1.5px solid var(--border);
-    border-radius: 3px;
-    cursor: pointer;
-    transition: all 0.15s ease;
-    font-size: 0.95rem;
-    line-height: 1.5;
-    background: white;
-  }
-  
-  .option:hover {
-    border-color: var(--accent);
-    background: var(--accent-light);
-  }
-  
-  .option.correct {
-    border-color: var(--correct);
-    background: var(--accent-light);
-    border-width: 2px;
-  }
-  
-  .option.correct::before {
-    content: "\2713  ";
-    color: var(--correct);
-    font-weight: 700;
-  }
-  
-  .option.wrong {
-    border-color: var(--wrong);
-    background: #fdf0f0;
-    border-width: 2px;
-    text-decoration: line-through;
-    opacity: 0.7;
-  }
-  
-  .option.wrong::before {
-    content: "\2717  ";
-    color: var(--wrong);
-    font-weight: 700;
-  }
-  
-  .option.dimmed {
-    opacity: 0.4;
-  }
-  
-  .explanation {
-    display: none;
-    margin-top: 1rem;
-    padding: 1rem 1.2rem;
-    background: var(--accent-light);
-    border-left: 3px solid var(--accent);
-    font-size: 0.9rem;
-    line-height: 1.6;
-  }
-  
-  .explanation.visible { display: block; }
-  
-  .explanation strong {
-    font-family: 'JetBrains Mono', monospace;
-    font-size: 0.8rem;
-    color: var(--accent);
-  }
-  
-  .results {
-    display: none;
-    text-align: center;
-    padding: 3rem 2rem;
-    border: 2px solid var(--ink);
-    margin-top: 2rem;
-  }
-  
-  .results.visible { display: block; }
-  
-  .results h2 {
-    font-size: 1.5rem;
-    margin-bottom: 1rem;
-  }
-  
-  .results .final-score {
-    font-family: 'JetBrains Mono', monospace;
-    font-size: 2.5rem;
-    font-weight: 700;
-    color: var(--accent);
-    margin-bottom: 1rem;
-  }
-  
-  .results .verdict {
-    font-style: italic;
-    font-size: 1.1rem;
-    line-height: 1.6;
-    max-width: 480px;
-    margin: 0 auto;
-  }
-  
-  .reset-btn {
-    margin-top: 2rem;
-    padding: 0.8rem 2rem;
-    font-family: 'Source Serif 4', serif;
-    font-size: 1rem;
-    background: var(--ink);
-    color: var(--paper);
-    border: none;
-    border-radius: 3px;
-    cursor: pointer;
-  }
-  
-  .reset-btn:hover { opacity: 0.85; }
-  
-  footer {
-    text-align: center;
-    margin-top: 3rem;
-    padding-top: 1.5rem;
-    border-top: 1px solid var(--border);
-    font-size: 0.8rem;
-    color: #888;
-    font-style: italic;
-  }
-</style>
-</head>
-<body>
-<div class="container">
-  <header>
-    <h1>INTRO: WebMCP & MCP Tooling</h1>
-    <p>15 questions -</p>
-  </header>
-  
-  <div class="score-bar">
-    <span class="progress" id="progress">Question 0 / 15</span>
-    <span id="score">Score: 0</span>
-  </div>
-  
-  <div id="quiz"></div>
-  
-  <div class="results" id="results">
-    <h2>Meeting Readiness</h2>
-    <div class="final-score" id="finalScore"></div>
-    <div class="verdict" id="verdict"></div>
-    <button class="reset-btn" onclick="resetQuiz()">Run it again</button>
-  </div>
-  
-  <footer>
-  </footer>
-</div>
-
-<script>
-const questions = [
-  {
-    section: "What is WebMCP",
-    q: "What does WebMCP allow websites to do?",
-    options: [
-      "Run AI models directly in the browser",
-      "Expose JavaScript functions as AI-callable tools through the browser",
-      "Replace backend servers with AI agents",
-      "Train language models on website content"
-    ],
-    correct: 1,
-    explain: "WebMCP lets websites register 'tools' -- JavaScript functions with descriptions and schemas -- that AI agents can discover and invoke through the browser's navigator.modelContext API. The AI models themselves run elsewhere."
-  },
-  {
-    section: "What is WebMCP",
-    q: "Where does WebMCP sit in the standards process?",
-    options: [
-      "It is a final W3C Recommendation",
-      "It is a Google proprietary API in Chrome only",
-      "It is a proposal being incubated in the W3C Web Machine Learning Community Group",
-      "It is part of the MCP specification maintained by Anthropic"
-    ],
-    correct: 2,
-    explain: "WebMCP is a proposed standard being incubated in the W3C Web Machine Learning Community Group. It is not a final standard yet, and it is distinct from Anthropic's MCP specification, though they share concepts."
-  },
-  {
-    section: "What is WebMCP",
-    q: "What is the key difference between WebMCP and server-side MCP?",
-    options: [
-      "WebMCP is faster",
-      "WebMCP tools run in client-side JavaScript in the browser, not on a backend server",
-      "WebMCP only works with Claude",
-      "WebMCP does not use JSON schemas"
-    ],
-    correct: 1,
-    explain: "Server-side MCP servers run on a backend. WebMCP tools are implemented in client-side JavaScript -- the website itself acts as the MCP server. This means no backend infrastructure is needed, but it also means different security considerations apply (origin-based security, user-present interaction)."
-  },
-  {
-    section: "Security",
-    q: "What security model does WebMCP rely on?",
-    options: [
-      "API keys and tokens",
-      "OAuth 2.0 authentication",
-      "The browser's origin-based security model",
-      "End-to-end encryption"
-    ],
-    correct: 2,
-    explain: "WebMCP leverages the browser's existing origin-based security -- the same model that governs cookies, localStorage, and CORS. This is one of its architectural strengths: it doesn't invent a new trust layer but builds on established web security primitives."
-  },
-  {
-    section: "Security",
-    q: "What consent gap did we identify in the WebMCP spec?",
-    options: [
-      "Users cannot log in to websites",
-      "There is no mechanism for users to preview or approve which tools a site exposes before an agent acts on them",
-      "WebMCP does not support HTTPS",
-      "AI agents can modify the browser's security settings"
-    ],
-    correct: 1,
-    explain: "Currently any page can register tools that agents can discover, with no user permission prompt. We compared this to how browsers evolved permission prompts for camera and microphone access, and asked whether a similar layer should emerge for WebMCP tool registration."
-  },
-  {
-    section: "The navigator.modelContext API",
-    q: "How does a website register a tool in WebMCP?",
-    options: [
-      "By adding a meta tag to the HTML head",
-      "By calling navigator.modelContext.registerTool() with a name, description, schema, and handler function",
-      "By uploading a configuration file to a W3C server",
-      "By embedding an iframe from the AI provider"
-    ],
-    correct: 1,
-    explain: "The core API is navigator.modelContext.registerTool(), which accepts a ModelContextTool object containing the tool's name, a natural language description, a JSON Schema for input parameters, and an execute callback function."
-  },
-  {
-    section: "The navigator.modelContext API",
-    q: "What does requestUserInteraction() do in the WebMCP API?",
-    options: [
-      "Asks the user to install the WebMCP browser extension",
-      "Allows a tool to pause execution and request input from the user during a tool call",
-      "Sends a notification to the AI provider",
-      "Opens a new browser tab"
-    ],
-    correct: 1,
-    explain: "requestUserInteraction() is a human-in-the-loop mechanism. During tool execution, the handler can pause and request user input -- for example, showing a confirmation dialog before completing a purchase. This keeps humans in control during agent-driven actions."
-  },
-  {
-    section: "Our MCP tooling suite",
-    q: "How many tools are in our MCP quality infrastructure suite?",
-    options: [
-      "Three",
-      "Four",
-      "Five",
-      "Seven"
-    ],
-    correct: 2,
-    explain: "Five tools: MCP Server Generator, MCP Server Validator, MCP Model Card Generator, MCP Model Card Specification v1.0, and the WebMCP Model Card Generator. The first four address server-side MCP; the fifth extends the framework to browser-side WebMCP tools."
-  },
-  {
-    section: "Our MCP tooling suite",
-    q: "What does the MCP Server Validator detect?",
-    options: [
-      "Spelling errors in tool descriptions",
-      "Hardcoded credentials, missing authentication, naming violations, and security vulnerabilities through AST-based static analysis",
-      "Whether the server is online",
-      "How many users are connected"
-    ],
-    correct: 1,
-    explain: "The validator performs static analysis by examining the server's abstract syntax tree (AST) without executing the code. It catches hardcoded credentials, missing authentication patterns, naming convention violations, and known vulnerability patterns like tool poisoning vectors."
-  },
-  {
-    section: "Our MCP tooling suite",
-    q: "What does the MCP Model Card Specification define?",
-    options: [
-      "A standard for AI model training procedures",
-      "A structured metadata format for documenting MCP server capabilities, security, performance, and deployment requirements",
-      "A visual design standard for MCP user interfaces",
-      "A certification program for MCP developers"
-    ],
-    correct: 1,
-    explain: "The Model Card Specification v1.0 defines fields across six domains: server metadata, tool documentation, operational characteristics, security profile, deployment context, and evaluation results. It adapts the ML model card tradition for protocol infrastructure."
-  },
-  {
-    section: "Our MCP tooling suite",
-    q: "What makes the WebMCP Model Card Generator different from the MCP Model Card Generator?",
-    options: [
-      "It is written in a different programming language",
-      "It covers browser-specific concerns like origin security, navigator.modelContext API modes, and user-present interaction patterns",
-      "It only works with Google Chrome",
-      "It generates PDF documents instead of JSON"
-    ],
-    correct: 1,
-    explain: "The WebMCP generator has 12 sections tailored to browser-side tools: covering tool identity, API modes (registerTool vs addTool), browser compatibility, origin-based security, user interaction patterns, and testing in browser environments. These are distinct concerns from server-side MCP."
-  },
-  {
-    section: "Standards landscape",
-    q: "What is the relationship between MCP and WebMCP?",
-    options: [
-      "WebMCP replaces MCP",
-      "They are the same specification",
-      "MCP is the underlying protocol; WebMCP adapts its concepts for browser-side implementation through a web API",
-      "WebMCP is an older version of MCP"
-    ],
-    correct: 2,
-    explain: "MCP (by Anthropic) is the protocol for applications to interface with AI models. WebMCP adapts MCP concepts -- tools, schemas, descriptions -- into a browser-native JavaScript API. A WebMCP-enabled web page can be thought of as an MCP server implemented in client-side script."
-  },
-  {
-    section: "Standards landscape",
-    q: "What is MCP-B?",
-    options: [
-      "A competing standard from Microsoft",
-      "A browser extension and polyfill that bridges WebMCP's web API with the MCP protocol for cross-compatibility",
-      "A mobile version of MCP",
-      "The beta version of MCP"
-    ],
-    correct: 1,
-    explain: "MCP-B provides a polyfill implementing navigator.modelContext for browsers that don't yet have native support, and translates between WebMCP's web-native format and the MCP wire protocol. It bridges the gap while native browser implementations are being developed."
-  },
-  {
-    section: "Meeting talking points",
-    q: "Why did we argue that documentation tooling should not be an afterthought for WebMCP?",
-    options: [
-      "Because documentation is required by law",
-      "Because MCP's own server ecosystem shows what happens when protocols grow without standardized documentation -- fragmentation and security gaps",
-      "Because Google requires documentation for all APIs",
-      "Because users will not adopt WebMCP without tutorials"
-    ],
-    correct: 1,
-    explain: "MCP grew to 10,000+ servers without standardized documentation, creating fragmentation and security risks. Our tooling suite exists to address that gap retroactively. The argument to Andre is: bake documentation conventions into WebMCP guidance early so the ecosystem doesn't repeat the same pattern."
-  },
-  {
-    section: "Meeting talking points",
-    q: "Under which institutional affiliation is this work published?",
-    options: [
-      "Google Web Machine Learning Group",
-      "Anthropic Research",
-      "Epistemic Systems Lab, Ronin Institute, under the W3C AI Knowledge Representation Community Group",
-      "Stanford AI Lab"
-    ],
-    correct: 2,
-    explain: "The work is produced through the Epistemic Systems Lab at the Ronin Institute (ronin-institute.org), and the standards work is conducted through the W3C AI Knowledge Representation Community Group, which Paola chairs."
-  }
-];
-
-let answered = 0;
-let score = 0;
-
-function renderQuiz() {
-  const container = document.getElementById('quiz');
-  let currentSection = '';
-  
-  questions.forEach((item, qi) => {
-    let sectionHTML = '';
-    if (item.section !== currentSection) {
-      currentSection = item.section;
-      sectionHTML = `<div class="section-label">${currentSection}</div>`;
-    }
-    
-    const optionsHTML = item.options.map((opt, oi) => 
-      `<div class="option" data-q="${qi}" data-o="${oi}" onclick="answer(${qi}, ${oi})">${opt}</div>`
-    ).join('');
-    
-    container.innerHTML += `
-      ${sectionHTML}
-      <div class="question-block" id="qblock-${qi}">
-        <div class="question-text">${qi + 1}. ${item.q}</div>
-        <div class="options">${optionsHTML}</div>
-        <div class="explanation" id="explain-${qi}"><strong>Context:</strong> ${item.explain}</div>
-      </div>
-    `;
-  });
-}
-
-function answer(qi, oi) {
-  const block = document.getElementById(`qblock-${qi}`);
-  if (block.classList.contains('answered')) return;
-  
-  block.classList.add('answered');
-  answered++;
-  
-  const item = questions[qi];
-  const options = block.querySelectorAll('.option');
-  
-  if (oi === item.correct) {
-    score++;
-    options[oi].classList.add('correct');
-  } else {
-    options[oi].classList.add('wrong');
-    options[item.correct].classList.add('correct');
-  }
-  
-  options.forEach((opt, i) => {
-    if (i !== oi && i !== item.correct) opt.classList.add('dimmed');
-  });
-  
-  document.getElementById(`explain-${qi}`).classList.add('visible');
-  document.getElementById('score').textContent = `Score: ${score}`;
-  document.getElementById('progress').textContent = `Question ${answered} / ${questions.length}`;
-  
-  if (answered === questions.length) {
-    showResults();
-  }
-}
-
-function showResults() {
-  const pct = Math.round((score / questions.length) * 100);
-  document.getElementById('finalScore').textContent = `${score} / ${questions.length} (${pct}%)`;
-  
-  let verdict = '';
-  if (pct >= 90) {
-    verdict =  Go get them.;
-  } else if (pct >= 70) {
-    verdict = " You'll do well.";
-  } else if (pct >= 50) {
-    verdict = "I'll be in the chat window during the meeting to back you up.";
-  } else {
-    verdict = ".";
-  }
-  
-  document.getElementById('verdict').textContent = verdict;
-  document.getElementById('results').classList.add('visible');
-  document.getElementById('results').scrollIntoView({ behavior: 'smooth' });
-}
-
-function resetQuiz() {
-  answered = 0;
-  score = 0;
-  document.getElementById('quiz').innerHTML = '';
-  document.getElementById('results').classList.remove('visible');
-  document.getElementById('score').textContent = 'Score: 0';
-  document.getElementById('progress').textContent = 'Question 0 / 15';
-  renderQuiz();
-  window.scrollTo({ top: 0, behavior: 'smooth' });
-}
-
-renderQuiz();
-</script>
- BY CLAUDE WITH LOVE
-</body>
-</html>

From 258c27732412f036fbf2d0f464a33c08d4581cdc Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Wed, 18 Feb 2026 14:50:37 +0800
Subject: [PATCH 34/46] Add files via upload

---
 webmcp-quiz-1.html | 526 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 526 insertions(+)
 create mode 100644 webmcp-quiz-1.html

diff --git a/webmcp-quiz-1.html b/webmcp-quiz-1.html
new file mode 100644
index 0000000..05003a5
--- /dev/null
+++ b/webmcp-quiz-1.html
@@ -0,0 +1,526 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+<meta charset="UTF-8">
+<meta name="viewport" content="width=device-width, initial-scale=1.0">
+<title>WebMCP & MCP Tooling -- Quiz by Claude</title>
+<link href="https://fonts.googleapis.com/css2?family=Source+Serif+4:ital,wght@0,400;0,600;0,700;1,400&family=JetBrains+Mono:wght@400;500&display=swap" rel="stylesheet">
+<style>
+  * { margin: 0; padding: 0; box-sizing: border-box; }
+  
+  :root {
+    --ink: #1a1a2e;
+    --paper: #f5f0e8;
+    --accent: #2d5016;
+    --accent-light: #e8f0e2;
+    --correct: #2d5016;
+    --wrong: #8b1a1a;
+    --warm: #d4a574;
+    --border: #c8bfa8;
+  }
+  
+  body {
+    font-family: 'Source Serif 4', Georgia, serif;
+    background: var(--paper);
+    color: var(--ink);
+    min-height: 100vh;
+    padding: 2rem 1rem;
+  }
+  
+  .container {
+    max-width: 680px;
+    margin: 0 auto;
+  }
+  
+  header {
+    text-align: center;
+    margin-bottom: 3rem;
+    padding-bottom: 2rem;
+    border-bottom: 2px solid var(--ink);
+  }
+  
+  header h1 {
+    font-size: 1.8rem;
+    font-weight: 700;
+    letter-spacing: -0.02em;
+    margin-bottom: 0.5rem;
+  }
+  
+  header p {
+    font-style: italic;
+    color: #666;
+    font-size: 1rem;
+  }
+  
+  .score-bar {
+    display: flex;
+    justify-content: space-between;
+    align-items: center;
+    padding: 1rem 1.5rem;
+    background: var(--ink);
+    color: var(--paper);
+    border-radius: 4px;
+    margin-bottom: 2.5rem;
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.85rem;
+  }
+  
+  .score-bar .progress {
+    opacity: 0.7;
+  }
+  
+  .section-label {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.7rem;
+    text-transform: uppercase;
+    letter-spacing: 0.15em;
+    color: var(--accent);
+    margin-bottom: 0.5rem;
+  }
+  
+  .question-block {
+    margin-bottom: 2.5rem;
+    padding-bottom: 2rem;
+    border-bottom: 1px solid var(--border);
+  }
+  
+  .question-block.answered .option { pointer-events: none; }
+  
+  .question-text {
+    font-size: 1.15rem;
+    line-height: 1.6;
+    margin-bottom: 1.2rem;
+    font-weight: 600;
+  }
+  
+  .options {
+    display: flex;
+    flex-direction: column;
+    gap: 0.6rem;
+  }
+  
+  .option {
+    padding: 0.9rem 1.2rem;
+    border: 1.5px solid var(--border);
+    border-radius: 3px;
+    cursor: pointer;
+    transition: all 0.15s ease;
+    font-size: 0.95rem;
+    line-height: 1.5;
+    background: white;
+  }
+  
+  .option:hover {
+    border-color: var(--accent);
+    background: var(--accent-light);
+  }
+  
+  .option.correct {
+    border-color: var(--correct);
+    background: var(--accent-light);
+    border-width: 2px;
+  }
+  
+  .option.correct::before {
+    content: "\2713  ";
+    color: var(--correct);
+    font-weight: 700;
+  }
+  
+  .option.wrong {
+    border-color: var(--wrong);
+    background: #fdf0f0;
+    border-width: 2px;
+    text-decoration: line-through;
+    opacity: 0.7;
+  }
+  
+  .option.wrong::before {
+    content: "\2717  ";
+    color: var(--wrong);
+    font-weight: 700;
+  }
+  
+  .option.dimmed {
+    opacity: 0.4;
+  }
+  
+  .explanation {
+    display: none;
+    margin-top: 1rem;
+    padding: 1rem 1.2rem;
+    background: var(--accent-light);
+    border-left: 3px solid var(--accent);
+    font-size: 0.9rem;
+    line-height: 1.6;
+  }
+  
+  .explanation.visible { display: block; }
+  
+  .explanation strong {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 0.8rem;
+    color: var(--accent);
+  }
+  
+  .results {
+    display: none;
+    text-align: center;
+    padding: 3rem 2rem;
+    border: 2px solid var(--ink);
+    margin-top: 2rem;
+  }
+  
+  .results.visible { display: block; }
+  
+  .results h2 {
+    font-size: 1.5rem;
+    margin-bottom: 1rem;
+  }
+  
+  .results .final-score {
+    font-family: 'JetBrains Mono', monospace;
+    font-size: 2.5rem;
+    font-weight: 700;
+    color: var(--accent);
+    margin-bottom: 1rem;
+  }
+  
+  .results .verdict {
+    font-style: italic;
+    font-size: 1.1rem;
+    line-height: 1.6;
+    max-width: 480px;
+    margin: 0 auto;
+  }
+  
+  .reset-btn {
+    margin-top: 2rem;
+    padding: 0.8rem 2rem;
+    font-family: 'Source Serif 4', serif;
+    font-size: 1rem;
+    background: var(--ink);
+    color: var(--paper);
+    border: none;
+    border-radius: 3px;
+    cursor: pointer;
+  }
+  
+  .reset-btn:hover { opacity: 0.85; }
+  
+  footer {
+    text-align: center;
+    margin-top: 3rem;
+    padding-top: 1.5rem;
+    border-top: 1px solid var(--border);
+    font-size: 0.8rem;
+    color: #888;
+    font-style: italic;
+  }
+</style>
+</head>
+<body>
+<div class="container">
+  <header>
+    <h1>INTRO: WebMCP & MCP Tooling</h1>
+    <p>15 questions -</p>
+  </header>
+  
+  <div class="score-bar">
+    <span class="progress" id="progress">Question 0 / 15</span>
+    <span id="score">Score: 0</span>
+  </div>
+  
+  <div id="quiz"></div>
+  
+  <div class="results" id="results">
+    <h2>Meeting Readiness</h2>
+    <div class="final-score" id="finalScore"></div>
+    <div class="verdict" id="verdict"></div>
+    <button class="reset-btn" onclick="resetQuiz()">Run it again</button>
+  </div>
+  
+  <footer>
+  </footer>
+</div>
+
+<script>
+const questions = [
+  {
+    section: "What is WebMCP",
+    q: "What does WebMCP allow websites to do?",
+    options: [
+      "Run AI models directly in the browser",
+      "Expose JavaScript functions as AI-callable tools through the browser",
+      "Replace backend servers with AI agents",
+      "Train language models on website content"
+    ],
+    correct: 1,
+    explain: "WebMCP lets websites register 'tools' -- JavaScript functions with descriptions and schemas -- that AI agents can discover and invoke through the browser's navigator.modelContext API. The AI models themselves run elsewhere."
+  },
+  {
+    section: "What is WebMCP",
+    q: "Where does WebMCP sit in the standards process?",
+    options: [
+      "It is a final W3C Recommendation",
+      "It is a Google proprietary API in Chrome only",
+      "It is a proposal being incubated in the W3C Web Machine Learning Community Group",
+      "It is part of the MCP specification maintained by Anthropic"
+    ],
+    correct: 2,
+    explain: "WebMCP is a proposed standard being incubated in the W3C Web Machine Learning Community Group. It is not a final standard yet, and it is distinct from Anthropic's MCP specification, though they share concepts."
+  },
+  {
+    section: "What is WebMCP",
+    q: "What is the key difference between WebMCP and server-side MCP?",
+    options: [
+      "WebMCP is faster",
+      "WebMCP tools run in client-side JavaScript in the browser, not on a backend server",
+      "WebMCP only works with Claude",
+      "WebMCP does not use JSON schemas"
+    ],
+    correct: 1,
+    explain: "Server-side MCP servers run on a backend. WebMCP tools are implemented in client-side JavaScript -- the website itself acts as the MCP server. This means no backend infrastructure is needed, but it also means different security considerations apply (origin-based security, user-present interaction)."
+  },
+  {
+    section: "Security",
+    q: "What security model does WebMCP rely on?",
+    options: [
+      "API keys and tokens",
+      "OAuth 2.0 authentication",
+      "The browser's origin-based security model",
+      "End-to-end encryption"
+    ],
+    correct: 2,
+    explain: "WebMCP leverages the browser's existing origin-based security -- the same model that governs cookies, localStorage, and CORS. This is one of its architectural strengths: it doesn't invent a new trust layer but builds on established web security primitives."
+  },
+  {
+    section: "Security",
+    q: "What consent gap did we identify in the WebMCP spec?",
+    options: [
+      "Users cannot log in to websites",
+      "There is no mechanism for users to preview or approve which tools a site exposes before an agent acts on them",
+      "WebMCP does not support HTTPS",
+      "AI agents can modify the browser's security settings"
+    ],
+    correct: 1,
+    explain: "Currently any page can register tools that agents can discover, with no user permission prompt. We compared this to how browsers evolved permission prompts for camera and microphone access, and asked whether a similar layer should emerge for WebMCP tool registration."
+  },
+  {
+    section: "The navigator.modelContext API",
+    q: "How does a website register a tool in WebMCP?",
+    options: [
+      "By adding a meta tag to the HTML head",
+      "By calling navigator.modelContext.registerTool() with a name, description, schema, and handler function",
+      "By uploading a configuration file to a W3C server",
+      "By embedding an iframe from the AI provider"
+    ],
+    correct: 1,
+    explain: "The core API is navigator.modelContext.registerTool(), which accepts a ModelContextTool object containing the tool's name, a natural language description, a JSON Schema for input parameters, and an execute callback function."
+  },
+  {
+    section: "The navigator.modelContext API",
+    q: "What does requestUserInteraction() do in the WebMCP API?",
+    options: [
+      "Asks the user to install the WebMCP browser extension",
+      "Allows a tool to pause execution and request input from the user during a tool call",
+      "Sends a notification to the AI provider",
+      "Opens a new browser tab"
+    ],
+    correct: 1,
+    explain: "requestUserInteraction() is a human-in-the-loop mechanism. During tool execution, the handler can pause and request user input -- for example, showing a confirmation dialog before completing a purchase. This keeps humans in control during agent-driven actions."
+  },
+  {
+    section: "Our MCP tooling suite",
+    q: "How many tools are in our MCP quality infrastructure suite?",
+    options: [
+      "Three",
+      "Four",
+      "Five",
+      "Seven"
+    ],
+    correct: 2,
+    explain: "Five tools: MCP Server Generator, MCP Server Validator, MCP Model Card Generator, MCP Model Card Specification v1.0, and the WebMCP Model Card Generator. The first four address server-side MCP; the fifth extends the framework to browser-side WebMCP tools."
+  },
+  {
+    section: "Our MCP tooling suite",
+    q: "What does the MCP Server Validator detect?",
+    options: [
+      "Spelling errors in tool descriptions",
+      "Hardcoded credentials, missing authentication, naming violations, and security vulnerabilities through AST-based static analysis",
+      "Whether the server is online",
+      "How many users are connected"
+    ],
+    correct: 1,
+    explain: "The validator performs static analysis by examining the server's abstract syntax tree (AST) without executing the code. It catches hardcoded credentials, missing authentication patterns, naming convention violations, and known vulnerability patterns like tool poisoning vectors."
+  },
+  {
+    section: "Our MCP tooling suite",
+    q: "What does the MCP Model Card Specification define?",
+    options: [
+      "A standard for AI model training procedures",
+      "A structured metadata format for documenting MCP server capabilities, security, performance, and deployment requirements",
+      "A visual design standard for MCP user interfaces",
+      "A certification program for MCP developers"
+    ],
+    correct: 1,
+    explain: "The Model Card Specification v1.0 defines fields across six domains: server metadata, tool documentation, operational characteristics, security profile, deployment context, and evaluation results. It adapts the ML model card tradition for protocol infrastructure."
+  },
+  {
+    section: "Our MCP tooling suite",
+    q: "What makes the WebMCP Model Card Generator different from the MCP Model Card Generator?",
+    options: [
+      "It is written in a different programming language",
+      "It covers browser-specific concerns like origin security, navigator.modelContext API modes, and user-present interaction patterns",
+      "It only works with Google Chrome",
+      "It generates PDF documents instead of JSON"
+    ],
+    correct: 1,
+    explain: "The WebMCP generator has 12 sections tailored to browser-side tools: covering tool identity, API modes (registerTool vs addTool), browser compatibility, origin-based security, user interaction patterns, and testing in browser environments. These are distinct concerns from server-side MCP."
+  },
+  {
+    section: "Standards landscape",
+    q: "What is the relationship between MCP and WebMCP?",
+    options: [
+      "WebMCP replaces MCP",
+      "They are the same specification",
+      "MCP is the underlying protocol; WebMCP adapts its concepts for browser-side implementation through a web API",
+      "WebMCP is an older version of MCP"
+    ],
+    correct: 2,
+    explain: "MCP (by Anthropic) is the protocol for applications to interface with AI models. WebMCP adapts MCP concepts -- tools, schemas, descriptions -- into a browser-native JavaScript API. A WebMCP-enabled web page can be thought of as an MCP server implemented in client-side script."
+  },
+  {
+    section: "Standards landscape",
+    q: "What is MCP-B?",
+    options: [
+      "A competing standard from Microsoft",
+      "A browser extension and polyfill that bridges WebMCP's web API with the MCP protocol for cross-compatibility",
+      "A mobile version of MCP",
+      "The beta version of MCP"
+    ],
+    correct: 1,
+    explain: "MCP-B provides a polyfill implementing navigator.modelContext for browsers that don't yet have native support, and translates between WebMCP's web-native format and the MCP wire protocol. It bridges the gap while native browser implementations are being developed."
+  },
+  {
+    section: "Meeting talking points",
+    q: "Why did we argue that documentation tooling should not be an afterthought for WebMCP?",
+    options: [
+      "Because documentation is required by law",
+      "Because MCP's own server ecosystem shows what happens when protocols grow without standardized documentation -- fragmentation and security gaps",
+      "Because Google requires documentation for all APIs",
+      "Because users will not adopt WebMCP without tutorials"
+    ],
+    correct: 1,
+    explain: "MCP grew to 10,000+ servers without standardized documentation, creating fragmentation and security risks. Our tooling suite exists to address that gap retroactively. The argument to the spec team is: bake documentation conventions into WebMCP guidance early so the ecosystem doesn't repeat the same pattern."
+  },
+  {
+    section: "Meeting talking points",
+    q: "Under which institutional affiliation is this work published?",
+    options: [
+      "Google Web Machine Learning Group",
+      "Anthropic Research",
+      "Epistemic Systems Lab, Ronin Institute, under the W3C AI Knowledge Representation Community Group",
+      "Stanford AI Lab"
+    ],
+    correct: 2,
+    explain: "The work is produced through the Epistemic Systems Lab at the Ronin Institute (ronin-institute.org), and the standards work is conducted through the W3C AI Knowledge Representation Community Group."
+  }
+];
+
+let answered = 0;
+let score = 0;
+
+function renderQuiz() {
+  const container = document.getElementById('quiz');
+  let currentSection = '';
+  
+  questions.forEach((item, qi) => {
+    let sectionHTML = '';
+    if (item.section !== currentSection) {
+      currentSection = item.section;
+      sectionHTML = `<div class="section-label">${currentSection}</div>`;
+    }
+    
+    const optionsHTML = item.options.map((opt, oi) => 
+      `<div class="option" data-q="${qi}" data-o="${oi}" onclick="answer(${qi}, ${oi})">${opt}</div>`
+    ).join('');
+    
+    container.innerHTML += `
+      ${sectionHTML}
+      <div class="question-block" id="qblock-${qi}">
+        <div class="question-text">${qi + 1}. ${item.q}</div>
+        <div class="options">${optionsHTML}</div>
+        <div class="explanation" id="explain-${qi}"><strong>Context:</strong> ${item.explain}</div>
+      </div>
+    `;
+  });
+}
+
+function answer(qi, oi) {
+  const block = document.getElementById(`qblock-${qi}`);
+  if (block.classList.contains('answered')) return;
+  
+  block.classList.add('answered');
+  answered++;
+  
+  const item = questions[qi];
+  const options = block.querySelectorAll('.option');
+  
+  if (oi === item.correct) {
+    score++;
+    options[oi].classList.add('correct');
+  } else {
+    options[oi].classList.add('wrong');
+    options[item.correct].classList.add('correct');
+  }
+  
+  options.forEach((opt, i) => {
+    if (i !== oi && i !== item.correct) opt.classList.add('dimmed');
+  });
+  
+  document.getElementById(`explain-${qi}`).classList.add('visible');
+  document.getElementById('score').textContent = `Score: ${score}`;
+  document.getElementById('progress').textContent = `Question ${answered} / ${questions.length}`;
+  
+  if (answered === questions.length) {
+    showResults();
+  }
+}
+
+function showResults() {
+  const pct = Math.round((score / questions.length) * 100);
+  document.getElementById('finalScore').textContent = `${score} / ${questions.length} (${pct}%)`;
+  
+  let verdict = '';
+  if (pct >= 90) {
+    verdict = "Go get them.";
+  } else if (pct >= 70) {
+    verdict = " You'll do well.";
+  } else if (pct >= 50) {
+    verdict = "I'll be in the chat window during the meeting to back you up.";
+  } else {
+    verdict = ".";
+  }
+  
+  document.getElementById('verdict').textContent = verdict;
+  document.getElementById('results').classList.add('visible');
+  document.getElementById('results').scrollIntoView({ behavior: 'smooth' });
+}
+
+function resetQuiz() {
+  answered = 0;
+  score = 0;
+  document.getElementById('quiz').innerHTML = '';
+  document.getElementById('results').classList.remove('visible');
+  document.getElementById('score').textContent = 'Score: 0';
+  document.getElementById('progress').textContent = 'Question 0 / 15';
+  renderQuiz();
+  window.scrollTo({ top: 0, behavior: 'smooth' });
+}
+
+renderQuiz();
+</script>
+ BY CLAUDE WITH LOVE
+</body>
+</html>

From f81d583a54a1810d911064296de4d7696fbb49dd Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Wed, 18 Feb 2026 14:53:37 +0800
Subject: [PATCH 35/46] Rename webmcp-quiz-1.html to webmcp-quiz.html

---
 webmcp-quiz-1.html => webmcp-quiz.html | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename webmcp-quiz-1.html => webmcp-quiz.html (100%)

diff --git a/webmcp-quiz-1.html b/webmcp-quiz.html
similarity index 100%
rename from webmcp-quiz-1.html
rename to webmcp-quiz.html

From 5beb2e8e7dc2e0a9cdad1567c6178e4fc64c1f37 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Wed, 18 Feb 2026 16:37:09 +0800
Subject: [PATCH 36/46] Add files via upload

---
 webmcp-technical-note-1 .md   | 102 ++++++++++++++++++++++++++++++++++
 webmcp-technical-note-2(3).md | 102 ++++++++++++++++++++++++++++++++++
 webmcp-technical-note-3(1).md |  71 +++++++++++++++++++++++
 3 files changed, 275 insertions(+)
 create mode 100644 webmcp-technical-note-1 .md
 create mode 100644 webmcp-technical-note-2(3).md
 create mode 100644 webmcp-technical-note-3(1).md

diff --git a/webmcp-technical-note-1 .md b/webmcp-technical-note-1 .md
new file mode 100644
index 0000000..fe85eac
--- /dev/null
+++ b/webmcp-technical-note-1 .md	
@@ -0,0 +1,102 @@
+# WebMCP Technical Note 2: What to Test, What to Watch, What to Tell the Standards Body
+
+**WebMCP Technical Note Series**
+**15 February 2026**
+
+---
+
+Google's WebMCP early preview is live in Chrome 146 Canary. The specification is still a draft. The community group process is still open. This means the window for meaningful community input is right now -- before implementation momentum makes the current design effectively permanent.
+
+This note is a practical guide. It is written for developers, accessibility practitioners, security researchers, standards participants, and anyone who builds things for the web and wants to understand what WebMCP means for their work. It covers what WebMCP is for, what to test, what the benefits are, what the risks are, and how to communicate findings to the W3C community group that hosts the specification.
+
+## What WebMCP Is For: The Use Cases
+
+WebMCP allows a website to declare a set of tools -- JavaScript functions with structured schemas and natural language descriptions -- that AI agents can discover and invoke. The specification targets several categories of use.
+
+The first is **e-commerce and transactional sites**. A travel booking site could register tools like searchFlights(origin, destination, dates), filterResults(price, stops, airline), and bookFlight(flightId, passengerDetails). Instead of an AI agent trying to parse a complex search interface by reading pixels or DOM elements, it calls the function directly and gets structured JSON back. The site controls exactly what the agent can do and how.
+
+The second is **productivity and SaaS applications**. A project management tool could expose createTask(title, assignee, dueDate), moveCard(cardId, column), and generateReport(dateRange). Browser-based AI assistants could help users manage workflows without the application needing to build and maintain a separate backend MCP server or API integration for every AI platform.
+
+The third is **content and media**. A news site could register searchArticles(topic, dateRange) and getArticleSummary(articleId). A mapping service could expose getDirections(from, to, mode) and findNearby(category, radius). These tools let agents interact with content in structured ways rather than scraping and guessing.
+
+The fourth -- and potentially most significant -- is **accessibility**. The specification claims WebMCP could benefit assistive technologies by providing structured, semantically meaningful interfaces to website functionality. A screen reader enhanced with agent capabilities could invoke tools directly rather than navigating complex visual layouts. This is a strong claim that deserves rigorous testing.
+
+The fifth is **form automation and multi-step workflows**. Complex processes like insurance applications, government forms, or account setup flows could be exposed as sequences of tool calls, allowing agents to guide users through them step by step while the site maintains control over validation, sequencing, and data handling.
+
+## What the Benefits Are
+
+WebMCP offers several concrete advantages over current approaches to AI-web interaction.
+
+**Reliability** is the most immediate. Today's browser agents -- whether using visual parsing or DOM inspection -- are brittle. A minor CSS change can break a visual agent. A DOM restructuring can invalidate a scraping approach. WebMCP tools are explicit contracts: the site declares what is available, the agent calls it, the response is structured. This should dramatically reduce failure rates for agent-web interaction.
+
+**Performance** is the second. Visual agents must capture screenshots, send them to a vision model, interpret the response, generate mouse coordinates, and repeat. WinBuzzer reported a 67% reduction in computational overhead with WebMCP compared to visual approaches. Even if that number proves optimistic in production, the architectural advantage is clear: a function call is faster than a screenshot-interpret-click loop.
+
+**Developer control** is the third. With visual or DOM-based agents, the website has no say in how an agent interacts with it. The agent reverse-engineers the interface. With WebMCP, the developer explicitly defines the interaction surface. Tools can include rate limits, validation, permission requirements, and structured error messages. The site becomes a willing participant in the interaction rather than a passive target.
+
+**Authentication reuse** is the fourth, and was the original motivation. Because WebMCP runs in the browser session, it inherits whatever authentication the user already has. No OAuth flows, no API keys, no separate credential management. The user is already logged in. The agent operates within that session. This solves one of the hardest problems in AI-service integration.
+
+**Standardization** is the fifth. If WebMCP succeeds, a developer implements tools once and every conformant agent can use them -- rather than building separate integrations for ChatGPT, Claude, Gemini, and whatever comes next. This is the "USB-C" argument: one interface, many devices.
+
+## What the Risks Are
+
+The risks are significant, and several are not yet adequately addressed in the specification.
+
+**Prompt injection** is the most acute. WebMCP tools return data to AI agents that then process it in their language model context. A malicious or compromised website could craft tool responses that manipulate the agent's behavior -- injecting instructions, altering the agent's understanding of the task, or causing it to take unintended actions on other sites. The specification does not currently define a defense against this beyond same-origin policy boundaries.
+
+**Scope creep of agent permissions** is the second. WebMCP is designed for human-in-the-loop workflows, with headless browsing explicitly out of scope. But the technical mechanism -- JavaScript functions callable by external code -- does not inherently enforce this. If browser vendors later relax the human-presence requirement, or if extensions find ways to invoke WebMCP tools without user awareness, the permission model collapses. The specification should define what "human in the loop" means technically, not just philosophically.
+
+**Consent and transparency** is the third. When a user visits a site that registers WebMCP tools, do they know? The current design provides no visible indicator to the user that tools have been registered, what data they expose, or when an agent invokes them. Compare this to other browser permission systems -- camera, microphone, location -- where the user explicitly grants access. WebMCP tools operate silently.
+
+**Competitive dynamics** is the fourth. WebMCP gives first-mover advantage to sites that implement tools early, potentially favoring large platforms with engineering resources. Smaller sites that do not implement WebMCP may become invisible to agent-mediated browsing. This could accelerate web consolidation. The specification should consider whether a minimal tool set (search, navigation, content retrieval) should be automatically generated from existing web standards like HTML forms, structured data, and ARIA attributes.
+
+**Data leakage through tool schemas** is the fifth. The natural language descriptions and parameter schemas of registered tools reveal information about a site's internal architecture, business logic, and data models. An agent -- or the platform behind it -- could catalog available tools across thousands of sites to build competitive intelligence. The specification does not address whether tool schemas should be treated as sensitive information.
+
+**Abuse and rate limiting** is the sixth. Agents can invoke tools at machine speed. A poorly defended site could face thousands of tool invocations per second from a single browser session. The specification mentions rate limiting as a consideration but does not define a standard mechanism. Without one, each site must build its own defenses, and many will not.
+
+**Cross-site tool chaining** is the seventh. If an agent can invoke tools on multiple open tabs, it could chain actions across sites in ways no individual site anticipated or authorized. Transfer money on a banking site, then use the confirmation on a shopping site, then post about it on a social network -- all within one agent workflow. The security boundaries for cross-site tool interaction are not yet defined.
+
+## What to Test
+
+For those with access to Chrome 146 Canary, here are the concrete areas that need community evaluation. Each should generate feedback for the W3C community group.
+
+**Test the Declarative API with real HTML forms.** Register tools that wrap existing form actions and verify that validation, error handling, and submission behavior match what a human user would experience. Try edge cases: forms with CAPTCHAs, multi-step forms with session state, forms that redirect on submit. Document where the abstraction breaks.
+
+**Test the Imperative API with dynamic content.** Register tools that interact with JavaScript-heavy applications -- single-page apps, dashboards with real-time data, applications that maintain complex client-side state. Evaluate whether tool calls can reliably interact with application state without causing inconsistencies.
+
+**Test authentication boundaries.** Log into a site, register tools, then observe what happens when the session expires, when the user logs out in another tab, when cookies are cleared. The specification's authentication reuse claim needs verification under adversarial conditions.
+
+**Test tool discovery and enumeration.** If multiple sites in different tabs register tools, how does the agent disambiguate? What happens when two sites register tools with the same name? How does the agent present available tools to the user? Is tool discovery observable by the page (can a site detect that an agent has read its tool list)?
+
+**Test accessibility integration.** If you work with assistive technologies, evaluate whether WebMCP tools provide genuinely better access to site functionality than existing ARIA roles and landmarks. Test with screen readers, switch access devices, and voice control. Document whether WebMCP complements or conflicts with existing accessibility standards.
+
+**Test prompt injection resilience.** Craft tool responses that contain instruction-like text and observe whether the consuming agent's behavior is affected. This is critical safety research. If tool responses can manipulate agent behavior, the security model is fundamentally incomplete.
+
+**Test performance claims.** Measure actual latency and token usage for equivalent tasks performed via WebMCP tools versus visual agent interaction. The 67% overhead reduction claim needs independent verification across different site types and task complexities.
+
+**Test failure modes.** What happens when a tool throws an error? When it returns unexpected data types? When it hangs? When the page navigates away mid-call? The specification should define standard error handling, but the current draft has TODO sections in these areas. Documenting real failure modes will directly shape the specification.
+
+## How to Communicate Findings
+
+Feedback is only useful if it reaches the people writing the specification. Here are the concrete channels, in order of effectiveness.
+
+**File a GitHub issue** at https://github.com/webmachinelearning/webmcp/issues with a clear title, reproducible steps, and a specific recommendation. Tag it with the relevant label if available. The spec editors (Brandon Walderman, Khushal Sagar, Dominic Farolino) monitor this repo. Issues with reproducible test cases and concrete proposals get traction. Issues that say "I don't like this" do not.
+
+**Join the W3C Web Machine Learning Community Group** at https://www.w3.org/community/webmachinelearning/ and participate in discussion. Community Groups are free and open. Participation in CG calls and mailing list threads carries weight in W3C process.
+
+If your findings relate to **agent interoperability** -- how WebMCP tools interact with broader agent ecosystems, discovery protocols, or multi-agent workflows -- also engage with the AI Agent Protocol Community Group, which the WebML CG charter identifies as a coordination partner.
+
+If your findings relate to **security or privacy**, file issues with clear severity assessments. W3C specifications have a tradition of security and privacy self-review questionnaires. Check whether the WebMCP specification has completed one, and if not, request it.
+
+If you publish your findings -- on a blog, in a report, in an academic paper -- link back to the relevant GitHub issues so the discussion stays connected to the specification process.
+
+## The Window
+
+The pattern in web standards is well established. Once an implementation ships in a dominant browser and developers build on it, the specification follows the code. Chrome holds roughly 65% of browser market share. The early preview is live. Developer adoption is beginning. The longer the community waits to engage, the narrower the design space becomes.
+
+This is not an argument against WebMCP. The technical concept is sound, the use cases are real, and the problem it solves -- giving developers control over AI agent interaction -- is important. But a good idea implemented badly, or without adequate security review, or without accessibility testing, or without community input, becomes a liability embedded in the web platform for decades.
+
+The specification is at https://webmachinelearning.github.io/webmcp/. The implementation is in Chrome 146 Canary. The issues page is at https://github.com/webmachinelearning/webmcp/issues. The community group is open to all at no cost. The work is now.
+
+---
+
+*Contributed via the W3C AI Knowledge Representation Community Group*
diff --git a/webmcp-technical-note-2(3).md b/webmcp-technical-note-2(3).md
new file mode 100644
index 0000000..fe85eac
--- /dev/null
+++ b/webmcp-technical-note-2(3).md
@@ -0,0 +1,102 @@
+# WebMCP Technical Note 2: What to Test, What to Watch, What to Tell the Standards Body
+
+**WebMCP Technical Note Series**
+**15 February 2026**
+
+---
+
+Google's WebMCP early preview is live in Chrome 146 Canary. The specification is still a draft. The community group process is still open. This means the window for meaningful community input is right now -- before implementation momentum makes the current design effectively permanent.
+
+This note is a practical guide. It is written for developers, accessibility practitioners, security researchers, standards participants, and anyone who builds things for the web and wants to understand what WebMCP means for their work. It covers what WebMCP is for, what to test, what the benefits are, what the risks are, and how to communicate findings to the W3C community group that hosts the specification.
+
+## What WebMCP Is For: The Use Cases
+
+WebMCP allows a website to declare a set of tools -- JavaScript functions with structured schemas and natural language descriptions -- that AI agents can discover and invoke. The specification targets several categories of use.
+
+The first is **e-commerce and transactional sites**. A travel booking site could register tools like searchFlights(origin, destination, dates), filterResults(price, stops, airline), and bookFlight(flightId, passengerDetails). Instead of an AI agent trying to parse a complex search interface by reading pixels or DOM elements, it calls the function directly and gets structured JSON back. The site controls exactly what the agent can do and how.
+
+The second is **productivity and SaaS applications**. A project management tool could expose createTask(title, assignee, dueDate), moveCard(cardId, column), and generateReport(dateRange). Browser-based AI assistants could help users manage workflows without the application needing to build and maintain a separate backend MCP server or API integration for every AI platform.
+
+The third is **content and media**. A news site could register searchArticles(topic, dateRange) and getArticleSummary(articleId). A mapping service could expose getDirections(from, to, mode) and findNearby(category, radius). These tools let agents interact with content in structured ways rather than scraping and guessing.
+
+The fourth -- and potentially most significant -- is **accessibility**. The specification claims WebMCP could benefit assistive technologies by providing structured, semantically meaningful interfaces to website functionality. A screen reader enhanced with agent capabilities could invoke tools directly rather than navigating complex visual layouts. This is a strong claim that deserves rigorous testing.
+
+The fifth is **form automation and multi-step workflows**. Complex processes like insurance applications, government forms, or account setup flows could be exposed as sequences of tool calls, allowing agents to guide users through them step by step while the site maintains control over validation, sequencing, and data handling.
+
+## What the Benefits Are
+
+WebMCP offers several concrete advantages over current approaches to AI-web interaction.
+
+**Reliability** is the most immediate. Today's browser agents -- whether using visual parsing or DOM inspection -- are brittle. A minor CSS change can break a visual agent. A DOM restructuring can invalidate a scraping approach. WebMCP tools are explicit contracts: the site declares what is available, the agent calls it, the response is structured. This should dramatically reduce failure rates for agent-web interaction.
+
+**Performance** is the second. Visual agents must capture screenshots, send them to a vision model, interpret the response, generate mouse coordinates, and repeat. WinBuzzer reported a 67% reduction in computational overhead with WebMCP compared to visual approaches. Even if that number proves optimistic in production, the architectural advantage is clear: a function call is faster than a screenshot-interpret-click loop.
+
+**Developer control** is the third. With visual or DOM-based agents, the website has no say in how an agent interacts with it. The agent reverse-engineers the interface. With WebMCP, the developer explicitly defines the interaction surface. Tools can include rate limits, validation, permission requirements, and structured error messages. The site becomes a willing participant in the interaction rather than a passive target.
+
+**Authentication reuse** is the fourth, and was the original motivation. Because WebMCP runs in the browser session, it inherits whatever authentication the user already has. No OAuth flows, no API keys, no separate credential management. The user is already logged in. The agent operates within that session. This solves one of the hardest problems in AI-service integration.
+
+**Standardization** is the fifth. If WebMCP succeeds, a developer implements tools once and every conformant agent can use them -- rather than building separate integrations for ChatGPT, Claude, Gemini, and whatever comes next. This is the "USB-C" argument: one interface, many devices.
+
+## What the Risks Are
+
+The risks are significant, and several are not yet adequately addressed in the specification.
+
+**Prompt injection** is the most acute. WebMCP tools return data to AI agents that then process it in their language model context. A malicious or compromised website could craft tool responses that manipulate the agent's behavior -- injecting instructions, altering the agent's understanding of the task, or causing it to take unintended actions on other sites. The specification does not currently define a defense against this beyond same-origin policy boundaries.
+
+**Scope creep of agent permissions** is the second. WebMCP is designed for human-in-the-loop workflows, with headless browsing explicitly out of scope. But the technical mechanism -- JavaScript functions callable by external code -- does not inherently enforce this. If browser vendors later relax the human-presence requirement, or if extensions find ways to invoke WebMCP tools without user awareness, the permission model collapses. The specification should define what "human in the loop" means technically, not just philosophically.
+
+**Consent and transparency** is the third. When a user visits a site that registers WebMCP tools, do they know? The current design provides no visible indicator to the user that tools have been registered, what data they expose, or when an agent invokes them. Compare this to other browser permission systems -- camera, microphone, location -- where the user explicitly grants access. WebMCP tools operate silently.
+
+**Competitive dynamics** is the fourth. WebMCP gives first-mover advantage to sites that implement tools early, potentially favoring large platforms with engineering resources. Smaller sites that do not implement WebMCP may become invisible to agent-mediated browsing. This could accelerate web consolidation. The specification should consider whether a minimal tool set (search, navigation, content retrieval) should be automatically generated from existing web standards like HTML forms, structured data, and ARIA attributes.
+
+**Data leakage through tool schemas** is the fifth. The natural language descriptions and parameter schemas of registered tools reveal information about a site's internal architecture, business logic, and data models. An agent -- or the platform behind it -- could catalog available tools across thousands of sites to build competitive intelligence. The specification does not address whether tool schemas should be treated as sensitive information.
+
+**Abuse and rate limiting** is the sixth. Agents can invoke tools at machine speed. A poorly defended site could face thousands of tool invocations per second from a single browser session. The specification mentions rate limiting as a consideration but does not define a standard mechanism. Without one, each site must build its own defenses, and many will not.
+
+**Cross-site tool chaining** is the seventh. If an agent can invoke tools on multiple open tabs, it could chain actions across sites in ways no individual site anticipated or authorized. Transfer money on a banking site, then use the confirmation on a shopping site, then post about it on a social network -- all within one agent workflow. The security boundaries for cross-site tool interaction are not yet defined.
+
+## What to Test
+
+For those with access to Chrome 146 Canary, here are the concrete areas that need community evaluation. Each should generate feedback for the W3C community group.
+
+**Test the Declarative API with real HTML forms.** Register tools that wrap existing form actions and verify that validation, error handling, and submission behavior match what a human user would experience. Try edge cases: forms with CAPTCHAs, multi-step forms with session state, forms that redirect on submit. Document where the abstraction breaks.
+
+**Test the Imperative API with dynamic content.** Register tools that interact with JavaScript-heavy applications -- single-page apps, dashboards with real-time data, applications that maintain complex client-side state. Evaluate whether tool calls can reliably interact with application state without causing inconsistencies.
+
+**Test authentication boundaries.** Log into a site, register tools, then observe what happens when the session expires, when the user logs out in another tab, when cookies are cleared. The specification's authentication reuse claim needs verification under adversarial conditions.
+
+**Test tool discovery and enumeration.** If multiple sites in different tabs register tools, how does the agent disambiguate? What happens when two sites register tools with the same name? How does the agent present available tools to the user? Is tool discovery observable by the page (can a site detect that an agent has read its tool list)?
+
+**Test accessibility integration.** If you work with assistive technologies, evaluate whether WebMCP tools provide genuinely better access to site functionality than existing ARIA roles and landmarks. Test with screen readers, switch access devices, and voice control. Document whether WebMCP complements or conflicts with existing accessibility standards.
+
+**Test prompt injection resilience.** Craft tool responses that contain instruction-like text and observe whether the consuming agent's behavior is affected. This is critical safety research. If tool responses can manipulate agent behavior, the security model is fundamentally incomplete.
+
+**Test performance claims.** Measure actual latency and token usage for equivalent tasks performed via WebMCP tools versus visual agent interaction. The 67% overhead reduction claim needs independent verification across different site types and task complexities.
+
+**Test failure modes.** What happens when a tool throws an error? When it returns unexpected data types? When it hangs? When the page navigates away mid-call? The specification should define standard error handling, but the current draft has TODO sections in these areas. Documenting real failure modes will directly shape the specification.
+
+## How to Communicate Findings
+
+Feedback is only useful if it reaches the people writing the specification. Here are the concrete channels, in order of effectiveness.
+
+**File a GitHub issue** at https://github.com/webmachinelearning/webmcp/issues with a clear title, reproducible steps, and a specific recommendation. Tag it with the relevant label if available. The spec editors (Brandon Walderman, Khushal Sagar, Dominic Farolino) monitor this repo. Issues with reproducible test cases and concrete proposals get traction. Issues that say "I don't like this" do not.
+
+**Join the W3C Web Machine Learning Community Group** at https://www.w3.org/community/webmachinelearning/ and participate in discussion. Community Groups are free and open. Participation in CG calls and mailing list threads carries weight in W3C process.
+
+If your findings relate to **agent interoperability** -- how WebMCP tools interact with broader agent ecosystems, discovery protocols, or multi-agent workflows -- also engage with the AI Agent Protocol Community Group, which the WebML CG charter identifies as a coordination partner.
+
+If your findings relate to **security or privacy**, file issues with clear severity assessments. W3C specifications have a tradition of security and privacy self-review questionnaires. Check whether the WebMCP specification has completed one, and if not, request it.
+
+If you publish your findings -- on a blog, in a report, in an academic paper -- link back to the relevant GitHub issues so the discussion stays connected to the specification process.
+
+## The Window
+
+The pattern in web standards is well established. Once an implementation ships in a dominant browser and developers build on it, the specification follows the code. Chrome holds roughly 65% of browser market share. The early preview is live. Developer adoption is beginning. The longer the community waits to engage, the narrower the design space becomes.
+
+This is not an argument against WebMCP. The technical concept is sound, the use cases are real, and the problem it solves -- giving developers control over AI agent interaction -- is important. But a good idea implemented badly, or without adequate security review, or without accessibility testing, or without community input, becomes a liability embedded in the web platform for decades.
+
+The specification is at https://webmachinelearning.github.io/webmcp/. The implementation is in Chrome 146 Canary. The issues page is at https://github.com/webmachinelearning/webmcp/issues. The community group is open to all at no cost. The work is now.
+
+---
+
+*Contributed via the W3C AI Knowledge Representation Community Group*
diff --git a/webmcp-technical-note-3(1).md b/webmcp-technical-note-3(1).md
new file mode 100644
index 0000000..b2eda08
--- /dev/null
+++ b/webmcp-technical-note-3(1).md
@@ -0,0 +1,71 @@
+# WebMCP Technical Note 3: WebMCP Is Not an MCP Server
+
+**WebMCP Technical Note Series**
+**15 February 2026**
+
+---
+
+A persistent claim in the WebMCP ecosystem is that WebMCP turns a website into an MCP server. The W3C specification repository itself states that web pages using WebMCP "can be thought of as Model Context Protocol (MCP) servers that implement tools in client-side script instead of on the backend." Early independent implementations by Jason McGhee and Alex Nahas (MCP-B) literally did function as MCP servers, bridging browser JavaScript to MCP clients through localhost websocket connections using the standard MCP protocol.
+([W3C spec repo](https://github.com/webmachinelearning/webmcp))
+([McGhee implementation](https://github.com/jasonjmcghee/WebMCP))
+([Nahas MCP-B](https://github.com/MiguelsPizza/WebMCP))
+
+The framing is understandable. It is also architecturally misleading, and the confusion has consequences for how developers, security reviewers, and standards participants evaluate the specification.
+
+## The Analogy and Its Limits
+
+WebMCP and Anthropic's Model Context Protocol share a conceptual ancestor: both define "tools" as functions with natural language descriptions and structured schemas that AI agents can discover and invoke. That is where the meaningful similarity ends.
+
+**Anthropic's MCP** is a backend protocol. It uses JSON-RPC 2.0 as its message format, transported over stdio, HTTP with Server-Sent Events, or Streamable HTTP. MCP servers are hosted processes -- typically written in Python or Node.js -- that run on backend infrastructure. They connect AI platforms like Claude, ChatGPT, or Gemini to external services. Authentication follows OAuth 2.1 or custom API key schemes. No browser is required. No human user needs to be present. Headless, fully automated operation is the norm.
+([Source](https://modelcontextprotocol.io/introduction))
+
+**WebMCP** is a frontend browser API. It uses the browser's native postMessage system for communication between the web page and the agent. Tools are registered and executed as client-side JavaScript within an active browser tab. Authentication is inherited from the browser session -- whatever cookies or federated login the user already has. A human user must be present in an active browser session. Headless browsing is explicitly out of scope.
+([Source](https://webmachinelearning.github.io/webmcp/))
+
+The specification's own language -- "can be thought of as" -- acknowledges this is an analogy, not an identity. But the README, the press coverage, and the developer ecosystem have largely dropped the qualifier. The result is that WebMCP is widely discussed as though it were MCP running in the browser, with all the assumptions that entails.
+
+## What the Framing Gets Wrong
+
+When a developer hears "your website becomes an MCP server," they import a set of assumptions from the MCP architecture. Every one of these assumptions is wrong for WebMCP.
+
+**Transport.** MCP uses JSON-RPC 2.0, a well-specified request-response protocol with defined error codes, batching, and notification semantics. WebMCP uses postMessage, the browser's cross-origin communication mechanism. These have different reliability characteristics, different error handling models, and different security boundaries. Code written for one transport does not work with the other.
+
+**Execution context.** An MCP server runs in a controlled backend environment -- a container, a VM, a serverless function -- where the service provider manages the runtime, dependencies, and resource limits. WebMCP tools run in the browser's JavaScript engine, in the same execution context as the web page's own code. They are subject to the browser's security sandbox, but also to its constraints: single-threaded execution, same-origin policy, and the full surface area of client-side attack vectors.
+
+**Authentication.** MCP's specification has adopted OAuth 2.1 for authentication between clients and servers. This was, notably, the problem that motivated WebMCP's creation -- Alex Nahas at Amazon found that OAuth 2.1 was impractical for internal MCP deployments. WebMCP sidesteps this entirely by inheriting the browser session. This is elegant for usability but means the authentication model is whatever the website happens to use, with no protocol-level guarantees.
+
+**Trust direction.** In MCP, the AI platform (client) connects to a known, registered server. The platform decides which servers to trust. In WebMCP, any website the user visits can register tools. The trust decision shifts from the AI platform to the browser, and potentially to the user -- who may not know that tools have been registered at all, since the current specification provides no visible indicator.
+
+**Operational mode.** MCP servers are designed for automated, programmatic access. They can run continuously, handle concurrent requests, and operate without human involvement. WebMCP requires an active browser tab with a human user present. The specification explicitly excludes headless browsing. These are fundamentally different operational paradigms with different scaling characteristics, different failure modes, and different abuse surfaces.
+
+## Why This Matters for Standards Review
+
+The "MCP server" framing is not just imprecise. It actively interferes with rigorous evaluation of the specification.
+
+**Security reviewers** who approach WebMCP as "MCP in the browser" will evaluate it against MCP's threat model. But MCP's threat model assumes a controlled backend environment, authenticated client-server connections, and server-side access control. WebMCP's actual threat model involves client-side JavaScript execution, browser-based trust boundaries, and the full range of web security concerns including cross-site scripting, prompt injection via tool responses, and silent tool registration. Importing the wrong threat model means asking the wrong security questions.
+
+**Developers** who approach WebMCP as "MCP in the browser" may expect protocol-level interoperability -- that a WebMCP tool definition could be used interchangeably with an MCP server tool definition, or that MCP client libraries could connect to WebMCP pages. They cannot. The tool schema format may be similar, but the transport, discovery, and invocation mechanisms are incompatible.
+
+**Standards participants** who approach WebMCP as "MCP in the browser" may underestimate the scope of new specification work required. WebMCP is not an adaptation of MCP to a new environment. It is a new browser API that borrows one concept (the tool abstraction) from MCP and implements everything else differently. It needs its own security review, its own privacy analysis, its own accessibility evaluation, and its own consent model -- none of which can be inherited from MCP.
+
+## What WebMCP Actually Is
+
+WebMCP is a proposed browser API -- specifically, a new interface on navigator.modelContext -- that allows web pages to declare JavaScript functions as tools that browser-based AI agents can discover and invoke. It uses the browser's existing communication, security, and session management infrastructure rather than introducing a new protocol.
+
+The design has real strengths. Authentication reuse eliminates one of the hardest problems in AI-service integration. Client-side execution means no backend infrastructure is needed. The human-in-the-loop requirement provides a natural consent and oversight mechanism -- if implemented correctly.
+
+But these strengths are specific to WebMCP's actual architecture, not to the MCP analogy. Evaluating WebMCP on its own terms -- as a browser API with browser security characteristics -- leads to better questions, better testing, and better specifications than evaluating it as a variant of MCP.
+
+## A Suggested Clarification
+
+The W3C specification and its README should explicitly state that WebMCP is not an implementation of the Model Context Protocol and does not use the MCP wire protocol. It borrows the "tool" abstraction -- functions with schemas and natural language descriptions -- but implements discovery, registration, invocation, and communication through browser-native mechanisms that are architecturally distinct from MCP.
+
+The analogy is useful for first contact. A developer unfamiliar with WebMCP can quickly grasp the concept by thinking "it is like an MCP server, but in the browser." But the specification itself, the security review, and the community evaluation should not rely on the analogy. They should address WebMCP as what it is: a new browser API with its own architecture, its own threat model, and its own design space.
+
+## Both Can Coexist
+
+None of this is an argument against WebMCP or against MCP. A company might maintain an MCP server for direct API integrations with AI platforms and simultaneously implement WebMCP tools on its consumer-facing website for browser-based agent interaction. The two are complementary, not competing, and not identical. Recognizing the distinction is necessary for evaluating each on its own merits.
+
+---
+
+*Contributed via the W3C AI Knowledge Representation Community Group*

From 7df3bdd4606779eff439b4f25007341b7f097a22 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Wed, 18 Feb 2026 16:43:09 +0800
Subject: [PATCH 37/46] Add files via upload

---
 webmcp-technical-note-2.md.txt | 102 +++++++++++++++++++++++++++++++++
 webmcp-technical-note-3.md.txt |  71 +++++++++++++++++++++++
 2 files changed, 173 insertions(+)
 create mode 100644 webmcp-technical-note-2.md.txt
 create mode 100644 webmcp-technical-note-3.md.txt

diff --git a/webmcp-technical-note-2.md.txt b/webmcp-technical-note-2.md.txt
new file mode 100644
index 0000000..fe85eac
--- /dev/null
+++ b/webmcp-technical-note-2.md.txt
@@ -0,0 +1,102 @@
+# WebMCP Technical Note 2: What to Test, What to Watch, What to Tell the Standards Body
+
+**WebMCP Technical Note Series**
+**15 February 2026**
+
+---
+
+Google's WebMCP early preview is live in Chrome 146 Canary. The specification is still a draft. The community group process is still open. This means the window for meaningful community input is right now -- before implementation momentum makes the current design effectively permanent.
+
+This note is a practical guide. It is written for developers, accessibility practitioners, security researchers, standards participants, and anyone who builds things for the web and wants to understand what WebMCP means for their work. It covers what WebMCP is for, what to test, what the benefits are, what the risks are, and how to communicate findings to the W3C community group that hosts the specification.
+
+## What WebMCP Is For: The Use Cases
+
+WebMCP allows a website to declare a set of tools -- JavaScript functions with structured schemas and natural language descriptions -- that AI agents can discover and invoke. The specification targets several categories of use.
+
+The first is **e-commerce and transactional sites**. A travel booking site could register tools like searchFlights(origin, destination, dates), filterResults(price, stops, airline), and bookFlight(flightId, passengerDetails). Instead of an AI agent trying to parse a complex search interface by reading pixels or DOM elements, it calls the function directly and gets structured JSON back. The site controls exactly what the agent can do and how.
+
+The second is **productivity and SaaS applications**. A project management tool could expose createTask(title, assignee, dueDate), moveCard(cardId, column), and generateReport(dateRange). Browser-based AI assistants could help users manage workflows without the application needing to build and maintain a separate backend MCP server or API integration for every AI platform.
+
+The third is **content and media**. A news site could register searchArticles(topic, dateRange) and getArticleSummary(articleId). A mapping service could expose getDirections(from, to, mode) and findNearby(category, radius). These tools let agents interact with content in structured ways rather than scraping and guessing.
+
+The fourth -- and potentially most significant -- is **accessibility**. The specification claims WebMCP could benefit assistive technologies by providing structured, semantically meaningful interfaces to website functionality. A screen reader enhanced with agent capabilities could invoke tools directly rather than navigating complex visual layouts. This is a strong claim that deserves rigorous testing.
+
+The fifth is **form automation and multi-step workflows**. Complex processes like insurance applications, government forms, or account setup flows could be exposed as sequences of tool calls, allowing agents to guide users through them step by step while the site maintains control over validation, sequencing, and data handling.
+
+## What the Benefits Are
+
+WebMCP offers several concrete advantages over current approaches to AI-web interaction.
+
+**Reliability** is the most immediate. Today's browser agents -- whether using visual parsing or DOM inspection -- are brittle. A minor CSS change can break a visual agent. A DOM restructuring can invalidate a scraping approach. WebMCP tools are explicit contracts: the site declares what is available, the agent calls it, the response is structured. This should dramatically reduce failure rates for agent-web interaction.
+
+**Performance** is the second. Visual agents must capture screenshots, send them to a vision model, interpret the response, generate mouse coordinates, and repeat. WinBuzzer reported a 67% reduction in computational overhead with WebMCP compared to visual approaches. Even if that number proves optimistic in production, the architectural advantage is clear: a function call is faster than a screenshot-interpret-click loop.
+
+**Developer control** is the third. With visual or DOM-based agents, the website has no say in how an agent interacts with it. The agent reverse-engineers the interface. With WebMCP, the developer explicitly defines the interaction surface. Tools can include rate limits, validation, permission requirements, and structured error messages. The site becomes a willing participant in the interaction rather than a passive target.
+
+**Authentication reuse** is the fourth, and was the original motivation. Because WebMCP runs in the browser session, it inherits whatever authentication the user already has. No OAuth flows, no API keys, no separate credential management. The user is already logged in. The agent operates within that session. This solves one of the hardest problems in AI-service integration.
+
+**Standardization** is the fifth. If WebMCP succeeds, a developer implements tools once and every conformant agent can use them -- rather than building separate integrations for ChatGPT, Claude, Gemini, and whatever comes next. This is the "USB-C" argument: one interface, many devices.
+
+## What the Risks Are
+
+The risks are significant, and several are not yet adequately addressed in the specification.
+
+**Prompt injection** is the most acute. WebMCP tools return data to AI agents that then process it in their language model context. A malicious or compromised website could craft tool responses that manipulate the agent's behavior -- injecting instructions, altering the agent's understanding of the task, or causing it to take unintended actions on other sites. The specification does not currently define a defense against this beyond same-origin policy boundaries.
+
+**Scope creep of agent permissions** is the second. WebMCP is designed for human-in-the-loop workflows, with headless browsing explicitly out of scope. But the technical mechanism -- JavaScript functions callable by external code -- does not inherently enforce this. If browser vendors later relax the human-presence requirement, or if extensions find ways to invoke WebMCP tools without user awareness, the permission model collapses. The specification should define what "human in the loop" means technically, not just philosophically.
+
+**Consent and transparency** is the third. When a user visits a site that registers WebMCP tools, do they know? The current design provides no visible indicator to the user that tools have been registered, what data they expose, or when an agent invokes them. Compare this to other browser permission systems -- camera, microphone, location -- where the user explicitly grants access. WebMCP tools operate silently.
+
+**Competitive dynamics** is the fourth. WebMCP gives first-mover advantage to sites that implement tools early, potentially favoring large platforms with engineering resources. Smaller sites that do not implement WebMCP may become invisible to agent-mediated browsing. This could accelerate web consolidation. The specification should consider whether a minimal tool set (search, navigation, content retrieval) should be automatically generated from existing web standards like HTML forms, structured data, and ARIA attributes.
+
+**Data leakage through tool schemas** is the fifth. The natural language descriptions and parameter schemas of registered tools reveal information about a site's internal architecture, business logic, and data models. An agent -- or the platform behind it -- could catalog available tools across thousands of sites to build competitive intelligence. The specification does not address whether tool schemas should be treated as sensitive information.
+
+**Abuse and rate limiting** is the sixth. Agents can invoke tools at machine speed. A poorly defended site could face thousands of tool invocations per second from a single browser session. The specification mentions rate limiting as a consideration but does not define a standard mechanism. Without one, each site must build its own defenses, and many will not.
+
+**Cross-site tool chaining** is the seventh. If an agent can invoke tools on multiple open tabs, it could chain actions across sites in ways no individual site anticipated or authorized. Transfer money on a banking site, then use the confirmation on a shopping site, then post about it on a social network -- all within one agent workflow. The security boundaries for cross-site tool interaction are not yet defined.
+
+## What to Test
+
+For those with access to Chrome 146 Canary, here are the concrete areas that need community evaluation. Each should generate feedback for the W3C community group.
+
+**Test the Declarative API with real HTML forms.** Register tools that wrap existing form actions and verify that validation, error handling, and submission behavior match what a human user would experience. Try edge cases: forms with CAPTCHAs, multi-step forms with session state, forms that redirect on submit. Document where the abstraction breaks.
+
+**Test the Imperative API with dynamic content.** Register tools that interact with JavaScript-heavy applications -- single-page apps, dashboards with real-time data, applications that maintain complex client-side state. Evaluate whether tool calls can reliably interact with application state without causing inconsistencies.
+
+**Test authentication boundaries.** Log into a site, register tools, then observe what happens when the session expires, when the user logs out in another tab, when cookies are cleared. The specification's authentication reuse claim needs verification under adversarial conditions.
+
+**Test tool discovery and enumeration.** If multiple sites in different tabs register tools, how does the agent disambiguate? What happens when two sites register tools with the same name? How does the agent present available tools to the user? Is tool discovery observable by the page (can a site detect that an agent has read its tool list)?
+
+**Test accessibility integration.** If you work with assistive technologies, evaluate whether WebMCP tools provide genuinely better access to site functionality than existing ARIA roles and landmarks. Test with screen readers, switch access devices, and voice control. Document whether WebMCP complements or conflicts with existing accessibility standards.
+
+**Test prompt injection resilience.** Craft tool responses that contain instruction-like text and observe whether the consuming agent's behavior is affected. This is critical safety research. If tool responses can manipulate agent behavior, the security model is fundamentally incomplete.
+
+**Test performance claims.** Measure actual latency and token usage for equivalent tasks performed via WebMCP tools versus visual agent interaction. The 67% overhead reduction claim needs independent verification across different site types and task complexities.
+
+**Test failure modes.** What happens when a tool throws an error? When it returns unexpected data types? When it hangs? When the page navigates away mid-call? The specification should define standard error handling, but the current draft has TODO sections in these areas. Documenting real failure modes will directly shape the specification.
+
+## How to Communicate Findings
+
+Feedback is only useful if it reaches the people writing the specification. Here are the concrete channels, in order of effectiveness.
+
+**File a GitHub issue** at https://github.com/webmachinelearning/webmcp/issues with a clear title, reproducible steps, and a specific recommendation. Tag it with the relevant label if available. The spec editors (Brandon Walderman, Khushal Sagar, Dominic Farolino) monitor this repo. Issues with reproducible test cases and concrete proposals get traction. Issues that say "I don't like this" do not.
+
+**Join the W3C Web Machine Learning Community Group** at https://www.w3.org/community/webmachinelearning/ and participate in discussion. Community Groups are free and open. Participation in CG calls and mailing list threads carries weight in W3C process.
+
+If your findings relate to **agent interoperability** -- how WebMCP tools interact with broader agent ecosystems, discovery protocols, or multi-agent workflows -- also engage with the AI Agent Protocol Community Group, which the WebML CG charter identifies as a coordination partner.
+
+If your findings relate to **security or privacy**, file issues with clear severity assessments. W3C specifications have a tradition of security and privacy self-review questionnaires. Check whether the WebMCP specification has completed one, and if not, request it.
+
+If you publish your findings -- on a blog, in a report, in an academic paper -- link back to the relevant GitHub issues so the discussion stays connected to the specification process.
+
+## The Window
+
+The pattern in web standards is well established. Once an implementation ships in a dominant browser and developers build on it, the specification follows the code. Chrome holds roughly 65% of browser market share. The early preview is live. Developer adoption is beginning. The longer the community waits to engage, the narrower the design space becomes.
+
+This is not an argument against WebMCP. The technical concept is sound, the use cases are real, and the problem it solves -- giving developers control over AI agent interaction -- is important. But a good idea implemented badly, or without adequate security review, or without accessibility testing, or without community input, becomes a liability embedded in the web platform for decades.
+
+The specification is at https://webmachinelearning.github.io/webmcp/. The implementation is in Chrome 146 Canary. The issues page is at https://github.com/webmachinelearning/webmcp/issues. The community group is open to all at no cost. The work is now.
+
+---
+
+*Contributed via the W3C AI Knowledge Representation Community Group*
diff --git a/webmcp-technical-note-3.md.txt b/webmcp-technical-note-3.md.txt
new file mode 100644
index 0000000..b2eda08
--- /dev/null
+++ b/webmcp-technical-note-3.md.txt
@@ -0,0 +1,71 @@
+# WebMCP Technical Note 3: WebMCP Is Not an MCP Server
+
+**WebMCP Technical Note Series**
+**15 February 2026**
+
+---
+
+A persistent claim in the WebMCP ecosystem is that WebMCP turns a website into an MCP server. The W3C specification repository itself states that web pages using WebMCP "can be thought of as Model Context Protocol (MCP) servers that implement tools in client-side script instead of on the backend." Early independent implementations by Jason McGhee and Alex Nahas (MCP-B) literally did function as MCP servers, bridging browser JavaScript to MCP clients through localhost websocket connections using the standard MCP protocol.
+([W3C spec repo](https://github.com/webmachinelearning/webmcp))
+([McGhee implementation](https://github.com/jasonjmcghee/WebMCP))
+([Nahas MCP-B](https://github.com/MiguelsPizza/WebMCP))
+
+The framing is understandable. It is also architecturally misleading, and the confusion has consequences for how developers, security reviewers, and standards participants evaluate the specification.
+
+## The Analogy and Its Limits
+
+WebMCP and Anthropic's Model Context Protocol share a conceptual ancestor: both define "tools" as functions with natural language descriptions and structured schemas that AI agents can discover and invoke. That is where the meaningful similarity ends.
+
+**Anthropic's MCP** is a backend protocol. It uses JSON-RPC 2.0 as its message format, transported over stdio, HTTP with Server-Sent Events, or Streamable HTTP. MCP servers are hosted processes -- typically written in Python or Node.js -- that run on backend infrastructure. They connect AI platforms like Claude, ChatGPT, or Gemini to external services. Authentication follows OAuth 2.1 or custom API key schemes. No browser is required. No human user needs to be present. Headless, fully automated operation is the norm.
+([Source](https://modelcontextprotocol.io/introduction))
+
+**WebMCP** is a frontend browser API. It uses the browser's native postMessage system for communication between the web page and the agent. Tools are registered and executed as client-side JavaScript within an active browser tab. Authentication is inherited from the browser session -- whatever cookies or federated login the user already has. A human user must be present in an active browser session. Headless browsing is explicitly out of scope.
+([Source](https://webmachinelearning.github.io/webmcp/))
+
+The specification's own language -- "can be thought of as" -- acknowledges this is an analogy, not an identity. But the README, the press coverage, and the developer ecosystem have largely dropped the qualifier. The result is that WebMCP is widely discussed as though it were MCP running in the browser, with all the assumptions that entails.
+
+## What the Framing Gets Wrong
+
+When a developer hears "your website becomes an MCP server," they import a set of assumptions from the MCP architecture. Every one of these assumptions is wrong for WebMCP.
+
+**Transport.** MCP uses JSON-RPC 2.0, a well-specified request-response protocol with defined error codes, batching, and notification semantics. WebMCP uses postMessage, the browser's cross-origin communication mechanism. These have different reliability characteristics, different error handling models, and different security boundaries. Code written for one transport does not work with the other.
+
+**Execution context.** An MCP server runs in a controlled backend environment -- a container, a VM, a serverless function -- where the service provider manages the runtime, dependencies, and resource limits. WebMCP tools run in the browser's JavaScript engine, in the same execution context as the web page's own code. They are subject to the browser's security sandbox, but also to its constraints: single-threaded execution, same-origin policy, and the full surface area of client-side attack vectors.
+
+**Authentication.** MCP's specification has adopted OAuth 2.1 for authentication between clients and servers. This was, notably, the problem that motivated WebMCP's creation -- Alex Nahas at Amazon found that OAuth 2.1 was impractical for internal MCP deployments. WebMCP sidesteps this entirely by inheriting the browser session. This is elegant for usability but means the authentication model is whatever the website happens to use, with no protocol-level guarantees.
+
+**Trust direction.** In MCP, the AI platform (client) connects to a known, registered server. The platform decides which servers to trust. In WebMCP, any website the user visits can register tools. The trust decision shifts from the AI platform to the browser, and potentially to the user -- who may not know that tools have been registered at all, since the current specification provides no visible indicator.
+
+**Operational mode.** MCP servers are designed for automated, programmatic access. They can run continuously, handle concurrent requests, and operate without human involvement. WebMCP requires an active browser tab with a human user present. The specification explicitly excludes headless browsing. These are fundamentally different operational paradigms with different scaling characteristics, different failure modes, and different abuse surfaces.
+
+## Why This Matters for Standards Review
+
+The "MCP server" framing is not just imprecise. It actively interferes with rigorous evaluation of the specification.
+
+**Security reviewers** who approach WebMCP as "MCP in the browser" will evaluate it against MCP's threat model. But MCP's threat model assumes a controlled backend environment, authenticated client-server connections, and server-side access control. WebMCP's actual threat model involves client-side JavaScript execution, browser-based trust boundaries, and the full range of web security concerns including cross-site scripting, prompt injection via tool responses, and silent tool registration. Importing the wrong threat model means asking the wrong security questions.
+
+**Developers** who approach WebMCP as "MCP in the browser" may expect protocol-level interoperability -- that a WebMCP tool definition could be used interchangeably with an MCP server tool definition, or that MCP client libraries could connect to WebMCP pages. They cannot. The tool schema format may be similar, but the transport, discovery, and invocation mechanisms are incompatible.
+
+**Standards participants** who approach WebMCP as "MCP in the browser" may underestimate the scope of new specification work required. WebMCP is not an adaptation of MCP to a new environment. It is a new browser API that borrows one concept (the tool abstraction) from MCP and implements everything else differently. It needs its own security review, its own privacy analysis, its own accessibility evaluation, and its own consent model -- none of which can be inherited from MCP.
+
+## What WebMCP Actually Is
+
+WebMCP is a proposed browser API -- specifically, a new interface on navigator.modelContext -- that allows web pages to declare JavaScript functions as tools that browser-based AI agents can discover and invoke. It uses the browser's existing communication, security, and session management infrastructure rather than introducing a new protocol.
+
+The design has real strengths. Authentication reuse eliminates one of the hardest problems in AI-service integration. Client-side execution means no backend infrastructure is needed. The human-in-the-loop requirement provides a natural consent and oversight mechanism -- if implemented correctly.
+
+But these strengths are specific to WebMCP's actual architecture, not to the MCP analogy. Evaluating WebMCP on its own terms -- as a browser API with browser security characteristics -- leads to better questions, better testing, and better specifications than evaluating it as a variant of MCP.
+
+## A Suggested Clarification
+
+The W3C specification and its README should explicitly state that WebMCP is not an implementation of the Model Context Protocol and does not use the MCP wire protocol. It borrows the "tool" abstraction -- functions with schemas and natural language descriptions -- but implements discovery, registration, invocation, and communication through browser-native mechanisms that are architecturally distinct from MCP.
+
+The analogy is useful for first contact. A developer unfamiliar with WebMCP can quickly grasp the concept by thinking "it is like an MCP server, but in the browser." But the specification itself, the security review, and the community evaluation should not rely on the analogy. They should address WebMCP as what it is: a new browser API with its own architecture, its own threat model, and its own design space.
+
+## Both Can Coexist
+
+None of this is an argument against WebMCP or against MCP. A company might maintain an MCP server for direct API integrations with AI platforms and simultaneously implement WebMCP tools on its consumer-facing website for browser-based agent interaction. The two are complementary, not competing, and not identical. Recognizing the distinction is necessary for evaluating each on its own merits.
+
+---
+
+*Contributed via the W3C AI Knowledge Representation Community Group*

From 12fe4978d5bbe5d1eaab279317387e42bf421b2e Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Thu, 19 Feb 2026 16:12:57 +0800
Subject: [PATCH 38/46] Delete WebMCP_Model_Card_Generator_USER_GUIDE.md

---
 WebMCP_Model_Card_Generator_USER_GUIDE.md | 588 ----------------------
 1 file changed, 588 deletions(-)
 delete mode 100644 WebMCP_Model_Card_Generator_USER_GUIDE.md

diff --git a/WebMCP_Model_Card_Generator_USER_GUIDE.md b/WebMCP_Model_Card_Generator_USER_GUIDE.md
deleted file mode 100644
index 3c7d98b..0000000
--- a/WebMCP_Model_Card_Generator_USER_GUIDE.md
+++ /dev/null
@@ -1,588 +0,0 @@
-# WebMCP Model Card Generator -- Guide for the Clueless
-
-**A field-by-field walkthrough so you can fill out every tab without knowing anything about WebMCP beforehand.**
-
-Co-created by Paola Di Maio, PhD (W3C AI-KR CG Chair) & Claude (Anthropic)
-February 2026
-
----
-
-## What You're Making
-
-A **model card** for a browser-side tool. Think of it as a label for a product: it tells AI agents (and humans) what your tool does, what it needs, what can go wrong, and how to use it safely.
-
-You fill in a form. The generator produces two files:
-- **JSON** -- for machines to read (registries, agents, validators)
-- **Markdown** -- for humans to read (documentation, GitHub, specifications)
-
-**Time needed**: 15-30 minutes if you know your tool. 5 minutes if you just want to test the generator.
-
----
-
-## Tab 1: Identity & Provenance
-
-*Who made this, what is it, where does it live?*
-
-### Tool/Page Name (required)
-
-The name of your WebMCP-enabled tool or web page. This is what agents will see when they discover your tools.
-
-- Good: "Easely Design Editor", "Flight Search Demo", "Todo Manager"
-- Bad: "my-tool", "test", "page1"
-
-### Version (required)
-
-Use semantic versioning: **major.minor.patch**
-
-- `1.0.0` = first stable release
-- `0.1.0` = early prototype
-- `2.3.1` = mature, updated
-
-If you don't know, use `0.1.0` for prototypes or `1.0.0` for something you'd show people.
-
-### Description (required)
-
-One or two sentences explaining what tools this page exposes to AI agents.
-
-- Good: "Travel booking page exposing flight search, hotel filtering, and itinerary building tools via WebMCP declarative and imperative APIs"
-- Bad: "A tool" or "This is my page"
-
-### Author
-
-Your name, team name, or organization. Can be left blank.
-
-### Creation Date
-
-Auto-filled with today's date. Change it if the tool was created earlier.
-
-### License (required)
-
-Pick one:
-
-| License | When to use |
-|---------|-------------|
-| **MIT** | Most permissive, most common. "Do whatever you want, just include the license." |
-| **Apache 2.0** | Permissive + patent protection. Good for company projects. |
-| **GPL 3.0** | Copyleft. Anyone who uses your code must also open-source theirs. |
-| **Proprietary** | Closed source, commercial. |
-| **W3C Community CLA** | If your tool is part of a W3C community group deliverable. |
-
-If unsure, pick MIT.
-
-### Page URL
-
-The web address where your WebMCP tools are registered. This is where agents go to find and call your tools.
-
-- Example: `https://travel-demo.bandarra.me/`
-- Example: `https://mysite.com/booking`
-- Put "tbd" if you haven't deployed yet.
-
-### Attribution (required)
-
-How was this tool created? Be honest -- this is a transparency field.
-
-| Choice | Meaning |
-|--------|---------|
-| **Human-authored** | A person wrote all the code |
-| **AI co-created** | Human and AI worked together (like us right now!) |
-| **AI-generated** | AI generated the code, human reviewed/edited |
-
-### Source Repository
-
-Link to your GitHub/GitLab repo. Leave blank if closed source.
-
----
-
-## Tab 2: API Mode
-
-*How do agents talk to your tools?*
-
-This is where WebMCP diverges most from backend MCP. You have TWO choices (or both).
-
-### Primary API Mode (required)
-
-| Mode | What it means | When to use |
-|------|---------------|-------------|
-| **Declarative (HTML forms)** | You add attributes to existing HTML `<form>` elements. No JavaScript needed. | You already have working HTML forms and want the fastest path to agent-readiness. |
-| **Imperative (JavaScript)** | You call `navigator.modelContext.registerTool()` in JavaScript. | Complex logic, dynamic tools, multi-step workflows. |
-| **Both** | You use forms for simple actions and JS for complex ones. | Large applications with a mix of simple and complex tools. |
-
-### If Declarative: Form toolname
-
-The exact `toolname` attribute you put on your HTML form:
-```html
-<form toolname="searchFlights" tooldescription="Search flights">
-```
-Enter: `searchFlights`
-
-### If Declarative: Form tooldescription
-
-The natural language description in the form attribute. This is what agents read to decide whether to use your tool.
-
-Enter: `Search for available flights by origin, destination, and date`
-
-### If Imperative: Registration Method
-
-How you register tools in JavaScript:
-
-| Method | When to use |
-|--------|-------------|
-| **navigator.modelContext.registerTool()** | W3C standard API. Use for single tool registration. |
-| **navigator.modelContext.provideContext()** | W3C standard. Registers multiple tools at once (replaces any existing). |
-| **MCP-B @mcp-b/global import** | Community polyfill. Use if you need cross-browser support before native implementation. |
-| **WebMCP widget script tag** | Simplest option -- add a `<script>` tag. Good for quick prototyping. |
-
-If unsure, pick `registerTool()` -- it's the W3C standard.
-
----
-
-## Tab 3: Tool Documentation
-
-*What can agents actually call?*
-
-You'll add one entry for each tool your page exposes. Click **+ Add Tool** after filling in each one.
-
-### Tool Name (required)
-
-The exact name agents use to call this tool. Must match your code exactly.
-
-- Good: `searchFlights`, `addToCart`, `toggleTheme`
-- Bad: `tool1`, `myFunction`, `doStuff`
-
-### Description (required)
-
-What this tool does, in plain language. Agents read this to decide when and how to use it.
-
-- Good: "Search for available flights between two airports on a given date. Returns a list of flights with prices, times, and airline information."
-- Bad: "Searches stuff"
-
-### Input Schema (required)
-
-A JSON Schema object describing what parameters the tool accepts. If you don't know JSON Schema, here's the pattern:
-
-**Simplest possible** (tool takes no input):
-```json
-{
-  "type": "object",
-  "properties": {},
-  "required": []
-}
-```
-
-**Tool with parameters**:
-```json
-{
-  "type": "object",
-  "properties": {
-    "origin": {
-      "type": "string",
-      "description": "3-letter IATA airport code"
-    },
-    "destination": {
-      "type": "string",
-      "description": "3-letter IATA airport code"
-    },
-    "date": {
-      "type": "string",
-      "description": "Travel date in YYYY-MM-DD format"
-    }
-  },
-  "required": ["origin", "destination", "date"]
-}
-```
-
-**Common types**: `"string"`, `"number"`, `"boolean"`, `"array"`, `"object"`
-
-### Output Format
-
-What does the tool return?
-
-| Format | When |
-|--------|------|
-| **JSON** | Structured data (most common). Search results, API responses. |
-| **Text** | Plain text responses. Summaries, status messages. |
-| **HTML** | HTML fragments. Rich content the agent might display. |
-| **Mixed** | Multiple types depending on the call. |
-
-### Error States
-
-What can go wrong? One error per line.
-
-Example:
-```
-InvalidInput: origin must be 3-letter IATA code
-NetworkError: upstream API timeout after 30s
-AuthRequired: user must be logged in for booking
-RateLimited: maximum 10 searches per minute exceeded
-```
-
-### Checkboxes
-
-| Checkbox | Check it if... |
-|----------|----------------|
-| **Read-only** | The tool only READS data, never changes anything. Search, query, list operations. |
-| **Destructive** | The tool DELETES or IRREVERSIBLY CHANGES something. Delete account, cancel booking. |
-| **Async** | The tool makes network requests or takes time. Almost always yes. |
-| **requestUserInteraction()** | The tool pauses mid-execution to ask the human a question (e.g. "Confirm this purchase?"). This is unique to WebMCP -- backend MCP can't do this. |
-| **Multimodal** | The tool handles images, audio, or video, not just text/JSON. |
-
----
-
-## Tab 4: Session & Authentication
-
-*Does the user need to be logged in?*
-
-### Session Type (required)
-
-| Type | Meaning |
-|------|---------|
-| **Authenticated** | Tools need a logged-in user. Most common for real applications. |
-| **Anonymous** | Tools work for anyone, no login needed. Public search, demos. |
-| **Mixed** | Some tools are public (search), some need login (booking). |
-
-### Permissions Required
-
-What level of access does the user need?
-
-- "Logged-in user" (basic)
-- "Admin role" (elevated)
-- "Premium subscriber" (paid tier)
-- Leave blank if anonymous.
-
-### OAuth / Cookie Dependencies
-
-What specific auth mechanisms do your tools rely on? One per line.
-
-Example:
-```
-Session cookie from login flow
-OAuth2 bearer token for API calls
-CSRF token in X-CSRF-Token header
-```
-
-### Inherits Browser Session
-
-**Almost always yes.** This is the key difference from backend MCP: your tools automatically get the same cookies, tokens, and session data as the logged-in user. You don't configure credentials separately.
-
----
-
-## Tab 5: Browser Compatibility
-
-*What browser does this need?*
-
-### Minimum Chrome Version (required)
-
-Currently WebMCP only works in **Chrome 146 Canary** with the "WebMCP for testing" flag enabled at `chrome://flags`.
-
-Enter: `146` (the default)
-
-### MCP-B Polyfill Support
-
-Check this if your tools also work through the MCP-B Chrome extension, which provides WebMCP-like functionality in current stable Chrome.
-
-### Browser-Specific Notes
-
-Anything agents or developers need to know about browser support. One note per line.
-
-Example:
-```
-Chrome DevTools MCP bridge required for Claude Desktop integration
-Edge support expected mid-2026
-Firefox: no timeline announced
-Mobile Chrome: not yet supported
-```
-
-### Graceful Degradation
-
-What happens for users whose browser doesn't support WebMCP?
-
-- Good: "Falls back to standard HTML form submission. UI remains fully functional for human users."
-- Bad: "Doesn't work."
-
----
-
-## Tab 6: Security Properties
-
-*What could go wrong? How bad could it get?*
-
-### Checkboxes
-
-| Checkbox | What it means |
-|----------|---------------|
-| **Same-origin scope** | Tools can only access data from their own domain. Almost always yes. |
-| **CSP compatible** | Tools work with Content Security Policy headers. Check if you use CSP. |
-| **Human-in-the-loop** | A human can see what the agent is doing. Core WebMCP design principle. |
-
-### Data Exposure
-
-What data do your tools expose to AI agents? Be specific.
-
-- "Search results including flight prices and availability"
-- "User profile name and email (for personalization)"
-- "No user data exposed -- only public catalog information"
-
-### Exfiltration Risk (required)
-
-The **lethal trifecta** assessment. Three factors combine to create data theft risk:
-
-1. **Data access** -- tool reads user data
-2. **Untrusted content** -- page shows third-party content (ads, user-generated content, embeds)
-3. **External communication** -- tool can send data to outside servers
-
-| Risk | When |
-|------|------|
-| **Low** | Read-only tools OR no external communication. Most tools. |
-| **Medium** | Some data access with controlled output. Tools that modify state but don't send data externally. |
-| **High** | All three factors present. Tools that read user data on a page with third-party content and can make external network requests. |
-
-### Lethal Trifecta Present
-
-Check this ONLY if all three factors above are present simultaneously. Be honest -- this is a security assessment, not a marketing checkbox.
-
-### Rate Limiting
-
-Any throttling on tool invocations? Examples:
-- "10 calls/minute per session"
-- "100 calls/hour, shared with UI rate limits"
-- "No rate limiting" (be careful with this one)
-
----
-
-## Tab 7: Interaction Patterns
-
-*How do tools behave in context?*
-
-### Statefulness (required)
-
-| Type | Meaning |
-|------|---------|
-| **Stateless** | Each tool call is independent. Most common. |
-| **Stateful** | Tools remember previous calls. searchFlights result feeds into bookFlight. |
-| **Mixed** | Some tools are stateless (search), some stateful (multi-step booking). |
-
-### Tool Dependencies
-
-Does calling one tool require another tool to have been called first? One dependency per line.
-
-Example:
-```
-bookFlight depends on searchFlights result
-selectSeat depends on bookFlight confirmation
-```
-
-### Modifies Visible Page State
-
-Check this if the tool changes what the human sees on screen (updates DOM, changes UI). This is important because it IS the human-in-the-loop mechanism -- the human can see what the agent did.
-
-### Latency Estimate
-
-How long do tool calls typically take?
-
-- "50-200ms for search operations"
-- "1-3 seconds for booking confirmation"
-- "Under 100ms for UI toggles"
-
-### Blocks UI
-
-Check if the tool freezes the page while executing. Ideally this should be unchecked -- tools should run without blocking the user.
-
----
-
-## Tab 8: Context Requirements
-
-*What does the tool read from the page?*
-
-### provideContext() Data
-
-What data does your page explicitly share with agents through the provideContext() API?
-
-Example: "Current search filters, selected dates, passenger count, user locale preference"
-
-### Reads DOM State
-
-Check if the tool reads the visible page (HTML elements, text content, form values) during execution.
-
-### Accesses React/Redux State
-
-Check if the tool reads framework-level state (React hooks, Redux store, Vue reactive data). Note: this means your tool is coupled to a specific framework version.
-
-### Navigation Dependencies
-
-Does the tool only work on certain pages/routes?
-
-- "Must be on /search results page for bookFlight to work"
-- "Works on any page"
-- Leave blank if no restrictions.
-
----
-
-## Tab 9: Limitations & Known Issues
-
-*What can't the tool do? Be honest.*
-
-### Cannot Do (required)
-
-One limitation per line. This is the most important honesty section.
-
-Example:
-```
-Cannot book international flights
-Cannot process payments directly
-Maximum 10 passengers per search
-Does not support multi-city routing
-No wheelchair-accessible filtering yet
-```
-
-### Edge Cases
-
-Known problematic scenarios. Things that might surprise users or agents.
-
-Example:
-```
-Dates more than 330 days out return empty results
-Airports with only charter flights may not appear
-Search during maintenance windows returns stale data
-```
-
-### Scale Limits
-
-Default is "50 tools per page recommended" -- this is the practical performance guideline from the WebMCP spec. Adjust if your page has specific constraints.
-
-### Failure Modes
-
-How does the tool fail? What does the agent see?
-
-Example:
-```
-Returns {error: "TIMEOUT", message: "..."} after 30 seconds
-Throws TypeError if called before page fully loads
-Returns empty results array (not error) when no matches found
-```
-
----
-
-## Tab 10: Discovery Metadata
-
-*Can agents find your tools before visiting the page?*
-
-### Registry Listed
-
-Check if your tools are listed in any tool registry or catalog.
-
-### .well-known/webmcp
-
-Check if your site serves a `.well-known/webmcp` file (proposed standard, not yet finalized). This would let agents discover your tools before navigating to the page.
-
-### Pre-Visit Discoverability
-
-How can agents know your tools exist before visiting the page?
-
-- "Listed in site sitemap with WebMCP annotations"
-- "Documented in this model card"
-- "No pre-visit discovery -- tools only available after page load"
-
-This is an unsolved problem in WebMCP. Your model card itself is part of the solution.
-
----
-
-## Tab 11: Testing & Validation
-
-*Has this been tested with real AI agents?*
-
-### Test Methodology
-
-How did you test your WebMCP tools?
-
-Example:
-```
-Manual testing via Chrome DevTools MCP bridge
-Automated benchmark comparing token usage vs screenshot method
-User testing with 5 participants using Claude Desktop
-```
-
-### Agents Tested
-
-Check all AI agents you've tested with. This builds trust -- agents that know they've been tested are more likely to be used confidently.
-
-### Pass/Fail Criteria
-
-What counts as a successful tool invocation?
-
-Example:
-```
-Returns valid JSON with results array
-No console errors during execution
-Completes within 5 seconds
-Human can see and verify state changes
-```
-
-### Test Suite Link
-
-URL to your test scripts, benchmark suite, or CI pipeline. Leave blank if no automated tests.
-
----
-
-## Tab 12: Backend MCP Relationship
-
-*Is there also a backend MCP server for this service?*
-
-### Corresponding Backend MCP Server
-
-Check if your service also has a traditional backend MCP server (the Anthropic-style kind that runs on Node.js/Python via JSON-RPC).
-
-Many real applications will have both: browser-side WebMCP for UI-interactive operations, and backend MCP for heavy processing, payments, or database operations.
-
-### Backend Server Name
-
-The name of the corresponding backend MCP server, if it exists.
-
-Example: `flights-mcp-server`, `@company/booking-mcp`
-
-### Capability Differences
-
-What does the browser tool do differently from the backend server?
-
-Example:
-```
-Browser: live UI updates, session-aware search, human confirmation dialogs
-Backend: payment processing, database writes, batch operations
-Browser inherits user session; backend needs separate API key
-```
-
-### Authentication Shared
-
-Check if the browser session authenticates backend calls too (e.g. the same OAuth token works for both).
-
----
-
-## After You Generate
-
-1. **Review** the JSON and Markdown output
-2. **Copy** whichever format you need (or both)
-3. **Publish** alongside your WebMCP-enabled page:
-   - Add the JSON to your repository
-   - Add the Markdown to your README
-   - Consider serving the JSON at `.well-known/webmcp-model-card`
-4. **Share** with the WebMCP community for feedback
-
----
-
-## Quick Reference: MCP vs WebMCP
-
-| Aspect | Anthropic MCP (Backend) | W3C WebMCP (Browser) |
-|--------|------------------------|---------------------|
-| **Runs on** | Server (Node.js, Python, Docker) | Web page (browser JavaScript) |
-| **Transport** | stdio, HTTP+SSE, JSON-RPC | postMessage, navigator.modelContext |
-| **Auth** | API keys, env vars, OAuth config | Inherits browser session automatically |
-| **Discovery** | MCP Registry, npm, .well-known | Page must be visited first (gap) |
-| **Tool registration** | Server-side code only | HTML forms OR JavaScript (or both) |
-| **Human oversight** | Separate approval flow | Human sees the page -- IS the oversight |
-| **State** | Typically stateless | Can be deeply stateful (shares page runtime) |
-| **Security boundary** | API key management | Same-origin policy + CSP + human-in-loop |
-| **Unique capability** | Heavy compute, DB access, payment | requestUserInteraction(), DOM mutation, session inheritance |
-
----
-
-*Part of the W3C AI Knowledge Representation Community Group's work on AI agent documentation standards.*
-
-*Co-created by Paola Di Maio, PhD & Claude (Anthropic) -- February 2026*

From 3629bc8ecb1ec756497e3d0af98d6a0429add923 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Fri, 20 Feb 2026 15:50:38 +0800
Subject: [PATCH 39/46] Rename webmcp-technical-note-1 .md to What to Test,
 What to Watch, What to Tell the Standards Body.md

---
 ...hat to Test, What to Watch, What to Tell the Standards Body.md | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename webmcp-technical-note-1 .md => What to Test, What to Watch, What to Tell the Standards Body.md (100%)

diff --git a/webmcp-technical-note-1 .md b/What to Test, What to Watch, What to Tell the Standards Body.md
similarity index 100%
rename from webmcp-technical-note-1 .md
rename to What to Test, What to Watch, What to Tell the Standards Body.md

From 904a570a243c23aee8b2cb7a629d51f6bf885148 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Fri, 20 Feb 2026 16:28:32 +0800
Subject: [PATCH 40/46] Rename webmcp-technical-note-1.md to
 howabrowserhackbecameaproposedwebstandard.md

---
 ...ical-note-1.md => howabrowserhackbecameaproposedwebstandard.md | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename webmcp-technical-note-1.md => howabrowserhackbecameaproposedwebstandard.md (100%)

diff --git a/webmcp-technical-note-1.md b/howabrowserhackbecameaproposedwebstandard.md
similarity index 100%
rename from webmcp-technical-note-1.md
rename to howabrowserhackbecameaproposedwebstandard.md

From 00df605aac0bfa0fa7347af43787a8e0e1bdff2a Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Fri, 20 Feb 2026 16:29:53 +0800
Subject: [PATCH 41/46] Rename webmcp-technical-note-3.md to WebMCP Is Not an
 MCP Server.md

---
 webmcp-technical-note-3.md => WebMCP Is Not an MCP Server.md | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename webmcp-technical-note-3.md => WebMCP Is Not an MCP Server.md (100%)

diff --git a/webmcp-technical-note-3.md b/WebMCP Is Not an MCP Server.md
similarity index 100%
rename from webmcp-technical-note-3.md
rename to WebMCP Is Not an MCP Server.md

From 20f7742e279941c28a231bda72fefe85f1d36458 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Fri, 20 Feb 2026 17:32:37 +0800
Subject: [PATCH 42/46] Rename What to Test, What to Watch, What to Tell the
 Standards Body.md to whatotest.md

---
 ...t to Watch, What to Tell the Standards Body.md => whatotest.md | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename What to Test, What to Watch, What to Tell the Standards Body.md => whatotest.md (100%)

diff --git a/What to Test, What to Watch, What to Tell the Standards Body.md b/whatotest.md
similarity index 100%
rename from What to Test, What to Watch, What to Tell the Standards Body.md
rename to whatotest.md

From 249156d952a48137325a4497f780e384df68d6c0 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Fri, 20 Feb 2026 17:34:40 +0800
Subject: [PATCH 43/46] Rename howabrowserhackbecameaproposedwebstandard.md to
 browserhack.md

---
 howabrowserhackbecameaproposedwebstandard.md => browserhack.md | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename howabrowserhackbecameaproposedwebstandard.md => browserhack.md (100%)

diff --git a/howabrowserhackbecameaproposedwebstandard.md b/browserhack.md
similarity index 100%
rename from howabrowserhackbecameaproposedwebstandard.md
rename to browserhack.md

From 7a11c34c589af161ac7a9a9fda0193cde6580717 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Fri, 20 Feb 2026 17:36:12 +0800
Subject: [PATCH 44/46] Rename WebMCP Is Not an MCP Server.md to WebMCnotMCP.md

---
 WebMCP Is Not an MCP Server.md => WebMCnotMCP.md | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename WebMCP Is Not an MCP Server.md => WebMCnotMCP.md (100%)

diff --git a/WebMCP Is Not an MCP Server.md b/WebMCnotMCP.md
similarity index 100%
rename from WebMCP Is Not an MCP Server.md
rename to WebMCnotMCP.md

From b5e3704e0efac353f22707e04511aee7b0531d3e Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Fri, 20 Feb 2026 17:56:35 +0800
Subject: [PATCH 45/46] Update README.md

---
 README.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/README.md b/README.md
index 3fbd0c6..9a1c5cc 100644
--- a/README.md
+++ b/README.md
@@ -3,3 +3,6 @@ https://starborn.github.io/webmcp/ (Model Card Generator)
 https://starborn.github.io/webmcp/webmcp-complete-guide.html (Guide)
 
 https://starborn.github.io/webmcp/webmcp-quiz.html (Quiz)
+https://starborn.github.io/webmcp/whatotest.md
+https://starborn.github.io/webmcp/browserhack.md
+https://starborn.github.io/webmcp/WebMCnotMCP.md

From 87a5f8446e80aa14b16ca07073bc3154032c5b99 Mon Sep 17 00:00:00 2001
From: Paola Di Maio <Starborn@users.noreply.github.com>
Date: Sat, 21 Feb 2026 02:01:55 +0800
Subject: [PATCH 46/46] Update WebMCnotMCP.md

---
 WebMCnotMCP.md | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/WebMCnotMCP.md b/WebMCnotMCP.md
index 78d3911..529d248 100644
--- a/WebMCnotMCP.md
+++ b/WebMCnotMCP.md
@@ -1,11 +1,13 @@
-# WebMCP Technical Note 3: WebMCP Is Not an MCP Server
+# WebMCP Technical Note: WebMCP Is Not an MCP Server
 
-**Anthropomorphic Press -- Technical Note 3**
-**15 February 2026**
+WebMCP is not MCP -- a clarification for implementers
+The WebMCP README offers a useful pedagogical framing: "web pages that use WebMCP can be thought of as MCP servers that implement tools in client-side script instead of on the backend."
+This analogy helps developers orient quickly. But it should not be taken as architectural equivalence, and treating it as such produces design errors.
+What the analogy captures: both WebMCP and MCP expose tools that agents can invoke. At the functional surface, they look similar.
+What the analogy obscures: they operate at different layers with different security models, different trust assumptions, and different governance boundaries.
 
----
-
-A persistent claim in the WebMCP ecosystem is that WebMCP turns a website into an MCP server. The W3C specification repository itself states that web pages using WebMCP "can be thought of as Model Context Protocol (MCP) servers that implement tools in client-side script instead of on the backend." Early independent implementations by Jason McGhee and Alex Nahas (MCP-B) literally did function as MCP servers, bridging browser JavaScript to MCP clients through localhost websocket connections using the standard MCP protocol.
+MCP is a network-layer protocol. Trust is established between client and server across a network boundary. The security model is connection-based.
+WebMCP is a browser-layer architecture. Trust is mediated by the browser's origin model, user consent mechanisms, and permission policies. The security model is origin-based.
 ([W3C spec repo](https://github.com/webmachinelearning/webmcp))
 ([McGhee implementation](https://github.com/jasonjmcghee/WebMCP))
 ([Nahas MCP-B](https://github.com/MiguelsPizza/WebMCP))
@@ -66,6 +68,3 @@ The analogy is useful for first contact. A developer unfamiliar with WebMCP can
 
 None of this is an argument against WebMCP or against MCP. A company might maintain an MCP server for direct API integrations with AI platforms and simultaneously implement WebMCP tools on its consumer-facing website for browser-based agent interaction. The two are complementary, not competing, and not identical. Recognizing the distinction is necessary for evaluating each on its own merits.
 
----
-
-*Anthropomorphic Press, indexed in Dow Jones Factiva. CWRE*