web_skeleton

Reads the web the way the other tools read code: a skeleton first, then only the section that matters.

Components

Capabilities

• search: search results, each with a title and a one-line summary.
• skeleton: a rendered page as headings, sections, links and form elements, each with a stable id; with layout, each with its position and size.
• context: only the parts of the page that match a search: the exact words first, then by meaning, so a search for "Installation" finds a heading that says "Installing".
• read: the full text of one section by id.
• click: follow a link or button by id and get the new page's skeleton. The click lands on exactly the element the skeleton numbered.

Layout and screen sizes

Ask for layout and every element comes with its place on the page: @x%,y% w%×h%, where x and the width are shares of the screen width, and y and the height are shares of the full page height. The agent can tell a sidebar from the main column, spot a repeating grid of cards, see that a table runs past the fold, and plan where to read or click before reading anything.

The agent also chooses the screen: viewport="390x844" renders the page as a phone and "1366x768" as a laptop, at any size from 240 to 3,840 pixels wide. Below 768 pixels the page is rendered as mobile, so menus collapse and layouts reflow as they do for real visitors. Clicks stay at the same size.

The same overview page of this site, seen both ways:

• Desktop (1920×1080): the main column starts at 28% of the width and is 43% wide; the Copy button sits beside the connector URL; the page is 3,975 pixels tall.
• Phone (390×844): the main column is the full width, the header menu collapses into a Menu button, the Copy button moves below the URL, and the page grows to 5,167 pixels.

How it compares

The same 10 public pages read five ways on the same day, with the same Chrome at 1920×1080. Tokens are estimated the same way for all of them: characters ÷ 4. web_skeleton was measured again that afternoon with its current version.

Tokens to see the page. Lower costs less. "Default" is web_skeleton's answer without options: the outline of any page over about 3,000 tokens.

• Finds what you mean, not just what you typed. Asked "can these models make things up" on Wikipedia's Large language model page, web_skeleton marks the Hallucinations paragraph in under 1,000 tokens, in about 2 seconds. The raw page is about 339,000 tokens and Playwright MCP's snapshot about 125,000: more than many context windows hold, just to find one paragraph.
• Among tools an agent can act with (click, navigate, find an element again), web_skeleton used about 43% fewer tokens than Playwright MCP and Chrome DevTools MCP for the whole page. By default it answers with an outline of about 1,000 tokens, and the agent zooms in from there.
• Fetch → Markdown (the MCP project's Fetch server) is the smallest for full text. It does a different job: text only, nothing to click, and on application-like pages much of the page is left out (on GitHub, only the start of the README remained).
• Stack Overflow: the other three received a challenge page or a refusal (HTTP 403); web_skeleton rendered the page.
• Finding one thing (one search per page): web_skeleton needed 7,563 tokens in total, Playwright MCP's search 14,773. On PyPI the word "Installation" is not on the page: Playwright MCP found no matches, web_skeleton found the "Installing" heading and the install command by meaning. Playwright MCP was a little leaner on exact single matches.

Measured on 12 October 2026 with Playwright MCP 0.0.83, Chrome DevTools MCP 1.10.1 and mcp-server-fetch 2026.10.10, each with its default output. Results change as the pages and the tools do, so try your own pages.

How it works

Pages are rendered in headless Chromium through the Chrome DevTools Protocol, so content built by JavaScript is included. In typical use, a page that would cost 50,000 to 200,000 tokens as raw HTML becomes a skeleton of 500 to 3,000 tokens.

Safety in the sandbox

• Egress guard: all browser traffic, including redirects, frames, background scripts and websockets, goes through a guard that resolves every address itself.
• Private, loopback, link-local and cloud metadata addresses are refused, and the guard connects only to the exact address it checked, so DNS tricks cannot reach this machine or its network.
• Only https for public sites; file://, data: and similar schemes are blocked.