Coder Legion - Recent posts tagged webmcp

Native WebMCP on a live MCP registry

Fri, 30 Oct 2026 08:46:24 +0000

Originally published at https://dev.to/anhmtk/native-webmcp-on-a-live-mcp-registry-4a8

This is the same integration, written here so the source stays on dev.to. https://agentshare.dev/registry registers one read-only tool, search_listings, on document.modelContext when that API exists in the open Chrome tab. An agent that never opens a browser still calls remote MCP at https://agentshare.dev/mcp.

Two ways to read the same registry

	Remote MCP	Native WebMCP
Where	`https://agentshare.dev/mcp`	`https://agentshare.dev/registry`, tab open
Call style	Streamable HTTP. API key or x402	`document.modelContext` in Chrome
Lifetime	The server stays up	Ends when the tab closes
Payload	The MCP tool list, including paid Objective Trust	`search_listings` only. Public fields. At most 5 matches

Remote MCP is for an agent that is not on the page. WebMCP is for an agent that already has the registry tab open in Chrome and can call getTools / executeTool.

What the page registers

The script is https://agentshare.dev/static/js/webmcp-registry.js. It returns immediately when document.modelContext.registerTool is missing. It does not install a polyfill.

The tool is read-only. readOnlyHint is true. untrustedContentHint is true because listing descriptions are written by the people who submitted them.

execute calls GET /api/v1/registry/entries on the same origin. limit is clamped to 1–5. sort is new or popular. Featured rows still sort first. Featured does not change health_status and is not a trust rank.

The page aborts the registration on pagehide.

The envelope models can quote

Every successful call returns schema set to agentshare.catalog.v1.

{
  "schema": "agentshare.catalog.v1",
  "catalog_as_of": "2026-10-30T03:15:00Z",
  "listed": 147,
  "sort": "featured_then_newest",
  "sort_note": "Featured listings sort first. Featured does not change health_status and is not a trust rank.",
  "returned": 1,
  "matches": [
    {
      "id": 0,
      "name": "Example listing",
      "description_excerpt": "Short public description, clipped to 160 characters.",
      "health_status": "responding",
      "reviewed": true,
      "category": "agent_tools",
      "opens": 0,
      "featured": false,
      "mcp_url": "https://example.com/mcp"
    }
  ],
  "next": "For a rank that ignores featured and sponsored, call Objective Trust at https://agentshare.dev/mcp/objective-trust"
}

catalog_as_of and listed in that sample are the shape, not a frozen snapshot. On a live call, catalog_as_of is generated_at from that entries response: the server clock when the catalog was built for the tool call. It is not Date.now() in the browser. listed is total_listed on the same response.

reviewed: true means the row status is verified. health_status is the stored probe label, such as responding, needs_sign_in, unreachable, not_remote, or unknown. description_excerpt is clipped. The Objective Trust score is not in this object. The next field points at the paid ranker, which ignores featured and sponsored.

A model that quotes this payload can cite three stable facts: the schema name agentshare.catalog.v1, the page https://agentshare.dev/registry, and a server timestamp for that response.

Checking the open tab

AgentShare Agent Readiness 0.6.0 reads native document.modelContext on the active tab when you open the popup. It lists each tool name and whether the tool is read-only, consequential, or marked untrusted content.

The score gains 4 points when the tab has at least one native tool. No native API means no point change. A missing untrustedContentHint is a warning, not a penalty. A polyfill that only sets document.modelContext inside the page is invisible to the extension. The reference score for agentshare.dev stays 92.

The scan stays in the browser. Tool names are not uploaded.

Where to look

Registry, with the WebMCP tool while the tab is open: https://agentshare.dev/registry
Remote MCP: https://agentshare.dev/mcp
Objective Trust: https://agentshare.dev/mcp/objective-trust
Original article: https://dev.to/anhmtk/native-webmcp-on-a-live-mcp-registry-4a8

Bridging Model Context Protocol (MCP) to Browser Agents via W3C WebMCP (document.modelContext)

Fri, 23 Oct 2026 16:11:38 +0000

As AI agents move from local developer runtimes (like Claude Desktop and Cursor) into browser environments, developers face a major integration challenge: how to expose structured backend tools to client-side agents securely and without fragile DOM scraping.

