CHAPTER 1
Fundamentals of the agentic web
From the mental model to the first tool registered within a page.
TRAINING 2 · PHASE 1
WebMCP Builder
Move beyond diagnosis and turn a website into a structured, visible, and controllable tool surface.
4
Builder Chapters
4
Available modules
24
Published topics
2
Laboratories
SHARED PROGRESS
Your journey continues across repositories
The same identifier as Formation 1 records completed items, questions, and notes. On GitHub Pages, the origin is shared; JSON keeps the fallback portable.
0 of 240%
Builder training roadmap
The top navigation moves between chapters. Within each chapter, modules follow the chapter.module numbering.
Available
CHAPTER 2
Tool design
Turn human journeys into clear, small, verifiable contracts.
- 2.1From journey to intent
- 2.2Schemas that guide agents
- 2.3Results, errors, and recovery
- 2.4Contextual catalogs
CHAPTER 3
Application integration
Connect tools to the interface, state, and backend without duplicating rules.
- 3.1UI state and execution
- 3.2Backend, session, and authorization
- 3.3Frameworks and lifecycle
- 3.4Fallback and compatibility
CHAPTER 4
Builder quality
Test selection, execution, safety, and experience before delivery.
- 4.1Threats and trust boundaries
- 4.2Choice and argument evals
- 4.3Observability and governance
- 4.4Final Builder project
Chapter 1 · available modules
Chained actions in practice
Search, filter, and build a study list with operations shared between the interface and tools. See calls, results, and measurement limits.
Open the chained actions labCROSS-CUTTING LAB
Tool and schema validator
Paste an auditable catalog in JSON and get a diagnosis of its contract, clarity, schema, lifecycle, risk, and sample output. The lab does not register or execute tools.
Detailed content
1.13h
🧭 WebMCP, MCP, and the agentic Web
Build a mental model that distinguishes visual automation, APIs, MCP, and tools exposed directly by the page.
0 of 60%
What it is:
The same search can be performed by a person, visual automation, or a structured tool.
Why learn this:
Comparing the three approaches builds the mental model that supports the rest of the course.
Key concepts:
human goal · visual steps · explicit capability · same interface
What it is:
Semantic web, browser automation, API, MCP, and agentic web solve different problems.
Why learn this:
The distinction prevents similar names from becoming one vague abstraction.
Key concepts:
understand · operate · call · discover
What it is:
The page registers; the browser observes; the agent chooses; JavaScript executes; the result comes back.
Why learn this:
Understanding the full lifecycle reveals where each responsibility really lives.
Key concepts:
registration · discovery · selection · execution
What it is:
A tool combines a name, description, schema, and an execute function.
Why learn this:
Each field influences a different decision by the agent and the application.
Key concepts:
name identifies · description guides · schema constrains · execute performs
What it is:
Useful capabilities change across the home page, product, cart, and authenticated area.
Why learn this:
A contextual catalog reduces noise and avoids offering impossible actions.
Key concepts:
home searches · product selects · cart updates · session authorizes
What it is:
The Builder must account for fallback, authorization, cancellation, evidence, and limits.
Why learn this:
The project completes the mental model with a deliverable that can be demonstrated and critiqued.
Key concepts:
fallback · safety · evidence · project
1.23h
🧪 Development environment
Prepare an environment that is safe, observable, and compatible with the experimental nature of the specification.
0 of 60%
What it is:
The ModelContext interface is defined for SecureContext; HTTPS and localhost are the lab’s minimum requirements.
Why learn this:
The correct test distinguishes an unavailable API, experimental configuration, and an actual code failure.
Key concepts:
HTTPS in production · localhost in the lab · flag may vary · origin matters
What it is:
Vite provides a local server and ES modules; Node runs the project automation, not the document’s WebMCP API.
Why learn this:
This separation lets you develop the site in any browser and enable WebMCP only as a progressive enhancement.
Key concepts:
Node for tooling · Vite serves the page · API lives in the Document · build does not determine support
What it is:
Feature detection checks for the actual capability at the time of use, without relying on the user agent or a fixed version.
Why learn this:
As the draft changes, detecting the available surface is more durable than hard-coding a list of browsers.
Key concepts:
test the property · fallback is functional · message is honest · no sniffing
What it is:
DevTools, the console, and a local inspector help you observe registration, catalog changes, input, and results.
Why learn this:
Without evidence, it's easy to confuse a well-registered tool with one that's actually safe and usable.
Key concepts:
structured console · observable toolchange · test inputs · captured result
What it is:
Types help the editor, and a polyfill can simulate the surface for testing, but neither proves the agent has native browser support.
Why learn this:
Distinguishing simulation from implementation prevents false positives in the readiness report.
Key concepts:
types don't execute · polyfill simulates · native is different · record the mode
What it is:
The matrix records the browser, channel, flag, secure context, date, and test result.
Why learn this:
An experimental API requires traceability; “it works here” isn’t enough for a team or for production.
Key concepts:
test date · version and channel · documented flag · verified fallback
1.33h
🧾 Experimental declarative API
Turn semantic forms into tools agents can understand, while keeping them under user control.
0 of 60%
What it is:
The toolname and tooldescription attributes declare the form's intent without removing its HTML semantics.
Why learn this:
It's the lowest-effort path for journeys that already have fields, validation, and a submit button.
Key concepts:
form remains HTML · toolname identifies · description guides · progressive enhancement
What it is:
The control's name becomes the property; toolparamdescription explains the meaning and expected format to the agent.
Why learn this:
Labels help people, while precise descriptions reduce plausible but incorrect entries.
Key concepts:
name is the key · label is for people · description guides selection · examples clarify
What it is:
Input types, required, min, max, and options contribute to the schema synthesized by the browser.
Why learn this:
Reusing semantic constraints keeps the manual form and the tool aligned.
Key concepts:
required becomes a requirement · select limits values · min/max constrain · algorithm is still evolving
What it is:
Without toolautosubmit, the agent fills in the form and the page returns focus to the user for review; with the attribute, submission can happen automatically.
Why learn this:
The choice should follow the action’s risk and impact, not just the convenience of the workflow.
Key concepts:
missing prompts review · boolean enables submission · risk guides decisions · UI shows completion
What it is:
For agent-triggered submissions, agentInvoked lets you identify the source, and respondWith returns a Promise with the structured result.
Why learn this:
The agent receives a verifiable protocol without relying on scraping the page after submission.
Key concepts:
preventDefault first · test agentInvoked · Promise as response · error is structured
What it is:
The draft describes tool activation and cancellation; support and event targets need to be confirmed in the browser being used.
Why learn this:
The interface must remain readable when the agent starts, the user reviews, or the call is canceled.
Key concepts:
explicit visual state · cancellation clears UI · draft may change · fallback doesn’t depend on this
1.43h
⚙️ Imperative API
Register JavaScript tools with schemas, asynchronous execution, cancellation, and structured results.
0 of 60%
What it is:
document.modelContext.registerTool accepts name, optional title, description, inputSchema, execute, and optional annotations. The name accepts 1 to 128 ASCII alphanumeric characters, underscores, hyphens, or periods.
Why learn this:
The imperative approach supports workflows that don’t fit in a form or depend on rich logic and state.
Key concepts:
unique name · nonempty description · execute required · registration returns a Promise
What it is:
inputSchema uses JSON Schema to declare properties, types, enums, descriptions, and required fields.
Why learn this:
The schema is part of the reasoning for choosing and generating arguments; actual validation must still happen in the code.
Key concepts:
type object · focused properties · coherent required · validate in execute
What it is:
The execute callback can return a Promise; the resolved value is delivered to the agent.
Why learn this:
Small results, typed by convention and accompanied by evidence, make verification and chaining easier.
Key concepts:
Promise is accepted · result is serializable · UI is updated · errors are useful
What it is:
The registerTool signal removes the tool when aborted; the signal received by execute cancels the call in progress.
Why learn this:
This model prevents obsolete tools and work from continuing after the agent loses interest.
Key concepts:
registration signal removes · execution signal cancels · fetch accepts signal · cleanup is deterministic
What it is:
getTools lists tools exposed to the document, and executeTool runs a RegisteredTool with structured input.
Why learn this:
These operations enable in-page agents and controlled tests without simulating an external agent.
Key concepts:
getTools is asynchronous · origin can filter · execute uses RegisteredTool · cancellation is optional
What it is:
Searching, querying, and checking availability form a sequence with distinct responsibilities and no generic tool.
Why learn this:
A streamlined catalog improves agent selection and creates a clear foundation for the Integrator phase.
Key concepts:
search lists · query provides details · availability checks · no overlap
BUILDER CONTINUATION
Next: tool design
After the fundamentals, the same training continues in chapters 2, 3, and 4. Each chapter will have its own modules; none of them changes the student’s role to Integrator, Agent, or Expert.