altronis.sg ships WebMCP: navigator.modelContext tools for AI agents

altronis.sg ships WebMCP: navigator.modelContext tools for AI agents

On 9 May 2026 we shipped 12 WebMCP tools to altronis.sg. AI agents — Chrome's browser-native ones, browser extensions, external agents like Claude or ChatGPT — can now call our site's capabilities directly instead of taking screenshots and guessing where to click.

The new browser API is navigator.modelContext. It is a W3C Web Machine Learning Community Group draft, currently behind chrome://flags#WebMCP in Chrome 146 and shipped in the early-preview channel since February 2026. Patrick Brosset's update from Microsoft covers the spec evolution. It is not a finished standard yet. We shipped anyway. This post is the why and the what.

What WebMCP actually is

The shape is simple. A site calls navigator.modelContext.registerTool(tool, options) with a tool object that has a name, a natural-language description, a JSON schema for input, and an execute function. The browser surfaces the registered tools to whatever agent is in the page — built-in browser AI, an extension like the MCP-B reference implementation, or an external agent calling the site through the browser.

It is the same Model Context Protocol shape Anthropic open-sourced for agent tool use, just lifted into the browser as a native capability. The agent sees an OpenAPI-shaped tool surface. The site keeps owning the implementation: the execute function runs in the page context with the user's session cookies, page state, and any client-side logic the app already has.

This matters because the alternative is awful. Today an agent that wants to use a website has to take a screenshot, guess at the layout, click whatever pixel looks right, and hope the page has not re-rendered since. Visual agents do this. They are slow, fragile, and break when sites change. WebMCP replaces guessing with declared intent.

What we registered on altronis.sg

Twelve tools across four categories. Names are namespaced — altronis.<verb><Noun> — so they don't collide with other sites' tools when an agent has many WebMCP-enabled tabs open.

Conversational

Lead capture

SG data + content

Catalogue / about

Why now, while the spec is still a draft

Three honest reasons.

One. The cost of shipping is small. The whole registration component is one client-side React component (~330 lines), feature-detected. Browsers without WebMCP no-op silently — there is no breakage. The downside risk is near zero.

Two. The cost of being late is real. The web's last comparable shift was OpenGraph metadata for social sharing. Sites that added og:image early dominated link previews on Facebook and Twitter for years. Sites that waited never recovered the traffic share. WebMCP is the agent equivalent. First-mover share is small but cumulative — if Chrome 146 users are running ChatGPT-Atlas or Claude-for-Chrome and our tools are registered, they get used. Competitors who wait three more months will be invisible to that growing cohort.

Three. We work in agentic AI. We sell agentic AI. Not shipping the obvious agent-native infrastructure on our own marketing site would be a bad look during a sales call.

What about MCP, the original?

Anthropic's Model Context Protocol (the original MCP) remains the protocol for AI clients to talk to local or remote tool servers — file systems, databases, APIs. We already publish @altronis/sgdata-mcp as one. WebMCP is the browser-side counterpart: tools the website itself exposes, called within the browser session, with the user's signed-in identity intact. Both can coexist. An agent might call sgdata-mcp directly for raw SG data and then navigate to altronis.sg and call altronis.captureContact to book a consultation, all in the same task graph.

What changes for SG sites that don't ship this

Short term, nothing. Chrome 146 with the flag enabled is a tiny audience. Most sites will be fine for most of 2026.

Medium term, the agent population grows. Browser-native AI in Chrome and Edge, agent-mode in ChatGPT, Claude-for-Chrome, hundreds of vertical agents in extensions. They will all prefer sites that declare tools over sites that require DOM scraping. Two practical effects:

  1. Conversion paths shorten. An agent that can call altronis.captureContact in one shot beats an agent that has to navigate three pages, fill a form field-by-field, and press submit. Even small completion-rate gaps compound over enough sessions.
  2. SEO converges with what we are calling GEO — generative engine optimisation. Search engines have always rewarded structured data. Agentic engines will reward structured tools. The two will be quoted in the same RFP question by procurement teams within twelve months.

The work is small enough that the cost-benefit is asymmetric. A SG SME site can ship one or two tools (a contact form, a price quote calculator, a booking endpoint) in an afternoon. Even if no agent calls them for six months, the marginal cost of being ready is tiny.

The honest caveats

The spec is a draft. Open issues on the WebMCP repo include real ones — tool overwriting in the same environment, permission models for side-effect-bearing tools, scoping by origin. Some shape changes are likely before standardisation. We will update the registration code as the spec settles.

Browser support is one and a half browsers. Chrome 146 with a flag, and probably Edge soon since they share the engine. Firefox and Safari are engaged in the spec process but have not committed timelines. If Safari never ships, half the global mobile market is opaque to WebMCP. Plan accordingly.

Side-effect tools are the part to watch. Lead capture, payments, anything that changes server state. The current spec leaves the consent UX to browsers and agents — there is not yet a uniform "tool wants to send your contact info, allow?" prompt. We added clear language to captureContact's description ("SIDE-EFFECT: this creates a real lead that triggers a human follow-up") so agents that respect descriptions don't fire it speculatively. Better protections will come; for now, design tool surfaces conservatively.

What we are doing next

Three things on the roadmap, none commitments.

One. Add WebMCP to TokenMark, our model benchmarking PWA. The natural tool there is tokenmark.runBenchmark(modelId) — let an agent kick off a model evaluation and read the results back. The PWA is a stronger natural fit than altronis.sg because the value of the tool is concrete and easy to test.

Two. Mirror our 12 altronis.sg tools as a regular Anthropic-MCP server too, so non-browser agents (Claude Desktop, custom tool-using LLMs, n8n workflows) can use them outside the browser. The shape is identical, the transport changes.

Three. Watch the spec PRs. Update the registration code as the API settles. Document the diff between draft and final for our consulting clients who ask about the standard's risk.

Try it

If you are on Chrome 146 or newer, enable WebMCP at chrome://flags#WebMCP, restart, then visit altronis.sg. Open devtools and run navigator.modelContext.tools — you should see the 12 entries. Or install the MCP-B reference extension and invoke a tool from its sidebar UI. The descriptions, schemas, and example invocations are visible there.

If you run a Singapore site and want to know whether WebMCP is worth shipping for your context, the short answer is yes if you have any callable surface at all (booking, contact, calculator, search). The implementation effort is hours, the downside is zero, and the audience is growing. We are happy to talk through what would expose well — drop us a line via altronis.sg/contact, or have your agent call altronis.captureContact directly.