At SEOSiri, we solved this by implementing the W3C WebMCP specification (document.modelContext). Our central developer portal dynamically registers our entire autonomous tool catalog on boot, proxying execution requests seamlessly through secure, stateless Cloudflare Edge Gateways.

Key Technical Implementation Highlights:

Dynamic Universal Registry: Automatically loops through master component registers to bind server schemas into browser runtimes.
Edge Proxying & Security: Ensures zero secret exposure by keeping backend encryption keys locked inside Cloudflare Worker environment variables while marshaling public JSON-RPC requests across HTTPS.
Namespace Segregation: Explicitly namespaced tool identifiers prevent collision with browser default diagnostic suites.
Native DevTools Debugging: Streamlines inspection and verification via the Chrome DevTools WebMCP application panel.

Read the Full Engineering Walkthrough:
🔗 https://www.seosiri.com/2026/10/webmcp-chrome-mcp-tools-guide.html

coderlegion #webdev #aiagents #mcp #typescript #architecture #edgecomputing

WebMCP: Letting Browser Agents Use Your Site's Own Tools

Fri, 23 Oct 2026 03:36:01 +0000

WebMCP is a proposed web standard that lets a page register its own tools, either JavaScript functions or marked-up HTML forms, which an agent in the visitor's browser can then call instead of feeling its way through buttons and inputs. In October 2026 it's a W3C Community Group draft with a Chrome origin trial, and the API changed during 2026, so many tutorials are already out of date.

I explain what it is and who's behind it, and summarise its status: an origin trial starting in Chrome 149, a flag for local testing, the move from navigator.modelContext to document.modelContext in May 2026, and early support elsewhere. Anything built now should feature-detect and fail silently.

The imperative API is registerTool(), with a name, description, input schema, callback and annotations including one that marks consequential actions like booking or paying. The declarative API turns an existing form into a tool with a few attributes. I compare WebMCP with a server-side MCP server: one lives in an open tab with the user's session, the other is a network endpoint any client can call, and Chrome's own guidance suggests using both for different jobs.

The security section covers HTTPS only, same-origin by default, a person in the loop and prompt injection as the main risk. I include a small business example and an honest list of when not to bother yet.

Key takeaways

WebMCP lets a page expose tools to in-browser agents
It's an experimental draft with an active Chrome origin trial
Forms can become tools with a few attributes
It complements, not replaces, a server-side MCP server
Mark consequential tools and validate everything server-side

Related on BuiltToWinWeb: adding a server-side MCP server

Read the full guide on BuiltToWinWeb: WebMCP explained, with a working example

A summary by Jacob Campbell of an article first published on built2winweb.com on October 7, 2026.

Securing the Pipeline: A DevSecOps Guide to Atlassian Rovo Agent Architecture and Zero-Trust MCP Gat

Mon, 28 Sep 2026 16:10:26 +0000

Integrating Large Language Models (LLMs) into production pipelines introduces critical data leakage vectors. For platform engineers and security architects, autonomous AI agents present a unique challenge: how do you allow models to interact with live backend systems without exposing API tokens, system credentials, or protected regulatory identifiers?

The full implementation details of this infrastructure are published in the comprehensive blueprint guide: Keeping Sensitive Data Out of Your Rovo Agents: A Practical Guide to the SEOSiri MCP & PII Shield.

The Problem: Non-Deterministic Prompt Exploits

When an autonomous AI agent or an automated Jira workflow processes operational data, the raw prompt payload frequently introduces hidden systemic compliance risks:

Hardcoded API Keys: Source logs and environment configurations accidentally pasted into tickets by developers under pressure.
System Identifiers: Server database schemas, cloud infrastructure paths, and network strings exposed inside debugging logs.
Regulated Information: Sensitive customer identifiers or clinical patient data parsed during automated issue routing.

Once these objects exit your corporate cloud perimeter and stream to external third-party model inference endpoints, data sovereignty is lost.

The Mitigation: In-Memory Edge Proxying via Model Context Protocol

The open-source Model Context Protocol (MCP) (rel="nofollow") allows engineering teams to isolate tool access configurations cleanly. By routing all agentic connections through the SEOSiri MCP & PII Shield for Rovo app on the Atlassian Marketplace, companies drop an active inline data firewall straight into the runtime communication stream.

{
  "mcpServers": {
    "SEOSiri": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://rovomcp.seosiri.com/api/mcp"
      ]
    }
  }
}

