sluicer

Overview Schema Source Related Servers Discussions Admin

Audit a page's markup

audit_page

Read-onlyIdempotent

Check a web page's structured data against Google's documented requirements to see which rich-result features are met or missing, including robots.txt access for AI agents.

Instructions

Check a page's structured data against what Google documents for it.

html_or_url: an http(s) URL to fetch, or the HTML itself. site: for a URL, also read the site's robots.txt, llms.txt and llms-full.txt.

Returns {"ok", "url", "records", "page", "not_checked", "errors", "warnings", "notes"}, and for a URL read with site "crawlers", "robots_txt", "other_agents", "llms_txt", "llms_full_txt" and "fetch". Every JSON-LD, microdata and RDFa record lists the rich-result features its type is documented for, each with requirements_met and the required and recommended properties it lacks, and findings that each name a severity, the record's source, the property path and the URL of the rule. crawlers says, per AI agent from its vendor's own page, whether robots.txt admits the page. ok is true whenever the audit ran: a page with errors is an answer; "not_checked" says what was not. errors, warnings and notes count everything found; past 75,000 bytes the last records, page findings and other_agents are left out, counted in records_left_out, page_left_out and other_agents_left_out.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`site`	No	for a URL, also read the site's robots.txt, llms.txt and llms-full.txt.
`html_or_url`	Yes	an http(s) URL to fetch, or the HTML itself.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	Yes
`tdm`	No
`url`	No
`page`	No
`error`	No
`fetch`	No
`notes`	No
`errors`	No
`records`	No
`crawlers`	No
`llms_txt`	No
`warnings`	No
`robots_txt`	No
`not_checked`	No
`other_agents`	No
`llms_full_txt`	No
`page_left_out`	No
`records_left_out`	No
`other_agents_left_out`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.9.0Sep 26, 2026

changedOutput schema / $defs / ErrorDetail / description

Previous value: -"Why a tool could not answer.\n\n``retryable`` is true only for ``fetch_failed``, and on a crawled page for\n``rate_limited``: the same call may work later. The others need something\nto change first -- an install, an input, or the caller's mind about a site\nthat said no."New value: +"Why a tool could not answer.\n\n``retryable`` is true only for ``fetch_failed``, and on a crawled page for\n``rate_limited``: the same call may work later. Not every ``fetch_failed``\nis: a redirect loop, or an encoding this install cannot read, would be\nmet again. The others need something to change first -- an install, an\ninput, or the caller's mind about a site that said no."

changedOutput schema / $defs / ErrorDetail / properties / code / enum

Previous value: -[
-  "missing_extra",
-  "refused_by_robots",
-  "refused_address",
-  "fetch_failed",
-  "too_large",
-  "bad_input",
-  "tdm_reserved"
-]New value: +[
+  "missing_extra",
+  "refused_by_robots",
+  "refused_by_site",
+  "payment_required",
+  "refused_address",
+  "fetch_failed",
+  "too_large",
+  "bad_input",
+  "tdm_reserved"
+]

addedOutput schema / properties / other_agents_left_out

Added value: +{
+  "title": "Other Agents Left Out",
+  "type": "integer"
+}

addedOutput schema / properties / page_left_out

Added value: +{
+  "title": "Page Left Out",
+  "type": "integer"
+}

addedOutput schema / properties / records_left_out

Added value: +{
+  "title": "Records Left Out",
+  "type": "integer"
+}

Changed2 schema fields changedv0.7.0Sep 24, 2026
- addedInput schema / properties / html_or_url / description
```
Added value: +"an http(s) URL to fetch, or the HTML itself."
```
- addedInput schema / properties / site / description
```
Added value: +"for a URL, also read the site's robots.txt, llms.txt and llms-full.txt."
```
First observedv0.1.0Sep 24, 2026

TDQS

A3.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the readOnly/idempotent annotations, disclosing nuanced behavior: ok is true even when the audit finds errors, not_checked records skipped items, and output is truncated past 75,000 bytes with counts in records_left_out, page_left_out, and other_agents_left_out. This is exemplary transparency about limits and semantics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and technically heavy, but every sentence adds information: input modes, the site flag, return fields, rule details, and truncation limits. It is front-loaded with the core purpose before diving into output specifics, so it earns a high mark despite its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool with a rich output contract, the description explains everything an agent needs: how to pass a URL versus raw HTML, what site adds, what each output section means, how errors affect ok, and what happens when the result is too large. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description essentially restates the schema descriptions for html_or_url and site rather than adding new semantic value. The baseline of 3 applies because the schema already documents both parameters adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and resource: "Check a page's structured data against what Google documents for it." This clearly distinguishes the audit/validation purpose from sibling tools like fetch_page or page_markdown. It does not name an alternative sibling, so it falls just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains parameter behavior and output shape, but it gives no guidance on when to choose this tool over the listed siblings, nor does it define exclusions or prerequisites. An agent must infer usage from the phrase 'Check a page's structured data against what Google documents'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server