MCP integrations

What WebMCP actually is#

WebMCP is a W3C Web Machine Learning Community Group proposal, authored by engineers from Google Chrome and Microsoft Edge (the public explainer lives at github.com/webmachinelearning/webmcp). It defines document.modelContext, a browser API a web page uses to register structured tools — with a name, a description, and a JSON Schema for their inputs — that an AI agent sharing the user's browser tab can discover and call.

OpenAI did not create this standard. OpenAI is an adopter of it: ChatGPT's built-in browser, ChatGPT Work, and Codex started discovering and calling WebMCP tools on sites like this one around 2026-08-25. OpenAI's own protocol, the Apps SDK, is a separate, server-side MCP-plus-widget model that needs a backend — this site does not use it, because this site has no backend for its local tools to call.

How to use it today#

Open any page on this site in a browser and AI surface that already speaks WebMCP — as of this writing that includes Gemini in Chrome and ChatGPT's built-in browser (including Codex) — and ask it to do something with a PDF tool. The agent can list tools, open one, and, once you've selected your files yourself, run it or ask you to confirm its settings first.

No setup is required on your end beyond using a WebMCP-capable browser or agent surface. There is nothing to install, authorize, or configure specifically for this site.

Discovery for MCP clients#

/llms.txt and /llms-full.txt are the fastest way for an MCP-aware client to enumerate available tools, their categories, and the trust routes (this page, Privacy, Security) that govern how they may be used.

/agents/webmcp.json (and its /.well-known/webmcp.json alias) is the static catalog for the browser integration. In a compatible browser, the live document.modelContext tools are authoritative because they reflect the current page and user-selected inputs — the static catalog is a fallback for a client that hasn't loaded the page.

/.well-known/security.txt is published for automated security tooling and follows RFC 9116; it is not a general capability-discovery route and should not be treated as one.

WebMCP and remote MCP are different surfaces#

WebMCP runs inside a compatible browser and shares the visible page, selected local files, progress, and results with the user in real time. It works without sending document bytes to a separate MCP server, because there is no separate server in the loop at all.

This app does not run a remote (desktop- or server-callable) MCP server, and doesn't plan to add one for its local tools — there's no backend for a local tool to call. A desktop or server-side MCP client does not automatically gain the browser tools described on this page; it would need its own WebMCP-capable browser integration.

The honest limits#

You must pick your own files. WebMCP has no file-bytes primitive in the spec today — an agent can never hand this site a file, and this site's tools can never ask WebMCP for one. Every tool here operates only on files you've already chosen through the browser's own file picker or drag-and-drop, a native user gesture no page or script can trigger on your behalf.

No document bytes ever reach an agent. Filenames are the one narrow exception — the active tool page's list_loaded_files tool returns filenames, sizes, and page counts so an agent can tell you what it sees loaded — but the file content itself is never included in any WebMCP response, from any tool, on any page.

There is no separate remote MCP server, because this app has no backend for local tools to call. Everything WebMCP does here happens inside your own browser tab.

Surfacing honest refusals#

Where a tool refuses an operation instead of faking success (Encrypt PDF is the clearest example — see Security), an agent should pass that refusal message through to you rather than silently retrying or masking it as a generic error.