DirFast

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

With no annotations, the description carries the full behavioral burden. It helpfully discloses that queries are live against 1.1.1.1 and lists the record types, but it does not describe failure behavior, rate limits, caching, or return/error handling.

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 two compact sentences with no filler. The core operation is front-loaded, followed by the practical use cases.

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 simple one-parameter DNS lookup, the description provides enough context to invoke the tool: supported record types, live resolver, and use cases. Because no output schema exists, it could say more about result shape or error behavior, but the core invocation context is complete.

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?

There is one parameter and schema description coverage is 100%, so the schema already defines `host` with an example. The description adds only the generic phrase 'for a domain' and does not supplement the schema with format constraints such as scheme omission or IDN handling.

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: resolve DNS records for a domain, and it lists the exact record types supported. This makes the tool clearly distinct from the sibling network/diagnostic tools such as http_head, ssl_check, and seo_snapshot.

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 usage contexts: verifying that a domain resolves, checking mail routing, and inspecting TXT/SPF records. It does not name exclusions or alternatives, but the intended use cases are explicit enough for an agent to select it correctly.

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 zero annotations provided, the description must carry the full burden of transparency. It details specific operational behavior, such as measuring 'total latency in ms,' retrieving 'key response headers,' and focusing on the lightweight aspect of a 'cheap probe.'

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 entire definition is contained in a single, dense, and highly efficient sentence. It is front-loaded with the action and is structured to maximize information density without becoming verbose.

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 simplicity of the single parameter and the nature of the task, the description provides a complete profile of the tool. It covers scope, output metrics, and intended use case, leaving no critical gaps for the agent.

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?

The schema description coverage is 100%, meaning the schema already fully defines the required 'url' parameter. The description simply confirms that the input is a URL, adding no crucial semantic detail beyond what is already covered in the structured input 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 clearly defines the tool's function (Fetch a URL and report) and lists the specific, measurable outputs (HTTP status, latency, headers, page title). This specific list clearly differentiates it from sibling tools like dns_lookup or security_headers.

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 explicitly advises on when to use the tool, defining its optimal use case as a 'cheap liveness/uptime probe.' This provides necessary context for choosing it over more comprehensive or slower tools.

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 burden and it does convey that this is a side-effect-free read returning two specific values. It does not mention whether reverse DNS can be absent or how the address is derived/observed, which is a minor remaining gap for a trivial zero-parameter 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 sentences, front-loaded with the return value, then the use case. 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 zero-parameter read with no output schema, the description tells the agent what comes back and why to call it, which is close to complete. It omits whether the reverse DNS field may be null or what format the values take, a small residual gap.

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?

