Read Live Page

Reads 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`. It answers structure questions (did an edit land, is there an H1, is the heading order right) in a small reply; a normal WordPress page is around 50 KB of HTML. 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`. It shows what a page says, whether it matches a CTA / ad / post, and which pages it links 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.

It shows what actually shipped: whether the page is live, 200 or 404, which language the server picked, the canonical/hreflang/meta description, and where a redirect lands. 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. `redirects` lists every hop, so whether www redirects to the apex host is answered by `redirects`, not by `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.