wigolo

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

Annotations already cover the safety profile (readOnly, openWorld, idempotent, non-destructive), and the description layers real operational detail on top: the exact pipeline stages, parallel execution within budget, per-step timing via steps[], MCP sampling with a keyword-extraction fallback, and a warning not to surface the raw step log as a result. This is the kind of behavior the annotations cannot express.

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 is front-loaded in one sentence, then organized into step-transparency, parameter, pipeline, and return sections — appropriate density for a 9-parameter tool. Minor redundancy: "Full step transparency" and the steps[] sentence in the pipeline block make the same point twice.

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?

With no output schema, the description discharges that burden by enumerating the return shape (result, sources[], pages_fetched, steps[], total_time_ms, sampling_supported) and explaining degraded-mode output. What's missing is failure/partial-result behavior and any notion of source-quality limits when the budget is exhausted.

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 100%, so the baseline is 3 and the schema already explains every param including citation_format's enum values. The description mostly restates defaults already present in the schema (max_pages 10, max_time_ms 60000) and adds only a single illustrative example for prompt, so it does not meaningfully exceed the 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 opening line states a specific resource and action: natural-language data gathering across sources, with the plan → fetch → extract → synthesize pipeline spelled out. An agent understands exactly what it gets back. However, it never names a sibling (research, search, crawl, fetch) to differentiate itself, despite 'research' sounding functionally close.

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 context is implied through the example prompt ("pricing for the top 5 CRM tools") and the guidance on when synthesis is vs. isn't available, plus the instruction that the caller must write the summary from returned evidence. But there is no explicit when-not-to-use-this and no routing statement against the near-siblings 'research', 'search', or 'crawl'.

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?

Annotations already declare destructiveHint=true, openWorldHint=true, and readOnlyHint=false, so safety characteristics are conveyed. The description adds useful behavioral context — instant cache hits with full markdown, persistence across sessions, and no remote round-trip — but doesn't elaborate on what exactly gets deleted by clear or the irreversibility of that action. It's still helpful beyond 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.

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

The description is front-loaded with the core purpose, followed immediately by usage guidance, then a bulleted list of key parameters. Every sentence earns its place, and there is no wasted text.

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?

Given the complexity (9 parameters, no output schema, destructive clear operation), the description is complete enough for correct invocation. It explains the tool's role, when to prefer it, key parameter semantics, and persistence. Missing details about some parameters are fully covered by the schema descriptions.

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 100%, so the schema already documents all parameters. The description adds operational meaning for key parameters: FTS5 syntax support (AND, OR, NOT, phrases) for query, a glob example for url_pattern, and the ISO date format for since. This goes beyond the schema's terse descriptions, though it doesn't mention mode, limit, check_changes, or max_tokens_out.

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 verb and resource: 'Search previously fetched content without hitting the network.' It immediately distinguishes itself from the sibling tools search and fetch by positioning itself as a local cache lookup rather than a live network operation.

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 explicit when-to-use guidance: 'Run this BEFORE any search/fetch — cache hits return instantly with full markdown.' This directly tells the agent when to choose this tool over its siblings, leaving little inference.

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?

Goes well beyond the annotations: discloses that every page is written to the local cache and reusable via cache/find_similar, that content is deduplicated anchor-fragment aware, and that per-page content_completeness flags let the agent skip un-rendered shells. These are meaningful side effects and data-quality traits not captured by readOnly/openWorld hints.

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 in one sentence, then uses a compact parameter list and a return-shape paragraph. Some bullets restate defaults already in the schema, which is minor waste but not damaging.

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 12-parameter open-world tool with no output schema, it explains the return payload (pages[] with title, evidence, depth, content_completeness) and key controls. It omits mention of use_auth, extract_links, and max_total_chars, but those are documented in the schema.

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 100%, so the schema already documents all 12 parameters and enum meanings. The description adds modest value (marking sitemap as fastest for doc sites, noting map is URL-only discovery, restating defaults) but largely mirrors what is already structured.

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 (crawl a site from a seed URL, return content from many pages) and scopes it with concrete use cases like indexing docs, wikis, and multi-page references. The 'many pages' framing implicitly separates it from the single-page fetch sibling, but it never names fetch/search explicitly.

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?

