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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description goes well beyond by disclosing cost limits (25 calls/day, shared quota, reset time), a paid fallback route, and the exact output shape including proof/attestation fields. This adds real decision-making 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?

Structured with WHAT/WHEN/WHEN NOT/COST/OUTPUT, front-loaded with the core purpose. Every sentence adds distinct information (cost, quota, typosquat, output). No fluff or redundancy, despite 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?

Tool complexity is moderate due to rate limits, paid route, and typosquat behavior. The description covers all of these, gives the full output shape (also in output schema), and includes cost details. Combined with strong annotations, the description is complete for selecting and invoking this 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% for both parameters (name and ecosystem) with examples. The description reinforces these but adds little new syntactic detail—its main additions (typosquat_adjacent, cost) relate to output and usage rather than parameter semantics. Baseline 3 applies since schema carries the load.

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 opens with a clear WHAT: 'checks whether a package name really exists in PyPI or npm.' This is a specific verb+resource (packages in public registries) and inherently distinguishes from sibling tools like attester_symbol_exists. It adds the typosquat behavior, further clarifying its unique role.

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

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

Explicit WHEN: 'before installing or importing a package a model suggested' with supporting evidence (5-20% hallucination rates). Explicit WHEN NOT: 'for private packages outside the public registries.' This gives the agent clear conditions for use and exclusion.

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

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

Beyond the readOnly/idempotent annotations, the description discloses the static analysis ceiling (cannot detect runtime-created symbols), free-tier rate limits (25 calls/day shared across attester_* tools), quota fallback to a paid route, and a detailed output structure including proof/attestation fields. This adds substantial behavioral context.

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 uses labeled sections (WHAT/WHEN/WHEN NOT/COST/OUTPUT) to pack information into a scannable format. Every sentence carries distinct information—no filler—making the length justified.

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 lookup tool with a full output schema, the description covers purpose, usage, limitations, cost, and output fields. It is self-contained and leaves no major questions about how to invoke or interpret 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 covers 100% of parameters with descriptions. The tool description adds that 'symbol' refers to functions, classes, and constants and reinforces the 'latest indexed version' default for the version parameter, slightly enriching the schema. Baseline 3 plus one for the semantic clarification.

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 opens with 'WHAT: checks whether a symbol (function, class, constant) exists in a package at the latest indexed version' — a specific verb and resource with clear scope. It also mentions closest-match suggestions, distinguishing it from sibling tools like package_exists and symbol_signature.

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 provides 'WHEN' (before calling an API you are not sure exists) and 'WHEN NOT' (dynamically created symbols), offering clear usage guidance. However, it does not name alternative tools directly, so it stops short of a full 5 on the alternatives criterion.

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, openWorldHint, idempotentHint, and destructiveHint, but the description adds valuable context: free shared quota (25 calls/day per client IP, reset 00:00 UTC), over-quota behavior pointing to paid route, and clarification of 'signature' vs 'attestation_signature'. No contradictions with annotations.

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

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

The description is well-structured with labeled sections (WHAT, WHEN, WHEN NOT, COST, OUTPUT, Note) and front-loaded with the purpose. Every sentence adds relevant information, and the output field list is clearly separated.

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?

Despite having an output schema, the description explains key output fields and the critical distinction between 'signature' and 'attestation_signature'. It also includes cost, quota, and sibling-tool distinctions, making it complete for selection and invocation.

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

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

Schema description coverage is 100%, so each parameter is documented in the schema itself. The description adds slight context (e.g., 'resolved at a pinned version') but not enough to push beyond the baseline for full schemas.

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

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

The description clearly states the tool returns 'the exact signature, structured params, docstring summary, and deprecation status for one symbol' with version resolution, which is specific and distinguishes it from sibling tools like attester_symbol_exists or attester_version_diff.

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 explicit WHEN guidance ('before writing a call against an API you have not used at this version') and WHEN NOT ('PyPI type annotations are unavailable'), as well as cost/alternative routing. This fully addresses when to use this tool versus others.

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

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

Beyond the annotations (read-only, open-world, idempotent), the description discloses important behavioral traits: rate limits (25 calls/day per client IP), quota reset time, behavior when over quota (redirects to paid route), error behavior for unresolvable versions (422 error, never partial diff), and the signed attestation output. This adds significant context beyond what annotations provide.

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 uses clear section labels (WHAT, WHEN, WHEN NOT, COST, OUTPUT) to front-load the core purpose and provide scannable details. Every sentence contributes value—purpose, usage guidance, error behavior, pricing, and output structure—with 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?