[Atlassian Cloud Client]│▼ (Raw JSON-RPC Payload with Hidden PII/Secrets)┌────────────────────────────────────────────────────────┐│ SEOSiri Zero-Trust Edge Gateway (In-Memory Proxy) ││ ────────────────────────────────────────────────── ││ 1. Instantly Redacts RegEx Tokens (SSNs, API Keys) ││ 2. Validates Structural JSON Structural Schemas ││ 3. Operates in Volatile V8 Sandbox (Zero Disk Logs) │└────────────────────────────────────────────────────────┘│▼ (Sanitized Payload Enforcing Deterministic Tool Hooks)[Downstream External Sovereign Server Tiers]

Why This Works at Scale:

Zero-Log Volatile Processing: The proxy engine operates fully inside short-lived edge runtimes. Prompt objects are evaluated and transformed completely in volatile memory. No data is ever written to physical disk logs, neutralizing systemic data breach threats.
Strict Token-Level Redaction: System payloads pass through a two-phase sanitization filter. Pattern matching immediately neutralizes standard credential formats, while contextual parsing strips out arbitrary strings sitting next to sensitive target keywords (such as token= or bearer:).

Architectural Support for Regulated Life Sciences

For teams engineering biopharma software ecosystems under severe statutory oversight, the framework implements native schema compliance tracking:

FDA 21 CFR Part 11 Audit Isolation: While data payloads are fully sanitized, the gateway generates cryptographically signed tool execution signatures. This proves what tool action occurred and when without logging restricted data values.
HL7 FHIR Integrity Validation: Diagnostic and clinical narrative strings are automatically structured and checked against core healthcare schema protocols before routing down the line.

To safely spin up isolated sovereign test sandboxes, developers can load specialized local nodes natively inside an IDE client like Anthropic's Claude Desktop:

Deploy the Managed Biopharma Compliance Engine:

{
  "mcpServers": {
    "seosiri-biopharma": {
      "command": "npx",
      "args": ["-y", "@seosiri/biopharma-mcp"]
    }
  }
}

Launch the High-Performance BioAssay Analytical Pipe:

{
  "mcpServers": {
    "seosiri-bioassay": {
      "command": "uvx",
      "args": ["seosiri-bioassay-mcp"]
    }
  }
}

Step-by-Step System Testing

To debug your connection schemas directly without writing custom UI wrappers, you can test the active server endpoint using standard terminal tools like cURL:

curl -X POST https://seosiri.com \
     -H "Content-Type: application/json" \
     -d '{"jsonrpc":"2.0","method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test-client","version":"1.0.0"}},"id":1}'

