<head> metadata and JSON script blocks are invisible to every default page-reading tool #515

Summary

None of the default page-reading tools (take_snapshot, take_enhanced_snapshot, get_page_content, get_page_links) expose <head> contents (<link>, <meta>) or <script type="application/json"> / application/ld+json blocks. An agent asked to read machine-readable data embedded in a page has no default path to it.

Evidence

• apps/server/src/tools/snapshot.ts:181 — take_snapshot walks document.body.querySelectorAll('*').
• src/browser/content-markdown.ts:26 — get_page_content is rooted at document.body.
• src/browser/content-markdown.ts:23 — SKIP = {SCRIPT, STYLE, NOSCRIPT, ...}, so even a <script type="application/json"> inside <body> is stripped.
• src/browser/browser.ts:395-400 — get_page_links reads a11y-tree link nodes only; <link> elements have no a11y node, so rel="alternate"/canonical/etc. never surface.

Scope note: page title and URL are available via list_pages/get_active_page (src/browser/navigation.ts:22-61) — the gap is specifically <link>, <meta>, and JSON script blocks.

Why this matters

This makes schema.org JSON-LD unreadable by default — the most widely deployed machine-readable format on the web (products, prices, recipes, articles, events), published specifically for machine consumption. An agent has to fall back to scraping rendered text for data the page author already structured for it.

Proposal

A get_page_metadata tool (returns <head> meta/link tags + any application/ld+json/application/json script blocks as structured data), or an includeStructuredData option on get_page_content. Additive, small blast radius, no change to existing tool behavior.