'Use for indexing docs, wikis, multi-page references' gives clear positive context for selection. It stops short of explicit exclusions or naming alternatives like fetch for single pages or search for targeted lookups.

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?

Beyond the annotations, the description discloses important behavior: URL inputs read from cache, cache misses return a structured `cache_miss` error with no network re-fetch, and diffs over 5000 lines are truncated with an approximate summary rather than silently degrading. These are meaningful operational details not covered by 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.

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

The description is front-loaded with the core purpose and then uses compact bullet points for parameters, output modes, and return shape. Every section carries operational value without repetition.

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?

Given the nested parameters, lack of an output schema, and read-only annotations, the description is complete enough to invoke the tool correctly. It covers input forms, cache miss behavior, output modes, truncation limits, and return shape.

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 100%, so the baseline is 3. The description adds useful meaning beyond the schema, especially that `old.url` reads from cache and can produce a structured `cache_miss` error, and that `section` granularity tags hunks with `section_title`.

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 uses a specific verb and resource: 'Compute a diff between two markdown bodies or two URL fetches.' This clearly distinguishes it from sibling tools such as fetch, crawl, and extract, and an agent can identify its operation without opening the 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?

The description gives clear contextual guidance for invoking the tool, including cache behavior for URL inputs and how to choose output and granularity. It does not explicitly name alternatives or say when not to use this tool, so it falls short of the full when/when-not/alternatives standard.

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?

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), and the description adds substantial behavior beyond them: the brand-mode resolution chain, provenance enums with their allowed values, the honesty guarantee that favicons never promote to logo_url, schema-mode's null-plus-warning for unverifiable fields, and what chart_hints surfaces for JS-rendered charts. These are exactly the non-obvious traits an agent could not infer from structured fields.

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-loaded with purpose and the key routing sentence before parameter detail, and for a six-mode tool with no output schema nearly every clause carries information. It is still a dense wall of prose, and the inline provenance enum listing arguably belongs in the schema rather than the description.

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?

With 8 parameters, nested objects, and no output schema, the description carries the return-value burden and does so — it names the structured response keys, the brand fields, and the trimming behavior under max_tokens_out. An agent has enough to pick a mode and predict the shape of the result.

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 100%, so the baseline is 3; the description earns above that by expanding mode semantics well past the enum strings (what 'structured' returns, the order 'brand' walks sources, evidence-only behavior for 'schema'). Some lines are pure restatement of the schema, e.g. "css_selector: required for mode='selector'", which keeps it from a 5.

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 ("Extract structured data from a URL or raw HTML") and immediately scopes it against the whole-page path with "Use for specific data points (tables, prices, schema fields) rather than whole-page markdown," which routes an agent away from the fetch/crawl siblings. The six enumerated modes make the tool's surface unambiguous.

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 clear selection context both across tools (specific data points vs. whole-page markdown) and within the tool ("Prefer mode='structured' over chaining multiple extract calls"), plus a rule for choosing mode='schema' vs named_schema flags. What's missing is an explicit named exclusion such as "use fetch instead when you need the full page text" — the routing is implied rather than 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?