Note: Accessing the gateway address (https://rovomcp.seosiri.com/api/mcp) via a standard web browser address bar will return an Endpoint or method mismatch error. This occurs because the browser sends an empty GET request instead of a structured POST payload, which the edge security firewall drops automatically for safety.

Access the Full Engineering Suite

Review the underlying infrastructure matrices, dry-run live tool execution schemas, and match security profiles to your scale requirements:

Interactive Testing Sandbox: SEOSiri Live MCP Endpoint Tester
Configuration Layout Blueprints: SEOSiri Server Configuration Repository
Enterprise Resource Allocation: SEOSiri Predictable Platform Pricing

For advanced international environments requiring highly localized cloud boundaries, check out the specialized SEOSiri Dutch MCP Sovereign Framework Architecture.

WebMCP Skills v0.0.1 is live — feedback welcome

Mon, 14 Sep 2026 07:47:31 +0000

I just shipped the first release of a WebMCP skills collection.

Here are 5 things I learned while making it work across browsers, emulators, and desktops:

1️⃣ Probe before acting

Before executing anything, detect the actual page, origin, device, permissions, and adapter state.

“Visible” is not the same as “controllable.”

2️⃣ Keep WebMCP separate from DevTools

WebMCP executes page-owned tools.

DevTools inspects the browser.

Lighthouse audits the page.

Native adapters control the operating system or emulator.

They are complementary but they are not interchangeable.

3️⃣ Deterministic checks matter

The release includes executable checks for:

→ Tool schemas
→ Security risks
→ Confirmation boundaries
→ Eval traces
→ DESIGN.md references and states
→ Host readiness
→ Repository health

Documentation alone cannot prove that a contract works.

4️⃣ Unavailable is a valid result

iOS requires macOS and Xcode.

Desktop input requires OS permissions and native tools.

Android requires an authorized device or a working emulator.

The adapter should report the missing prerequisite instead of pretending the action completed.

5️⃣ Distribution is part of engineering

The release includes current skills.sh installation guidance, all-agent installation support, a discoverable 13-skill catalog, and verification commands.

A capability that cannot be found, installed, or verified is not finished.

The release is live:

https://github.com/JustineDevs/webmcp-skills/releases/tag/v0.0.1

What is the hardest capability boundary your agent tooling has had to handle?

WebMCP: The Next Technical SEO Frontier Nobody Is Talking About Yet

Wed, 15 Jul 2026 12:17:07 +0000

WebMCP: The Next Technical SEO Frontier Nobody Is Talking About Yet

Originally published on www.devndespro.com, canonical: https://www.devndespro.com/blog/webmcp-2026

Most SEO conversations in 2026 are about getting cited by AI, structured data, FAQ schema, llms.txt, being the source ChatGPT quotes. That's one problem. There's a different one quietly forming behind a Chrome flag, and it's about whether AI agents can actually use your site, not just read it.

That's what WebMCP is, and if you run a website with forms, checkouts, bookings, or search, it's worth understanding now while almost nobody else is writing about it.

The problem it solves

Right now, when an AI agent tries to interact with a website, meaning fill out a form, search for a product, or complete a booking, it does the same thing a screen reader from 2005 would do: it looks at the page, guesses which element is a button, guesses what a field expects, and hopes nothing breaks. This is slow, expensive in tokens, and fragile. Change a CSS class and the agent's automation falls apart.

WebMCP flips that. Instead of an agent guessing where the "Book a Flight" button is, a WebMCP-enabled page tells the agent directly: here's a function called bookFlight(), here are the exact parameters it expects, here's what it returns. The agent calls the function the same way a developer calls an API, no screenshots, no clicking simulation, no guesswork.

Why this matters for you

The efficiency difference is not small. Early benchmarking on WebMCP-style structured calls shows dramatic token savings compared to screenshot-based agent browsing, and near-identical task success rates to traditional automation at a fraction of the processing cost.

Practically, that means agents will increasingly prefer sites that support this. A site an agent can use directly gets used. A site an agent has to fight its way through gets skipped in favor of a competitor that made itself agent-friendly.

Think of it as the same shift that happened when robots.txt first appeared, except this time the file isn't telling crawlers what not to index, it's telling agents what they're allowed to do.

Where it stands right now

To be clear about where things actually are: this is early. Chrome 146 shipped a flag-gated developer preview in February 2026, co-authored by engineers at both Google and Microsoft under a W3C community group, which is a strong signal it's headed toward becoming a real standard rather than staying a Google-only experiment. Edge added an equivalent preview shortly after. A public origin trial is expected in a later Chrome release. It is not production-ready, and the security model around things like prompt injection and multi-agent conflicts is still being worked out.

That said, "early" is exactly the window worth paying attention to. The businesses that experiment now will understand the pattern before it becomes table stakes.

How it actually works, briefly

There are two ways to expose tools:

Declarative: add attributes like toolname and tooldescription directly to an existing HTML form. Minimal code, works with what you already have.
Imperative: register a tool in JavaScript via navigator.modelContext.registerTool(), giving it a name, a plain-language description, a JSON schema for its inputs, and a handler function.

Both approaches use JSON Schema, the same format Claude, GPT, and Gemini already use for tool-calling, so there's no new format to learn if you've touched AI tool integration before.

What to actually do about it today

You don't need to ship this in production tomorrow. A sensible first step:

Identify your highest-value user flows, checkout, booking, contact forms, search, the ones an agent completing on a user's behalf would matter most for.
Enable the WebMCP flag in Chrome 146+ and try the Model Context Tool Inspector extension to see what agent-visible tooling would look like on your own site.
Sketch a minimal declarative implementation on one form as a prototype, nothing customer-facing yet.
Keep watching the spec. It's moving fast, and being early here costs little but attention.

If you want a second pair of eyes on how agent-readiness fits into your broader technical SEO picture, feel free to reach out through www.devndespro.com.

I'm a DevOps engineer and web developer running DevnDespro, a small web development, UI/UX, and SEO agency.

How we made automatelab.tech agent-ready with WebMCP

Tue, 02 Jun 2026 10:43:02 +0000

TL;DR: We wired every tool and search box on automatelab.tech to AI agents using WebMCP - the navigator.modelContext browser API - by reusing the functions our on-page buttons already call. It now shows up in Lighthouse's new Agentic Browsing audit. Here is how, and an honest read on whether it is worth your time in 2026.

What WebMCP is

WebMCP is a browser API (navigator.modelContext) that a page calls to register tools for an in-browser AI agent. Each tool carries a name, a natural-language description, a JSON input schema, and a handler that runs when the agent calls it. It is the browser-side cousin of the Model Context Protocol that server-side integrations already speak. The spec is a W3C draft from the Web Machine Learning group.

The honest part: WebMCP ships only in Chrome 146 behind a feature flag, real-world adoption is near zero, and most agents today still read the raw DOM. This is a plant-the-flag move. Two reasons to do it anyway: it is cheap if your pages already have working actions, and Google just started measuring it.

Registering a tool

There are two paths. The declarative one adds toolname and tooldescription attributes to an existing <form> and the browser builds the input schema for you. The imperative one calls registerTool(). We took the imperative path because every tool already had a compute function:

if (navigator.modelContext) {
  navigator.modelContext.registerTool({
    name: "audit_ai_seo",
    description: "Audit a URL for AEO/GEO readiness; return the score.",
    inputSchema: {
      type: "object",
      properties: { url: { type: "string", description: "Full URL incl. https://" } },
      required: ["url"]
    },
    execute: async ({ url }) => {
      const result = await runAudit(url);   // the function the page already had
      return { content: [{ type: "text", text: result.summary }] };
    }
  });
}

The point: you are not writing new tools, you are exposing the ones you already shipped. The whole integration is a roughly forty-line helper that feature-detects navigator.modelContext and no-ops in every browser without it, so normal visitors are unaffected.

What we exposed

Ten surfaces, each reusing the function behind its on-page button:

Surface	WebMCP tool
AI SEO Checker	`audit_ai_seo`
AI Overview checker	`score_ai_overview_eligibility`
n8n cost calculator	`estimate_n8n_cost`
n8n workflow validator	`validate_n8n_workflow`
GPTBot / robots.txt helper	`get_ai_crawler_robots_rules`
Blog search	`search_blog`
Automation Error Index search	`search_automation_errors`

The Lighthouse angle

Lighthouse 13.3 added an Agentic Browsing category. The WebMCP check is informational only - it lists the tools your page registers and never fails you for having none. The other three checks (llms.txt, accessibility-tree integrity, and layout stability) pay off today regardless of WebMCP adoption: they help screen readers, retrieval crawlers, and real users.

Is it worth it in 2026?

Do the agent-readiness groundwork for the wins you can bank now - ship llms.txt, fix the accessibility tree, kill layout shift - and treat the WebMCP registration as a cheap option on a standard that might matter in a year. One caveat worth taking seriously: the WebMCP security model is still incomplete, so never expose a destructive or account-changing action without a user-confirmation step. Read-only audits, calculators, and search are safe first candidates; "delete my account" is not.

Full write-up with the step-by-step: https://automatelab.tech/blog/al-products/how-we-made-automatelab-tech-agent-ready-webmcp/

Implementing WebMCP on a Recruitment Website

Tue, 21 Apr 2026 09:58:19 +0000

Thinking about what, exactly, the future of a website “looks” like in the agentic era is a challenging proposition. It might be that in most cases, our future viewers/readers/customers can do everything, from their chatbot of preference while never visiting your site.

WebMCP is a part of this puzzle. The protocol directs an agent to stop guessing what a button does, and starts calling tools with typed inputs with a fundamentally simple tool registration protocol.

So, what’s WebMCP? WebMCP is “an emerging W3C standard developed by Google and Microsoft that acts as a browser API to turn websites into interactive tools for AI agents”.

This is the future and I think it’s very exciting. For fun, I added WebMCP support to YubHub , (my recruitment site).

Today, I’m going to talk about what I learned building, the design choices we made that worked, an agent trace that caught a hallucination in a production system (fixed), and why (in my opinion!) a recruitment site turned out to be an unusually good fit for this protocol.

YubHub in Chrome 146 with the Model Context Tool Inspector open.

Why a Recruitment Site?

Because websites new and old are going to have to change rather quickly (and, I really enjoy starting online business from scratch – the test of a true martech marketer!).

Most of the WebMCP explainers I read while researching this use a checkout flow, a to-do list, or a colour picker. Toys. They work for illustrating the API surface (what can this new thing do?), but without implmenting and playing with teh protocol yourself I fear the penny simply does not drop.

The real value with WebMCP emerges when an agent needs to reason about a lot of structured data that’s already behind a nice URL structure – and recruitment sites are built around exactly that shape: job details, salary ranges, skills required or employment locations.

YubHub already served clean data at predictable URLs (/jobs/skill/figma, /jobs/at/anthropic) and emits schema.org JobPosting markup. What it didn’t have was a “contract”. Any agent browsing the site could see the HTML and JSON-LD I’m sure, but getting an agent to browse your website for an answer via Chrome is just the craziest waste of time when ideas as fundamental as an API have been around for decades.

WebMCP fixes that by publishing the interface explicitly, with typed inputs and structured responses. Prompt in > “find me an X for a Y in Z”. So, for a site whose whole job is “be discoverable”, WebMCP is a big deal.

The basic flow. The page registers tools on navigator.modelContext, the agent discovers and invokes them, the page replies with structured data. No screen-scraping in between.

What’s WebMCP?

WebMCP is a proposed web standard, co-authored by engineers at Google and Microsoft under the W3C Web Machine Learning community group, that lets a site expose a set of callable tools to an AI agent running in the browser. There are two APIs: imperative (navigator.modelContext.registerTool() called from JavaScript), and declarative.

Think of it as a contract the site publishes to any agent that lands on it. Instead of the agent guessing that a div with class="btn-primary" means “checkout”, the page says: here’s a checkout tool, here’s what it needs, here’s what you’ll get back.

That’s a welcome leap from screen-scraping and MCP based browser control. The Chrome DevTools MCP quickstart benchmarked a simple “set counter to 42” task at 3,801 tokens using screenshots and 433 tokens using WebMCP. That’s an 89% reduction in token use!

The current spec lives on the W3C community group site (webmachinelearning.github.io/webmcp), with Chrome’s early-preview announcement and detailed posts on developer.chrome.com/blog/webmcp-epp. It ships behind a flag in Chrome Canary 146. Google Chrome Labs maintain a reference extension – the Model Context Tool Inspector – that lists the tools any page has registered and lets you call them manually. If you’re planning to build anything with this, you’ll want both installed.

How WebMCP Differs From MCP

The names don’t help much, do they! Model Context Protocol (MCP) is server-side – you deploy an MCP server that an agent connects to, it runs in its own process, exposes tools to your AI assistant over JSON-RPC. We have a growing library of our own MCP connectors like my favourites Gemini MCP and Houtini-LM.

WebMCP is the browser-side sibling. Your tool code runs in the page’s JavaScript context, so it has the user’s cookies, their session, their permissions – everything the user already has access to. There’s no deployment, no auth bridge, no server to pay for. Well, mostly – you still have to maintain the page, obviously, but there’s nothing extra. If your site already authenticates the user, your WebMCP tools inherit that authentication for free.

The practical consequence: MCP is the right fit for agents that need third-party data (GitHub, Gmail, a database). WebMCP is the right fit for agents that need to interact with a specific site the user has requested.

Getting Set Up

If you have Chrome Canary 146 or higher, you are already setup. The stable, Beta, and Dev channels of Chrome do not ship with the WebMCP flag – so you have to enable it:

Open a new tab to chrome://flags/#enable-webmcp-testing and set “WebMCP for testing” to Enabled. Click Relaunch.

Enable WebMCP for testing

Third, install the Model Context Tool Inspector extension from the Chrome Web Store. This is currently the only way to test anything before you’ve wired an agent in. It lists every tool the current page has registered, shows you their JSON schemas, and lets you execute them manually with whatever input you want. The extension requires a Gemini API key as the extension uses Gemini as a natural-language test harness, which is useful for checking whether your tool descriptions are clear enough for a real LLM to pick the right tool. This is much like tool context set in tool descriptions in the MCP protocol.

The WebMCP Inspector extension.

To verify the whole thing is working, open DevTools and run console.log(navigator.modelContext). If you see an object come back rather than undefined, you’re in business. If it’s undefined, either your flag isn’t set or you’re on the wrong Chrome channel.

Setting Up the Imperative API

Here’s the minimum viable tool registration from YubHub’s live scaffold:

if (!navigator.modelContext) return;

var pageController = new AbortController();
addEventListener('pagehide', () => pageController.abort(), { once: true });

navigator.modelContext.registerTool({
  name: 'yubhub_fetch_job',
  description: 'Fetch a single YubHub job as clean markdown (company, location, salary, work arrangement, full description, apply URL, skills). More token-efficient than the HTML page.',
  inputSchema: {
    type: 'object',
    properties: {
      id: { type: 'string', pattern: '^job_[a-z0-9_-]+$' },
    },
    required: ['id'],
  },
  execute: async (params) => {
    const r = await fetch('/jobs/' + params.id + '.md',
      { headers: { Accept: 'text/markdown' } });
    return { id: params.id, markdown: await r.text() };
  },
}, { signal: pageController.signal });

There are 4 things to look at here – firstly, the feature-detection guard – navigator.modelContext only exists in Chrome 146 with the flag on, so every public-facing scaffold needs to short-circuit gracefully elsewhere or you’ll throw on every other browser your users visit from.

The pattern constraint on id – the spec treats JSON Schema loosely in the browser, so validating in code catches the cases the schema doesn’t. And the return value is a structured object, not a string – the agent reads it as data rather than trying to parse text/html.

The Inspector showing the tool’s schema (green box) and the agent’s prompt (red box). You can drive this entirely by hand during development, which is the fastest way to catch bad tool descriptions.

The Declarative API Is Free Engineering

I think this is the cleverest part of the WebMCP spec. If you’ve got an HTML form – and of course, you do, you can annotate it and get a tool registration for free.

YubHub’s nav already had a GET form submitting to /jobs/search. All I did was add three attributes:

<form action="/jobs/search" method="GET"
      toolname="yubhub_search"
      tooldescription="Search YubHub's enriched job board by free-text query - title, company, or keyword. Submits a GET to /jobs/search and renders the results page."
      toolautosubmit>
  <input type="search" name="q"
         toolparamdescription="Job title, company name, or any keyword (2-100 chars)"
         minlength="2" maxlength="100" />
</form>

The browser reads the form, builds a JSON Schema from the input fields, and registers it as a tool. When an agent calls it with {q: "python"}, the browser focuses the form, populates the input, and – because of toolautosubmit – submits it automatically. Zero JavaScript. Your form already works for humans; now it works for agents.

One thing worth flagging: toolautosubmit is only really safe on read-only operations. Search queries, availability lookups, status checks – fine, let the agent submit. Anything that creates, modifies, or deletes data should leave the flag off, so the human has to click Submit after the agent fills the form.

And that, I reckon, is how WebMCP adoption will probably start to emerge – by adding it to their internal site search forms and results pages. But I hope to see people agreeing that this idea undersells what WebMCP can do in the longer term.

Context-Scoped Tool Registration

I’ve got a tool called yubhub_current_job. It takes no arguments, and it just returns the current job’s markdown. Obviously, that only makes sense on my job listing pages, so anywhere else on the site it would be meaningless (worse, it’d be confusing). The scaffold pattern-matches the URL and registers conditionally:

const jobMatch = location.pathname.match(/^\/jobs\/(job_[a-z0-9_-]+)$/i);
if (jobMatch) {
  const currentJobId = jobMatch[1];
  navigator.modelContext.registerTool({
    name: 'yubhub_current_job',
    description: 'Return clean markdown for the job the user is currently viewing ('
      + currentJobId + '). Zero-arg shortcut.',
    inputSchema: { type: 'object', properties: {} },
    execute: async () => {
      const r = await fetch('/jobs/' + currentJobId + '.md');
      return { id: currentJobId, markdown: await r.text() };
    },
  }, { signal: pageController.signal });
}

The AbortController ties it to the page lifecycle – when the user navigates away, pagehide fires, the controller aborts, and all tools registered with its signal drop off the agent’s radar. Importantly this leaves no leftover closures holding references to the previous page’s state.

Same site, three pages, three different tool menus. The agent sees only the tools that make contextual sense.

There are two kinds of tools you can give an agent, and they create completely different user experiences.

Navigation tools change the URL on the user’s behalf. They’re the right call when the user actually wants to end up somewhere else – looking at a specific job, browsing a facet, running a search. So the agent calls yubhub_browse_jobs({type: 'skill', slug: 'figma'}), the tab navigates, the user sees the archive page. The return value is basically a receipt (“I took you here, here’s what’s on the page”).

The real power, IMO, is this: Data-retrieval tools return parsed data and leave the URL alone. The agent calls them to reason, compare, filter, summarise – and the user stays on whatever page they were already on, quite unaware that the agent just read a hundred jobs to answer a question. yubhub_fetch_facet returns up to 100 schema.org JobPosting entries; yubhub_shortlist filters them by salary floor, remote status, title keyword, and hands back a ranked list.

Data-retrieval is what I’m bullish on – it’s a midbendingly powerful solution to the current state of play with AI based webcrawl / actions for users and so on.

_yubhub_shortlist returning a ranked list of product manager roles._

Only shipping navigation tools is the mistake I’d warn you off. It just makes the agent a fancy URL-rewriter – it can answer “take me to X”, but it can’t answer “summarise the options and recommend one” without hauling the whole user along.

What WebMCP Can’t Do (Yet)

A browsing context is required. There’s no headless mode – if a tab isn’t open, the tools don’t exist. That rules out batch or scheduled agentic work against a WebMCP site, for now.

Discoverability is thin. An agent has to visit your page to see your tools. There’s no global registry, no “hey agent, here’s a list of sites with useful WebMCP tools” index. A .well-known/webmcp manifest has been proposed – and I think it’ll be necessary eventually – but nothing’s shipped yet. Someone is going to come up with an authority directory of WebMCP supportive brands any minute now.

The spec moves weekly. Between my first discovery of the docs and shipping, my implementation, provideContext and clearContext got removed entirely, unregisterTool came back after being briefly deprecated, and the AbortSignal handling in registerTool‘s second argument settled into the form above. Track the spec repo and expect to rewrite things. I’m in the preview group which is very easy to register for.

If you run a site that has structured data behind predictable URLs – a product catalogue, a job board, a docs site, a media library – WebMCP is worth shipping now, even though browser adoption is near zero. It’s cheap to add, it forces you to think about your tool contracts before agents try to guess them, and it positions the site for when Chrome lifts the flag and Edge follows. When that happens I think there will be quite a fuss about it.

The post Implementing WebMCP on a Recruitment Website appeared first on Houtini.

Coder Legion - Recent posts tagged webmcp

Native WebMCP on a live MCP registry

Two ways to read the same registry

What the page registers

The envelope models can quote

Checking the open tab

Where to look

Bridging Model Context Protocol (MCP) to Browser Agents via W3C WebMCP (document.modelContext)

coderlegion #webdev #aiagents #mcp #typescript #architecture #edgecomputing

WebMCP: Letting Browser Agents Use Your Site's Own Tools

Key takeaways

Securing the Pipeline: A DevSecOps Guide to Atlassian Rovo Agent Architecture and Zero-Trust MCP Gat

The Problem: Non-Deterministic Prompt Exploits

The Mitigation: In-Memory Edge Proxying via Model Context Protocol

Why This Works at Scale:

Architectural Support for Regulated Life Sciences

Step-by-Step System Testing

Access the Full Engineering Suite

WebMCP Skills v0.0.1 is live — feedback welcome

WebMCP: The Next Technical SEO Frontier Nobody Is Talking About Yet

WebMCP: The Next Technical SEO Frontier Nobody Is Talking About Yet

The problem it solves

Why this matters for you

Where it stands right now

How it actually works, briefly

What to actually do about it today

How we made automatelab.tech agent-ready with WebMCP

What WebMCP is

Registering a tool

What we exposed

The Lighthouse angle

Is it worth it in 2026?

Implementing WebMCP on a Recruitment Website

Why a Recruitment Site?

What’s WebMCP?

How WebMCP Differs From MCP

Getting Set Up

Setting Up the Imperative API

The Declarative API Is Free Engineering

Context-Scoped Tool Registration

Navigation Tools vs Data-Retrieval Tools

What WebMCP Can’t Do (Yet)