Surprised to see this on HN front-page.

A lot has happened since I proposed / built this.

WebMCP is being incubated in W3C / webmachinelearning, so highly recommend checking that out as it's what will turn into WebMCP being in your browser.

https://github.com/webmachinelearning/webmcp

▲

koolala a day ago | parent | next [-]

How much of this can or can't be done by a Extension or Bookmarklet running JS in a page? What is your biggest dream from standardizing this?

▲

jasonjmcghee a day ago | parent | next [-]

If there's a standard instead of needing to download the Jira mcp server, you just visit their website and all the tools are described and usable from there.

Or put differently, as a company / group / individual, instead of needing to build and distribute an mcp server and public API, you can just support WebMCP.

Another alternative is LLMs / agents operating playwright or the equivalent which will likely be less reliable and consume more tokens. (By a fair margin)

	▲	a day ago \| parent [-]
		[deleted]

▲

nsonha a day ago | parent | prev [-]

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.

▲

huflungdung a day ago | parent | prev [-]

[dead]