No output schema exists, yet the description discloses return fields (title, markdown, links, metadata, fetch_method, http_status, content_completeness), site-specific site_data, cache staleness semantics, and the explicit no-match behavior for `section`. It does not address the destructiveHint=true side — that `actions` (click/type) can mutate the target page — nor rate limits, which is a real gap for a tool annotated destructive.

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-loaded with purpose and routing, then a bulleted parameter list and a returns paragraph — easy to scan. Several bullets restate schema descriptions verbatim (mode, render_js, use_auth), which is waste given 100% schema coverage, but nothing is buried or redundant in a harmful way.

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 15-parameter, nested-object, open-world tool with no output schema, the description still covers return shape, cache/freshness behavior, auth session reuse, JS rendering, failure semantics for `section`, and repeat-fetch speed. An agent has enough to call it correctly on first attempt.

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 100%, so baseline is 3, but the description adds genuine decision guidance beyond the schema: `section` is cheaper than the whole page, `max_content_chars` truncates smartly vs `max_chars` hard slicing, `max_tokens_out` wins, and `include_full_markdown: false` returns excerpts only. It omits any mention of `citation_format`, `headers`, `screenshot`, or `section_index`.

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 ('Fetch a single URL and return clean markdown') and immediately delimits scope with 'Use when you already have a URL', which separates it from sibling search/crawl tools. An agent can pick it without opening the 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?

Gives a clear selection condition ('when you already have a URL') and names an alternative it beats (built-in WebFetch) with four concrete reasons. It never states when *not* to use it or routes to siblings like crawl/extract, so it stops short of full routing guidance.

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?

Annotations already cover readOnly/idempotent/openWorld, and the description adds substantial behavior beyond them: the RRF fusion of three signals, the `cold_start` response flag and how to surface it, the cache-warming effect on cost and quality, and an env-var tuning hook. This is the kind of context annotations cannot carry.

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 usage condition and keeps parameter notes in a scannable bullet list. The cold-start/cache-warming point is repeated three times (main paragraph, concept bullet, ranking-debug bullet), which costs space without adding 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?

With 13 parameters and no output schema, the description does the necessary work of enumerating the return fields (results[], method, cache_hits, match_signals, cold_start), which an agent could not get elsewhere. The value is undercut by the incorrect default values and the missing `mode` parameter.

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 100%, so the baseline would be 3, but the description actively misstates structured data: it says `max_results` default 5 (schema: 10), `threshold` default 0.5 (schema: 0), and names a parameter `include_cached` that does not exist (schema: `include_cache`). It also omits the `mode`, `include_domains`, and `exclude_domains` parameters entirely, so an agent trusting it would pass wrong defaults.

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: 'Find content related to a URL or concept,' with the two supported input modes named up front. It doesn't explicitly contrast itself with the `search` sibling, so an agent must infer the difference, which keeps it at 4 rather than 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?

Explicit when-to-use guidance ('Best after a successful crawl/fetch') and explicitly names the alternative tools (`crawl`/`fetch`) as prerequisites for warm-cache usage. It also warns when results will be poor (concept-only on cold cache) and tells the agent what to do instead.

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?

Annotations already cover safety (readOnly, idempotent, non-destructive, open-world), and the description adds substantial behavior beyond them: latency per depth, what changes when a synthesis LLM is or isn't configured, the fallback instruction that the caller must write the answer from `brief`, and a recommendation to set up a provider key. That is exactly the kind of degradation-mode disclosure annotations cannot express.

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-loaded with purpose and differentiator, then behavior, parameters, and returns in clearly separated blocks. The parameter block is somewhat redundant with a fully-covered schema, but given the absence of an output schema the returns paragraph is not 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?

With no output schema and a 10-parameter nested-input tool, the description carries its weight: it enumerates return fields (report, citations, sources, sub_queries, depth, total_time_ms, sampling_supported) and the `brief` sub-structure including the meaning of `gaps`. An agent knows what it will receive and how to consume it.

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 100%, so the schema already documents all ten parameters; the description's 'Key parameters' list largely restates them. It does add sub-query counts per depth (2/4/7) that the schema omits, but that is marginal value over the schema baseline.

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 ('Multi-step research on a complex question') and immediately describes the pipeline steps (decompose, parallel search, fetch, synthesize a cited report). It explicitly distinguishes itself from sibling tools by naming the `search` + `fetch` chaining pattern it replaces.

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?

