it seems like a cleaner approach to declare a handful of tools that users can approve/ask for granularily, than just say "my website can run any wacky script, here is some bookmarklet, nerds" or the very generic permission model of browser extensions

▲

koolala a day ago | parent [-]

Couldn't that be solved with a simple bookmarklet permission model? The script would request the same pop-up features as a website?

▲

miguelspizza a day ago | parent [-]

It's more providing permission granularity on the action level rather than the sandbox level. Your script might not be able to make external api calls, but there is no way to gate the ability to take destructive action within the webpage.

With something like WebMCP you get elicitation and the ability to disable tools from the client.

▲

koolala a day ago | parent [-]

What kind of destructive action do you mean that is so critical?

▲

miguelspizza a day ago | parent [-]

WebMCP essentially turns your website into an MCP server. Which means it is kind of like building a UI for the LLM that lives alongside the human UI.

It's also a contract for how LLM's interact with a website, they can do no more than the tools allow them to do. When you are running javascript on the page, the entire website is an attack surface.

Let's take gmail, for example. There is no way to protect your webpage from an agent running a script that sends an email by triggering the send email button. But with WebMCP, you can explicitly disable the "send_email" tool when the agent interacts with gmail.

	▲	koolala a day ago \| parent [-]
		That sounds nice. That makes the WebMCP both capabilities and permissions.