sluicer

by Gi0tto

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Fetch a page

fetch_page

Read-onlyIdempotent

Fetch a web page's HTML in slices using offset and max_chars, returning the full length and next offset for pagination.

Instructions

Fetch a page's HTML, and say what it cost: plain HTTP or a browser.

url: an http(s) URL. Literal HTML is refused, since nothing would be fetched. offset: where in the HTML this answer starts, 0 for the beginning; the answer before gives the next as next_offset. max_chars: the most characters this answer carries, 1 to 60,000; fewer when more would weigh over 75,000 bytes, as 60,000 characters of Chinese do.

Returns {"ok", "html", "url", "fetch", "truncated", "length", "next_offset"}: html is one slice of the page, length the whole page's, and next_offset where the next slice starts, or null when this one reaches the end. Prefer extract_declared or page_markdown, which return what is in the page rather than all of it.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	an http(s) URL. Literal HTML is refused, since nothing would be fetched.
`offset`	No	where in the HTML this answer starts, 0 for the beginning; the answer before gives the next as next_offset.
`max_chars`	No	the most characters this answer carries, 1 to 60,000; fewer when more would weigh over 75,000 bytes, as 60,000 characters of Chinese do.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	Yes
`url`	No
`html`	No
`error`	No
`fetch`	No
`length`	No
`truncated`	No
`next_offset`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.9.0Sep 26, 2026

changedInput schema / properties / max_chars / description

Previous value: -"how many characters this answer carries, 1 to 60,000."New value: +"the most characters this answer carries, 1 to 60,000; fewer when more would weigh over 75,000 bytes, as 60,000 characters of Chinese do."

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"
+]

Changed4 schema fields changedv0.7.0Sep 24, 2026

addedInput schema / properties / max_chars

Added value: +{
+  "default": 30000,
+  "description": "how many characters this answer carries, 1 to 60,000.",
+  "title": "Max Chars",
+  "type": "integer"
+}

addedInput schema / properties / offset

Added value: +{
+  "default": 0,
+  "description": "where in the HTML this answer starts, 0 for the beginning; the answer before gives the next as next_offset.",
+  "title": "Offset",
+  "type": "integer"
+}

addedInput schema / properties / url / description

Added value: +"an http(s) URL. Literal HTML is refused, since nothing would be fetched."

addedOutput schema / properties / next_offset

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Next Offset"
+}

First observedv0.1.0Sep 24, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The annotations already mark this read-only, idempotent, and non-destructive, and the description adds valuable behavioral details beyond that: the returned 'fetch' field reveals whether a browser was used, results are sliced with next_offset pagination, and max_chars is subject to a byte-weight cap with an illustrative example. Nothing contradicts the annotations.

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 front-loads the core behavior in the first sentence, uses a compact keyed parameter layout, and clearly separates the return contract and the alternative-tool guidance. Every sentence contributes: parameter rules, return shape, and routing advice. It is dense but not bloated.

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?

Given there is an output schema, the description goes beyond what is structurally required by explaining pagination semantics, truncation behavior, the meaning of next_offset, and the literal-HTML rejection. It is complete enough for an agent to call the tool correctly and interpret the response, without missing critical usage constraints.

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 schema property descriptions are essentially identical to the description text for url, offset, and max_chars. The baseline is therefore 3; the description restates semantics rather than adding meaning beyond the schema, though it does frame the parameters coherently as a pagination mechanism.

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 opens with a specific verb and resource: 'Fetch a page's HTML' and immediately reveals a distinguishing trait—reporting whether the fetch used 'plain HTTP or a browser.' This differentiates it from siblings like page_markdown and extract_declared, which return processed content rather than raw HTML.

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

Usage Guidelines5/5

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

The description explicitly says 'Prefer extract_declared or page_markdown, which return what is in the page rather than all of it,' giving a clear when-not-to-use rule and naming alternatives. It also warns that literal HTML is refused, so an agent knows not to pass page content directly as the URL.

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

Deploy Server