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 (3)
Thanks for the mention! You should have tagged me, I would have noticed it much sooner 😂
And honestly, this is a very interesting angle. The more comments I read under my own post, the more convinced I become that we should be very careful here. The technology itself is fascinating, but once agents start getting access to more powerful actions, questions around safety, permissions, and trust become impossible to ignore.
Really enjoyed reading your perspective!
Ha—the missing tag is on me, I'll @ you next time so it doesn't take a week to find you.
Real credit to you, though: the demo did the hard part. You can't teach "exposing an action isn't neutral" from a spec—but fire_employee() in a toy app teaches it in one line. The humor was the pedagogy; it's the reason the reframing had anything to stand on.
And your instinct in the thread is the right one. The question was never whether to be careful, it's where the line actually sits—which actions are safe to expose and which never should be. You're closer to the building edge of that than most, so I'd genuinely like to keep comparing notes as the standard shakes out. Thanks for being so open to the angle.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.