Given the tool's complexity (4 required parameters, output schema, rate limits, paid routes, signed attestation), the description is remarkably complete. It covers the operation, usage context, failure modes, cost structure, and output keys, leaving little ambiguity for an agent deciding whether and how to invoke it.

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

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

The input schema already documents all four parameters with clear descriptions (ecosystem, package, from_version, to_version) at 100% coverage. The description does not add additional parameter-level meaning beyond what the schema provides, so the baseline score 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 opens with a precise action: "symbol-level diff between two pinned versions of one package" and enumerates the specific outputs (added, removed, changed signatures, new deprecations, breaking/additive/neutral classification). This clearly distinguishes it from sibling tools like attester_package_exists or attester_symbol_signature, which serve different purposes.

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 an explicit use case ("before upgrading a dependency, or when reviewing what an upgrade breaks") and a 'WHEN NOT' statement about unresolvable versions. However, it does not name alternative tools for cases where a diff cannot be performed, so it lacks the explicit alternative guidance that would earn 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?

The description reveals cost per call ($0.10 USDC), latency range (~2-6s), the independent verification pipeline, and the attestation mechanism, all beyond the annotations' readOnly/openWorld/idempotent hints. It gives critical operational details without contradicting annotations.

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

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

The labeled sections (WHAT, WHEN, WHEN NOT, COST, LATENCY, OUTPUT) make the dense information scannable and front-loaded. There is no redundant wording; every section provides necessary information for an agent to decide and invoke the 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?

The description covers purpose, usage, exclusions, cost, latency, and output structure, with annotations covering safety. However, the optional 'context' input parameter is not explained, which is a minor completeness gap given the tool's 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?

The description implicitly defines 'query' as the coding question but does not explain the optional 'context' parameter. With 0% schema description coverage, some compensation exists (e.g., query semantics), but the context parameter's purpose remains unclear, leaving a notable 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 clearly states the tool answers coding questions (library/API usage, error diagnosis, best practices) and provides real citations with a signed attestation. This specific verb+resource distinguishes it from siblings like oracle_verify_work or oracle_watchtower_report, and the contrast with web search clarifies its niche.

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 explicitly includes WHEN and WHEN NOT sections: use when you need a grounded, cited answer mid-task and are willing to pay; avoid for open-ended code generation, private/proprietary docs, or when a free unverified answer suffices, citing web search as the alternative. This is exemplary usage guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds substantial context beyond these: cost ($0.10 USDC), latency (~1s to ~30s), deterministic grading behavior, the literal interpretation of the rubric, score bands, and output details (signed attestation). This enriches the agent's understanding of side effects, resource usage, and response characteristics without contradicting any annotation.

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 organized with clear labeled sections (WHAT, WHEN, WHEN NOT, COST, LATENCY, OUTPUT, Bands), making it easy to scan and parse. Every sentence serves a distinct purpose—purpose, usage guidance, exclusions, cost, latency, output format, and thresholds—with no fluff or redundant restatement of schema/annotations.

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

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

For a tool with 3 parameters, an output schema, and rich annotations, the description covers all critical operational aspects: exact use cases, alternatives, cost, latency, determinism, score bands, and output structure. The presence of an output schema means return values need not be exhaustively documented, but the description still summarizes the key output fields and thresholds, leaving no significant gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context by explaining that the judge is 'literal and grades exactly what you write,' which directly informs how the rubric parameter should be constructed, and ties the weight parameter to the returned per-criterion weighted score. This goes slightly beyond the schema's structural descriptions.

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 opens with 'WHAT: grades an agent output against your rubric and returns a 0-100 weighted score with per-criterion evidence and a signed attestation,' which is a specific verb+resource statement that immediately clarifies the tool's function. It further distinguishes itself from the sibling tool oracle_verify_work by explicitly naming the alternative for citation truth-checking.

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 includes explicit 'WHEN' and 'WHEN NOT' sections, listing concrete use cases (accepting/rejecting deliverables, ranking candidate answers, logging QA receipts) and exclusions (subjective taste, citation truth-checking alone, vague rubric). It also names the specific alternative tool, oracle_verify_work, for one of the exclusions, providing clear decision 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 mark readOnly and idempotent, but the description adds valuable behavioral context: cost per check, latency, the policy that 'An unknown payee is always caution, never clear,' and a detailed output structure. This goes well beyond annotations without contradicting them.

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 uses labeled sections (WHAT, WHEN, WHEN NOT, COST, LATENCY, OUTPUT) that are concise and front-loaded. Each sentence adds useful information without redundancy or wasted words.

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?

