WebMCP now ships by default with Thally documentation sitesWebMCP now ships by default with Thally documentation sites

Every Thally-powered docs site now ships with WebMCP support by default in the latest framework release.

Your documentation exposes ten tools for searching content, reading pages, inspecting API references, and navigating the site. A WebMCP-compatible client gets an explicit interface to those capabilities, with named tools, defined inputs, and structured results.

For the team publishing the docs, that means browser tools come with the site. You do not need to design a tool catalog, wire each page into it, or maintain a separate copy of your content for this integration. Thally supplies the tools through the same documentation engine that publishes your pages.

New sites include the integration automatically. Existing sites get it by updating their framework and redeploying. Browser and client requirements are covered below.

Why this matters for your documentation

Documentation contains more than text. It has navigation, sections, API operations, locales, and links between pages. WebMCP gives compatible clients tools that expose those parts of the site directly.

A defined way to retrieve your content. Search and read tools provide access to published pages and sections. A client developer can use those interfaces without building a scraper for the site's visual layout.

API references exposed as tools. Generated operations are part of the same integration. Clients can list operations and inspect their documented definitions, alongside your authored guides.

Context from the page being read. Browser tools expose the active page, locale, headings, and API-operation context where applicable. They also provide navigation to published content on the same site.

One content source to maintain. Your team writes the documentation once. Thally's shared content representation supplies HTML, Markdown, JSON, and the documentation tools. Updating the published content updates what those tools read.

That is why I wanted WebMCP in the framework itself. A team choosing Thally should get this interface as part of publishing its documentation, with the site's existing content and permissions behind it.

Our guide to agent-readable documentation explains the other layers: discovery files, content negotiation, and remote MCP access. WebMCP adds browser-level tool registration to that foundation.

Ten tools, with two different scopes

Eight tools access the site's documentation through its existing /api/mcp endpoint. Two more belong to the browser session: they describe the current page and navigate to another published page.

Tools	What they provide	Scope
search_docs, search_sections	Find pages and relevant sections for a question	HTTP MCP and native browser tools
read_page, list_pages	Read documentation and discover published pages	HTTP MCP and native browser tools
list_api_operations, get_api_operation	Discover API operations and read their documented definitions	HTTP MCP and native browser tools
list_changes, agent_readiness	Read published changes and the site's readiness assessment	HTTP MCP and native browser tools
get_current_page, navigate_to_page	Read the active page context and open published content	Native browser tools only

These scopes are separate. A remote MCP client connects to /api/mcp and gets eight site tools. The WebMCP adapter registers ten tools when the browser exposes the experimental API. An assistant client must support discovering and calling them.

The documentation tools read content. Inspecting an API operation describes its documented request and response; it does not execute that request against your customer's API. The navigation tool changes the page the reader sees.

How we implemented it

I wanted the browser integration to use the documentation machinery we already maintain.

The native adapter reuses the existing tool metadata registry, including tool names and input schemas. It validates inputs in the browser, then calls the fixed, same-origin /api/mcp endpoint for the eight documentation tools. Their content comes from the same canonical structured pipeline used by the other published formats.

Those requests preserve the reader's existing permissions and the endpoint's quota rules. Registering a browser tool does not grant access to documentation the reader could not otherwise read.

The browser-specific tools handle session context separately. get_current_page reads the current URL when the tool executes, so it follows navigation instead of holding onto the page where registration first happened. Navigation accepts safe, published destinations on the same origin.

When a call fails, the adapter returns an isError result with helpful text. It also handles aborted calls and unregisters its tools during cleanup.

The component checks for document.modelContext before registering tools, so registration runs only where the browser supports the API.

The implementation lives in the public Thally source.

Testing on Thally's own documentation

We tested the integration on Thally's documentation through the browser's native WebMCP tool interface.

All ten tools were registered. Page and section searches returned results from the published documentation, and list_pages returned 83 pages. We also retrieved changelog entries and the site's agent-readiness assessment.

A search for “publish documentation” returned the managed-hosting guide, including its “What triggers a publish” section. We used read_page to retrieve the guide as Markdown, then navigate_to_page to open that section from the quickstart. After the destination rendered, get_current_page reported the managed-hosting page and the requested heading. Navigating to the homepage then returned the introduction page with the heading cleared.

Thally's documentation currently publishes no generated API operations. list_api_operations returned an empty catalog, and get_api_operation returned a helpful error for a missing operation ID. These checks cover the empty-catalog and error cases; they do not demonstrate retrieval of a published API operation on this site.

These were direct tool checks against our live documentation. They confirm tool registration, retrieval, and navigation in the tested browser. We have not measured conversational answer accuracy or speed.

Browser and client support

WebMCP is an experimental, proposed web standard. The browser must expose document.modelContext, and a client must support discovering and calling the registered tools. Including WebMCP in a site does not make every browser assistant use it automatically or add a new chat interface to the documentation.

For browser testing, follow Chrome's WebMCP setup instructions. You can inspect the registration and invoke tools directly with WebMCP developer tooling in a browser where the API is enabled.

Get WebMCP support on your site

For a new project, create a site with the latest scaffold:

npm create thally-docs@latest my-docs

For an existing project, preview the framework update from its directory:

npx --yes @thallylabs/cli@latest starter update

Review the plan, including any conflicts or manual review items, before applying it:

npx --yes @thallylabs/cli@latest starter update --apply

Then build, verify, and redeploy the site. Existing deployments do not acquire the feature automatically when we publish a framework release.

WebMCP support is now part of what Thally publishes with your documentation: ten tools backed by the same content your team already maintains.