The tool takes zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly implies no input is required.

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 ('Return') plus exactly what is returned (caller's public IP and reverse DNS name). The possessive 'caller's' scopes it to the requesting agent, which separates it from the sibling dns_lookup that resolves arbitrary hostnames.

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 concrete when-to-use: confirming which egress IP an agent or service presents. It does not name exclusions or alternatives, but the self-scoped nature of the call makes the boundary with dns_lookup fairly evident.

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 load. It usefully discloses the 8-hop cap and the per-hop return content (status code and Location), but says nothing about HTTP method used, timeout behavior, error handling, or what happens when the hop limit is exceeded.

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 with zero waste; the mechanism and hop limit are front-loaded before the diagnostic use case.

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 exists, so the description must explain returns, and it does so adequately by describing per-hop status codes and Location targets. Edge-case behavior such as errors and hop-limit overflow is the only notable gap.

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?

A single parameter with 100% schema coverage, and the schema already documents that it accepts a URL or bare domain. The description adds no syntax, format, or normalization details beyond what the schema provides, so baseline 3 applies.

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 (follow), resource (URL redirect chain), and scope (up to 8 hops), plus what gets reported per hop. An agent can distinguish this from http_head or seo_snapshot 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?

Explicitly names the diagnostic use cases: redirect loops, http->https, and www canonicalisation issues. It gives clear positive context but never contrasts against siblings like http_head or seo_snapshot, so the when-not guidance is absent.

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 burden and does disclose the key behaviours: it performs a network fetch and returns parsed rules plus sitemaps rather than raw text. It says nothing about what happens on 404/missing robots.txt, redirects, or any timeout/rate-limit behaviour, which matters for a network tool whose common case is a site with no robots file.

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 sentences, zero filler: capability first, usage second. Both are front-loaded and every clause earns its place.

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 one-param tool with no output schema, it does the important work of describing the return value (rules + sitemaps) and the reason to call it. The remaining gap is edge-case behaviour when robots.txt is absent or unreachable, which an agent would reasonably want to know.

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% and the single param is documented as "URL or bare domain", so the description has little left to add and indeed adds nothing the schema does not already say. Baseline 3 applies.

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 pair (fetch and parse) on a specific resource (a site's robots.txt) and even names the return shape: allow/disallow rules and declared sitemaps. That is clearly distinct from every sibling (dns_lookup, http_head, ssl_check, etc.), none of which touch robots policy.

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 before crawling a site to respect its policy" gives a clear triggering context and a rationale. It stops short of naming an alternative or stating when not to use it, but no sibling is a plausible substitute here, so the routing risk is low.

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 must carry behavioral disclosure; it does disclose the return shape (0-100 score plus missing headers), which is valuable given there is no output schema. However, it says nothing about redirect handling, authentication/rate limits, or whether the fetch is passive versus invasive.

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?

A single well-formed sentence that front-loads the action and immediately follows with the concrete output format. Nothing redundant.

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 one-parameter read-only audit with no output schema, the description covers what is inspected and what comes back, which is close to sufficient. It could add redirect/timeout behavior to be fully complete.

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% for the single 'url' parameter and the description adds no format or normalization details beyond it. Baseline 3 applies when the schema does the heavy lifting.

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?

Specific verb (audit) plus the exact resource (HTTP security headers), with the six headers enumerated so the agent knows the scope precisely. It is clearly distinguishable from siblings like ssl_check or http_head, which address different aspects of a URL.

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?

No statement of when to use this versus site_audit or seo_snapshot, which plausibly overlap, and no prerequisites (e.g., reachable URL, redirects followed). Usage is only implied by the tool name.

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. "Without a browser" usefully discloses that the page is fetched as static HTML with no JS rendering, but it says nothing about network fetch behavior, redirect handling, timeouts/rate limits, or what happens on non-HTML or error responses.

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 sentences, front-loaded with the verb and resource, then the field inventory, then the usage clause. No filler; every clause carries signal.

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 single-parameter read tool with no annotations or output schema, the field enumeration effectively doubles as return documentation, which is the key need. Minor gaps remain around failure modes and whether redirects are followed, but an agent can call this correctly as written.

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% and the single required parameter is already documented as "URL or bare domain." The description adds no syntax, normalization, or scheme-handling detail beyond that, so baseline 3 applies.

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?

Uses a specific verb ("Extract") with a precisely scoped resource (on-page SEO signals from a URL) and enumerates the exact fields returned, so the agent knows the tool's boundary versus siblings like security_headers or robots_txt without reading 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?

"Use for quick SEO triage without a browser" gives a situational hint, but it never names alternatives (e.g., when to prefer site_audit for a full crawl) or states exclusions. Usage is implied rather than routed.

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 are provided, so the description carries the full burden. It discloses the composite nature and the 'one call' efficiency, but says nothing about latency/cost of fanning out six checks, what happens if one sub-check fails, or whether results are partial. Adequate but with real behavioral gaps for an aggregator 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 sentences, zero filler. The bundle contents are front-loaded in the first sentence and the selection rule follows immediately.

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 no annotations, the description should clarify the return shape of an aggregate call (per-check sections? combined verdict?) and failure semantics. It establishes scope and the inclusion list but stops short of telling the agent what it will actually get back.

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% and the single 'url' parameter is documented as 'URL or bare domain', so the schema already does the work. The description adds no format, normalization, or validation detail beyond it. Baseline 3 applies for a 1-param tool with full schema coverage.

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?

Names a specific verb and resource ('Run the full audit bundle') and enumerates exactly which signals are included (SSL, security headers, redirect chain, HTTP head, DNS, SEO), which map cleanly onto the sibling single-signal tools. An agent can immediately tell this is the aggregate counterpart to ssl_check/dns_lookup/http_head etc.

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 the selecting condition: 'Use when you need a complete health picture of a site rather than one signal.' This effectively routes the agent away from the single-signal siblings, though it does not name those siblings or give a when-not/quota 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?

With no annotations provided, the description carries the full behavioral burden. It implies a safe read-only inspection and lists returned fields, but it does not disclose connection behavior, timeouts, error handling, or whether the check reaches the host directly. Those gaps matter for an agent invoking a network-facing check, though the implied read-only nature limits the risk.

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 two efficient sentences: the first defines what is inspected and returned, and the second states the use case. There is no redundant or filler content, and the purpose is front-loaded.

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 one-parameter tool with no output schema and no annotations, the description is largely complete: it names the key return values and the intended use case. It lacks behavioral details such as timeout or failure modes, but those are minor for a straightforward certificate inspection 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 description coverage is 100%, and the single `host` parameter is documented in the schema with an example. The description does not add parameter-specific meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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 ("Inspect") and resource ("a host's TLS certificate") and names the exact fields returned: issuer, subject, SAN list, expiry date, and days remaining. It clearly distinguishes this from sibling tools such as dns_lookup, http_head, and security_headers, which do not focus on TLS certificate inspection.

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 usage context: "Use to catch expiring or misconfigured certificates." That tells the agent when the tool is relevant, but it does not name alternatives or state when not to use it, so it falls short of explicit 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?

With no annotations, the description carries the full burden, and it does disclose the return shape (status, changed flag, new hash) — valuable since there is no output schema. However, it omits that this triggers an outbound fetch and rewrites the stored hash, whether it counts against rate limits, and what happens for an invalid or deleted watch id.

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 short sentences with zero filler, and the core action is front-loaded before the return-value clause. Every sentence carries information an agent needs.

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 single-parameter tool with no annotations and no output schema, the description covers purpose and return values adequately. The remaining gap is failure/edge-case behavior and any side effects on the stored watch state, which is minor but not negligible.

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% and the single parameter is already documented as 'Watch id from watch_create', so the description need not repeat it. The description adds no further meaning about the id, which is acceptable at this coverage level but earns only the 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 and resource ('force an immediate re-fetch of a watch') plus the exact behavior it replaces ('instead of waiting for its interval'). That framing distinguishes it cleanly from watch_diff, watch_history, and watch_list without needing to name them.

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 phrase 'instead of waiting for its interval' gives clear usage context: call this when you need current content now rather than on schedule. It stops short of naming when-not-to-use conditions or the sibling tools that answer adjacent questions (e.g. watch_diff for comparison).

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: the server persists a snapshot and reports a unified diff on text change. It does not cover what happens on the first check (no baseline exists yet), whether the interval can be changed after creation, reliability/error behavior, or auth requirements.

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 sentences, each doing distinct work: what it does, when to use it, and how to specify the selector. Nothing is repeated from the schema verbatim and the contrast with fetch is front-loaded rather than buried.

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-param tool with no output schema and no annotations, this covers the essentials including the return shape (unified diff). The gap is lifecycle detail — first-run baseline behavior and the handoff to watch_diff/watch_history for retrieving results.

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 earns credit by enumerating the accepted selector grammars (css:#id, css:.class, css:tag, regex:PATTERN, json:$.path, empty for whole body) — a form the schema only sketches with two examples.

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 ('Start watching a URL for changes') and immediately explains the mechanism (snapshot, periodic re-fetch, unified diff). It also contrasts against a plain fetch, which separates it from http_head and the rest of the sibling set.

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 gives the selecting condition: 'Use this when you need to know if something changed since last time - an ordinary fetch cannot tell you that.' That is a clear when-to-use rule, though it never names the adjacent watch_* siblings (watch_check, watch_diff, watch_history) that an agent must pick between.

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 of behavioral disclosure. It usefully states that stored snapshots are also deleted, but it does not mention irreversibility, permission requirements, or what happens if the watch id is invalid.

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?

A single, front-loaded sentence with no wasted words. The destructive scope is stated immediately.

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 simple one-parameter delete tool, the description covers the core action and cascade effect. However, without annotations it should ideally disclose irreversibility or error behavior to be fully complete.

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?

There is only one parameter, and schema coverage is 100%, so the schema already documents "id" as the watch id. The description adds no parameter-level detail, which is acceptable given the schema's completeness.

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 ("Delete") and resource ("a watch"), and clarifies scope with "and its stored snapshots." This makes it immediately distinguishable from sibling watch tools such as watch_create, watch_list, and watch_check.

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 no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no warning about irreversibility. Usage is only implied by the verb "Delete."

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 are provided, so the description carries the full behavioral burden. It does usefully disclose the return format ('unified diff') and that only the most recent change is returned, but says nothing about behavior when no change has been detected, whether the watch id must exist, or whether the diff is repeatable or consumed on read.

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 sentences, front-loaded with what it returns, followed by the trigger condition. No filler or redundancy.

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?

A simple one-parameter read tool with no output schema, and the description sufficiently covers what comes back (a unified diff of the latest change) and when to call it. Minor omissions: no-change behavior and watch-existence prerequisites.

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% and the single parameter is documented as 'Watch id'. The description's phrase 'for a watch' only loosely ties the id to a watch; it adds no filtering semantics or format detail beyond the schema, so baseline 3 applies.

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 ('Get the unified diff') scoped to 'the most recent detected change for a watch', which implicitly separates it from the broader watch_history sibling. It does not name that sibling explicitly, so the distinction relies on inference.

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 concrete trigger — 'Use after watch_check reports changed=true' — naming the sibling whose output selects this tool, plus a second valid use case ('report what changed since you last looked'). No explicit when-not-to-use guidance (e.g., older changes via watch_history).

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 are provided, so the description carries the full burden. It discloses the shape of the returned timeline, which is genuinely useful, but never states that this is a read-only operation, how far back history is retained, or whether history is trimmed by retention policies — meaningful gaps for a history 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 sentences, zero waste: the return payload is front-loaded and the usage hint follows. Nothing repeats the name or title.

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 usefully enumerates the returned fields, so an agent knows what it will get back. The remaining gap is behavioral rather than structural: retention scope and read-only nature are unstated for a tool with no annotations to cover them.

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 both `id` and `limit` (with its default of 20) are already documented in the schema. The description adds no meaning beyond that — no ordering direction, no pagination cursor behavior, no note on which snapshots count as 'changes'.

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 ('List a watch's snapshot timeline') and enumerates the returned fields (timestamps, content hashes, HTTP status, change flags), which clearly distinguishes it from mutation siblings watch_create/watch_delete. It does not explicitly name watch_diff or watch_check as alternatives, so an agent must infer the boundary from the field 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?

'Use to see how often a page actually changes' gives an implied usage context, but there is no explicit when-to-use versus watch_diff (compare snapshots) or watch_check (trigger a check now). Exclusions and prerequisites are absent, leaving routing between the four watch_* siblings to 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?

No annotations are provided, so the description carries the burden; it does disclose that this is a read/list returning URL, selector, interval, last check time, check count and change count. It says nothing about ordering, result caps, or whether the list is scoped to a user, which matters for an unbounded listing operation.

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 sentence, front-loaded with the verb and resource, with the field list trailing. No waste and nothing an agent must read 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 input parameters and no output schema, the description usefully enumerates what comes back, which is exactly the gap. Missing only secondary operational detail such as ordering or caps on how many watches are returned.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline applies. The enumeration of return fields is a small bonus rather than parameter 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?

Specific verb ('List') plus resource ('all watches') plus an enumeration of the returned fields, so the agent immediately knows this is the enumerating read for the watch resource. It does not, however, distinguish itself from siblings like watch_history or watch_check, which the agent must infer are per-watch rather than global.

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?

No statement of when to use this versus watch_history, watch_check, or the other watch_* siblings. The 'all' implicitly signals the unfiltered enumeration, but there are no exclusions, prerequisites, or alternative routing given.

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