The tool has an output schema, but the description still provides a helpful preview of return fields. It also covers cost, latency, usage boundaries, and a key policy caveat. The inclusion of sibling tool references and cost information makes it operationally complete for an 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?

Schema coverage is 100%—both payTo and amount_usd are well-described. The description adds some contextual framing (e.g., 'pre-payment' and 'raising a payment limit') but does not introduce parameter-specific meaning beyond the schema. This aligns with the baseline for high 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?

The description clearly states a specific verb+resource: 'pre-payment counterparty check. Given a 0x address or URL, returns a clear/caution/avoid verdict with per-source evidence... and a signed attestation.' It distinguishes from siblings by explicitly pointing to oracle_verify_work for judging delivered work.

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

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

Explicit WHEN clauses: 'before sending any x402 payment to a service you have not paid before, or before raising a payment limit.' WHEN NOT is also explicit: 'for services you already trust, for judging delivered work (use oracle_verify_work), or as a guarantee.' This provides clear alternatives and exclusions.

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 read-only/idempotent/non-destructive, and the description adds valuable behavior beyond that: cost ($0.15 USDC, x402, free tier), latency range, output structure, and the meaning of 'abstain'. This is rich, non-redundant context that helps the agent anticipate side effects and results.

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 long but tightly organized with labeled sections (WHAT, WHEN, WHEN NOT, COST, LATENCY, OUTPUT). Every sentence provides distinct and necessary information, and the most critical what-it-does is front-loaded. 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?

Given 2 params, no schema descriptions, and an output schema, the description covers purpose, usage conditions, exclusions, cost, latency, output structure, and the abstain semantics. It addresses both selection and invocation contexts comprehensively, leaving very little to infer.

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?

Input schema has zero description coverage, and the description does not explain the structure of the `job` or `spec` objects. It mentions three job domains but not how to encode them, leaving parameter usage ambiguous. The description compensates only partially; an agent would still need examples or field-level semantics to invoke correctly.

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 opens with 'WHAT: independently checks another agent's work' and enumerates specific domains (citation support, code correctness, dataset/schema conformance). It clearly distinguishes a verification oracle from sibling research/report/spend/judge tools, and it specifies the unique output (verdict + signed attestation).

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 'WHEN' section lists concrete scenarios (before paying for subcontracted work, before merging agent-produced content) and 'WHEN NOT' gives explicit exclusions (already trusted work, subjective judgments, non-Python code). This provides strong guidance on when to choose this tool over alternatives.

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, and destructiveHint, so the safety profile is known. The description adds valuable behavioral context: reports are aggregated over 24h, probes run every 30 minutes, reports are pre-computed (~1s latency), EIP-191 signed, and there is a cost of $0.05 USDC with 3 free reports. No contradictions with annotations.

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

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

The description is well-organized with clear labels (WHAT, WHEN, WHEN NOT, COST, LATENCY, OUTPUT) and every sentence provides distinct, useful information. It is concise for the amount of context it delivers, with no 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?

The description covers purpose, usage boundaries, cost, latency, output shape, and limitations. The presence of an output schema reduces the need to explain return values, and the description goes beyond what is required, making it fully complete for a 1-parameter 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 100% for the single parameter 'service', and the schema already provides its description ('Host or URL substring of the watched service'). The tool description does not add additional parameter-level detail, 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 opens with 'WHAT: returns the latest signed SLA report for a watched x402 service' and enumerates the exact output fields (uptime_pct, price_match_pct, current_verdict). It clearly distinguishes from siblings by naming oracle_verify_work as the tool for work products, and clarifies the report is for SLA health, not real-time status.

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 explicitly provides WHEN ('before routing paid traffic to an x402 service you do not control, or when checking whether a service still charges its advertised price'), WHEN NOT ('for real-time health', 'for services not yet watched', 'for verifying work products'), and names an alternative tool (oracle_verify_work). This is exemplary guidance for tool selection.

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