'Beats chaining `search` + `fetch` manually for multi-source synthesis' names the alternative and the condition that favors this tool, and the depth tiers give timing/scope guidance for choosing invocation cost. No explicit when-not case (e.g., single-fact lookups should use `search`), so it stops short of full routing guidance.

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?

Annotations already declare readOnly/openWorld/idempotent, and the description goes well beyond them: default response shape, always-emitted fields (engines_used, evidence_score, response_time_ms), the conditional emission of freshness_signal, brand_collision_warning behavior, cache bypass via force_refresh, the fallback path when format=answer, and the fact that retired format values reject with a migration error. Latency budgets for ultra-fast (≤300ms) and fast (≤1s) plus the ultra-fast empty-result-on-miss behavior are exactly the kind of traps an agent needs disclosed.

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?

Well front-loaded — the first sentence carries the core value proposition and the response shape before the parameter list. However, several bullets are near-verbatim restatements of schema descriptions that already have 100% coverage (from_date/to_date, category enum, max_results default 5, force_refresh, include_images), which costs tokens without adding 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 28-parameter tool with no output schema, the description carries the full burden of explaining return values and it does: default evidence shape, opt-in full markdown, conditional fields, citation rendering, and truncation controls. Combined with the mode/search_depth fallback semantics, an agent has enough to call this correctly on the first attempt.

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 100%, so the baseline is 3, but the description adds genuine guidance beyond the schema: 3-5 query variants with deduplication, the instruction to always scope library/framework queries, and the note that image results carry image_url/thumbnail_url/dimensions. Some bullets merely restate schema text (from_date/to_date ISO format, category enum, max_results default), which keeps it from a 5.

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?

Opens with a specific verb+resource ("Search the web") and immediately defines the default output shape (scored evidence excerpts + citations), which lets an agent predict the return contract. It positions itself against the built-in WebSearch, but says nothing about when to pick it over siblings like research, find_similar, or extract, so sibling differentiation is incomplete.

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 concrete operational guidance: "Always scope library/framework queries" to include_domains, 3-5 keyword variants for the array form, omit format for the evidence shape, and search_depth tiers with latency expectations. It stops short of naming conditions that select a sibling tool (e.g. research vs search vs find_similar), so there is no explicit when-not guidance.

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?

Rich disclosure beyond annotations: persistence across restarts, fire-and-forget triggering on sibling tool calls, SSRF rejection at registration, a 60-second floor for target-site rate limits, and best-effort webhook delivery with no retry/queue/backoff. One nuance conflicts with annotations — the description says `create` is idempotent while `idempotentHint=false` — though that hint remains defensible for `check`/`delete`, so this is a clarification rather than a hard contradiction.

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-loaded with the single most important fact ('LAZY EXECUTION — NOT CRON') before any parameter detail, and the bulleted parameter block is scannable. A few lines merely restate the schema's action enum and create-only flags, which is the only mild redundancy in an otherwise dense, purposeful text.

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?

Given seven parameters, six actions, no output schema, and an unusual lazy-execution model, the description covers lifecycle, trigger conditions, failure modes, idempotency, and the one return field that matters (`staleness_seconds`). An agent could invoke every action correctly from this text alone.

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 already 100%, so the baseline would be 3; the description goes well past it by adding constraints (public http/https only, loopback/RFC 1918/link-local rejected, interval min 60), the forward-compatibility caveat that `selector` is persisted but diffs are currently full-page, and the meaning of `staleness_seconds` (negative = not due, positive = overdue by N).

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?

Opens with a specific verb+resource+outcome: 'Schedule lazy re-checks of a URL and surface diffs on change,' which immediately separates it from the one-shot `fetch`, `crawl`, and `diff` siblings. It does not, however, explicitly name any sibling and contrast itself with `diff` (which presumably does a one-shot comparison), leaving a small inference gap.

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?

Explicitly states when checks fire ('ONLY when: 1... 2...'), what does NOT happen ('no background daemon', 'not cron'), and pairs `list` with `check` to force immediate execution. The action enumerations are each given a context of use rather than left to inference.

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