Sodium WebMCP: Turn Website Features Into Agent Tools

Browser agents still spend most of their time pretending to be users — clicking, scrolling, guessing form fields. WebMCP flips that: the page registers structured tools (navigator.modelContext) so an agent calls createInvoice() instead of hunting a submit button. Sodium, surfaced on Result.dev (sodium.result.dev), is an early implementation that wraps existing website features as WebMCP tools — the idea Savio Martin demoed in August 2026 on X.

If you ship web products and expect agents to operate them, Sodium is a concrete pattern to study — not just OpenAI's WebMCP Challenge brief.

TL;DR

Why page-native tools beat DOM scraping

Classic agent flows:

1. Agent loads your SaaS dashboard.
2. Vision or DOM heuristics find "Export CSV."
3. One CSS change breaks the workflow.

WebMCP path:

1. Page registers exportCsv with JSON schema + handler.
2. Agent lists tools, calls with parameters.
3. Handler runs your existing JavaScript business logic — same auth cookie, same validation.

That is the same architectural bet as MCP for server-side agents, but scoped to the tab the human already authenticated. Sodium automates the registration layer so teams do not hand-write fifty tool stubs for fifty buttons.

How Sodium fits Result.dev

Result is an operator workspace (build, grow, support, Company Brain) with a first-party MCP server at https://app.result.dev/mcp — OAuth 2.1, Streamable HTTP, same permissions as the human UI. Sodium extends the idea from "agent operates Result" to "agent operates any Result-hosted app's surface."

Practical split:

YC's Spring 2026 batch listing cites Result's private beta users collectively around $2.8M ARR — small sample, but it signals the team is shipping production agent doors, not a demo repo.

What builders should copy (even without Sodium)

1. Inventory invocable UI actions — not pages, actions (create, refund, publish, invite).
2. One schema per action — name, natural-language description, JSON input/output (WebMCP pattern).
3. Reuse server validation — tools call the same API handlers as buttons; never fork business rules for agents.
4. Session-bound auth — agent inherits user consent; log tool calls like API calls.
5. Progressive rollout — start with read-only tools, then mutating tools with approval gates (see Claude in Chrome safety patterns).

OpenAI's WebMCP Challenge (submissions due Sept 3, 2026) rewards apps that get better when humans and agents use them together — Sodium is an on-ramp example for that rubric.

Limits and honest gaps

• Spec drift: WebMCP remains a draft; Chrome flag builds ≠ stable cross-browser API.
• Security: Exposing a button as a tool does not remove abuse risk — rate limits, CSRF, and scope checks still apply (indirect prompt injection can target tool descriptions).
• Not a replacement for MCP servers: Background jobs, cron, and cross-user admin still belong on server MCP or workflows — see the MCP roadmap explainx.ai tracked in August.
• Vendor coupling: Sodium is Result-ecosystem tooling; the pattern (wrap features → register tools) ports anywhere.

What this means for what you build

• SaaS founders: Agent parity becomes a product requirement — if there is no tool, agents will click badly.
• Agent harness devs: Prefer pages that advertise WebMCP tools; fall back to computer-use only when necessary (Cloudflare agent browser isolates show the cost of raw DOM control).
• MCP registry curators: Track WebMCP as a sibling protocol, not a fork — explainx.ai lists server MCP at /mcp-servers.

Related on explainx.ai

• OpenAI WebMCP Challenge — deadline Sept 3, 2026
• What is MCP? Complete guide
• The new MCP roadmap (August 2026)
• Claude in Chrome — extension safety guide
• Indirect prompt injection and agents
• Cloudflare Kitesurf — agent browser on V8 isolates

External: Result.dev about · Result llms.txt / MCP setup · WebMCP explainer (draft spec context)

WebMCP and Sodium are experimental as of August 31, 2026. Verify browser support and Result pricing before production commitments.