Read Live Page
site_read_urlReads a LIVE web page exactly as a visitor's browser would and returns the HTTP status code, the response headers and the HTML body. Writes NOTHING anywhere — this is the read-only counterpart of site_fetch.
outline=true returns the page's STRUCTURE instead of the body: title, meta description, canonical, and the full h1-h6 heading tree with an h1_count. Use it when the question is "did my edit land", "does this page have an H1", "is the heading order right" — a normal WordPress page is 50 KB of HTML and does not fit in one tool result, so asking for the whole body to check one heading wastes the call. The outline is computed from the SAME fetch, so it reflects what the server actually rendered, including whatever a theme or page builder shortcode produced (issue #260: post_content shows the shortcode, not the <h1> the theme emits from it).
text=true returns the page's READABLE TEXT instead of the HTML: title, meta description, canonical, H1s, the visible text with scripts/styles/navigation markup stripped (first 6,000 characters, text_truncated says if there was more) and the list of same-site internal_links. Use it for "what does this page say", "is this the right landing page for my CTA / ad / post", "which pages does it link to". A typical page is 50-120 KB of HTML and the raw body does not fit in one tool result; the text view is a few KB.
Use it to verify what actually shipped: is the page live, did it come back 200 or 404, which language did the server pick, is the canonical/hreflang/meta-description what you intended, did the redirect land where you meant it to. REDIRECTS ARE REPORTED, NOT HIDDEN: when the URL you asked for redirects, the answer carries redirected: true, requested_url, final_url and a redirects list with every hop (from, status, to), and status/headers describe the FINAL page. So "does www redirect to the apex host" is answerable in one call — read redirects, do not infer it from status alone.
Why this exists (issue #257): the other tools with similar names do different jobs and cost a wasted turn. site_fetch is a DOWNLOADER, it requires a path and writes the file into the site. site_headers MANAGES response headers, it does not read a page. And curl inside site_run_command cannot resolve the site's own domain from the hosting container. So verifying a page you just published had no tool at all.
max_bytes caps the body (default 200 KB, max 2 MB) and is applied exactly — the body is cut to it and truncated tells you when something was left behind. Pass max_bytes=0 when you only need to know whether a URL answers: the response then carries status and headers and NO body, which is the cheap way to check a batch of internal links one call at a time. The URL passes the same SSRF guard as every other outbound request, so private and internal addresses are refused. Read-only.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| text | No | ||
| outline | No | ||
| max_bytes | No |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||