WebMCP for Browser Agents

AI agents are getting pretty good at using the web, but it still feels like a lot of guesswork based on parsing HTML. In reality, the AI agent is a new audience and I want to present a clear interface for that audience, just as I would for a human visitor.

WebMCP is an early proposal that gives sites a way to be more direct. A page can register a structured tool with the browser: a name, description, input schema, and JavaScript function to run. An agent with that page open can discover and call the tool instead of reverse-engineering the interface.

The basic idea is to let a website declare an element’s purpose instead of making an agent infer it from the interface. As Chrome’s WebMCP overview puts it:

This is more reliable than actuation, which may have numerous steps and leaves each step open to interpretation by the agent.

I recently added a small WebMCP surface to Kyoto Tech Meetup. The point is to give agents a clear and efficient interface to get information about the community without altering the human-facing interface or standing up an API server.

WebMCP is for the tab in front of you

WebMCP is not a replacement for the Model Context Protocol.

An MCP server is a service an agent can connect to from anywhere. It can expose a database, background jobs, or business operations. But WebMCP lives in the browser. Its tools exist while the page is open, execute in that page’s JavaScript context, and go away when the visitor navigates away.

That makes it feel like a nice fit for an existing human-first interface. I don’t need an agent to infer the meaning of a page; I can tell it exactly what the current page knows how to do:

• Find the next meetup.
• List a few upcoming meetups.
• Get the official community links.
• Browse the member publications already shown on the homepage.

The regular website is still the regular website. The browser stays in the middle. An agent just gets a small, typed interface for the things we want to make easily accessible for agents.

Read the site, don’t operate it

For Kyoto Tech Meetup, the useful questions are straightforward: when is the next event, where is it, how do I RSVP, and what are community members publishing?

I intentionally did not add tools to automate RSVP, emit Discord notifications, or publish content. Those actions have real consequences. A read-only tool can return an RSVP link for a person or an agent to review. It cannot enroll anyone in a meetup.

So the tool surface is small:

Tool	Purpose
get_next_meetup	Return the next upcoming event and its RSVP/map links.
list_upcoming_meetups	Return up to ten upcoming events.
get_event_details	Return one event using an ID returned by the meetup tools.
get_community_links	Return official Meetup, Discord, GitHub, LinkedIn, contact, and calendar links.
list_member_posts	List recent items from the homepage’s member-publications section.
get_member_post	Return one publication by its stable ID.
search_member_posts	Search the already-published homepage items by title, summary, or source.

There isn’t a new content system hiding behind these tools. We’re simply surfacing what was already there in a new way for a new audience of agents.

Using the data the site already has

The homepage already consumes a committed Meetup cache and a generated composite RSS feed. The WebMCP provider builds its snapshot from those same normalized sources:

const webMcpData = {
  events: events.map((event) => ({
    ...event,
    description: "",
    image: null,
  })),
  memberPosts: feedsWithItems.flatMap((feed) =>
    feed.items.map((item) => ({
      id: item.id,
      title: item.title,
      link: item.link,
      publishedAt: item.publishedAt,
      summary: item.summary,
      sourceName: feed.name,
      sourceUrl: feed.siteUrl ?? undefined,
    })),
  ),
  links: { meetup, discord, github, linkedin, contact, calendar: "#calendar" },
};

The page serializes that snapshot and registers tools in a small client-side component. In a browser without WebMCP support, feature detection does nothing. The page still renders and behaves exactly as it did before.

const modelContext = documentLike?.modelContext;
if (!modelContext?.registerTool) return false;

for (const tool of tools) await modelContext.registerTool(tool);
return "registerTool";

This uses WebMCP’s imperative API: the page registers structured tools in JavaScript and does nothing in browsers that do not support the feature.

Keeping the data boundary small

The tools do not reach into a new API or fetch arbitrary URLs when they run. They read only the event and feed data the homepage has already selected and normalized.

Some of that data comes from outside Kyoto Tech Meetup. The event and publication tools mark it as such with untrustedContentHint: true; the official community links are site-owned configuration, so they do not.

Every tool is readOnlyHint: true, and the inputs stay small: lists are limited to 1–10 items, search input is capped, unknown lookups return null, and external URLs pass through the site’s safe-URL validation.

For example, the next-event tool is intentionally boring:

{
  name: "get_next_meetup",
  title: "Get the next Kyoto Tech Meetup",
  description: "Find the next upcoming Kyoto Tech Meetup and its RSVP and map links.",
  inputSchema: { type: "object", properties: {}, additionalProperties: false },
  annotations: { readOnlyHint: true, untrustedContentHint: true },
  execute: () => ({ event: events[0] ?? null }),
}

Boring is good here. The tool exposes an answer the homepage already knows. It does not initiate something on a visitor’s behalf.

Inspecting it on the live site

WebMCP is still experimental. Chrome 149 introduced an origin trial for deployed sites, and the experimental WebMCP view in DevTools is the most direct way to inspect a page’s registered tools. Chrome’s WebMCP documentation and the Chrome 149 DevTools release notes describe the current preview.

To inspect Kyoto Tech Meetup’s live tools:

1. In Chrome 149 or newer, open these flags and set them to Enabled:

   • chrome://flags/#enable-webmcp-testing
   • chrome://flags/#devtools-webmcp-support

2. Relaunch Chrome, then visit kyototechmeetup.com.

3. Open DevTools, choose the Application panel, then choose WebMCP in the sidebar.

4. Select a tool, inspect its schema, supply JSON input, and invoke it.

I’m not going into deep detail on the DevTools interface here, because it will change. The important part is that you can see the input and output of a tool in a structured way, which makes it easier to test and debug.

Groundwork, not a user feature yet

This is still developer tooling. Chrome has a natural-language Inspector extension for testing WebMCP, but it is explicitly separate from Gemini in Chrome. As of July 2026, I don’t know of a mainstream, non-developer browser agent that publicly promises to consume WebMCP tools.

That means this doesn’t add a new behavior for someone visiting Kyoto Tech Meetup today. It is groundwork: a small interface that a browser agent can use when that user-facing ecosystem arrives.

Interfaces for different audiences

A website already has more than one audience. We build accessibility into the human interface for people with specific needs. We add structured data for search crawlers and Open Graph metadata for social platforms. Each is a clearer interface for a particular audience.

WebMCP is that kind of interface for browser agents. It gives an agent a typed way to ask what a page can do, instead of making it infer intent from HTML and screenshots.

WebMCP will keep changing, and browser support is nowhere near broad enough to make it a default integration. But for Kyoto Tech Meetup, the promise is not “an agent can operate this website.” It is narrower: “an agent can help someone find an event and understand what this community is sharing.”

It’s a low lift, and given that agents are increasingly the first touch point before a human visitor, it feels like a good investment in the future of the site. Let’s see where it goes!