x402-endpoints

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

No annotations are provided, so the description carries full burden. It reveals the tool is paid ($0.25 per call via x402 payment on Base mainnet), generates a signed receipt, and composes reports from live public web signals. This sufficiently discloses behavioral traits for a non-destructive, fee-based research tool.

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

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

The description is dense but well-structured, front-loading the core output (positioning, strengths, risks, score, rating, recommendation). Every sentence adds value, though it could be slightly more concise without losing detail.

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 2 parameters and no output schema, the description provides a thorough outline of what the report contains (score, rating, receipt) and the pricing model. It is adequate for an agent to understand the tool's functionality, though exact JSON structure is assumed.

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 parameters described. The tool description adds meaningful context by listing example input values ('stripe.com') and specifying focus options (investment, competitive, partnership, security, general), which expands on the schema's hint.

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 specifies the tool produces a 'structured analysis report' on URLs, companies, products, or subjects, listing concrete outputs like positioning, strengths, risks, score, rating, and receipt. It clearly distinguishes from siblings by mentioning competitive/investment/partnership analysis, making the purpose 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?

The description implies usage for analysis tasks but does not explicitly state when to use this tool versus alternatives like agent_due_diligence or agent_content_scan. It lacks when-not-to-use guidance or context about prerequisites.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool performs risk assessment and returns a verdict (CLEAR/LIMIT/REVIEW/BLOCK) along with a signed ClearancePacket. It does not mention side effects, but since it's a preflight, it is likely read-only. The description is transparent enough.

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 a single dense paragraph that front-loads the core purpose and then details key aspects like the verdict and signed packet. It is concise but includes useful information like pricing. Minor redundancy exists but overall it's well-structured.

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

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

Given the tool's complexity (6 parameters, no output schema, no annotations), the description covers the essential aspects: what it does, what it returns, and when to use it. It lacks an explicit description of the output format but compensates with a detailed overview of the ClearancePacket.

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 has 100% coverage with descriptions for all 6 parameters. The tool description adds contextual value by explaining the overall flow and providing examples for the 'action' parameter, such as 'delete the production users table'. This enhances understanding beyond the schema.

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

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

The description clearly states the tool's purpose as a safety preflight for destructive/costly/irreversible actions, listing specific verbs like risk assessment, reversibility check, and verdict. It distinguishes itself from sibling tools like agent_analysis_report by focusing on clearance and human-in-the-loop gating.

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 specifies when to use the tool: before running destructive, costly, or irreversible actions. It does not mention alternatives or when not to use it, but the context is clear enough for an AI agent to infer appropriate usage.

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

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

No annotations are provided, so the description carries full burden. It discloses the return components (verdict, amounts, expiry, signature) and the price ($1.50, x402 payment on Base mainnet). However, it does not mention any potential side effects, authentication requirements, or rate limits. It states the output is a signed packet, implying it is read-only, but does not explicitly confirm non-destructiveness.

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 contains two similar paragraphs, making it repetitive. Key information (purpose, components, price) is front-loaded, but redundant sentences could be merged. The length could be reduced without losing meaning.

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 no output schema, the description clearly explains the return values (verdict, approved amount, expiry, signature) and includes pricing and payment method. It covers the essential behavioral and param aspects for a tool that produces a signed verdict, making it fairly complete for its 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 description coverage is 100%, but the description adds significant value beyond the schema. It explains 'to' as the counterparty wallet, 'amount_usd' as the capital moved, and 'depth' as forensics graph hops with default 2. This extra context helps the agent understand parameter roles, especially for 'depth' which has enumeration-like options.

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 explicitly states the tool returns a signed clearance packet with a CLEAR/REVIEW/BLOCK verdict for a capital move, fusing OFAC/sanctions, mixer screening, fund-flow forensics, and counterparty trust. It clearly identifies the resource (clearance packet) and the action (pre-payment AML/KYT clearance). The sibling list includes 'agent_clearance', which might be a simpler version, but this description differentiates by mentioning the multi-hop forensics and signed verdict.

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 implies use for large capital moves with the phrase 'before a large capital move' and the question 'Can I send this capital to THIS wallet?'. However, it does not explicitly state when to use this tool versus alternatives like 'agent_clearance' (which appears in siblings) or when not to use it. No usage exclusions or conditions are given.

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

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

With no annotations, the description discloses behavior: returns risk score, verdict, findings; notes it's deterministic, cheap, high-volume; and includes pricing. It doesn't cover failure modes or limits, but is fairly transparent for a scanning tool.

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

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

The description is front-loaded with core purpose and reasonably concise despite some redundancy (e.g., 'Prompt-injection / skill-audit / untrusted-content security check'). It could be tighter but is not overly verbose.

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

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

Given no output schema, the description covers output (risk score, verdict, findings) and use case (pre-ingest). It includes pricing and mentions determinism. Missing details like limitations or error conditions, but complete enough for typical usage.

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%, but description adds context by explaining the raw content parameter's role and listing example content types, aligning with source_type enum values. This provides meaning beyond the schema.

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

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

The description clearly states the tool scans external content before ingestion for security threats, listing specific threats (prompt-injection, etc.) and types of content. It distinguishes from siblings like agent_due_diligence and agent_preflight by specifying it as a pre-ingest firewall.

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 explains when to use: before agent ingestion of external content. It provides context as a fast, cheap, deterministic firewall but does not explicitly exclude alternatives or mention when not to use.

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?

Describes output components (synthesis, signals, risk score, verdict, receipt), live public web signals, and pricing ($0.50 per call with x402 payment). Fully conveys behavioral traits.

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?

Single paragraph, front-loaded with purpose, but somewhat lengthy. Every sentence adds value, though could be slightly more concise.

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?

Covers input, output, use case, and pricing. Lacks details on error handling or prerequisites, but sufficient given simplicity of 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 covers 100% of parameters with descriptions. The tool description adds broader context but no new parameter-level details beyond the schema.

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

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

Clearly states it vets entities (company, crypto project, etc.) and produces a risk dossier. Distinguishes from siblings by explicitly replacing manual searches and synthesis.

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

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

Explains when to use: before engaging with a counterparty or project. Implicitly compares to other tools but does not explicitly name alternatives or state when not to use.

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

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

