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

With no annotations, the description carries the full burden and does well: it discloses background execution, pacing at the host's pace, retention for `days`, that reads/recipe runs with cached=true use only the copy, and that archive source makes no request to the site. It does not describe failure handling or what happens if a job is re-started.

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

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

Three dense sentences, front-loaded with the scenario and the core behavior, with each clause carrying parameter or behavioral meaning. No filler.

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

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

For a 6-parameter, no-annotation, no-output-schema job-control tool, this covers purpose, mode selection, retention, and lifecycle actions. The omission of max_pages semantics and any job-failure/status-return detail are the only remaining gaps.

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

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

Schema coverage is 0%, so the description must compensate and largely does: it explains source values (archive/live/auto), the meaning of days (copy retention), filter (narrows the urls), and action (status/stop). Only max_pages and the url parameter are left without any semantic explanation.

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

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

States a specific verb+resource ('download every page once into Scout's copy') and the scenario it serves ('pulling a lot from one site'). It is clear what the tool does, though it does not name or differentiate itself against any of the many sibling tools.

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

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

Gives a clear when-to-use trigger ('for pulling a lot from one site') and describes the source selection trade-off (archive = no request to the site, auto = live with archive fallback). It never names an alternative sibling tool or an explicit when-not-to-use condition.

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

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

No annotations, so the description carries the full burden, and it does disclose real behavior: the recipe is executed against every example and only saved if all pass, and the reply carries a one-line card. This is meaningful beyond a bare 'compile' claim, though side effects, failure messaging, and storage semantics are not covered.

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

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

Front-loads purpose, then presents the step types as a clean, indented reference where each line earns its place. It is long, but density is justified by the DSL it documents; nothing reads as filler.

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

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

For a complex DSL-compiler tool with no annotations, no output schema, and 0% schema coverage, the description supplies the purpose, the saving gate, the reply contents, and a nearly complete step grammar. Remaining gaps ('about', error behavior on failed compilation) are small relative to the complexity handled.

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

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

Schema coverage is 0%, so the description must compensate, and it documents name ('<host>/<slug>'), input_name (what the caller supplies, empty for none), examples (2+ inputs), and the entirety of the steps DSL. Only the 'about' parameter is left unexplained, which is a minor gap against otherwise strong compensation.

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

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

States a specific verb and resource: 'Compile what you worked out about a site into a recipe a small model can run in one call,' and adds the downstream workflow ('Scout runs it on every example and saves it only if all pass'). It is distinguishable from most siblings, though it leans on domain jargon and does not explicitly contrast itself with 'recipes', 'run', or 'scout'.

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

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

Usage is implied by the workflow narrative (compile then Scout validates) and one conditional hint is given: 'Prefer map over a guessed url template.' But there is no explicit statement of when to choose compile over siblings like recipes, run, or scout, nor any prerequisite conditions.

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

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

With no annotations, the description carries the full behavioral burden and does so substantially: it discloses that recording a keyed route creates an enrollment request, that Scout tests the key on the sample before marking 'enrolled', and the key-handling constraint ('keys are never passed here: they go in the keys file or SCOUT_KEY_<NAME> env vars'). It still omits permissions required, reversibility, and what a call returns, which keeps it from a 5.

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

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

The text is dense but nearly waste-free, with each action line earning its place and key-handling rules placed last as a constraint. Structure is poor, though: it is a run-on block with slash- and pipe-delimited fragments and no front-loaded summary, making it harder to scan than its length warrants.

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

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

For a 5-parameter, no-annotation, no-output-schema workflow tool, the description covers the action modes and the info payload adequately but leaves host/note/include_all undocumented and gives no return-value or state-transition details. It is usable for the common path but incomplete for an agent needing to call it precisely in every mode.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate and it does so well for the two hardest inputs: the full action= vocabulary (which supplies the missing enum) and the nested info object's fields (route types, auth kinds, sample, cost). The host, note, and include_all parameters, however, are left completely unexplained in both schema and description, so compensation is only partial.

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

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

The description states a specific resource ('official routes and the enrollments they need') and enumerates distinct operations via action= list/request/applied/done/decline, so an agent can tell it manages the enrollment workflow rather than generic site data. It does not name any sibling tool, however, and the referent 'Scout' is undefined, leaving some ambiguity about the boundary versus tools like site_map or scout.

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

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

The action= vocabulary implicitly conveys the workflow states (open request → applied → done/decline), which is useful triage context. But there is no explicit statement of when to choose enroll over its siblings, no preconditions, and no when-not-to-use condition; the agent must infer usage from the mode names.

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

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

With no annotations at all, this description carries the full disclosure burden and does unusually well: it explains the sampling/voting/walking/ranking mechanics and flags that `best.recipe_hint` is a draft recipe for `compile`. It omits operational traits an agent would want (network cost, rate limits, whether it is a safe read-only crawl), so not a 5.

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

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

Purpose and the compile cross-reference are front-loaded, but the long middle sentence bundles four algorithm stages into one run-on clause, mixing helpful rationale with implementation detail. Adequately sized, not optimally structured.

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

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

For a three-parameter, no-annotation, no-output-schema tool, the description explains the mechanism and one return field (`best.recipe_hint`) but leaves all inputs unexplained and says nothing about the shape of the ranking output. Partially complete rather than fully adequate.

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

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

Schema description coverage is 0% for all three parameters. The description never explains `url`, `want`, or `depth`; only the passing phrase 'walked one level deeper' faintly gestures at the depth parameter. With low coverage the description was expected to compensate and largely does not.

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

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

The description states a specific resource (a page's link "families") and what the tool produces (which families lead to good pages and how many), and it defines its own jargon with the /chapter/1/ vs /chapter/14A/ example. It is distinguishable from the cryptically named siblings, though the framing as a question about results rather than a crisp verb keeps it from a 5.

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

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

It gives one explicit routing condition: use it on sites with no useful sitemap, which implicitly points away from the confusingly named `site_map` sibling. There is no explicit when-not guidance beyond that, but the key selecting condition is present.

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

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

With no annotations, the description carries the full burden and does disclose real behavior: automatic holds after a block page or 429, a single probe when the block ends, and that min_interval permanently slows Scout's pace on that host. It still omits scope and side effects — whether lifting affects in-flight requests, whether the hold persists across sessions, and what permissions are needed.

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

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

The core purpose is front-loaded in the first clause, which is good, but the second sentence is a run-on whose referent ('reason says what was asked and when') is easy to misparse. The three sentences are dense and could be tightened without losing information.

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

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

For a 4-parameter mutation tool with no annotations and no output schema, the description supplies an unusual amount of operational context (auto-hold triggers, probe behavior, permanent pacing). It is nearly complete, with the main remaining gap being persistence scope and any return/confirmation semantics.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: 'lift' is defined by 'let them back', 'reason' by 'says what was asked and when', and 'min_interval (seconds)' is explained as a permanent pacing change. Only 'host' is left implicit, though it is inferable from 'off a host'.

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

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

The description names a specific verb and resource: it keeps agents off a host, or lifts that block ('or let them back'). The hold/lift duality is unambiguous once read, but there is no differentiation from the sibling tools (scout, reach, cache, etc.), which are not referenced at all.

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

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

It gives an explicit trigger for the lift path ('when a site blocked you and a person has asked for the block to be lifted') and implies that manual holding is often unnecessary because 'Scout holds a host by itself after a block page or a 429'. That implicit when-not-to-use is valuable, but no alternative tool is ever named.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the source (legislature sites), the max-50 limit, the scale warning for whole codes, and the returned fields (citation, heading, text, url). It does not cover permissions, rate limits, or error behavior.

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

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

Front-loads the purpose, then walks through no-state, state, and whole-code behavior efficiently. It is dense but appropriately sized. Bullet formatting would improve scanability, but no sentence is wasted.

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

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

For a tool with no annotations and no output schema, the description covers both modes, return fields, and the scale limitation plus an alternative for full codes. It omits auth/permissions and pagination beyond limit, but is otherwise adequate.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the state format (e.g. 'us-tx'), the no-state mode, and the limit cap (max 50). The default limit of 10 is not restated, though the schema supplies it.

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

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

States a specific verb and resource: reading US state codes from each legislature's own site. It also distinguishes two modes based on whether the state parameter is provided. It does not explicitly differentiate from sibling tools, but the scope is clear.

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

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

Explains when to omit state (list of states with citation form/source) versus when to provide state (first limit sections of that state's code). It also gives an alternative CLI path for reading a whole code. No sibling-tool alternatives or exclusions are given.

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

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

With no annotations, the description carries the full burden. It usefully discloses the returned content (winning reader, reader order, routes, moves, recent failures) and the no-host fallback behavior, but says nothing about read-only nature, side effects, or any limits, leaving gaps for a retrieval tool.

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

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

Two tight sentences, front-loading the with-host case before the no-host fallback, with no filler. Dense jargon slightly hurts readability but nothing is wasted.

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

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

For a low-complexity single-parameter retrieval tool with no output schema and no annotations, the description adequately sketches the payload but leaves return shape and safety profile undefined, and the undefined terminology prevents fully confident invocation.

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

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

Schema description coverage is 0% for the lone 'host' parameter, so the description must compensate — and it does, explaining both the per-host result set and what happens when host is omitted ('recent failures everywhere and the whole register'). That meaningfully exceeds the silent schema.

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

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

The description conveys that this retrieves learned state about a host (readers, routes, moves, failures), which is a real purpose beyond the name. However it is saturated with unexplained domain jargon ('winning reader', 'the register', 'moves') and never distinguishes itself from siblings like scout, moves, recipes, or cache, so an agent cannot cleanly route to it over those.

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

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

It does specify the two operating modes via the host argument ('with host' vs 'No host'), which is genuine conditional guidance. But there is no explicit when-to-use/when-to-avoid statement relative to the many sibling tools, so the agent must infer the routing.

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

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

With no annotations, the description carries the full burden and does well: it discloses the scoring formula (wins+1)/(tries+2), the retirement rule (5 straight losses), and the exception that locale_prefix/listing_root are ranked and never retired. It omits auth/permission requirements and any notion of what a mutation returns or whether it is reversible.

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

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

Extremely dense but front-loaded: the registry purpose and scoring rule come first, then action syntax, then kind/scope vocabularies. The terse pseudo-grammar earns its space, though it reads as a compressed spec rather than prose.

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

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

For a 7-parameter, no-annotation, no-output-schema tool, the description covers actions, parameter vocabularies, scoring, and lifecycle rules well. It does not describe the shape of list results or what propose returns (e.g. a new id), which an agent might need when chaining calls.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it defines kind values with their spec shapes (url_rewrite {pattern, repl} with \1 group semantics, locale_prefix, listing_root, listing_path, detail_suffix) and explains scope ('*', domain with www coverage, or host regex). Minor gaps remain for host/note as list filters.

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

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

The description names the resource (the moves register), its role (rewrite rules Scout tries when built-in moves fail), and enumerates the three concrete actions (list, propose, retire). An agent can distinguish this from siblings like scout, reach, or site_map without opening any schema.

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

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

It gives the operating context (rules that fill in for failed built-in moves) and a clear directive: 'Propose only what you saw work.' Action syntax shows how to invoke each mode, but no alternative tool is named and no explicit when-not-to-use exclusion is stated.

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

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

With no annotations, the description carries the full burden and does so richly: it names the retrieval cascade, the return fields (ok, markdown, tried, error with code/message/next_steps), the mirror-vs-Wayback fallback and the `archived` capture time, and that cached=true issues no network request. It does not address permissions, rate limits, or whether any state is mutated, which are the remaining gaps for a network-fetching tool.

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

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

The purpose is front-loaded in the first sentence and every following clause carries behavioral information (return shape, mirror, fallback, cache semantics) with little filler. It is dense and somewhat run-on, and jargon like 'winner-first' and 'detail sub-pages' costs a little clarity without being wasteful.

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

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

There is no output schema and no annotations, so the description correctly takes on the job of describing return values and fallback semantics, which it does well. The main shortfall for a five-parameter tool is the unexplained `want` parameter and the absence of any auth or rate-limit context.

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

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

Schema description coverage is 0%, so the description must compensate. It explains three of five parameters inline (full=true for full markdown, fresh=true to re-read, cached=true for no-request mirror reads), but `url` and especially `want` (default "") are left entirely undefined in both schema and description. Partial compensation for a real coverage gap.

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

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

The description states a concrete action on a concrete resource: fetch one page and judge whether it is good information, then names the internal retrieval strategies it tries (learned readers, url rewrites, detail sub-pages). This is distinguishable from purpose-level siblings like site_map or cache, though it never explicitly routes away from its closest sibling, scout. The idiosyncratic verb 'reach' is only clarified by the body text rather than the opening clause.

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

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

Usage is implied rather than stated: cached=true 'sends no request' and fresh=true re-reads, which tells the agent about modes but not when to pick this tool over scout or site_map. Automatic fallback behavior (wall/hold → Wayback) is described, but there is no when-not guidance or explicit alternative named for the general case. An agent can infer the single-page-fetch role, but must infer it.

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

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

With no annotations at all, the description carries the full behavioral burden, and it partially discharges it by naming the returned payload: what each recipe takes, its score, last-run-failure status, and its card. It is silent on permissions, ordering, pagination, and whether 'failed' reflects the most recent run only, so it is adequate but not rich.

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

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

One dense sentence that front-loads the resource and then lists the salient returned fields. It earns its length, though the closing clause about 'the one-line card a small model runs' is jargon that costs a little clarity for no functional gain.

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

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

For a tool with one optional parameter and no output schema, the description does describe the return shape in lieu of an output schema, which is the right instinct. It still leaves the agent unsure of ordering, completeness, and how failure status is scoped, so it is only minimally sufficient.

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

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

Schema coverage is 0% (the single 'host' property has no description), so the description must compensate. The phrase 'optionally for one host' does add meaning: it signals the parameter is an optional filter and identifies the filtering dimension, which is more than the bare schema gives, but it omits format/matching semantics.

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

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

The description conveys that this returns the collection of compiled recipes, with the per-recipe fields enumerated, and that it can optionally be scoped to one host. However, it is phrased as a noun phrase ('The compiled recipes') rather than a verb+resource action, and it never distinguishes itself from siblings like compile, run, or cache, so the agent must infer the operation is a read/list.

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

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

The only usage information is the parenthetical 'optionally for one host', which explains filtering but not when to call this tool. There is no guidance on when to prefer recipes over compile or run, or any stated preconditions.

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

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

No annotations, so the description carries the full burden. It usefully discloses that cached=true sends no request and reads Scout's copy, and that `inputs` yields one RESULT line per input — real behavioral detail. But it omits error behavior, whether the run mutates remote state, auth/permission needs, and rate limits.

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

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

Three tight sentences, front-loaded with the core purpose before parameter notes. Dense but every clause carries information; no padding.

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

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

No output schema and no annotations, so the description should do more. It hints at the return format ('RESULT line') but doesn't define it, describe failure modes, or resolve the input/inputs relationship — leaving real gaps for a 4-param execution tool.

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

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

Schema coverage is 0% across 4 params, so the description must compensate. It explains `inputs` (batch) and `cached` (local read, no request) meaningfully, but leaves `input` (singular) versus `inputs` and the required `recipe` value unexplained, so half the parameters remain ambiguous.

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

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

States a specific verb+resource: 'Run a compiled recipe.' This clearly separates it from the sibling 'compile' (which produces a recipe) and 'cache'. However, it doesn't explicitly name or contrast the sibling tools, so differentiation is inferred rather than stated.

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

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

Gives a conditional usage hint for one parameter ('cached=true ... use after cache') and notes the batch mode for `inputs`, but never states when to choose `run` over `compile`/`cache`, nor any prerequisites for running a recipe. Usage is implied rather than spelled out.

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

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

With no annotations the description carries the full burden. It does disclose some behavior: the return is markdown, it maps url patterns, it finds a listing page, it reports failures via 'page.error', and 'good = real content that is not a wall' hints at a content-quality judgment. It says nothing about rate limits, auth, caching, or what the successful return shape looks like.

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

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

The action is front-loaded in the first sentence, which is good, but the remaining sentences are cryptic shorthand ('good = real content that is not a wall', 'what Scout has learned') that costs more parsing effort than it saves. Appropriately sized, poorly worded.

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

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

For a multi-step tool with three parameters, zero schema coverage, no annotations, and no output schema, the description is too thin. It hints at 'page.error' but never describes the successful return, and leaves 'full' unexplained, so an agent cannot call it confidently.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'want' (an optional regex the page must carry, with concrete examples), but 'url' is only implied and 'full' is never mentioned at all, leaving one of three parameters completely undocumented in both schema and prose.

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

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

The description enumerates concrete steps (reach the page as markdown, map url patterns, find the listing page, return findings), so the agent gets a rough sense of the operation. But it leans on undefined internal jargon like 'what Scout has learned about the host,' and the verb 'scout' itself is vague, so the exact purpose stays fuzzy.

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

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

There is no when-to-use guidance and no differentiation from closely related siblings such as 'reach' and 'site_map', which appear to overlap heavily with this tool's fetch-and-map behavior. The agent must guess which of the several crawling/navigation tools to pick.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses a 12-hour listing reuse window, explains that fresh=true re-lists only when the site changed, warns that repeated full listing can get crawlers blocked, and describes Wayback Machine behavior for archive modes. It does not cover return format, pagination, or error behavior.

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

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

The description is dense but front-loaded with the tool's purpose and mechanisms. Every sentence adds some operational detail, though the parameter explanations are interleaved rather than clearly structured.

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

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

There is no output schema and no annotations, so the description must be complete. It covers important behavioral details and hints at returned URL patterns, but omits the limit parameter, return format specifics, and error or permission behavior.

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

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

Schema description coverage is 0%, so the description must compensate. It explains filter as a regex, fresh=true semantics, and archive='only'/'auto' behavior, but never explains the url parameter or the limit parameter, leaving two of five parameters undocumented.

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

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

The description clearly states the resource and method: it returns a site's real URLs gathered from robots.txt sitemaps, a polite link walk, and the catalogue root, along with their URL patterns. It distinguishes itself from generic guessing rather than from named sibling tools, so it is clear but lacks explicit sibling differentiation.

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

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

It gives clear context for use with 'Use it instead of guessing paths,' and explains when to use fresh=true and archive='only' or 'auto.' It does not name alternative sibling tools or state explicit exclusions, but the usage context is clear.

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