Editor's note (2026-05). Chrome 150 deprecated navigator.modelContext in favour of document.modelContext (per WebMCP spec PR #184, since tools are scoped per-Document). Examples in this post use the forward-compatible feature-detection pattern recommended by the Chrome team:

const modelContext = document.modelContext || navigator.modelContext;
if (modelContext)

WebConverter's own integration uses this exact fallback, so it keeps working on browsers that still ship the older identifier.

The Model Context Protocol (MCP) standardised how AI agents call tools. WebMCP brings that idea to the open web: instead of a separate server process, a website itself exposes tools through a browser API — document.modelContext — that an in-browser agent can discover and invoke. We just shipped a WebMCP integration for WebConverter, turning every conversion the site can do into an agent-callable tool that still runs 100% locally in your browser. This post explains what WebMCP is, why a File Converter MCP that needs no upload and no API key is a genuinely useful thing, and exactly how we built it.

What Is WebMCP?

WebMCP is a draft web standard from the W3C Web Machine Learning Community Group, designed by engineers from Google and Microsoft. It defines a single new entry point on the browser's document object: document.modelContext (originally exposed as navigator.modelContext, which Chrome 150 deprecated; see the note above). A page calls registerTool() to publish a named tool — with a description and a JSON Schema for its inputs — and supplies an execute() function that the browser (or an agent acting through it) invokes when the tool is called.

The key difference from classic MCP: there is no separate transport, no localhost server, no token to manage. The tool is the page's own JavaScript. That has a profound consequence for a privacy-first converter — the agent gets the capability, but your file never leaves the tab. As of early 2026 the API is available behind a flag in Chrome (chrome://flags/#enable-webmcp-testing) and is decorated [SecureContext], so it only exists on HTTPS pages (and localhost).

Why a "File Converter MCP" Matters

Ask an AI assistant to "convert this PNG to WebP" today and it usually has three bad options: upload your file to some third-party API, run a server-side tool that touches your data, or refuse. A WebMCP-powered converter changes the calculus entirely:

  • No upload. The conversion runs in a Web Worker via WebAssembly — the same code path the human-facing UI uses. The agent passes bytes in, gets bytes out, all within the page sandbox.
  • No API key, no rate limit, no cost. There is no backend to bill against. The tool is as free as visiting the page.
  • Deterministic and inspectable. The tool's JSON Schema tells the agent exactly what formats are valid, so it does not have to guess.
  • Near-zero carbon. Skipping the upload-process-download round trip avoids roughly 3 kg of CO2 per gigabyte of data not transferred — the tool even reports the saving back to the agent.

The Tools We Exposed

WebConverter registers two tools through document.modelContext:

  • list_supported_formats — returns the readable input formats (BMP, DDS, GIF, HDR, ICO, JPEG, KTX, PGM, PIC, PNG, PPM, PSD, TGA, WebP) and the writable output formats. An agent calls this first to plan a valid conversion.
  • convert_image — takes a base64 file, a target format, and optional encoder settings, and returns the converted file as base64 plus a data: URL. It is annotated readOnlyHint because it never mutates page or server state.

Because the tools wrap the existing Worker pipeline, anything the image converter can do, an agent can now do too — PNG to WebP, JPEG to PNG, conversion to OpenEXR, and the rest.

How We Built It

The integration is a single small, deferred script loaded site-wide. It does three things:

  1. Defines the tool descriptors — name, human-readable description, JSON Schema, and an execute() that base64-decodes the input, hands it to a fresh /worker.js Web Worker (the very same WebAssembly converter the UI uses), waits for the result, and base64-encodes it back into an MCP content array.
  2. Registers them with the spec API — when document.modelContext exists, it calls registerTool() for each (or provideContext() on older builds).
  3. Exposes a tiny programmatic registry — window.webmcpToolRegistry mirrors the exact same tool definitions. This is not a content fallback; it is a documented automation seam so the tools are testable from Playwright and callable by extensions or polyfills even on browsers that have not shipped the native API yet.

The whole thing is wrapped so a missing Worker, blocked WASM, or sandboxed navigator can never throw into the host page. It adds only a few kilobytes — no new WebAssembly, keeping the asset budget tiny.

A Note on Trust and Safety

Agent-callable tools deserve scrutiny. WebConverter's tools are read-only by design: they take bytes and return bytes. They never write to disk, never make network requests, never read other tabs, and never persist anything. The conversion is the same audited WebAssembly build used by millions of human conversions. An agent calling convert_image has exactly the capability a human clicking "convert" has — and not one bit more.

Try It

Open the WebMCP page for a live demo that drives the convert_image tool through the registry, and a full reference of the tool schemas. If you are building an agent, this is what an honest, private, zero-cost file-conversion tool looks like — and it is just a web page. For everything else, browse all conversions or read more on the blog.

Ready to convert your images?

Try WebConverter Free