sluicer

Overview Schema Source Related Servers Discussions Admin

Map a site

map_site

Read-onlyIdempotent

Discover a website's URLs by reading its sitemaps, or fall back to scanning the start page's links when sitemaps are absent.

Instructions

List a site's addresses, from its sitemaps or its start page's links.

url: an http(s) address on the site; its links stand in when the site has no sitemap. limit: the most addresses returned, 1 to 1,000.

Returns {"ok", "url", "source", "urls", "sitemaps", "truncated"}. source is "sitemaps" or "links"; each of urls is {"url", "lastmod", "sitemap"}, only addresses on the site, in the order the sitemaps list them; sitemaps says what became of each one tried. At most ten sitemaps are read, politely, within a minute; truncated is true when a bound cut the map short, urls_left_out counting the addresses left out to keep the answer under 75,000 bytes. Hand the addresses worth reading to extract_declared, or crawl_site to follow links from one.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes	an http(s) address on the site; its links stand in when the site has no sitemap.
`limit`	No	the most addresses returned, 1 to 1,000.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	Yes
`url`	No
`urls`	No
`error`	No
`source`	No
`sitemaps`	No
`truncated`	No
`urls_left_out`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 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 / urls_left_out

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

Changed2 schema fields changedv0.7.0Sep 24, 2026

addedInput schema / properties / limit / description

Added value: +"the most addresses returned, 1 to 1,000."

addedInput schema / properties / url / description

Added value: +"an http(s) address on the site; its links stand in when the site has no sitemap."

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?

Annotations already declare read-only, idempotent, and non-destructive behavior, but the description discloses additional operational details: only ten sitemaps read 'politely, within a minute', a 75,000-byte response cap, truncation behavior with urls_left_out, and that urls include only on-site addresses. These specifics are not derivable from the annotations and materially affect how the agent interprets and uses results.

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 densely informative without waste. It leads with the core purpose, then parameters, output structure, operational limits, and follow-up guidance. Every sentence carries a distinct piece of information; nothing is redundant. The structure naturally guides the reader from what, to how, to what next.

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 tool with this complexity (source fallback, sitemap handling, truncation, follow-up routing), the description fully covers the invocation context. It explains both possible sources, output schema (including fields like source and sitemaps), edge cases (truncation), and downstream usage. The presence of an output schema in the tool definition supplements the textual description, so nothing essential is omitted.

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

Parameters4/5

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

Schema coverage is 100% and both parameters have descriptions identical to the tool description, so the schema already explains them. The description adds value by connecting the limit parameter to output behavior ('truncated is true when a bound cut the map short' and 'urls_left_out counting the addresses left out'), which goes beyond the schema's simple 'most addresses returned' phrasing.

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 and unambiguous purpose: 'List a site's addresses, from its sitemaps or its start page's links.' It clearly identifies the resource (site addresses) and the sources (sitemaps or links). It differentiates itself from siblings by explicitly routing the output to extract_declared or crawl_site, making it clear this is the discovery step, not a content fetch or extraction tool.

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 description explains the tool's role in a pipeline: 'Hand the addresses worth reading to extract_declared, or crawl_site to follow links from one.' This tells an agent when to use it (when needing to enumerate site addresses) and what to do next. However, it does not explicitly compare against all siblings (e.g., fetch_page, page_markdown) or state conditions when those would be preferred, leaving some room for inference.

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

Deploy Server