With no annotations, the description carries the full burden. It clearly explains the tool is a read-only report (structured USDC accounting), mentions the output fields, pricing, and that it processes data. It does not hide any destructive behavior. However, it lacks details on rate limits or error states.

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 key points but is mildly repetitive (e.g., 'Your AI agent's books in one call' appears twice). It includes pricing and a summary of outputs, which is useful, but could be more streamlined without losing information.

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

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

Given no output schema, the description effectively lists the report contents (revenue, expenses, net, tx count, top payers/payees, weekly breakdown). It covers the essential information an agent needs to decide to use the tool, though it omits response format or pagination details.

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

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

Schema coverage is 100%, so baseline is 3. The description mentions the wallet and period parameters but adds little beyond the schema's own descriptions. The phrase 'Input: wallet (+period 7d/30d/90d)' is helpful but does not significantly enhance understanding.

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 provides structured USDC accounting for any wallet on Base, including specific outputs like revenue vs expenses, net, transaction count, top payers/payees, and a weekly breakdown. This specific verb+resource distinguishes it from sibling tools like agent_analysis_report or x402_seller_audit.

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 implies the tool is for obtaining a bookkeeping report, but it does not explicitly state when to use it over alternatives or when not to use it. No exclusions or comparisons to siblings are provided.

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

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

With no annotations, the description carries the full burden. It discloses that the tool scores, rates, suggests, and rewrites the output, and mentions the cost and payment method. It does not hide any side effects, though it could be more explicit about idempotency or limits.

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

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

The description is fairly concise but includes some fluff (e.g., 'Will this message land or get flagged as spam?'). Front-loads the key action. Slightly verbose with pricing details, 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?

Despite lacking output schema, the description fully explains the output: scorecard, rating, suggestions, and rewrite. With only 3 well-documented parameters, it provides a complete picture of what the tool does and returns.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant value beyond schema by detailing the multi-criteria scorecard and the rewrite output, which are not in the parameter 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 clearly states it reviews and improves agent outbound text, listing specific aspects (clarity, spam-safety, etc.) and outputs (scorecard, rating, suggestions, rewrite). It distinguishes from sibling tools like agent_content_scan by specifying it does output review, spam check, and copy QA.

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 implies usage context (before sending, to check if message lands or gets flagged as spam) and lists the criteria. However, it does not explicitly state when not to use this tool or name alternatives, though the sibling set suggests different tools for different purposes.

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

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

With no annotations, the description carries full burden. It discloses key behaviors: reads on-chain registries, computes declared and measured reputation, returns delta and verified verdict. It also mentions price and payment method. Missing details on error handling or rate limits, but overall transparent.

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 overly verbose with significant repetition (e.g., the first and last sentences are nearly identical). It could be more concise without losing meaning, which hinders quick agent parsing.

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

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

Given the complexity of on-chain reading, reputation computation, and payment integration, the description covers core functionality, input options, pricing, and output (delta + signed verdict). No output schema, but description adequately describes return values.

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 minor value by explaining that wallet resolves to agentId, but does not elaborate further. It adequately complements the schema.

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

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

The description clearly states the tool's function: a reputation dossier comparing measured vs declared reputation for AI agents using on-chain ERC-8004 registries. It distinguishes itself from sibling tools like agent_analysis_report or agent_due_diligence by focusing on Sybil-corrected reputation and returning a signed verdict.

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 implies usage for audit-grade due diligence and mentions x402 payment on Base mainnet, but does not explicitly state when to use this tool versus alternatives or provide when-not-to-use guidance. The context is present but 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?

With no annotations, the description fully discloses the tool's behavior: it's a cheap call ($0.10), returns best rank and per-category-keyword rank, and points to a full audit. It also clarifies what it does not show (raw settled-volume rank). No contradictions or hidden traits.

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 somewhat repetitive, with the first paragraph essentially restating itself. While it contains necessary information, it could be more concise without sacrificing clarity. Core details are front-loaded.

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

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

Given the tool's simplicity (one parameter, no output schema), the description sufficiently covers the return value (best + per-category rank), cost, and relationship to a sibling tool. It is complete enough for an agent to use 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 single parameter 'seller' has 100% schema coverage with a description that already explains the acceptable formats. The description reiterates this without adding new semantics, meeting 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 the tool's function: quick keyword-relevance rank check for x402 sellers in CDP Bazaar discovery. It distinguishes itself from sibling tools like agent_visibility_audit and specifies it's not the raw settled-volume rank, making the purpose very specific and 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?

The description provides clear context for when to use this tool: as a frequent pulse for monitoring discoverability, with a pointer to the full visibility-audit when rank slips. However, it lacks explicit 'when not to use' or detailed alternatives beyond the audit reference.

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

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

With no annotations provided, the description fully carries the burden of disclosing behavioral traits. It states the cost ($1.00 per call, x402 payment), required inputs (seller, optional snapshot), and outputs (rank, score, benchmarks, delta). No contradictions.

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 repetitive, restating the same information almost verbatim in two paragraphs. While it contains all necessary information, it could be more concise by removing 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?

Despite lacking an output schema, the description enumerates all expected outputs (rank per category, metadata score, settlement activity, benchmarks, prioritized fixes, delta). It also covers cost, payment method, and input details, making it self-contained and complete.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds value by explaining the purpose of the snapshot ('compute a dated delta') and clarifying the seller format ('wallet or origin domain'), going beyond the schema 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 clearly states the tool's purpose: auditing discoverability of x402 sellers across specific registries (CDP Bazaar, 402index) and lists detailed outputs. It distinguishes from sibling tools like 'x402_seller_audit' and 'agent_rank_check' by focusing on visibility and discovery rather than general audit or rank.

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 implies when to use (when wondering 'Why am I not being found?') and specifies it's for 'Discovery/GEO/AEO audit for x402 sellers'. Although it doesn't explicitly contrast with alternatives or state when not to use, it provides sufficient context for appropriate invocation.

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

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

No annotations are provided, so the description carries full burden. It discloses cost ($0.01 per call), payment method (USDC on Base mainnet), output fields (announcement type, family, date, court, registre/SIREN, link), and coverage (France, official DILA source). It does not mention rate limits or authentication but is transparent about what the tool does and returns.

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 somewhat redundant: the first sentence and the second paragraph repeat similar content about announcement types. It could be streamlined into one concise paragraph. However, it is structured with a clear main function, payment info, return description, and use cases. It earns its place but has some 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 no output schema, the description provides a good overview of return fields. It covers purpose, input format, filters, cost, and use cases. While it lacks details on error handling, pagination, or rate limits, the tool is straightforward (search with filters). The description is sufficiently complete for an agent to use 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 100%, so baseline 3. The description adds business context not in the schema: explaining filter values 'creation, modification, radiation, depot, collective' as corresponding to 'incorporations, modifications, radiations, insolvency proceedings'. This links parameters to real-world announcements, adding value beyond the schema's literal 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 clearly states the verb 'Search', the resource 'BODACC registry', and specifies the scope 'company legal announcements: incorporations, modifications, radiations and insolvencies'. It also mentions coverage (France) and input types (name, SIREN, RCS). It implicitly distinguishes from siblings like fr_legifrance_search (legal texts) and fr_sirene_lookup (company registry) by focusing on announcements.

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 states use cases: 'For credit-risk, supplier-risk, KYB and AML agents.' This tells when to use. While it does not list alternatives or exclusions, the siblings table provides context that other tools serve different purposes (e.g., sanctions screening, patent searching). The usage guidance is clear enough for an agent.

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

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

With no annotations, the description discloses key behavioral traits: uses eth_getLogs on Base, decodes specific events, includes raw topics for unknown signatures, has block span cap, costs $0.05 per call via x402 payment. It omits rate limits or error handling but provides substantial transparency.

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 somewhat repetitive (first sentence restated later) and could be more concise. It includes useful details but would benefit from tighter wording.

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 (pricing, payment, multiple event types) and lack of output schema, the description adequately covers return values (normalized events, raw topics) and usage context, though some details like pagination or error codes are 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 coverage is 100% with descriptions for all 6 parameters. The description adds value by explaining filtering by event name/signature/topic0 and block range/lookback, and summarizing input structure, enhancing understanding beyond schema alone.

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 specifies 'decoded on-chain events for AI agents: query a contract's event logs on Base (eth_getLogs)' and lists specific event types (Transfer, Approval, etc.), distinguishing it from sibling tools that focus on wallets, tokens, or derivatives.

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 mentions pricing and payment method but does not explicitly guide when to use this tool versus siblings. It implies usage for querying on-chain events but lacks exclusions or alternative suggestions.

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 discloses that the score is derived/heuristic, not official, and based on a single high-emissions pathway. It also mentions price and determinism. No annotations were provided, so the description carries the burden well, though it doesn't cover rate limits or auth.

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 verbose and repetitive, stating the same caveats twice ('Derived/heuristic, NOT official' and 'single high-emissions pathway'). Could be condensed significantly.

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 no output schema and no annotations, the description provides a good level of detail about what the tool returns (composite score, subscores, indicators, comparison) and its methodology. It includes price and use cases, making it fairly complete.

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

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

The input schema has 100% coverage with descriptions for all parameters. The description adds minimal extra meaning beyond listing lat/lon, scenario, horizon and noting scenario is informational. Baseline 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 clearly states it returns a climate risk score (0-100) derived from CMIP6 projections, specific to coordinates and scenario. It distinguishes itself from siblings, which are unrelated 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?

The description mentions use cases (property due-diligence, ESG, etc.) but does not explicitly state when not to use or provide alternatives. The siblings are diverse, so differentiation is not critical.

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

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

No annotations are provided, so the description carries full burden. It discloses the screening sources (OFAC SDN, Tornado Cash), output format (PASS/WARN/BLOCK + signed receipt), price, and payment method. It does not mention rate limits, authorization, or whether it is read-only, but covers major behavioral traits.

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 moderately long but well-structured, front-loading the core purpose. It includes price and payment details which, while behavioral, are relevant for usage. No fluff, but could be slightly more concise.

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 no output schema, the description explains return values and the signed receipt feature. It covers purpose, parameters, output, and pricing. Does not mention prerequisites or rate limits, but is sufficiently complete for this tool's function.

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 already describes wallet formats and chains. The description adds little beyond the schema for parameter meaning, but contextually ties parameters to the screening process (e.g., mixer exposure). Marginal added value.

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 screens wallets for sanctions/compliance, specifies supported blockchains (EVM, Solana, BTC, Tron, XRP), output levels (PASS/WARN/BLOCK), and a signed receipt. It distinguishes from siblings like sanctions_screen by mentioning mixer exposure, wallet age, and cryptographic 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 description implies the tool is for OFAC compliance and travel-rule screening with an auditable receipt, but does not explicitly state when to use it over alternatives like sanctions_screen or crypto_wallet_forensics. No exclusion criteria or context-specific guidance provided.

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

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

With no annotations, the description carries the full burden. It mentions resilience ('returns whatever venues respond') and pricing ($0.05 per call, payment method), but lacks details on authentication, rate limits, data freshness, or error handling for invalid symbols.

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 verbose and repetitive, with near-identical sentences appearing twice. It includes pricing info that could be elsewhere. While front-loaded, it wastes space and could be more concise.

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?

Without output schema, the description fails to explain the return structure or data format for the multiple metrics. It lacks error handling, pagination, or field details, making it incomplete for a multi-venue data 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% with one parameter 'symbol'. Description adds 'Input: coin ticker' and examples, but does not add significant meaning beyond the schema description. Baseline 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 clearly states it provides perpetual funding rates, open interest, long/short ratios across Binance/Bybit/OKX/Hyperliquid, plus computed arbitrage spread and crowding signal. It uses specific verbs and resource names, distinguishing it from sibling tools like crypto_dex_cex_spread and crypto_new_pairs.

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 says 'For trading and funding-arbitrage agents' and notes resilience, but does not explicitly state when not to use it or suggest alternatives. Usage context is implied but not fully guided.

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

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

With no annotations, the description carries full burden. It discloses the fee adjustment, specific DEX and CEX sources, execution direction, profitability flag, and pricing ($0.05/call, x402 payment). No contradictions. Could improve by mentioning output format explicitly.

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 somewhat repetitive, restating the same core information twice. It is front-loaded but could be more concise by removing duplication. Pricing info could be separated. About 130 words, acceptable but not maximally 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?

For a simple tool with one parameter and no output schema, the description explains the computation, sources, fees, and profitability detection. It includes pricing and target audience. Lacks output structure, but the description implies the agent will receive spread and profitability info.

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 single parameter 'symbol' is described in the schema with examples. The description adds 'Input: coin ticker' which is redundant. Schema coverage is 100%, so baseline 3 is appropriate; no additional semantic value beyond what the schema provides.

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 computes the fee-adjusted net spread between DEX and CEX, including execution direction and profitability. It distinguishes itself from sibling crypto tools by focusing on arbitrage spread, not raw prices or other metrics.

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 targets 'arbitrage agents' and describes the tool's role in identifying profitable opportunities. While it doesn't list alternative tools or when NOT to use it, the context of sibling tools (e.g., crypto_derivatives_radar, crypto_new_pairs) makes the use case clear.

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

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

With no annotations, the description fully carries the behavioral burden. It discloses return fields (pool, base token, price, liquidity, age), EVM vs Solana behavior, and pricing. However, it does not specify error handling, rate limits, or what happens when safety check fails (e.g., pair excluded?). Still, it provides substantial behavioral detail.

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 repetitive (first two sentences nearly identical) and includes extraneous pricing info. While it front-loads the core purpose, it could be shortened by half without losing key information. Every sentence does not fully earn 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?

Given moderate complexity (3 params, no output schema), the description covers necessary aspects: input parameters (chain, limit, safety), returned fields, payment details, and platform specifics. It lacks pagination info, but for a list-of-pairs tool, it is sufficiently complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reiterates the safety default and mentions 'Input: chain + limit' but adds no new meaning beyond the schema's enums and ranges. No additional parameter context is provided.

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 it returns newly launched DEX pairs with an integrated safety check, using verbs like 'filters rugs' and 'sniping agent'. It distinguishes from siblings like 'crypto_token_safety' by bundling the check directly. The resource (new pairs per chain) and specific purpose (safe sniping) are explicit.

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 implies use for sniping agents seeking new pairs with instant rug filtering. However, it does not explicitly mention when not to use (e.g., for existing pairs) or compare to sibling tools like 'crypto_derivatives_radar'. The context is clear but lacks exclusion criteria.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool fuses multiple safety checks, returns a signed receipt, costs $0.05 per call via x402 payment, and supports EVM + Solana. However, it does not explicitly state that the tool is read-only or non-destructive, which is implied.

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 informative but contains redundant phrasing (e.g., the first and third sentences repeat similar information). It could be more concise by removing repetition while retaining key details.

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 usage, input, pricing, and supported chains well, but it does not detail the output format beyond mentioning a signed receipt. Without an output schema, the agent needs clarity on what GO/CAUTION/NO-GO looks like. Adequate but incomplete.

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%; the schema already explains each parameter. The description adds minimal extra context (e.g., 'Input: token (+chain, optional wallet)'), but no new technical details. 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 clearly states it provides a GO/CAUTION/NO-GO verdict for AI trading agents, fusing multiple checks. It specifically says it 'replaces three separate calls' (token-safety, wallet-screen, signal), distinguishing it from siblings like crypto_token_safety and compliance_wallet_screen.

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 frames the use case with 'Should I buy this token now?' and states it replaces three alternative calls. Supported chains are listed. It does not explicitly state when not to use it, but the context is clear.

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

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

With no annotations, the description carries full burden. It discloses data sources (funding rate, crowding, regime, lead-lag), data freshness claim, and fusion approach. It also states the price per call. Missing details on error handling, rate limits, or behavior when data is stale, but overall transparent for a paid signal tool.

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

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

The description is fairly concise with two substantive sentences plus a question and price note. It front-loads the purpose. Slight wordiness in enumerating sources, but no unnecessary repetition.

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

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

Despite no output schema, the description mentions the output includes LONG/SHORT/NEUTRAL with confidence. Given the complexity of a fused signal from multiple exchanges, it covers key aspects. However, more detail on the full output structure (e.g., confidence level format) would improve completeness.

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 clear parameter descriptions: symbol as 'Coin ticker' with examples, and timeframe with valid values and defaults. The description adds context about fusion and pricing but does not add new semantic meaning beyond what the schema already provides, so 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 clearly states the tool provides a fused trading signal (long/short/neutral with confidence) by combining multiple data sources like funding rate and market regime. It distinguishes itself from competitors who sell components separately. The verb 'provide' and resource 'fused trading signal' are specific and distinct from 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?

The description explicitly answers the question 'Should I go long or short on this coin?' and mentions it's for derivatives trading signals. It also includes pricing and payment method. However, it does not provide any alternative tools or conditions when not to use this tool, lacking exclusion criteria.

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

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

With no annotations, the description must disclose all behaviors. It covers cost ($0.10 per call via x402), supported chains (EVM + Solana), and input format. However, it does not mention failure behavior, rate limits, or response time, leaving some gaps despite good coverage.

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 moderately concise but contains repetition (the list of features is stated twice). It could be tightened without losing information. Still, it is not overly verbose.

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

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

Despite no output schema, the description thoroughly outlines the report contents (safety score, holders, liquidity, etc.). It covers input requirements, chains, and payment. Missing minor non-obvious behaviors like synchronicity or error handling, but generally complete for a paid 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%, so baseline is 3. The description repeats parameter info already in the schema (token format, chain options, default). It adds no new meaning beyond what the schema provides, meeting but not exceeding 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 explicitly states what the tool does: 'Full degen token dossier in one call' listing specific data points. It distinguishes itself from plain safety checks by calling it a 'premium tier', differentiating it from sibling tools like crypto_token_safety.

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 advises using this tool 'before aping' and positions it as a premium alternative to a plain safety check, implying when and when not to use it. It lacks explicit exclusions but provides clear situational 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?

With no annotations, the description discloses pricing ($0.05, x402 payment, USDC on Base mainnet), supported chains (EVM), and that it produces a 0-100 score and verdict. This goes beyond basic purpose, though it could mention read-only nature and any rate limits.

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

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

The description is verbose and contains repetitive phrases, such as the opening sentence nearly duplicated later. It could be streamlined to one clear statement without repetition. Pricing info is useful but adds 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?

Given no output schema, the description adequately explains the return value (0-100 score with buy/avoid verdict) and lists data sources. It covers input parameters, supported chains, and pricing, leaving few gaps for a trading 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%, so description adds minimal extra meaning; it repeats the token address format and chain list already in schema. The mention of 'EVM chains' provides slight context but not new semantic detail.

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's purpose: 'Token safety check before buying' and specifies it detects honeypots, rug pulls, and other risks. It also distinguishes itself by saying it 'replaces three lookups', setting it apart from possible sibling tools that might handle individual checks.

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 says 'For trading agents screening a token' and provides input format, but does not explicitly tell when not to use this tool or mention alternatives among siblings. Usage is implied but not fully guided.

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

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

With no annotations, the description carries the burden. It details the return components: flow graph, ranked counterparties, detected patterns (flow concentration, circular flows, linked wallets, high-degree hubs), and a signed receipt. It also discloses pricing and payment method (x402, USDC on Base). No side effects are mentioned, but it appears read-only. The description is thorough and transparent.

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 verbose and repetitive, stating 'Multi-hop wallet forensics' twice and including pricing details that could be separated. It is not front-loaded; key functionality takes time to reach. Could be more concise without losing essential information.

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

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

The description covers main outputs (nodes, edges, patterns, receipt) and input parameters. However, it lacks details on error handling, rate limits, chain-specific behavior, or how to interpret patterns like 'signed receipt'. For a complex tool, it is adequate but not fully complete.

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

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

Schema coverage is 100%, so all parameters have descriptions. The description adds minor context (e.g., depth controls hops 1-3, chain defaults to base) but largely repeats schema info. The extra value is marginal, so baseline 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 clearly states it performs 'multi-hop wallet forensics' by traversing ERC-20 counterparty graphs. It specifics the verb (traverse, trace) and the resource (address's counterparty graph). Among siblings, tools like crypto_wallet_xray or crypto_token_dossier do not offer multi-hop graph analysis, so it distinguishes well.

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 implies use for tracing fund movement and connections, but does not explicitly guide when to use this tool vs alternatives like compliance_wallet_screen or sanctions_screen. It mentions EVM chains and input parameters but lacks exclusions or prerequisites. Usage context is implied but not 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?

No annotations are provided, so the description carries the full burden. It discloses pricing ($0.05 per call, x402 payment, USDC on Base mainnet) and mentions it is a single call. However, it does not address rate limits, authentication requirements, error behavior, or whether the operation is read-only (though implied).

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 verbose and repeats information (e.g., 'Wallet risk analysis: native + ERC-20 balances...' appears twice). While front-loaded with key points, it could be condensed to a single clear sentence without 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 lack of output schema, the description enumerates the returned data (balances, valuation, token count, OFAC flag) and outlines usage context (compliance, trading). It covers the tool's scope well, though it omits details on error handling, chain validation, or output format specifics.

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 baseline is 3. The description adds minimal value beyond the schema, only restating 'Input: wallet address + chain' and noting chain default is base. It does not elaborate on parameter constraints, formats, or relationship to output.

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?

Description clearly states the tool performs wallet risk analysis including native and ERC-20 balances, USD valuation, token count, and OFAC sanctions flag. It distinguishes itself from sibling tools by being a bundled 'one call' solution that provides a full portfolio valuation plus risk, whereas siblings focus on specific aspects like derivatives or token safety.

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

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

Explicitly states the target audience ('on-chain analysis, compliance and trading agents') and mentions EVM chains. It implies a bundled use case compared to primitive tools. However, it does not explicitly state when not to use or list alternative tools for specific needs.

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

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

No annotations are provided, so the description must carry the full burden. It discloses pricing ($0.01 per call) and payment method (USDC on Base mainnet) and mentions worldwide availability. However, it omits details like rate limits, error handling, or what happens when a CVE is not found. The transparency is adequate but not comprehensive.

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 moderately concise but contains redundancy: the opening sentence is repeated almost verbatim later. It front-loads the main purpose but could be tightened to remove duplication without losing information.

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

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

Given the tool's simplicity (3 parameters, no output schema), the description covers key aspects: purpose, input options, output summary, pricing, and target users. It is missing error handling details and a clear definition of 'status', but overall it provides sufficient context for an agent to use 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 coverage is 100%, so baseline is 3. The description adds value by explaining the search modes ('by exact CVE id or by keyword/product') and providing usage examples (e.g., 'CVE-2021-44228', 'log4j'). It also clarifies the 'limit' parameter's role. This exceeds the schema's 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?

Description clearly states it is a security vulnerability lookup tool using the official NVD database. It specifies the two search modes (exact CVE ID or keyword/product) and lists the returned information (description, CVSS severity, CWE weaknesses, references). This is specific and distinguishes it from sibling tools, none of which are vulnerability-related.

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

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

Explicitly states the target users ('devsecops, SBOM and dependency-audit agents') and gives example inputs. However, it does not mention when NOT to use this tool or suggest alternatives, leaving some ambiguity about scope limitations.

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 are absent, so the description carries full weight. It mentions cost, US coverage, and return content (key label sections). It does not disclose error handling, rate limits, or data freshness, but for a read-only lookup this is acceptable.

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 somewhat repetitive (first and fourth sentences overlap). It contains useful details but could be more streamlined. The structure is logical but not front-loaded with the core action.

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 simple nature (2 params, no output schema), the description covers purpose, target users, cost, and data source. It lacks details on possible errors, pagination, or output format, but is sufficient for basic selection.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description reinforces 'drug' usage with examples and explains 'limit' implicitly via max labels. This adds marginal value beyond the schema.

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

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

The description clearly states the verb 'lookup' and the resource 'official FDA openFDA drug labels' with specific scope 'by generic or brand name' and lists returned sections. It is distinct from sibling tools which cover unrelated domains.

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 specifies target audience ('healthcare, pharmacy and clinical-decision-support agents') and includes a disclaimer ('Not medical advice'), implying appropriate use. However, it lacks explicit exclusion scenarios or alternative tools.

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

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

With no annotations, the description carries full burden. It thoroughly discloses behavioral traits: data source (ECB SDMX), official nature, publication schedule, non-live rate nature, pricing model (USDC on Base mainnet), and returns real observation date. No annotation contradiction exists.

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 informative but repetitive: 'reference rates' and 'EUR reference rate' appear multiple times. Key information is front-loaded (euro exchange rate lookup), but the redundancy reduces conciseness. It could be trimmed without losing meaning.

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 has 3 parameters, no output schema, and no annotations, the description comprehensively covers all needed context: input format, data provenance, update timing, pricing, use cases, and return characteristics. It leaves minimal ambiguity for an AI agent to correctly invoke the 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% and parameters are described clearly. The description adds value beyond schema by stating default for date ('latest available') and clarifying frequency ('D for daily, default; M for monthly'). It also provides examples for currency codes. This extends understanding beyond raw schema.

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

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

The description explicitly states the tool does EUR foreign exchange reference rate lookup by currency, latest or by date. It clearly identifies the resource (ECB reference rates) and the action (lookup). This is specific enough to distinguish from sibling tools like 'crypto_derivatives_radar' or 'crypto_dex_cex_spread' which focus on different financial data.

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 provides context for when to use: 'For pricing, accounting, FX and treasury agents' and notes that rates are not live market rates. It explains the publication time (16:00 CET on working days) and pricing ($0.01 per call). However, it does not explicitly state when not to use or provide direct alternatives, though the sibling list implies other financial tools.

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

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

With no annotations, the description discloses key behaviors: it performs a full-text title search, returns specific fields (CELEX number, title, date, link), is multilingual, and costs $0.01 per call with payment via USDC on Base. However, it does not mention rate limits, error handling, or auth requirements.

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

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

The description is two paragraphs with some repetition (e.g., multilingual list appears twice). It includes necessary info but could be more streamlined. The first sentence front-loads the purpose effectively.

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 search tool without output schema, the description explains return values (CELEX number, title, date, link) and pricing. It lacks details on error states or pagination, but overall provides enough context for basic use.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minimal new meaning beyond the schema—it reinforces that 'query' is for keywords, lists languages, and mentions limit range (1-50). No additional semantic depth is provided.

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 searches EUR-Lex for EU legislation, treaties, case law, and legal acts by keyword, returning CELEX number, title, and date. It specifies that it is for legal-research, regulatory, and compliance agents, distinguishing it from sibling tools like fr_legifrance_search (French law) or uk_companies_search (UK companies).

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 provides general context ('For legal-research, regulatory and compliance agents') but does not explicitly state when to use this tool versus alternatives like other legal databases. It lacks when-not-to-use guidance or direct comparisons with 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?

With no annotations, the description adds value by disclosing the pricing model ($0.01 per call, payment details). It also implies the read-only nature but lacks explicit mention of rate limits, authentication, or behavior for empty results. The transparency is adequate but not exhaustive.

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 concise at two sentences, with the main purpose front-loaded. There is minor redundancy (first and second sentences both mention worldwide coverage and output details), but overall it is efficient and well-structured.

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

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

In the absence of an output schema, the description adequately explains return values (operator, connector type, power, etc.) and adds pricing context. It lacks details on pagination and error handling, but for a simple search tool, it remains fairly complete.

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

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

The input schema provides 100% coverage with descriptions for all four parameters. The description reiterates the parameters with examples, adding only slight contextual value. Baseline score of 3 applies as schema does the heavy lifting.

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

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

The description clearly states the tool's function: retrieving EV charging stations from Open Charge Map based on location and radius, with specific output fields. It uses a direct verb-resource pair and distinguishes itself from unrelated 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?

The description explicitly targets routing, fleet, and trip-planning agents, providing clear use context. However, it does not specify when not to use it or mention alternatives among the diverse sibling set, which is acceptable given the tool's unique focus.

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

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

No annotations exist, so the description carries the full burden. It discloses pricing ($0.01 per call) and data source (adsb.fi ODbL), but omits details on rate limits, authentication, or response format, leaving gaps for an agent to infer safe usage.

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 verbose and contains redundant phrasing (nearly identical sentences repeated). It lacks clear sectioning or prioritization, making it less efficient for an agent to parse quickly.

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

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

Given the complexity of real-time aircraft data and no output schema, the description fails to specify return structure, error handling, or bounding box size limits. This omission hinders an agent's ability to use the tool effectively without additional context.

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

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

Schema coverage is 100% with clear parameter descriptions. The description repeats the bounding box concept but adds no further semantic nuance beyond the schema, meeting the baseline expectation for a well-documented schema.

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

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

The description clearly states the tool retrieves real-time aircraft states within a bounding box, specifying live position, altitude, speed, heading, and ground status. It uniquely identifies the resource and action, distinguishing it from diverse 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?

The description mentions use cases ('For travel, logistics, airspace-monitoring and tracking agents'), providing clear context. However, it lacks explicit when-not-to-use guidance or alternative tools, which are less critical given the unique domain.

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

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

With no annotations, description carries full burden. Discloses cost ($0.05 per call, payment method), return fields (title, identifier, nature, date, legal status), and the read-only nature. Could mention pagination or rate limits but sufficient for search tool.

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

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

Description is somewhat repetitive, e.g., 'Official Légifrance... via DILA/PISTE' appears twice. Includes price info which, while useful, adds length. Could be more streamlined but still informative.

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 search tool with 4 parameters and no output schema, description covers input modes, corpus options, return fields, and usage context (legal research). Lacks explicit output structure but sufficient given 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 coverage is 100% (baseline 3). Description adds examples ('données personnelles'), explains corpus options (LODA_DATE, CODE_DATE, JORF), and specifies text_id for direct consultation. Adds value beyond schema field 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?

Clearly states the tool searches French legal texts (codes, laws/decrees, JORF) or looks up by ID. Distinguishes from sibling eurlex_search by specifying it complements EU law with national French coverage. Provides specific verbs: 'search and lookup' and 'consult by id'.

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 mentions complementing EUR-Lex, indicating when to use this national version vs the EU sibling. Also states 'For legal-research, regulatory and compliance agents.' However, does not explicitly state when not to use or alternative approaches within the same tool.

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

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

No annotations are provided, so the description carries full burden. It discloses the cost ($0.01 per call, payment details) and that it is a read-only lookup returning specific data. It does not mention side effects or rate limits, but for a lookup tool this is adequate.

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 somewhat repetitive, restating similar information in consecutive sentences (e.g., the list of return fields appears twice). It front-loads the key purpose but could be more concise.

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 no output schema, the description lists returned fields (legal name, status, NAF/APE, etc.) and price. It does not explain free-text search syntax (though schema covers it) or error handling. Overall adequate for a lookup 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% with descriptions for each parameter. The description adds grouping by stating 'Input: SIRET, SIREN or company name' but does not significantly extend beyond the schema's examples. Baseline 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 clearly states 'French company/establishment lookup by SIREN, SIRET or name against the official INSEE Sirene register (France)' with a specific verb and resource. It also lists returned fields, distinguishing it from sibling tools like bodacc_annonces (gazette) or fr_legifrance_search (legal documents).

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 provides context by stating 'For KYB, AML and supplier due-diligence agents (France)', implying when to use. However, it lacks explicit when-not-to-use or direct alternatives. The sibling tools are diverse enough that this tool's domain is clear.

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

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

With no annotations, the description must fully disclose behavior. It mentions real-time coverage, worldwide scope, and cost ($0.01 per call) – all helpful. However, it contradicts the input schema by claiming legal name is accepted, and it omits error handling or limitations (e.g., what happens if LEI not found). This inconsistency undermines transparency.

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 has two paragraphs with some redundancy (e.g., output fields listed twice: once in the first sentence and again in the second paragraph). It could be more concise without losing information. Front-loading of core function is acceptable.

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 no output schema, the description lists key fields (legal name, status, jurisdiction, etc.) and includes use cases and pricing. However, the input discrepancy (legal name mentioned but not supported) reduces completeness, and there is no mention of output format or empty result handling.

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

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

The schema covers 100% of the single parameter 'lei' with pattern and description. The description adds 'Input: LEI code or legal name,' which implies two possible inputs, but the schema only validates LEI codes. This addition is misleading and does not align with the actual parameter specification.

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 'Look up any Legal Entity Identifier (LEI)' with specific output fields. However, it also says 'Input: LEI code or legal name' while the schema only accepts a 20-character LEI pattern, creating ambiguity about the tool's actual input capability.

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 suggests use cases: 'For regulatory reporting (EMIR/MiFID), KYB and counterparty agents.' This provides good context for when to use the tool, though it does not mention when not to use or compare to 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?

No annotations are provided, so the description carries the full burden. It discloses that the validation is deterministic, local, costs $0.01 per call, and is a format-only check. This is sufficient behavioral context for an agent.

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 somewhat repetitive, stating the same core functionality multiple times (e.g., 'IBAN format validation' and 'structural validation' repeated). While it covers important points, it could be more concise.

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 absence of an output schema, the description adequately explains the return value: 'valid/invalid with reason, country code, check digits, bank code and grouped formatting.' This provides the agent with sufficient understanding of the tool's output.

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 a description for the single 'iban' parameter. The description adds value by explaining the expected input format (e.g., 'FR1420041010050500013M02606') and what validation components are extracted (country code, check digits, bank code, grouped formatting).

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 validates IBAN format using ISO 13616 mod-97, performs structural validation, and extracts country and bank code. It also explicitly distinguishes itself by noting it is a format check only, not an account existence check, differentiating it from 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?

The description specifies the use case: 'for payment, onboarding and treasury agents.' It also clarifies what it does not do ('does NOT verify the account exists'), though it does not explicitly mention when not to use it or provide alternative tools.

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

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

With no annotations, the description carries full burden. It discloses that the tool returns dated indicators, includes a signed receipt for backtests, costs $0.005 per call, and uses x402 payment on Base. It is transparent about the data source and pricing, though it could mention rate limits or error handling.

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

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

The description is detailed but every sentence serves a purpose: purpose, indicators, behavioral details, pricing. It is front-loaded with the core purpose and could be slightly more concise, but remains 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?

Given no output schema, the description covers what is returned (value, as_of date, next_release cadence, receipt), input parameters, pricing, and use case. It is fully complete for an agent to understand the tool's capabilities 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 coverage is 100% with descriptions for both parameters. The description adds value by providing context for the indicators (e.g., 'inflation_hicp, core_inflation' etc.) and explaining the reference area default ('U2'). It enhances the schema by explaining the purpose of the data returned.

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?

Description clearly states the tool provides 'Macro economic snapshot API' with specific Eurozone indicators (HICP/CPI, ECB rates, unemployment, EUR FX) for trading/research agents. It explicitly distinguishes itself from siblings by focusing on dated Eurozone economic indicators from official ECB data.

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 implies usage context: 'the interest-rate, inflation and currency context an agent needs before trading.' It does not specify when not to use it or provide explicit alternatives, but the context is clear enough for an agent to decide.

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

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

With no annotations, the description carries the burden. It discloses the cost ($0.10 per call, x402 payment), output structure (headline, outlook, signals, risks), and parametric options. No destructive behavior is indicated, and payment requirements are mentioned.

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 highly repetitive, stating the same content three times with slight variations. It could be condensed to a third of its length without losing meaning.

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 no output schema and no annotations, the description covers parameters, output summary, cost, and payment method. It does not explain error handling or authentication beyond payment, but it is largely complete for a paid read-only report 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% with descriptions for both parameters. The description adds default values (quick/crypto) and clarifies that 'deep' includes SOL and more web signals, going beyond the schema.

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

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

The description clearly states the tool produces an AI market intelligence report combining cross-exchange perp derivatives, fused directional signals, and euro-area macro snapshot. It is distinct from specialized siblings like crypto_derivatives_radar or macro_snapshot by offering a fused output.

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 implies usage for a comprehensive one-call report but does not explicitly guide when to use this tool versus specialized siblings. It mentions input parameters (focus, depth) but lacks when-not-to-use 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?

No annotations are provided, so the description carries the full burden. It discloses data source (OpenStreetMap), pricing ($0.01 per call), and server-computed results, but lacks details on rate limits, authentication, error handling, or behavior when no building is found. Adds useful context but not exhaustive.

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 mostly concise and front-loaded with the core capability. It contains minor redundancy (e.g., repeating 'building footprint and geometry by coordinate' in different phrasing) but overall each sentence adds value.

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 no output schema, the description adequately explains return values (GeoJSON polygon, area, levels, height, name). It covers input constraints and pricing. However, it could clarify handling of multiple buildings and response structure.

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%, baseline 3. The description adds value by clarifying that lat/lon use a radius (default 50m, range 1-200), providing an example coordinate, and explaining the bbox format ('south,west,north,east' with ~2km max span). This aids correct parameter usage beyond the schema.

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

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

The description clearly states the tool provides building footprints, geometry, area, levels, and height via OpenStreetMap/Overpass, specifying inputs (coordinate or bounding box). It distinguishes itself from diverse sibling tools by targeting geospatial building data for real-estate, insurance, solar, and urban-planning use cases.

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 mentions use cases ('for real-estate, insurance, solar, geospatial and urban-planning agents'), providing clear context. It does not specify when not to use or list alternatives, but given the unique domain, implicit alternatives are absent.

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

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

No annotations exist, so the description bears full burden. It discloses returned fields (publication number, country, kind code, dates, titles, applicants, inventors, classifications, family id), coverage (EU and worldwide), and input types. Omits rate limits or auth, but overall transparent.

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 repetitive, with two paragraphs covering similar content. It could be condensed to improve conciseness while maintaining clarity. However, it is well-structured with front-loaded purpose.

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 (7 params, CQL, dual mode, global coverage), the description covers key aspects: input modes, output fields, pricing, and use cases. Lacks details on pagination and error handling, but adequate for a search 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%, providing baseline 3. The description adds significant value by explaining CQL syntax for title, applicant, and inventor parameters, giving examples, and clarifying the dual mode (biblio lookup vs. search based on publication_number).

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 performs European patent search and bibliographic lookup by number, title, applicant, or inventor via the EPO. It distinguishes from sibling tools which cover different domains like climate risk, crypto, or legal.

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 specifies use cases: 'For IP due-diligence, freedom-to-operate, prior-art and R&D agents.' Pricing ($0.05 per call) is mentioned. No explicit when-not-to-use or alternatives, but siblings are unrelated, so no confusion.

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?

Discloses cost ($0.05 per call, payment method) and output structure, but no annotations exist. Missing details on authentication or rate limits. Description adds cost context but not full behavioral profile.

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?

Some redundancy (first sentence repeated in third sentence). Overall front-loaded with key info, but could be tightened slightly without losing clarity.

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?

Covers input format, output fields, and cost. No output schema, but the description sufficiently explains return values. Lacks error handling details, but acceptable for a simple 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%, baseline 3. Description adds value by explaining what the market parameter yields and how it relates to the output (probabilities, volume, etc.), beyond the schema's type and example.

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?

Clearly states verb 'get live prediction market odds' and resource 'from Polymarket', specifies input (market id or slug) and output fields. Distinguishes from siblings like 'polymarket_resolution' by focusing on odds/probabilities.

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?

Provides clear context for use ('for event-forecasting, hedging and research agents') and explains input/output. Does not explicitly contrast with sibling tools, but the purpose is distinct enough.

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

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

With no annotations provided, the description fully carries the burden of behavioral disclosure. It explains the return values (closed/resolved status, winning outcome, resolution source, end date, condition id/slug), explicitly states the winning outcome is 'derived from final outcome prices, only when unambiguous — never invented,' and discloses the pricing ($0.01 per call, USDC on Base mainnet). 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 front-loaded with the key purpose and is mostly concise. However, there is some repetition (e.g., 'Distinct from live odds' appears twice, and 'Polymarket market resolution oracle via the Gamma API' is restated). Overall, every sentence contributes value, but minor redundancy prevents a perfect score.

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 no output schema, the description adequately explains return values, payment details, coverage, and use cases. It covers all necessary aspects for an agent to understand the tool's functionality and limitations, making it complete for 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?

Schema description coverage is 100%, so baseline is 3. The description adds minor context by explaining the parameters collectively ('Input: market slug or condition id') and implying the 'limit' parameter is for listing recent markets. However, the schema already provides detailed descriptions for each parameter, so the description does not significantly add meaning beyond the schema.

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

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

The description clearly states the tool's purpose: 'Polymarket resolution status via Gamma API — market resolution, winning outcome and resolution source lookup by slug or condition id (or list recent resolved markets).' It uses a specific verb ('lookup') and resource ('resolution status'), and explicitly distinguishes from the sibling tool 'polymarket_odds' by noting 'Distinct from live odds.'

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 provides clear context on when to use the tool: 'For settlement, audit, research and event-forecasting agents.' It also contrasts with 'live odds' and mentions payment structure, giving implicit guidance. However, it does not explicitly state when not to use or list alternative tools beyond the distinction from polymarket_odds.

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

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

With no annotations, the description covers key behaviors: it is a signed proof-of-existence, not destructive, issuer never sees content if only hash sent, and it requires payment. It lacks details on rate limits or error handling but is otherwise transparent.

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 somewhat repetitive, with similar phrasing in two paragraphs ('Notarize a document or data hash... verifiable offline'). While well-structured with clear sections, the repetition reduces conciseness.

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 no output schema, the description adequately explains the output as a timestamped, Ed25519-signed receipt verifiable offline. With only three simple parameters, it covers the essential information for an agent to invoke the 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%, and the description adds value by explaining that content is an alternative to hash (hashed server-side), providing an example for memo ('invoice #42'), and noting the max content length. This enhances the meaning beyond the schema.

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

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

The description clearly states the tool notarizes a document or data hash by submitting a SHA-256 hash and receiving a timestamped, Ed25519-signed proof-of-existence receipt. It explicitly distinguishes itself from legal/blockchain timestamps, avoiding confusion with siblings like crypto_token_safety or sanctions_screen.

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 explains when to use it ('prove an artifact existed at a point in time') and when not to use it ('NOT a blockchain-anchored or legal timestamp'). It also mentions pricing and payment method, providing clear context for selection.

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

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

No annotations are provided, so the description carries the full burden. It discloses the cost ($0.01 per call with payment details) and coverage (US), which are critical behavioral traits. It implies a read-only query (search, lookup) and describes the data source. It does not mention rate limits or error handling, but the cost and coverage add significant transparency beyond 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?

The description is longer than necessary, with redundancy (e.g., 'Product recall lookup against the official FDA openFDA enforcement reports' appears twice). It is front-loaded with key information but contains repetitive phrasing that could be trimmed without loss of clarity.

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 is provided, so the description compensates by listing return fields: recall number, classification, status, reason, recalling firm, dates, and distribution. It also covers cost and coverage. For a tool with 4 parameters and no nested objects, this is adequate. Missing details like pagination or error cases, but sufficient for basic understanding.

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 descriptive parameter properties (e.g., 'Product, firm or reason, e.g. metformin'). The description adds minimal extra meaning beyond the schema, mentioning 'filter by Class I/II/III' which maps to the classification parameter. With high schema coverage, a 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 clearly identifies the tool as a product recall lookup for drugs, devices, and food, using the official FDA openFDA enforcement reports. It specifies actions (lookup, search) and resources (recall data by product, firm, reason). The sibling tools are diverse and specialized (e.g., drug_label, cve_lookup), and this tool's focus on FDA recalls is distinct.

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 states the tool is for e-commerce, supply-chain, pharmacovigilance, and compliance agents, indicating appropriate use cases. It does not mention when not to use it or provide alternatives, but the context signals and sibling list make it clear that this is the go-to for FDA recall data. Minor gap in exclusion 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?

No annotations are provided, so the description carries full burden. It transparently describes the return format (not binary, ranked matches with context), includes pricing and payment details, and notes the output is meant for human review. It does not disclose any potential side effects or authorization needs, but for a read-only screening tool, this is sufficient.

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 key info front-loaded: purpose and price in the first sentence. It repeats some information (e.g., reference to FISMA twice) but remains compact at three sentences. Every sentence adds value.

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 no output schema, the description fully explains what the tool returns (similarity score, EU reference, subject type, programme, designation details) and its intended use (KYB, AML, payment-compliance). It also covers pricing and input parameters, making it complete for the agent to decide and invoke 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 100%, so baseline is 3. The description adds context beyond schema by explaining the optional type ('person' or 'enterprise'), limit range, and threshold default. It also reiterates the input format. This adds meaningful value for agent invocation.

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 screens a name against the official EU consolidated sanctions list (FISMA) and returns matches with similarity score and context. It explicitly says it is not a binary yes/no but ranked for human review. This distinguishes it from any sibling tools, none of which are sanctions-related.

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 identifies the target users: 'For KYB, AML and payment-compliance agents.' It also mentions the price and payment method. However, it does not explicitly state when NOT to use this tool or provide alternative tools for different scenarios. Given sibling tools are unrelated, the guidance is clear and adequate.

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

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

With no annotations, the description fully discloses the four modules (token security, liquidity depth with slippage estimates, deployer history/control, holder concentration) and cost ($0.05 per call via x402). No destructive actions are implied, and the behavior is clearly explained.

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 somewhat repetitive ('Full token due-diligence in one call — replaces 3-4 lookups') but overall concise and front-loaded with the key purpose. It could be slightly tighter.

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

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

For a single-parameter tool with no output schema, the description provides complete context: what it does, what it includes, cost, and intended use. No gaps remain.

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

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

The schema covers the single parameter 'mint' with a description. The tool description adds context but doesn't provide significant extra semantics beyond the schema.

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

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

The description clearly states it's an all-in-one pre-trade decision tool for Solana tokens, combining four modules to output BUY-SAFE/CAUTION/AVOID verdicts. It explicitly mentions it replaces 3-4 separate lookups, distinguishing it from sibling tools like solana_token_safety.

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 indicates it's for trading/sniping agents in a risk-review pipeline, answering 'Should I buy or avoid this Solana token?' It implies use before purchase, but doesn't explicitly state when not to use or compare to all 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?

No annotations are provided, so the description carries full burden. It discloses that it combines static and behavioral analysis, includes a blue-chip false-positive guard, and outputs a verdict and score. It also mentions pricing. However, it does not specify whether the tool modifies any state or detail the exact return format, leaving some behavioral traits implicit.

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 a single paragraph that front-loads the main purpose of the tool. It includes necessary details without excessive verbosity. While it could benefit from bullet points, it is reasonably concise for the amount of information conveyed.

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 no output schema and no annotations, the description covers the tool's purpose, analysis methodology, output (verdict and score), and pricing. It lacks details on possible error states or pagination, but for a straightforward analysis tool, it is largely complete.

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

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

Schema coverage is 100% (both parameters described). The description adds minor context like the base58 format for 'mint' and implies the 'deep' parameter increases analysis depth, but these are already captured in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the tool is for Solana SPL token safety checking, rug pull and honeypot detection, and mentions verdicts SAFE/RISKY/CRITICAL with a score. It implies distinction from static checkers but does not explicitly differentiate from sibling tools like crypto_token_dossier or solana_pre_trade.

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 indicates use before trading ('pre-trade SPL token security') and mentions catching behavioral rugs that static checkers miss. However, it does not provide explicit guidance on when not to use the tool or mention alternative tools.

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

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

With no annotations, the description provides key behavioral traits: worldwide partial coverage (EU well covered), pricing ($0.05/call), payment details (USDC on Base), and input quality parameter. It lacks error handling info but is otherwise transparent.

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 somewhat repetitive, stating the same information about returns twice. It front-loads key details but could be more concise.

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 no output schema, the description thoroughly explains return values (max panel count, roof area, sunshine hours, carbon offset) with units, plus pricing and coverage. Missing error handling, but otherwise complete for the 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 100% and all three parameters (lat, lon, quality) are adequately described in the schema. The description adds minimal extra meaning beyond mentioning 'imagery quality'.

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 'rooftop solar potential, panel capacity, sunshine hours and carbon offset' from the Google Maps Platform Solar API, with specific outputs listed. It uniquely identifies its domain among diverse 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?

The description explicitly states use cases: 'For agents sizing solar installs, real-estate energy scoring, or carbon/ROI estimates.' It does not exclude alternatives, but sibling tools are mostly unrelated, making usage context clear.

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

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

No annotations provided; description discloses pricing ($0.05/call) and return fields, but does not mention rate limits or authentication. Sufficient for a read-only search.

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?

Description is slightly verbose but front-loaded with key information. No wasted sentences.

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 no output schema, description explains return fields (publication number, title, buyer, country, notice type, date, link) and pricing. Complete for a straightforward search 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?

All parameters have clear descriptions with examples (e.g., 'cloud software' for query, 'FRA' for country). Schema coverage is 100%, and description adds useful context beyond schema.

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

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

Clearly states the tool searches EU TED for procurement notices with specific filters (keywords, country, CPV code). Distinguishes from siblings as no other tool covers EU tenders.

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?

Mentions target users (business-development, bid, market-intelligence agents) but does not explicitly state when not to use or alternatives. Adequate 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?

With no annotations, the description carries the full burden. It discloses pricing ($0.01 per call), payment method, and the specific data returned for detailed profiles (status, SIC codes, officers, etc.). It does not address rate limits or error conditions, but covers the essential behavioral aspects for a read-only tool.

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

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

The description is front-loaded with the main action but contains redundancy (e.g., 'UK company verification via the official Companies House register' repeats earlier phrasing). It is longer than necessary, and some information (pricing) could be in annotations. A more streamlined version would improve conciseness.

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 has 4 parameters, no output schema, and no annotations, the description provides a comprehensive overview: two modes, return data fields, use cases, and pricing. It covers most user needs, though it could mention query behavior (e.g., fuzzy vs exact search) or error handling.

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 has 100% coverage, so baseline is 3. The description adds value by explaining that setting 'company_number' triggers a detailed profile fetech, while omitting it performs a search. It also provides examples and clarifies pagination parameters, exceeding 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 states it searches the UK Companies House register, with two distinct modes: search by name/number and detailed profile by company number. This verb+resource pairing is specific and distinguishes it from all sibling tools (no other UK company 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?

The description mentions usage for KYB, AML, and supplier due-diligence agents, providing clear context. It implicitly guides when to use this tool (UK company verification) but does not explicitly list alternatives or when not to use it, though no similar sibling exists.

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?

Without annotations, the description covers pricing ($0.01/call via x402 payment), the two distinct error states, and the use of the official VIES registry. It lacks rate limits or idempotency guarantees, but is otherwise transparent about behavior.

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

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

The description contains repetition (e.g., the first two paragraphs largely overlap). While not overly long, it could be more concise by removing redundant phrases while retaining all information.

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

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

Given the tool's simplicity (2 required params, no output schema), the description covers input format, return value details, error distinctions, pricing, and use cases. It is complete for an agent to decide when and how to use 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 schema covers 100% of parameters with descriptions. The description adds concrete examples (e.g., 'EL' for Greece, '6388047V') and clarifies that the vat parameter should be without country prefix, adding value beyond the schema.

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

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

The description explicitly states the tool validates an EU VAT number against the official VIES registry, returns valid/invalid with company name/address, and distinguishes 'invalid' from 'unavailable'. This differentiates it clearly from siblings like iban_validate or gleif_lei.

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 provides clear use cases (invoicing, B2B onboarding, KYB, tax compliance) and explains the key distinction between invalid and unavailable, but does not explicitly state when not to use it or compare to alternative tools.

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

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

With no annotations, the description effectively discloses output format (clean, LLM-ready markdown with source URLs), pricing ($0.05 per call), payment method (USDC on Base), and the underlying service (Jina Reader). It does not cover rate limits, auth requirements, or behavior when both parameters are provided.

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 slightly repetitive, with the opening sentence restated in the second half. While it is front-loaded with key information, the redundancy and inclusion of payment details (USDC on Base) could be trimmed for better conciseness.

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 absence of an output schema and annotations, the description covers input modes, output format, cost, and intended use case. It is missing details on search result structure, error handling, and behavior when both parameters are provided, but is adequate for a tool with only three optional parameters.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the two modes, providing an example query ('latest Base chain TVL'), and clarifying that using 'url' scrapes the page 'instead of searching'. This goes beyond the schema 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 clearly states the tool performs web search and webpage extraction, returning clean markdown. It specifies two modes via 'query' or 'url' parameters, distinguishing it from sibling data retrieval tools by focusing on web content and LLM-ready output.

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 states when to use each parameter: 'Give 'query' to search the web or 'url' to scrape and extract a page'. It also mentions the tool is for 'research and RAG agents', providing clear usage context. However, it lacks explicit guidance on when not to use it or alternatives among 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?

Discloses behavioral traits: runs checks (OFAC, mixer, overspend) with <200ms response, returns ALLOW/REVIEW/BLOCK, and mentions pricing. Without annotations, the description carries the burden and provides substantial context, though details on triggers for REVIEW vs BLOCK and anomalous-amount guard are vague.

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 with marketing fluff ('The hosted spending guard...') that doesn't add utility. First sentence is effective, but the rest could be trimmed. Adequate but not 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?

Covers key outputs (ALLOW/REVIEW/BLOCK) and performance, but lacks details on output format, error handling, or exact criteria for 'anomalous-amount guard'. With no output schema and no annotations, completeness is moderate.

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%, baseline 3. The description adds value by clarifying usage context: chain is inferred, amount in USD, expected_price flags overspend. Does not specify format constraints but goes beyond schema.

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

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

The description clearly states the tool is a pre-payment risk firewall for x402 payments, validating recipient, amount, and chain before sending. It lists specific checks (OFAC blocklist, sanctioned-mixer, overspend) and distinguishes from siblings like sanctions_screen by focusing on pre-payment context.

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 to use 'BEFORE sending an x402 payment' and 'Stop an agent from overpaying or paying a bad address'. Clear context, but no mention of when not to use or alternative tools like sanctions_screen or compliance_wallet_screen.

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

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

With no annotations provided, the description carries full burden. It discloses the cost ($0.50 per call), payment method (x402 on Base), and that the output includes a signed, offline-verifiable receipt. It also describes the verdict types (TRUSTED/CAUTION/AVOID). This goes beyond basic functionality, but does not confirm whether the tool is idempotent or if any state changes occur.

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 structured but contains notable redundancy—the second paragraph largely repeats the first. It uses clear language and front-loads key information, but could be tightened by removing duplicate content. Not excessively long, but not optimally concise.

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 no output schema and missing annotations, the description provides a comprehensive overview: input format (wallet or domain), parameter details, output shape (full report with verdict and signed receipt), and cost structure. An agent can make an informed decision to invoke this tool based on the given context.

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

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

Input schema coverage is 100%, so baseline is 3. The description adds extra context for the 'depth' parameter by stating the approximate number of settlements (~200 for shallow, ~500 for deep), which provides meaningful guidance beyond the schema's enum values. The 'seller' parameter is also clarified with examples.

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

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

The description clearly states it performs a deep audit of an x402/ACP seller, listing specific components (on-chain settlement reputation, endpoints, liveness, web reputation) and outputs a verdict with a signed receipt. It distinguishes itself from simpler pass/fail badges, making the purpose very specific and actionable.

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 implies this tool is for deep due diligence beyond a simple badge, but it does not explicitly mention when to use this vs. alternatives like the sibling 'x402_seller_trust'. No exclusions or prerequisites are stated; only basic input requirements are given. Lacks explicit guidance on when not to use.

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

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

No annotations provided, so description carries full burden. It discloses key behaviors: uses on-chain settlement graph, checks wash-trade and sybil signals, provides signed receipt, costs $0.01 per call. Good transparency.

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 main action. Each sentence adds value. No fluff.

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, but description explains return values (verdict + confidence + receipt) and signals. Also mentions pricing. Adequate for 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 100% but description adds context: depth values explained (~200 vs ~500 settlements) and seller_wallet purpose clarified. Adds meaning beyond schema.

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

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

Description clearly states the tool 'Score an x402 seller wallet BEFORE paying it' and provides verdict categories. However, it does not explicitly differentiate from sibling tools like x402_seller_audit.

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?

Description implies usage by saying 'Vet an unknown x402 endpoint or merchant wallet before you pay', but lacks explicit when-not-to-use or alternative tools.

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