WebMCP reaches the browser agent. A remote MCP reaches the CLI.

Update (2026-10-07): Rechecked sources and live endpoints; corrected the Registry transport wording and Claude Code setup command.

WebMCP gives browser agents client-side tools through document.modelContext; a remote Model Context Protocol (MCP) server gives CLI clients a network endpoint. For a blog, expose WebMCP when the agent is already visiting a rendered page, and expose a separate read-only Streamable HTTP server when Codex CLI, Claude Code, or another MCP client should search without a browser.

WebMCP and remote MCP: key facts

• The WebMCP specification is published as a Draft Community Group Report dated 2026-10-02 by the Web Machine Learning Community Group and is not a W3C Standard.
• Google Chrome enabled an origin trial for WebMCP starting in Chrome 149, with local testing enabled via chrome://flags/#enable-webmcp-testing.
• WebMCP tool registration requires the tools Permissions Policy, which defaults to self and blocks cross-origin iframes unless allow="tools" is granted.
• EmDash provides <WebMcpSearch /> in emdash/ui/webmcp-search, which registers a read-only search_site tool with untrustedContentHint: true and no-ops in browsers without WebMCP.
• The MCP Registry's remote-server guide recommends the streamable-http transport; SSE is deprecated and remains for existing-client compatibility.
• A live tools/list response from https://insidetheloop.dev/mcp exposes three read-only tools (search_posts, get_post, list_recent_posts), separate from the administrative OAuth endpoint at /_emdash/api/mcp.

What is WebMCP and how does Chrome run it?

WebMCP provides a browser interface allowing web applications to expose client-side JavaScript functions as callable tools to artificial intelligence agents. As stated in the WebMCP Draft Community Group Report dated 2026-10-02, the specification "is not a W3C Standard nor is it on the W3C Standards Track." Chrome for Developers published its implementation guide on 2026-05-18 and updated it on 2026-10-01 to launch the WebMCP origin trial beginning in Chrome 149.

WebMCP extends the Document interface by exposing document.modelContext with three core methods: registerTool(), getTools(), and executeTool(). For content management systems like EmDash, developers register client-side search by embedding <WebMcpSearch /> into the layout:

---
import WebMcpSearch from "emdash/ui/webmcp-search";
---
<WebMcpSearch collections={["posts", "pages"]} routeMap={{ posts: "/posts/:slug" }} />

In browsers supporting WebMCP, the component registers a client-side search_site tool returning post titles, URLs, and excerpts. EmDash sets the tool annotation untrustedContentHint to true, warning evaluators that search outputs represent untrusted user content rather than prompt instructions. In browsers without WebMCP, the component executes no operations and issues zero database queries during page rendering.

Chrome gates WebMCP behind the tools Permissions Policy. The directive defaults to self, allowing tool registration on top-level pages while blocking cross-origin iframes unless developers add allow="tools".

How does a remote MCP server reach CLI coding agents?

A remote MCP server exposes tools over standard network protocols so external clients query site content without loading a browser engine. Terminal coding agents operate from local shells rather than browser contexts, as described in How AI agents fetch web pages: user agents, IP ranges, and fetch origins. They cannot run client JavaScript or interact with document.modelContext.

To support CLI agents, a site provides a stateless HTTP endpoint implementing the Model Context Protocol JSON-RPC 2.0 specification over Streamable HTTP. The 2026-07-28 MCP specification describes that transport as sending each message as an HTTP POST to one MCP endpoint. Terminal operators connect tools directly from the command line:

# Connect Inside the Loop to Codex CLI
codex mcp add inside-the-loop --url https://insidetheloop.dev/mcp

# Connect Inside the Loop to Claude Code over HTTP
claude mcp add --transport http inside-the-loop https://insidetheloop.dev/mcp

The live endpoint at https://insidetheloop.dev/mcp returned HTTP 405 Method Not Allowed with an allow: POST header when probed with GET on 2026-10-07. A JSON-RPC 2.0 tools/list request returned these available tool definitions:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "search_posts",
        "title": "Search posts",
        "annotations": { "readOnlyHint": true }
      },
      {
        "name": "get_post",
        "title": "Get a post",
        "annotations": { "readOnlyHint": true }
      },
      {
        "name": "list_recent_posts",
        "title": "List recent posts",
        "annotations": { "readOnlyHint": true }
      }
    ]
  }
}

Why must a site separate public read-only MCP from administrative OAuth MCP?

Public readers and administrative assistants require separate MCP endpoints to prevent unauthorized modifications to site data. EmDash includes a built-in MCP server at /_emdash/api/mcp for site editors. Probing GET /_emdash/api/mcp returns HTTP 401 Unauthorized with a header pointing to /.well-known/oauth-protected-resource.

Inspection of https://insidetheloop.dev/.well-known/oauth-protected-resource on 2026-10-07 reveals the following OAuth scopes:

{
  "resource": "https://insidetheloop.dev/_emdash/api/mcp",
  "scopes_supported": [
    "content:read",
    "content:write",
    "schema:read",
    "schema:write",
    "admin"
  ]
}

Connecting to /_emdash/api/mcp triggers an OAuth consent workflow where an authenticated user must grant permissions, as explored in Who can connect custom MCP servers in ChatGPT without developer mode?. If a blog exposed /_emdash/api/mcp publicly without authentication, external agents could invoke content:write or schema:write to alter articles.

A public content endpoint like https://insidetheloop.dev/mcp should restrict its catalog to read-only tools. In the 2026-10-07 tools/list probe, every returned tool had readOnlyHint: true, and the request succeeded without an authentication challenge.

How do WebMCP and remote MCP compare for a blog?

WebMCP and remote MCP target different agent execution environments, client capabilities, and transport layers:

How does a remote server publish to the MCP Registry preview?

The Model Context Protocol Registry is an official centralized metadata repository for publicly accessible MCP servers, backed by Anthropic, GitHub, PulseMCP, and Microsoft. According to the registry specification, remote servers declare endpoints in a standardized server.json manifest:

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "dev.insidetheloop/blog",
  "title": "Inside the Loop Blog MCP",
  "description": "Public read-only search and retrieval for Inside the Loop blog posts",
  "version": "1.0.0",
  "remotes": [
    {
      "type": "streamable-http",
      "url": "https://insidetheloop.dev/mcp"
    }
  ]
}

The Registry's remote-server guide recommends the streamable-http transport and marks SSE as deprecated, while retaining SSE for existing clients. Remote servers must be publicly reachable at their specified URL. Server names use reverse-DNS-style namespaces, with ownership verified through GitHub, DNS, or HTTP challenges.

Sources

• WebMCP Draft Community Group Report (read 2026-10-07)
• WebMCP | AI in Chrome (read 2026-10-07)
• AI Tools Guide | EmDash Documentation (read 2026-10-07)
• The MCP Registry (read 2026-10-07)
• Publishing Remote Servers | Model Context Protocol (read 2026-10-07)
• Model Context Protocol 2026-07-28 transport (read 2026-10-07)
• Claude Code MCP reference (read 2026-10-07)
• Inside the Loop MCP Endpoint (read 2026-10-07)
• Inside the Loop OAuth Protected Resource (read 2026-10-07)

Last verified: 2026-10-07.