My kids still ask for a new coloring page every day. They want all kinds of wild combinations, like a unicorn swimming in a lake, a dragon riding a skateboard, or a cat that is also a firefighter. That’s exactly why I built Colorburst, and I wrote about the workflow that made building it fun. Over the summer I did a little experiment. I had been thinking about how an agent could use Colorburst, and with WebMCP making progress, I wanted to try it and see how it works.
Why WebMCP
Generally, I’m a big fan of MCP. For me it’s the most interesting integration layer for agents, especially when you don’t own the agent you want to integrate with. People want to bring their own agent and connect it to the services they use, and we see this with Claude and OpenAI. MCP reduces the friction of talking to services from your own agent.
I’ve built MCP servers before, and I know how much work it is to get one running in production and at scale. You need the server and the infrastructure to run it, with monitoring and rate limits. Authentication alone is a project of its own: an OAuth flow, token storage and scopes, all of it secure. And then people still have to find your server. In Colorburst’s case nobody had asked for it yet, so I wouldn’t set up an MCP server out of the blue.
Then I looked at WebMCP, a W3C community group draft by folks from Google and Microsoft. With it I don’t need any of that infrastructure and friction, I can just add some tools to the website. That sounded worth a shot. The page calls document.modelContext.registerTool() for each tool, and the browser hands those tools to the agent. The explainer calls these pages in-page MCP servers, because the tools run within the page and nothing special runs behind them.
Chrome ships it as an origin trial, and the browser built into the ChatGPT desktop app reads the same entry point and calls the result “site tools”. That’s a good sign. There’s nothing to host: if your page registers a tool, an agent opening the page can call it. This was the zero-friction version of what I wanted.
Right Tool for the Job
I know the MCP debate, and the context purists have a point. For coding agents I agree with them: a CLI is cheaper in tokens and easier to compose, and I use CLIs there too. But MCP was never only about coding agents. Think of knowledge workers connecting their tools to an assistant, or a product that lets its users bring their own tools. MCP lets you integrate without learning someone else’s API. Its output is usually shaped for agents, which many APIs aren’t yet, and it puts everything behind one channel an agent can call.
For a website, WebMCP removes almost everything a hosted server needs. The user is already signed in, and the tool runs in the page with the session cookie, the quotas and the consent state, so the agent gets exactly the access the user has and nothing more.
What It Looks Like
Here’s the tool that spends a credit, trimmed down:
document.modelContext.registerTool({
name: "generate_template",
description:
"Generate a new coloring page from a text prompt. Spends one generation credit, so the user is asked to confirm first.",
inputSchema: {
type: "object",
properties: {
prompt: { type: "string", description: "What the coloring page should show." },
ageGroup: { type: "string", description: "Target age group; controls line complexity." },
},
required: ["prompt", "ageGroup"],
},
execute: async (input) => {
const confirmed = await confirmGeneration(input);
if (!confirmed) return JSON.stringify({ status: "cancelled" });
const template = await generateTemplate(input);
return JSON.stringify({ status: "created", url: `/app/templates/${template.slug}` });
},
});The function calls the same API as the website, so all the validation is done by the same schema, and I didn’t have to do any additional backend work. The page I already had became the agent interface.
But a fool with a tool is still a fool. WebMCP takes care of the plumbing. The real work, and the most important part, is shaping the tools for an agent. Colorburst exposes four tools around its coloring pages, and most of the few hours went into deciding what stays out. Generating a page costs a credit, so that tool has to open a confirmation dialog before anything happens. Cancelling does nothing, and confirming charges exactly one credit. The dialog is there for consent: any script on the page could call the tools anyway, just as it could already call the API directly. Rate limiting also came for free, because signed-in users already have limits, and the agent adopts them too.
Checkout and billing stay out of reach, so no tool touches any money. If the agent wants to upgrade to a plan, it can ask the user to click the button on the website. The tool contract is also different from the API: the tools return a page handle and a URL instead of internal IDs or file links, and the summaries contain only the fields an agent would need.
The Demo
This is still pretty early and pretty slow, but those things will improve for sure. Here’s the whole loop in the ChatGPT desktop app, from asking for a page to holding the PDF:
If the embed does not load, watch it on YouTube.
Where It Stands
The spec is still moving. In the middle of the origin trial, Chromium moved the entry point from navigator.modelContext to document.modelContext, and by Chrome 152 the old name was gone. I had wrapped the browser API in one small module, so for me it was a one-file change.
When I built the tools, the only client that could actually drive them was Google’s Model Context Tool Inspector extension. Gemini in Chrome was still “coming soon”, and Anthropic had closed the request for Claude in Chrome as not planned. Then OpenAI shipped site tools in the ChatGPT desktop app and even ran a ten-day WebMCP challenge. So a real consumer agent exists now, and I’m pretty sure the others will follow. Shopify is moving too. In August they put WebMCP tools on every Liquid storefront, all the way to the handoff to checkout. That was only two weeks after a state-of-WebMCP writeup had put real adoption at roughly zero.
The Bet
Before AI, a product without an API was a product you couldn’t build on. I think the same is about to be true for a site without an agent interface. The explainer says it a bit differently: adapt the front end for agents, instead of letting backend integrations replace it. The spec will change again, and the clients will get better for sure. But getting ready is cheap. You just register what your page can do, right where it already runs, and that’s the part I’m betting on.
I haven’t tried it yet, but that’s the next experiment. With Colorburst connected to ChatGPT, my kids could just say what they want, a unicorn swimming in a lake or something even wilder, and get their coloring page without asking me first. And I wouldn’t have to build a voice interface or an agent into the site for that. The agent they talk to already exists, and the page already knows what it can do.