Sylwia Laskowska's webMCP article is clever, funny, and genuinely enjoyable—and she's explicit that it's experimental, not a production recommendation. This isn't a rebuttal. It's a reframing: the same demo, viewed through the lens of risk surfaces and governance. My concern isn't with her intent — it's with how easily newcomers building client systems may misread a playful demo as a pattern to copy.
I. The Demo Was Funny Because the Risk Is Real
In Sylwia's article, she writes:
webMCP allows websites to expose structured information about available actions…
Those "actions" aren't descriptive hints. They are callable functions wired directly into application logic.
In her demo, those actions include:
- hire_employee
- fire_employee
- rewriteInRust
- pivotToAgents
It's hilarious in a toy app. It's catastrophic in a real one. The humor works precisely because the underlying risk is real.
II. The Hidden Assumption: Exposing Actions Is Neutral
webMCP is framed as "like accessibility metadata." But accessibility metadata is descriptive. webMCP metadata is executable.
That's the conceptual inversion most newcomers will miss.
III. Structural Vulnerability #1: Unbounded Action Surface
If a tool exists, an agent can call it. There is no:
- permission model
- capability scoping
- rate limiting
- intent validation
- safety envelope
Sylwia jokes: "someone will definitely give an agent access to fireEmployee(), the agent will lay off the entire company…"
This is not a hypothetical. It is the exact failure mode.
IV. Structural Vulnerability #2: Agent Overreach
Her CEO sim demonstrates the problem perfectly:
the agent selected the appropriate tools and immediately got to work.
Agents act with high confidence even when their world model is incomplete. webMCP gives them direct levers into application state. This is the same overreach problem MCP has—just moved into the browser.
V. Structural Vulnerability #3: Protocol Brittleness
webMCP relies on human-authored descriptions:
html<form mcp-name="createSupportTicket"
mcp-description="Create a new customer support ticket">
If the description is wrong, incomplete, or misleading, the agent will act incorrectly.
A commenter in Sylwia's article captured this perfectly: "ARIA roles were the easy part—the hard part was verifying the flow actually works."
webMCP is at the ARIA stage. But unlike ARIA, the consequences aren't limited to usability. They include state mutation, data loss, and privilege escalation.
VI. The Browser Makes Everything Worse
webMCP inherits MCP's risks and adds browser-specific ones:
- authenticated session hijack amplification
- cross-site agent orchestration
- confused-deputy problems
- drive-by agent activation
- no cross-application authorization model
One commenter put it bluntly: "We're building highways before traffic lights." They're right.
VII. A Better Frame: High-Risk Integration Layer, Not Accessibility
webMCP is not accessibility. It is not progressive enhancement. It is not a harmless compatibility layer.
It is a privileged interface for autonomous agents, and it requires:
- authorization
- auditability
- safety gates
- policy
- capability envelopes
- state-transition validation
If you wouldn't expose an action in your public API, you shouldn't expose it in webMCP.
Closing
Sylwia's article is fun, imaginative, and genuinely valuable as an exploration of what webMCP could enable. The risks are real, structural, and easy to miss—especially for newcomers.
webMCP may become part of the future web. But if it does, it will need the same rigor we apply to any privileged interface.
Until then, treat it not as an accessibility layer, but as an attack surface.
Top comments (0)