WebMCP

How It Works

On every Solid# page, a small client provider feature-detects navigator.modelContext and registers the verbs allowed for that page. If the browser doesn’t support WebMCP, the provider no-ops cleanly. If it does, the agent sees the tools instantly.

if (navigator.modelContext) {
  await navigator.modelContext.registerTool({
    name: "view_pricing",
    description: "Navigate to Solid#'s pricing page.",
    inputSchema: { type: "object", properties: {}, additionalProperties: false },
    annotations: { readOnly: true, destructive: false, idempotent: true },
    execute: async () => {
      window.location.assign("/pricing");
      return { navigated: true, path: "/pricing" };
    },
  });
}

You don’t register tools by hand on Solid# pages — our generators do it. But this is the wire-level contract we sit on top of.

Five Surfaces, One Vocabulary

Each Solid# surface has its own catalog of verbs. They’re all backed by the same JSON-LD registry on the backend, so external agents that speak stdio MCP, UCP, or in-browser WebMCP see consistent metadata.

Manifest & Execute

The same WebMCP verbs are introspectable as a server-side manifest — useful for crawlers, agent training pipelines, and solid graph.

curl https://api.solidnumber.com/webmcp/manifest?surface=public

Returns the JSON-LD verb catalog. Each entry has a resolvable IRI under https://api.solidnumber.com/webmcp/tools/{name} — the platform-canonical identifier shared by stdio MCP and UCP.

curl -X POST https://api.solidnumber.com/webmcp/execute \
  -H 'Authorization: Bearer <api-key>' \
  -H 'Idempotency-Key: <opaque b64url>' \
  -H 'Content-Type: application/json' \
  -d '{"tool": "create_contact", "input": {"name": "Ada", "email": "ada@example.com"}}'

CLI

The Solid# CLI (@solidnumber/cli v2.7.0+) ships first-class WebMCP commands. Every command supports --json for agent consumption.

# List verbs on a surface
solid webmcp manifest --surface public
solid webmcp manifest --surface dashboard --json

# Inspect one verb (input schema, annotations, IRI)
solid webmcp verb view_pricing

# Execute a verb (idempotency-key auto-generated)
solid webmcp execute create_contact --input '{"name":"Ada","email":"ada@example.com"}'

Consent Ladder

Public-surface (marketing) verbs are read-only and don’t prompt. Every other surface inherits the same 4-rung consent ladder used by UCP and the tenant API:

Revocation is immediate. Every grant + revocation writes an append-only audit event. Retention follows the subscription tier (starter 30d → enterprise 365d).

Match-Pattern Integration

WebMCP is not a side-system on Solid#. It’s a transport on top of the same JSON-LD vocabulary that powers our other agent surfaces:

• ▸Vocab. solid:MCPTool and solid:Verb are first-class types in our Schema.org-extended JSON-LD.
• ▸Generators. Site/page/block generators auto-attach verbs at write time via the intent detector — not as a post-process.
• ▸Renderer. The page renderer emits the matching<script type="application/ld+json"> and registers the verbs client-side in the same render pass.
• ▸One registry, three transports. services/webmcp/tool_registry.py is the source of truth for stdio MCP, UCP capabilities, and WebMCP in-browser verbs.

Browser Support

Related