sluicer

Overview Schema Source Related Servers Discussions Admin

Run an extractor

run_extractor

Read-onlyIdempotent

Replay a saved extractor on a page to verify it still matches expected data structure, detecting drifted layouts or missing fields.

Instructions

Replay an extractor on one page, and check the page still keeps to it.

extractor: the object compile_extractor returned. html_or_url: an http(s) URL to fetch, or the HTML itself.

Returns {"ok", "rows", "fields", "summary", "failed"}; "fields" holds the page's own values an extractor learnt from examples. ok is false when the page drifted -- the listing moved, rows or a field vanished, a price no longer looks like a price -- and "failed" says which expectation broke. Never read rows from an answer whose ok is false as if nothing happened. Past 75,000 bytes the last rows are left out, counted in rows_left_out, then the heaviest summary and fields entries, named in summary_left_out and fields_left_out.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`extractor`	Yes	the object compile_extractor returned.
`html_or_url`	Yes	an http(s) URL to fetch, or the HTML itself.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	Yes
`rows`	No
`error`	No
`failed`	No
`fields`	No
`summary`	No
`rows_left_out`	No
`fields_left_out`	No
`summary_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 / fields_left_out

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "title": "Fields Left Out",
+  "type": "array"
+}

addedOutput schema / properties / rows_left_out

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

addedOutput schema / properties / summary_left_out

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "title": "Summary Left Out",
+  "type": "array"
+}

Changed2 schema fields changedv0.7.0Sep 24, 2026
- addedInput schema / properties / extractor / description
```
Added value: +"the object compile_extractor returned."
```
- addedInput schema / properties / html_or_url / description
```
Added value: +"an http(s) URL to fetch, or the HTML itself."
```
First observedv0.1.0Sep 24, 2026

TDQS

A4.5/5.0

Behavior5/5

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

The description adds significant behavioral detail beyond the readOnly/idempotent hints: ok=false means page drift, 'failed' names the broken expectation, and the warning 'Never read rows from an answer whose ok is false as if nothing happened' is a crucial safety caveat. It also discloses the 75,000-byte truncation behavior and the exact fields that report left-out data.

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

Conciseness5/5

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

The description is front-loaded with the core purpose, then parameter definitions, return-value semantics, a safety warning, and truncation behavior. Every sentence earns its place; there is no filler or redundant restatement of the tool name.

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 non-trivial verification tool, the description covers the call pattern, the meaning of ok/failed, the danger of trusting failed rows, and the truncation edge case. The presence of an output schema reduces the need to fully specify return structure, and the prose covers the important semantic and edge-case behavior.

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 description coverage is 100%, and the description restates the same meaning for both parameters: extractor is the compile_extractor return value and html_or_url is either an http(s) URL or raw HTML. This is useful but adds no information beyond the structured schema, so the baseline of 3 applies.

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

Purpose5/5

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

The description uses a specific verb-plus-resource framing: 'Replay an extractor on one page, and check the page still keeps to it.' The 'on one page' scope and the drift-checking return semantics clearly distinguish it from siblings like extract_many, crawl_site, and heal_extractor. The title, name, and description align without tautology.

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

Usage Guidelines4/5

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

The context is clear: use this after compile_extractor to validate a single page against an extractor and detect drift. It does not explicitly name alternatives or state when not to use it, but the 'on one page' scope and the focus on checking expectations imply the correct use case strongly enough.

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

Deploy Server