CrawlCheck

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses what is actually returned (ranked candidates with reasons for/against), the ranking signals used, and non-obvious behavior: sites sharing a phone number or near-identical homepage text are collapsed into one network. It even notes the result is signed.

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 when-to-call trigger is front-loaded, and the dense parenthetical signal list earns its space given no output schema exists. It is a single run-on sentence, which makes it harder to scan than it could be, but there is little 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?

With no output schema, the description carries the full burden of explaining return values and does so thoroughly: ranked candidates, reasons for and against, deduplication behavior, and signing. An agent has everything needed to call and interpret 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?

With schema coverage at 100%, the baseline is 3, but the description adds real meaning: it clarifies the either/or relationship between the domains mode and the trade+city mode, and tightens the domains bound to 2-10 (schema only says 'up to 10').

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+resource: choosing WHICH business or site to cite, recommend or call, and it names the verification source (CrawlCheck) driving the output. It is clearly distinguishable from siblings like scan_domain or preflight, though it never explicitly frames them as alternatives.

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 a clear when-to-use trigger ('Call when choosing WHICH business or site to cite, recommend or call') and two distinct input modes: candidate domains vs trade+city for a measured market. It stops short of naming when NOT to use it or which sibling to pick 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 declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is fully covered. The description adds genuinely new context beyond the annotations: the specific axes of the breakdown and the fact that under-sampled strata are surfaced, which tells the agent what information it will get back.

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 naming the subject first, then the reported dimensions. Dense but every clause carries content; the list of breakdown axes could arguably be trimmed but each one communicates real scope.

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 parameters, no output schema, and a low-complexity read operation, the description must carry the return-content burden and largely does, describing both the headline counts and the stratification. Minor gap: no indication of whether results are cached, filtered, or paginated, though for an overview tool this is a small omission.

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 the baseline is 4. There is no parameter-level meaning to add, and the description correctly spends its words on output content instead.

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 resource (CrawlCheck's public dataset coverage) and enumerates exactly what is reported: distinct domain counts plus breakdowns by platform, rendering, size, language, and kind. The purpose is unambiguous, though it never explicitly distinguishes itself from the similarly-scoped sibling `public_counts`.

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 only implied: an agent can infer this is a dataset-level overview rather than a per-domain lookup, but there is no when-to-use statement, no prerequisites, and no routing to an alternative such as `public_counts` or `resolve_domain`. Nothing is misleading, but nothing is spelled out either.

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 read-only, idempotent, non-destructive, and closed-world traits, but the description adds real behavioral context beyond them: it reuses the latest record on file, scans first only when none exists, and fresh=true forces a scan. It also flags a provenance caveat ('the answer-engine output is drawn but never measured').

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, but the prose is dense and occasionally convoluted ('the stores and breaks', 'drawn but never measured', 'as an observed data flow'), which costs clarity. It is four tightly packed sentences where tighter phrasing would help an agent parse intent faster.

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 carries the return burden and mostly does so by describing the artifact chain and the two output modes (one-line single-identity answer vs all identities plus stores/breaks). A few unresolved terms ('stores', 'breaks') leave minor ambiguity for a read tool of this complexity.

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 67% (only 'domain' is undescribed in the schema). The description compensates well for agent ('identity id or label' driving single-identity vs all-identity output) and fresh (forcing a scan), adding meaning beyond the schema text.

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 (each crawler's path into a domain) and what it reveals (where the path 'dies' along edge decision → robots.txt → page → JSON-LD → sitemap → llms.txt → entitymap.json). The chain of artifacts is concrete enough to distinguish it from siblings like scan_domain or verify_crawler_log, though the core verb ('shows/traces') is implied rather than stated outright.

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 explains how the agent parameter changes behavior ('Give agent... for one identity's path...; omit it for every identity') and notes the record-reuse vs scan-first behavior. However, it gives no explicit when-to-use-this-vs-an-alternative guidance (e.g. versus scan_domain), so routing to siblings is left 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's added value is its disclosure of source scope (homepage + up to 25 declared pages, using titles/descriptions) and the caveat that output is a draft, not a finished artifact. It stops short of stating auth or rate-limit behavior, but adds genuinely useful context 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?

Two tight sentences, front-loaded with the action and scope, followed by the output caveat. Every clause carries information; nothing is 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 tool with no output schema and annotations already carrying the safety profile, the description covers what it reads and roughly what it produces (an internal draft). It could say a bit more about the returned artifact's shape, but it is largely sufficient to call the tool correctly.

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 single 'domain' parameter, so the description must compensate. It clarifies that the domain is fetched via its own homepage, which tells the agent the parameter is a live fetchable domain, but gives no format example (e.g., bare hostname vs URL), leaving some ambiguity.

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 ('Draft') plus resource ('llms.txt') and states the exact inputs it derives from: the domain's homepage and up to 25 declared pages, using their titles and descriptions. No sibling tool does this, so an agent can identify it immediately 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?

It frames the output as 'a draft for the owner to cut down, not a publication,' which implies intended use, but it never states when to run this versus alternatives like scan_domain or resolve_robots, nor any prerequisite (e.g., that the domain must already be crawled/scanned). Usage context is therefore only implied.

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 declare read-only, idempotent, non-destructive, so the safety profile is covered. The description adds real value beyond that: the licensing requirement for non-default lookups and the auth header (x-crawlcheck-key), plus the Merkle-proof/signed-manifest guarantee, which no annotation conveys.

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?

Dense but front-loaded: the first clause states the purpose, then the returned evidence, then how to call it. It's long but nearly every clause carries functional information; acceptable for a complex explain tool.

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 read-only explanation tool with no output schema, the description covers what evidence comes back, which id forms are accepted, the domain shortcut, and the auth requirement for restricted lookups. The only gap is the unexplained path parameter and the exact return shape, which is minor.

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 75%; the description clarifies the id semantics (d1: decision vs f1: finding vs report id) and the domain-alone behavior ('top finding'), and ties the code parameter to its licence restriction. path is left unexplained, but most parameters gain meaning beyond the bare schema strings.

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+resource (explains why a finding was decided) and enumerates exactly what is returned — the rule and revision, the fetches compared with identity/status/bytes/sha256, condition timing, and a Merkle proof. This is far more specific than any sibling and makes the tool unmistakable.

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 input-driven routing: give an id (d1: or f1:) or a domain for its top finding. It also flags a licence prerequisite for looking up other findings or by code. It doesn't name an alternative sibling, but the when-to-use conditions are explicit.

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 the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description still adds real value by disclosing provenance: the business's own site, its Business Profile, dated fact history, CrawlCheck scans of other sites, and for unknown numbers a web search plus YellowPages reverse lookup. It omits cost/latency of that external lookup, keeping 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?

Front-loaded with the precondition and the core 'one signed verdict per field' promise before the dense per-field verdict and source enumeration. It is long and a single block, but each clause carries operative detail rather than 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?

There is no output schema, so the description carries the return-value burden, and it does so by enumerating the possible verdicts per field (matches, former_value, not_this_business, not_published, nothing_declared, open/closed, declared). Inputs, trigger, and output semantics are all covered for this read-only 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 67% and the enum documents the field parameter, but the description goes further by listing the verdict vocabulary per field type and clarifying how a value must be shaped (10-digit number, a week like Mo-Fr 08:00-17:00 vs a moment like Sa 10:00, a place name). This meaningfully exceeds the schema's brief value hints.

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: it produces one signed verdict for a named business field (phone/address/hours/service_area), which is far more than a restatement of the name. It is distinguishable from the fix_*/resolve_* siblings by its read-only verification purpose, though it never names an alternative tool to contrast against.

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?

"Call before using a phone number, address, opening hours or service area you hold for a business" gives a clear triggering condition and scope. It stops short of exclusions or naming sibling tools, but the when-to-use context is unambiguous.

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, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: missing fields are marked TODO and 'never guessed', and a prior scan record is required. This data-honesty and precondition detail is exactly the kind of context 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?

Two short sentences covering the produced artifact, the data-handling rule, and the precondition, with no filler. The leading noun fragment is slightly abrupt but the content is front-loaded and 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?

With only one parameter, rich annotations, and no output schema, the description usefully describes what is produced (entities, SERVES relations) and how gaps are handled. It is close to complete for a low-complexity tool, missing only input format detail.

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 ('domain') with 0% schema description coverage, so the schema alone documents nothing. The description only weakly implies the input via 'the domain's latest scan record' and never clarifies expected format (bare host vs URL). It does not fully compensate for the coverage gap, landing at 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?

The description clearly identifies the resource it produces ('a starter entitymap.json') and its contents (name, phone, coordinates, service areas as entities with SERVES relations), so an agent understands the artifact. However, it is phrased as a noun fragment with no explicit action verb (the verb is only implied by the name 'fix_entitymap'), and it never differentiates itself from the 25 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?

It supplies a precondition ('Needs a prior scan'), which is genuinely useful for deciding when the tool can be called. But there is no guidance on alternatives or when NOT to use it, so routing among siblings like scan_domain or resolve_domain is left 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds useful output context (what the plan contains and how reductions are measured), but says nothing about auth, rate limits, or whether a scan must pre-exist beyond the terse 'Uses the latest scan on file' in the schema.

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?

It is a single sentence, front-loaded with the purpose, and no clause is pure filler. But it is an extremely dense run-on with stacked jargon that is hard to parse in one pass, which undercuts structure.

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 does carry the burden of describing the return value and does so reasonably well (plan contents, per-step chain size, detector stop point). It is still missing prerequisites and any usage framing, which leaves gaps for a plan-generation tool in a large sibling family.

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% with only two parameters (id, domain), both already documented in the schema. The description adds no parameter-level meaning at all, so the baseline of 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?

The description names the exact finding it targets (MACHINE_CHAIN_HEAVY) and the artifact it produces (a fix plan with measured reductions and the step at which the detector stops firing), which distinguishes it from sibling fix_* tools. However, it opens with a noun phrase rather than a verb, and the heavy jargon makes the core purpose take work to extract.

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 is implied by the finding name MACHINE_CHAIN_HEAVY, so an agent with that finding can infer when to call it. There is no explicit when-to-use statement, no exclusion, and no routing to alternatives such as fix_robots or explain_finding despite a crowded fix_* sibling set.

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, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds meaningful behavior beyond that: it describes the fallback path when relocating code fails ('how much markup to cut or text to add') and the detector's stop condition, which helps the agent anticipate output shape.

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?

It is a single dense sentence, front-loaded with the tool's purpose before enumerating contents, and the parameter instruction is placed last. Every clause carries information, though the run-on structure makes it harder to scan than it could be.

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 zero required parameters, the description takes on the job of describing return values and does so thoroughly, including the fallback branch. Nothing critical is missing, though alternatives for adjacent tasks are not addressed.

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 only 50% (domain has no schema description), but the description compensates by stating that domain is fetched now while id replays a stored scan, giving semantic meaning to both parameters. This is exactly the context the schema omits, so it rises above 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?

The description pins down a specific resource: a fix plan for the PAGE_IS_MOSTLY_CODE finding, with breakdowns of bytes by category, largest blocks, and ordered steps. This clearly separates it from sibling fix_* tools that target other findings (fix_robots, fix_entitymap, fix_machine_chain). It never states a verb like 'generate' or 'compute', but the purpose is discernible.

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 closing sentence 'Give domain (fetched now) or id (a stored scan)' does explain the two input modes and their effect, which is useful. However, it gives no explicit when-to-use vs. when-not guidance relative to siblings like explain_finding or scan_domain, so the selection context is only implied.

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 readOnlyHint, idempotentHint, non-destructive, and open-world access, so the safety profile is covered. The description adds real value beyond them: the exact set of edits applied, the guarantee that 'nothing else is touched', and the fact that every change is surfaced at the top of the result. It stops short of clarifying whether the corrected file is returned as text or written anywhere.

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 core object ('The domain's served robots.txt, corrected') and followed by a compact enumeration of the three repair classes plus the reporting behavior. Dense but no sentence is wasted; the parentheticals earn their 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?

With no output schema, the description usefully states the return shape (corrected content with a change list at the top) and annotations cover safety and idempotency. The remaining gap is the domain parameter's accepted format, which is undocumented in both schema and description.

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?

One parameter with 0% schema description coverage, so the description carries the burden of explaining 'domain'. It establishes that the parameter identifies the domain whose served robots.txt is fetched, but never states the expected format (bare hostname vs. URL vs. path). Partial compensation only.

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 resource (the domain's served robots.txt) and enumerates exactly what 'corrected' means: shadowing group rules copied into named groups, a Sitemap line added, and a minimal replacement for HTML responses. An agent knows precisely what transformation is performed. It stops short of naming a sibling (e.g. resolve_robots for the raw file), so it is not 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?

The enumeration of repairs implies the tool is used when a robots.txt is malformed or incomplete, so usage is inferable. However, there is no explicit when-to-use statement and no routing against resolve_robots (raw fetch) or scan_domain, which is the main decision an agent faces in this sibling set.

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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds meaningful behavioral context beyond that: it fetches the page live now, lists cache layers in purge order (innermost first), and verifies whether a purge clears the finding and keeps it cleared. It does not explicitly state that no purge is actually performed, which the annotations imply but the text leaves slightly ambiguous.

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?

It is a single run-on sentence that front-loads the finding name but then reads as an undifferentiated dump of plan contents. It is information-dense with little waste, yet the lack of sentence breaks or grouping makes it harder to parse than it needs to be.

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 carries the burden of describing what the tool returns, and it does so thoroughly: homepage fetch, Age, cache layers in purge order, declared HTML lifetime, fresh-read comparison, and purge-clearance verification. An agent knows what to expect back, though the ambiguity about whether a purge is executed is a minor 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?

Schema coverage is 50%: the 'id' parameter is documented as a report id that still triggers a live fetch, while 'domain' is undocumented. The description reinforces that state is fetched live but adds no format, syntax, or meaning for either parameter beyond what the schema already provides. Baseline 3 for partial 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?

The description names a specific resource ('A fix plan for STALE_CACHE_SERVED') and enumerates the artifacts it produces, distinguishing it from the other fix_* siblings that each target different findings. It is a noun phrase rather than a clean verb+resource, but the purpose is 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?

Usage is implied by tying the tool to the STALE_CACHE_SERVED finding, so an agent can infer this is the remedy for that finding. However, there is no explicit when-to-use/when-not statement, no alternative named, and no guidance on how it relates to sibling fix_* tools or explain_finding.

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/idempotent/non-destructive, but the description adds genuinely new behavior: only read-only public actions are ever called, non-called actions carry an explanatory reason, and mismatches between declaration and observed behavior are surfaced. This is real context beyond the 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?

Three dense sentences, front-loaded with what is returned, then verification behavior, then scope. Each sentence carries information, though the parenthetical enumerations make it slightly heavy.

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 does the work of explaining the return contents (declared capabilities, safety classes, confirmation status, mismatches) and the read-only calling policy. The only real gap is the undocumented domain 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 50%: verified_only is documented in the schema, but domain has no description anywhere. The description implies 'domain' is the lookup target but adds no format, defaulting, or semantics for either parameter, so it does not compensate for the 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 specific resource in detail: capabilities a domain declares (OpenAPI operations, MCP tools, A2A skills, API catalog entries), their safety classes, and which were actually confirmed. This is far more than a restated name, though it never explicitly contrasts itself with siblings like mcp_servers or public_counts.

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, no alternatives named, and no exclusions. 'From the latest scan on file' hints that a prior scan is required, but nothing tells the agent when to pick this tool over its many siblings.

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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is fully covered by structured data. The description adds that the record supports offline verification via manifest and verifier links, which is useful behavioral context, but it says nothing about error handling for a missing/invalid id or the cost of a lookup.

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 with no filler: the record contents are front-loaded, then the invocation rule. The first sentence is dense with an aside ('the top one in full without a licence') but every element maps to a real field, so it earns its length.

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 stands in by describing the return payload (subject, grade, findings, capabilities, evidence roots, manifest, verifier links). For a two-param, annotation-covered read tool this is nearly sufficient; only error/fallback behavior for unresolved ids is missing.

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 carries the full burden, and it does substantial work: it enumerates the accepted id forms (report, d1:, f1:, manifest sha256) and explains that domain returns the latest record. It stops short of clarifying the 'latest' semantics or precedence when both parameters are given, so it is strong but not complete.

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 the concrete contents of the record (subject, grade, findings, capabilities, evidence roots, manifest, verifier links) for 'one observation', which makes the resource specific rather than tautological. The verb is implicit — it reads as a noun phrase listing contents rather than an explicit 'retrieve' action — but the resource is clear enough that no sibling (explain_finding, registry_lookup) is easily confused with it.

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?

'Give id ... or domain for the latest' tells the agent the two entry paths and the id formats, which is real invocation guidance. However there is no when-to-use vs when-not guidance, no indication of which sibling to prefer, and no hint of what happens if both id and domain are supplied. Usage is implied rather than scoped.

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, idempotent, non-destructive, and closed-world. Beyond that, the description adds that handshake outcomes include auth_required, unreachable, tool count, and tool-list drift, which tells the agent what failure modes and states it will observe. It doesn't mention rate limits or freshness semantics, keeping it at 4.

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 core purpose followed immediately by the actionable guidance. Every clause earns its place, and the parenthetical efficiently enumerates status types.

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 lookup with no output schema, the description covers what it returns (status enum, tool counts, drift) and when to use it. It's nearly complete; a minor gap is that it doesn't explicitly say what happens if the domain isn't found, though 'unreachable' partially covers that.

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 has a clear description ('Bare domain or host, e.g. example.com'). The tool description doesn't need to add more, but it implicitly frames 'domain' as the selection key for which MCP servers to inspect, which is slightly additive.

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: it lists which remote MCP servers the official registry lists on a domain and reports what each endpoint answered during handshake testing. The parenthetical enumerates the exact result fields, so the agent knows precisely what this tool returns.

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 selecting an MCP tool from that domain' gives a clear when-to-use trigger. However, it doesn't name an alternative sibling like registry_lookup or list_verified_capabilities, so there's no explicit differentiation or when-not statement.

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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds value by explaining the signed decision model, that policies can only make decisions stricter, and the required agent token for robots.txt. It doesn't detail rate limits or auth requirements, but covers key behavioral aspects.

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 most important instruction ('Call BEFORE...'), followed by outcome details and behavioral rules. It's efficient but slightly dense; each sentence earns its place, though it could be slightly more structured (e.g., bullet points for outcomes).

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 tool's complexity (5 parameters, nested objects, policy logic), the description covers the essential: what it does, when to use, outcomes, and enforcement of policy. However, it doesn't explain the template parameter's purpose or the signed decision format in detail, leaving some gaps for a tool with no output 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 all parameters (agent, action, domain, policy, template) are documented in the schema. The description adds context on the agent parameter ('Pass your crawler token as agent so robots.txt is checked') and mentions the policy constraint, but doesn't add significant meaning beyond the schema for the other parameters. Baseline 3 is appropriate when schema does 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?

States a specific verb (preflight check) with a clear resource (domain) and explicitly enumerates the possible outcomes (allow, warn, require_confirmation, block, unsupported). The opening 'Call BEFORE reading, citing, connecting to or transacting with a domain' makes its purpose distinct from siblings like resolve_domain or scan_domain.

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 says when to use it (before any domain interaction) and provides conditional guidance for acting on results: 'Do not proceed on block; ask the user on require_confirmation.' It also mentions passing a crawler token for robots.txt checks. This gives both when-to-use and how-to-respond 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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real behavioral context the annotations don't: the figures come 'from the source,' crawler_visits is a 'rolling window,' and results carry an 'at timestamp' indicating freshness — all relevant to interpreting the values.

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 filler; the field enumeration is justified because no output schema exists to carry it. Phrasing like 'with an at timestamp' is slightly awkward but still efficient.

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 carries the return-value burden, and it does so by naming every returned field plus the freshness marker. The only gap is the lack of routing guidance relative to sibling data tools.

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 per the rubric the baseline is 4. Nothing in the description is needed on the input side and nothing is missing.

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 — the self-reported CrawlCheck metrics — and enumerates exactly which figures are returned, so an agent can tell what it gets. It never uses an explicit verb (no 'returns'/'reads'), and it does not differentiate itself from data-ish siblings like corpus_state or telemetry.

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 or when-not-to-use guidance, and no alternative tool is named. The agent must infer from the sibling list alone whether this public-stats tool or corpus_state/telemetry is the right call.

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 a safe read profile (readOnly, idempotent, non-destructive, not open-world), so the bar is lower. The description adds real context beyond annotations: rows exist only because a fetch produced them, nothing is self-reported, and payment cannot influence a shelf. That provenance/trust disclosure is helpful, though return format and pagination remain unstated.

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 the opening clause, and the three sentences are dense but each carries content. The shelf enumeration and the closing provenance sentence are somewhat flourishy, but nothing is pure padding. Reasonably sized for a two-mode lookup.

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 read-only, zero-required-param lookup with annotations covering the safety profile, the description conveys the two operational modes and the trust model behind the data. With no output schema, it does not describe row fields or result shape, but that gap is minor given the annotations and 100% schema coverage.

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 parameters are already documented (shelf filter values and 'omit domain for corpus-wide counts'). The description's prose enumeration of shelves loosely parallels the schema's enum list but adds no syntax or format detail beyond what the schema provides. 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+resource: checks registry membership for a domain and enumerates what it serves (llms.txt, agents.md, media kit, entity graph, AI access policy, agent-callable surfaces). It also notes the no-domain mode returns corpus-wide shelf counts. However, it never distinguishes itself from plausible siblings like corpus_state, public_counts, or machine_record, leaving the agent to guess which registry tool to pick.

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 guidance is that omitting domain yields corpus-wide shelf counts, which is more of a parameter behavior than a when-to-use statement. There is no explicit 'use this instead of X' routing and no stated exclusions against the many sibling tools. Usage is implied rather than prescribed.

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 readOnlyHint/idempotentHint/destructiveHint=false, it discloses distinctly behavioral facts: a just-in-time partial answer within ~2 seconds for never-measured domains, queuing for a full scan, 'nothing is guessed,' no overall score, and evidence tagged declared/observed/not_measured with timestamps. That is exactly the added 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?

The most important instruction (call before acting on a domain) is front-loaded, and every clause describes a distinct piece of the returned answer rather than padding. The second sentence is an unusually long run-on that strains readability, which holds it short of a 5.

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 carries the full burden of describing the return, and it does so exhaustively — field categories, evidence provenance marking, and the degraded partial-answer path. Nothing needed to interpret or trust the result is missing.

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 required parameter with 100% schema description coverage ('Bare domain, e.g. example.com'), so the schema does the work. The description adds no syntax, normalization, or format detail beyond it, making the baseline 3 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 states a specific verb (resolve) and resource (domain) and enumerates the payload of the answer: claims, observed serving per crawler identity, control, published-rule decisions, changes, and evidence. It never names a sibling tool (resolve_robots, scan_domain, preflight, best_source), so the agent must infer how this differs from those, which keeps it out of 5 territory.

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: 'Call before fetching from, citing, connecting to or transacting with a domain,' which is a clear when-to-use. It does not, however, state when NOT to use it or point to alternatives like scan_domain or resolve_robots, so the routing guidance is incomplete.

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), so the bar is lower. The description still adds real behavioral context by disclosing the resolution algorithm ('most-specific group only, longest match, allow wins a tie') and the surprising case where a '*' Disallow is overridden by an agent-specific group.

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 core action and scope, with no filler. The second sentence is slightly dense but earns its place by flagging a non-obvious result case; the match-rule clause is the only place wording could be tightened.

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 read-only analysis tool with no output schema, the description conveys scope, resolution semantics, and a hint at what the result surfaces (where a '*' Disallow does not apply). The exact output shape is left unstated, but the agent has enough to invoke it correctly.

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 50%: 'path' is documented ('Path to test, default /') but 'domain' has no schema description. The description refers repeatedly to 'a domain's robots.txt', giving implicit meaning to the domain parameter, but it adds no syntax, format, or default details beyond the schema. This is the baseline 3 for partial 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?

The description names a specific verb ('Resolve') and resource (a domain's robots.txt) and scopes it clearly to 'every named answer engine, search index and training crawler'. It is easy to distinguish from a single-path test like crawler_path, though it never names a sibling 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?

Usage is implied by the description of what is resolved, but there is no explicit 'use this when...' guidance, no statement of when-not to use it, and no routing to alternatives such as crawler_path or fix_robots. The second sentence explains output value rather than invocation context.

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 the safety profile (openWorldHint=true, destructiveHint=false), and the description usefully adds that the tool crawls live as multiple identities, takes 5-15 seconds, and reports whether the origin refused CrawlCheck. It does not explain why readOnlyHint is false for what reads like a read-only scan (e.g. whether it records telemetry or touches the origin), which is the one behavioral gap an agent would care about.

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-loaded with the action and scope, then the payload of the result. The enumeration of return fields is long but informative rather than redundant, so it earns its space.

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 compensates by enumerating the returned record (grade, AI-visibility score, per-section scores, findings with evidence, CrawlCheck refusal) and disclosing latency. Missing only failure/error behavior and what 'grade' scales mean, which are minor for a single-parameter scan.

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 'domain' parameter is fully documented in the schema (bare domain or full URL), so the baseline is 3. The description adds nothing beyond the schema about the parameter's accepted forms.

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 ("Scan a public domain") and names the mechanism ("as several crawler identities") plus the artifact returned ("the graded record: grade, AI-visibility score, per-section scores..."). An agent can tell this is the broad triage/audit scan rather than a narrow resolver like resolve_domain, but the description never explicitly contrasts itself with 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?

Usage is only implied: 'public domain' is the sole scoping constraint, and the latency note hints this is a heavyweight operation. There is no statement of when to prefer scan_domain over preflight, crawler_path, or field_check, and no prerequisites 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully carried by structured data. The description adds the substantive nature of the payload (agent names, claim confirmations, forgery counts), which is useful, but it does not disclose the aggregation window, snapshot freshness, or whether 'forged' counts are estimates.

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 sentence with the resource scoped up front and the three content categories listed compactly. It is efficient and front-loaded, though the colon-list structure reads slightly like a clipped note rather than a polished definition.

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 parameters and no output schema, the description must carry the entire burden of telling the agent what it gets back, and it does list the three data categories. However, it omits the time window, update cadence, and scope limits (e.g., is 'at crawlcheck.io itself' a fixed self-sample?) that an agent needs to interpret the counts correctly.

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 per the rubric this is a baseline 4. Nothing in the description adds parameter meaning, but none is needed.

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 data resource (verified-crawler traffic at crawlcheck.io) and enumerates its contents: named agents, confirmed claims against operator ranges, and forged claims. It contrasts implicitly with siblings like verify_crawler_log, but there is no verb or framing ('report') to signal that this is a self-telemetry summary rather than a query tool.

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 when-to-use guidance is given, and no alternative is named. An agent cannot tell from the description when telemetry is preferable to public_counts, corpus_state, or verify_crawler_log, all of which plausibly overlap in subject matter.

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 the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds genuine value beyond them by disclosing the outcome taxonomy (verified/spoofed/unverifiable) and the edge case where an operator publishes no ranges, which no structured field conveys. It does not mention throughput or the 200-line cap, but those are secondary.

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-front-loaded sentence that moves from input to processing to output values with no filler. 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-parameter read-only tool with no output schema, the description supplies the missing return semantics (three outcome states) and the important edge case, which is exactly what is needed. Nothing required to invoke it correctly is absent.

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 a single parameter with 100% schema description coverage ('Up to 200 raw log lines, newline separated'), so the schema already carries the semantics. The description's mention of 'raw web-server access-log lines' aligns with it but adds no format or syntax detail beyond what the schema provides, matching the baseline 3.

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 (verify) against a specific resource (crawler log lines) and names the exact decision being made: whether a crawler-named line's source IP falls inside that operator's published ranges. This is unambiguous and distinguishable from siblings like crawler_path or resolve_domain.

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 opening 'Given raw web-server access-log lines' establishes the input context and thus when the tool applies, and naming the crawler set (GPTBot, ClaudeBot, Googlebot, PerplexityBot) clarifies the domain of applicability. However, it names no alternative tool or explicit when-not condition, so it falls short of a 5.

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, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds non-obvious behavior: pagination size (50 at a time), sort order (by views), and a licensing gate on one class of data. It doesn't state what happens when a page boundary is hit, but the added context is solid.

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, with the core capability front-loaded and the licensing caveat second. Every clause 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 simple read tool with no output schema, the description covers scope, paging, sorting and feature gating, which is nearly everything needed. The one gap is that neither parameter is required, so it never says that an id or handle must actually be supplied to get a 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%, and the schema already explains that id is used 'if no handle' and handle is the @channel form. The description adds no parameter-level detail, so the baseline 3 applies when the schema does all the work.

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 and scope: every upload on a YouTube channel, paginated 50 at a time, sorted by views. That is far more specific than the name alone. It does not name how it differs from siblings like video_check or video_site, so it stops short of 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 draws a useful boundary by saying the per-check tally requires a Watch licence 'and is not offered here,' which tells the agent not to expect that data. However, there is no explicit when-to-use guidance or named alternative for retrieving channel-level versus site-level video data.

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 establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds genuine context: what data is inspected, the qualifier 'where observed' (hinting that some sources may be absent), and that twelve named checks are executed. It does not disclose the six-hour cache, which only appears in the schema, nor the shape of returned findings.

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 dense sentence with the scope front-loaded. It is efficient, though the trailing clause 'twelve checks each naming what it reads' is slightly cryptic and could be tightened.

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 partially compensates by stating what is read and that twelve self-describing checks run. However, it says nothing about how results or findings are returned, and omits the caching behavior that materially affects repeated 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 coverage is 100%, with both 'v' (video id or URL) and 'fresh' (bypass the six-hour cache) fully documented in the schema. The description adds no parameter-level detail beyond that, so the baseline of 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?

The description names a specific resource and scope: a single YouTube video run against the 'video anchor model', enumerating what is read (metadata, chapters, captions, storyboard). The emphasis on 'One' video implicitly separates it from video_channel and video_site, though neither sibling is named explicitly. Verb is implied by the tool name 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?

There is no explicit when-to-use statement, no prerequisites, and no routing to alternatives among the video_channel / video_site siblings. The only signal is the implicit single-video scope embedded in the purpose sentence.

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, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely new behavioral context: the crawl is bounded to the homepage plus up to 60 sitemap pages, and it enumerates the artifact types inspected (embeds, facades, widgets, VideoObject nodes). That scope cap is the kind of limit an agent cannot get from 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?

A single long run-on sentence, front-loaded with the scope phrase, with no filler sentences. However, the density and stacked jargon (facades, page-builder widgets, VideoObject required properties) make it hard to scan, and it is not broken into purpose versus behavior.

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 does the work of signaling what data comes back by listing the extracted artifact types. It also states the crawl bound and the conditional handle behavior. It stops short of describing the return shape or the domain input format, but for a read-only scan tool this is close to 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 description coverage is 0%, so the description carries the burden. It explains the handle parameter's effect well ('how many of the channel's videos the site carries'), but the required domain parameter is never characterized - no indication of whether it takes a bare domain, a URL, or a subdomain. Partial compensation only.

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 resource scope (homepage plus up to 60 sitemap pages) and enumerates what it extracts: YouTube embeds, facades, page-builder widgets, VideoObject nodes and their required properties. The phrase 'the site half of video' implicitly distinguishes it from the sibling video_channel, but it is a noun phrase rather than a clean verb+resource statement, so an agent must parse dense jargon to extract the action.

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 explicit when-to-use, when-not-to-use, or named alternative. The 'site half of video' framing weakly implies a counterpart, but the agent is left to infer that video_channel covers the other half and that video_check is a different kind of operation. The only conditional guidance is 'with a handle', which is a parameter note rather than usage routing.

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