Tanod Security

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes further with material context: 'Nothing is signed or sent,' error semantics (422 for bad input, 502 for failed read, neither charged), runtime (3-15 s), price (USD 0.005), a free tier (10 chain reads per IP per UTC day), and a docs link. This is rich disclosure beyond the structured 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?

Front-loads the verb and the sibling routing, then layers return fields, risk tiers, errors, timing, and pricing. Dense but mostly load-bearing per sentence. It loses a point for enumerating return fields ('amount, `unlimited`, spender code... `revoke`') that the output schema already supplies.

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 6-parameter, Permit2-aware audit tool the description covers scope, candidate sources, risk semantics, staleness, errors, latency, cost, and safety. With an output schema present, the return values needn't be re-explained, and nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description nonetheless adds behavior beyond the schema by explaining that the 6,000-block scan only surfaces recent candidates and that older approvals require `spenders` or Permit2, plus how risk tiers (High/Medium/Low) are assigned from unlimited/key-controlled vs contract-with-no-code distinctions.

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

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

States a specific verb+resource+scope: 'List a wallet's live token approvals and get revoke transactions,' naming ERC-20 and Permit2 coverage in the title. It explicitly distinguishes itself from two siblings, check_wallet_drain (already-drained tokens) and get_allowance (single allowance), so an agent can route without opening any schema.

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

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

Gives explicit when-to-use routing ('For tokens already pulled out use check_wallet_drain; for one allowance use get_allowance') and an edge-case condition ('Older approvals are found only via `spenders` or Permit2'). It also explains when the spenders/lookback_blocks path is the necessary choice.

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 only cover the read-only/idempotent safety profile; the description adds the real behavioral payload: the exact read performed (one token, last 2,000 blocks), the lookalike matching rule (first 4 and last 4 hex chars), the high/medium/low decision rules, error semantics (422 bad input, 502 failed read, neither charged), latency (0.5-4 s), price and a free-tier rate limit.

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

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

A single dense paragraph, front-loaded with the purpose and the sibling routing before the mechanics. Nearly every clause carries information (risk rules, errors, price, quota), though the length and lack of sentence breaks make it harder to scan than it needs to be.

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

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

Output schema exists, so return values need not be explained, yet the description still summarizes the `risk` field and its reason/evidence shape. Combined with the error mode and rate-limit disclosure, an agent has everything needed to invoke and interpret this tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters including defaults, ranges and the dust/lookback semantics — the baseline is 3. The description reinforces the read scope (one token, default USDC, ~2,000 blocks) but adds no syntax or constraint detail 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?

States a specific verb (check), resource (transfer recipient), and threat (address poisoning) and spells out the detection method — lookalikes in the sender's history. It explicitly names the sibling tools it is not (transfer_preflight, check_sanctions), so an agent can route without opening any schema.

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

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

Explicitly routes alternatives: 'For balance, gas and blacklist checks too use transfer_preflight; for OFAC use check_sanctions.' It also states scope limits ('Older history, other tokens and other lookalikes are not seen'), so the agent knows when results will be incomplete.

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

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

Annotations already establish the safe read-only, idempotent profile, and the description goes well beyond them: USD 0.005 pricing, free-tier quota (3 scans / 30 checks per IP per UTC day), p95 ~1 s and max ~4 s latency, 10-minute result caching, and the failure semantics ('if the chain cannot be read the call fails and is not charged'). The heuristic limitations and specific risk signals detected are unusual, valuable disclosure.

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

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

Front-loaded with purpose, then routing, then returns, then cost/limits/limitations in a logical order. It is long and packs in a pricing figure and docs URL that are useful but not strictly needed for invocation, keeping it just short of a clean 5.

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

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

Even though an output schema exists, the description summarizes the return shape (verdict enum, risk_score 0-100, plain-language reasons) with concrete examples. Combined with cost, latency, caching, and failure behavior, an agent has everything needed to decide whether and how to call it.

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

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

Schema coverage is 100% with a documented enum on chain, so the schema already carries both parameters. The description restates the supported chains and the address's role but adds no syntax or format detail beyond the schema, so the 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?

States a specific verb and resource ('check an address for risk') and pins the exact moment of use ('right before you send a transaction to it, approve it, or buy its token'). It explicitly names two siblings it is not (scan_contract_address, check_token_honeypot), so an agent can route without opening either schema.

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

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

Gives explicit when-to-use triggers plus named alternatives with the condition that selects each: full verified-source scan goes to scan_contract_address, sellability goes to check_token_honeypot. It also states the scope limits ('Heuristic, not an audit', 'a low verdict is not a clearance'), which is exclusions-level guidance.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior. The description adds substantial context beyond that: the exact list and date basis, false-negative caveat, compliance limitations, verification link, latency, price, and free-tier limit. Nothing contradicts the annotations.

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

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

Front-loads the core purpose and alternatives, then packs caveats, limits, and pricing into a single dense paragraph. Every sentence carries operational information, though the result is long and could be more scannable.

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 screening complexity, single-address schema, existing output schema, and safety annotations, the description covers scope, alternatives, limitations, timing, cost, and verification guidance. It omits nothing material for correct selection or 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 covers the address parameter at 100% with a description and pattern. The description adds matching semantics: EVM/bech32 addresses match case-insensitively while base58 BTC, TRX, and other formats must be provided exactly as listed, useful for correct input formatting. It does not restate the schema's length/pattern constraints.

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

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

States a specific verb and resource: screen one crypto address against the US OFAC SDN digital-currency list. It explicitly names the sibling tools check_sanctions_batch and check_address_poisoning and distinguishes single-address vs lookalike use cases, so an agent can select it without opening schemas.

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 routes to alternatives: use check_sanctions_batch for up to 1,000 addresses and check_address_poisoning for lookalikes. It also states scope (OFAC SDN digital-currency addresses only), that a non-match does not clear, and that this is not legal advice or full compliance.

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

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

Annotations already establish readOnly/idempotent/non-destructive, yet the description adds substantial behavior beyond them: per-address and per-call pricing with a minimum, error semantics (422 naming the offending index, not charged), latency (~0.5 s for 1,000), data-handling (submitted text never logged or stored), and honest limitations (non-match does not clear an address; not legal advice; verify at OFAC). That is exactly the kind of context structured fields cannot carry.

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

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

Front-loaded and dense with useful facts, but there is real repetition: sentence three ('Returns the OFAC sanctions screen of 1-1,000 crypto addresses in one call') restates sentence one, and the batch-size/pricing figures appear multiple times. Trimming the redundant return line and price restatement would sharpen it 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?

An output schema exists, so return values need not be explained. Given that, the description covers everything else an agent needs before calling: matching rules, batch limits, cost bounds, failure mode, latency, data retention, and legal caveats. Nothing material is missing for a one-parameter screening 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 the baseline would be 3, but the description goes further: it explains that EVM and bech32 entries match case-insensitively while other formats are matched exactly as listed, that pricing is per address, and that a single invalid item aborts the batch with a 422 identifying its index. That is meaning the schema's regex and min/max alone do not convey.

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

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

States a specific verb (screen), resource (crypto addresses), and scope (up to 1,000, against the OFAC SDN list) in the first sentence, then explicitly names the sibling it is not for: 'For one address use check_sanctions.' An agent can pick between the batch and single-address tools without opening either schema.

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

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

Names the alternative tool and the exact condition that selects it (single address → check_sanctions), and bounds the batch regime with concrete limits (1-1,000 per call, one invalid item fails the whole batch). This is explicit when-to-use/when-to-use-something-else guidance rather than implied context.

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

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

Annotations already cover the read-only/idempotent safety profile, yet the description layers on substantial behavioral detail: private/internal/IP-literal targets are refused with 422 and not charged, max 4 redirects, ports 80/443 only, latency 0.3-2 s, price, free tier, and a prompt-injection warning about treating page text as untrusted. This is well beyond what the structured fields convey.

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

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

Front-loaded with purpose and sibling routing, followed by scope caveat, mechanics, and pricing. Every sentence carries information, though the operational details (latency, price, free tier, docs URL) make it dense; nothing is wasted.

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?

An output schema exists, so return values need not be spelled out, yet the description still names score/grade/deduction and the redirect chain. With the one required param, safety annotations, and full behavioral constraints all present, an agent has everything needed to call it correctly.

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

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

With one parameter at 100% schema coverage, the schema already documents the url field, so the baseline is 3. The description adds real meaning about what the URL may be: public http(s) only, ports 80/443, redirect handling, and refusal of private/internal targets.

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

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

States a specific verb (grade) and resource (a public page's HTTP security headers) and enumerates exactly which headers are evaluated. It explicitly names the sibling tools it is not (check_url_phishing for phishing lists, inspect_domain for DNS/TLS), so an agent can distinguish it without opening any schema.

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

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

Gives explicit routing: 'For a phishing-list check use check_url_phishing; for DNS and TLS use inspect_domain.' It also states scope limits ('grades one response's headers, not the site... not an audit'), which is when-not guidance of the highest value.

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?

Despite annotations already covering readOnly/idempotent/destructive, the description adds unusual depth: source-level degradation ('each part says unavailable when its source is down'), error semantics (422 for bad address or non-mint), billing behavior ('a failing RPC is never charged'), latency envelope (2-6 s typical, ~25 s max), price and free-tier quota, and an explicit prompt-injection warning about returned page text.

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

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

Purpose and sibling routing are front-loaded, then operational caveats. It is long and dense, but nearly every clause carries distinct information (timing, pricing, degradation, untrusted-data warning); only the redundant title text and the doc-link tail are padding.

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

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

For a read-only heuristic scan with an output schema and full annotations, the description covers what an agent still needs to decide and act: inputs, latency budget, failure modes, partial-result behavior, cost, and quota. Nothing material is left to inference.

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?

Both parameters are fully documented in the schema (100% coverage), including the 5%-of-supply cap and the `sell_route.amount_usd` echo. The description only gestures at the sell quote ('as a loss number') without adding format or syntax beyond the schema, so it sits at the baseline for high-coverage schemas.

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

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

States a specific verb and resource ('Check a Solana token for rug risk') and enumerates the concrete outputs: mint/freeze authority, Token-2022 risks, top-10 holder share, Jupiter sell quote, risk level with reasons. It explicitly routes away from the two nearest siblings: 'For authorities alone use get_solana_token_info; for ERC-20 tokens use check_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?

Gives explicit when-to-use plus two named alternatives with the selecting condition (authorities-only lookups; ERC-20 tokens). It also sets expectations about when results are not trustworthy ('Heuristic, not an audit; a snapshot of now') and what to do with the data (treat as untrusted).

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 only declare readOnly/idempotent/non-destructive; the description goes far beyond them. It discloses the exact return fields (type, line, column, offset, confidence, redacted preview), that the secret itself is never returned and how redaction works, that detection is pattern-based with a false-negative caveat, the 422 on blank input (not charged), latency, price and free tier, and that text is never logged.

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

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

Front-loaded with purpose and sibling routing, then operational facts; almost every sentence carries decision-relevant information. The long vendor enumeration (AWS, GitHub, GitLab, Stripe, Slack, Google, OpenAI...) is the one part that runs long, though it usefully signals detection breadth.

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 scanning tool with an output schema, the description already covers everything an agent needs: what is detected, what is returned, error behavior, latency, cost and privacy. Nothing material is left to guesswork.

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

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

Schema coverage is 100% and the schema already documents maxLength and the no-logging guarantee, so the description's repetition there earns little. It does add semantic meaning by naming what the input typically is (a log, draft post, message, tool result, config file) and by restating the no-secret-returned contract at the call site.

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

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

States a specific verb+resource ('Scan text for leaked secrets') and enumerates the exact detection classes (API keys, tokens, private keys, seed phrases). It explicitly distinguishes itself from two named alternatives, redact_pii and check_text_for_prompt_injection, so an agent can route without opening any schema.

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

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

Gives explicit when-to-use-this vs when-to-use-something-else: personal data goes to redact_pii, injected instructions go to check_text_for_prompt_injection. It also frames the trigger context ('before it is posted'). No inference is required to choose the right 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?

Annotations already establish read-only, non-destructive, idempotent, open-world behavior, but the description adds substantial operational detail: return fields, tax measured from real balances, 422 on bad address or non-contract and not charged, caching, latency, price, free quota, and untrusted-data handling. No annotation contradiction is present.

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 purpose and then dense with useful limits, errors, pricing, and security context. It is longer than typical but mostly earns its length; some pricing and documentation details are less central to immediate invocation.

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, an output schema, and full parameter schema coverage, the description is complete enough for correct invocation. It covers scope, alternatives, failure modes, latency, caching, billing, and security caveats without needing to duplicate every return value.

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 mentions the simulated buy/sell context and supported chains, but it does not add parameter-level detail beyond what the input schema already documents for token, chain, and amount_usd.

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

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

The description states a specific verb and resource: detect whether an ERC-20 token can be sold via simulated buy and sell-back with tax on Base or Ethereum. It explicitly distinguishes itself from the sibling check_token_safety, which adds contract flags rather than a tradability 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?

It names the alternative check_token_safety and the condition that selects it, and adds important usage caveats: heuristic not audit, no-pool tokens return unknown, delayed or wallet-gated sell blocks may pass, and the call is cached for 60 seconds. This gives clear when-to-use and when-to-trust guidance.

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

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

Annotations already establish read-only, idempotent, non-destructive, open-world, but the description adds substantial context beyond them: the verdict is derived from a simulated buy/sell and contract flags, it is heuristic not an audit, error semantics (422 non-token, 5xx unpaid RPC failure), latency bounds, price, free tier, and a prompt-injection warning on returned text. This is exactly the extra behavioral disclosure the dimension rewards.

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

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

Front-loaded with the trigger and alternatives, and nearly every clause carries distinct information. It is dense and somewhat run-on across a long block, which slightly hurts scanability, but there is little genuine waste.

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

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

For a read-only single-verdict tool with an output schema present, the description covers trigger, alternatives, method, uncertainty caveat, errors, latency, cost, and trust posture. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100% with only two params, both documented in-schema (chain enum with default, address pattern). The description names the supported chains but adds no syntax or format detail beyond what the schema already provides, so the baseline of 3 applies.

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

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

States a specific verb and resource ('token risk check before buying an ERC-20 on Base or Ethereum') and explicitly distinguishes itself from the two closest siblings, token_verdict and check_solana_token_safety. An agent can route correctly without opening any schema.

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

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

Front-loads an explicit 'Use when' trigger, then names the alternatives and the exact condition that selects them (written summary/share card → token_verdict; Solana → check_solana_token_safety). No inference required.

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

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

Annotations already establish read-only, idempotent, closed-world behavior, and the description adds substantial context beyond them: the two named source lists and their refresh cadence, the fact the URL is never fetched, the 422 invalid_input behavior (not charged), latency, $0.001 price, 10 free reads per IP per UTC day, and a no-logging privacy guarantee.

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

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

Front-loaded with the purpose and sibling routing, then moves through mechanics, caveats, and commercial terms in a logical order. Every sentence carries information, though the run-on middle paragraph about lists, return fields, and latency is denser than it needs to be.

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

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

Output schema exists, so return values need no explanation, yet the description still names the key fields and, more importantly, warns that absence from the lists is not a clearance. For a screening tool whose failure mode is false reassurance, that caveat is the essential missing piece and it is present.

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 3 baseline applies and the description exceeds it: it clarifies that the input is only parsed and never fetched, that host and parent domains are matched, and that the two parameters are alternatives rather than complements. These details go beyond the schema text without fully specifying precedence when both are supplied.

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

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

States a specific verb and resource ('Check if a URL or domain is phishing or a scam') and immediately differentiates itself from siblings by naming check_urls_phishing_batch for volume and check_security_headers for headers. An agent can select this tool without opening any schema.

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

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

Explicit routing: batches of up to 1,000 URLs go to check_urls_phishing_batch, header checks to check_security_headers, and the remaining single-URL/single-domain case is implicitly this tool. It also sets expectations about what negative results mean ('an unlisted host is not cleared'), which is usage guidance in the truest sense.

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

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

Goes well beyond the annotations: discloses that the URL is never fetched, names the two lists (PhishDestroy, Phishing.Database) and their refresh cadence, warns that an unlisted host is not cleared due to staleness, and specifies a 422 whole-batch failure naming the offending index (uncharged). Performance, pricing and privacy ('never logged or stored') are also disclosed.

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

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

Front-loads purpose and the sibling routing, then layers cost, error and caveat details. Dense but nearly every sentence carries distinct decision-relevant information; slightly long, which keeps it off a 5.

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

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

With an output schema present, return formatting need not be explained, and the description nonetheless covers pricing, failure semantics, performance, privacy and the staleness caveat. Nothing material is missing for correct invocation.

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

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

Schema description coverage is 100% and the single 'items' param already documents the 1-1,000 range, 2,048-char limit, and per-item pricing. The description reinforces the same facts but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Check up to 1,000 URLs or domains for phishing or scams in one batch') and explicitly distinguishes itself from the single-URL sibling check_url_phishing. An agent can select it correctly without opening the schema.

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

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

Explicitly routes single-URL callers to check_url_phishing and scopes itself to batch use ('1-1,000 URLs in one call'). The when-to-use decision is unambiguous, including the boundary at one item.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: verdict semantics (drained/review/clean) with the exact rules that trigger each, the 2,000-block scope, the four transfer classifications, error behaviour (422 bad input, 502 failed read, neither charged), latency (2-10 s), pricing and a free daily quota. This is unusually rich behavioural disclosure 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 purpose is correctly front-loaded, but the body is a dense multi-clause run-on that packs verdict rules, classifications, pricing, error codes and quotas into a single paragraph. Much of it earns its place, yet the wall-of-text format makes it harder to scan than a structured list would be.

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

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

For a paid, rate-limited security read, the description covers scope, verdict logic, edge cases (gasless orders look like pulls, smart-account/EIP-7702 wallets), failure modes, timing, cost and docs. An output schema exists, so return values need not be detailed, and nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so all four parameters are already documented, and the description largely restates them (default 2,000 blocks, USDC/USDT or up to 5 tokens). It adds no format or syntax detail the schema lacks, so the 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?

States a specific verb and resource ('check a wallet for a drain: find tokens pulled out without its signature') and explicitly routes the related case to a named sibling (audit_token_approvals). An agent can distinguish this from the other wallet/contract checkers without opening a schema.

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

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

Names the alternative tool and the condition that selects it ('For live approvals with revoke transactions use audit_token_approvals'), which is exactly the routing an agent needs. It does not cover other near-neighbours (get_wallet_counterparties, check_address_poisoning) or state when a drain check is unnecessary, so it stops short of the full when/when-not pattern.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantive context the annotations cannot: 0.2-1 s latency, USD 0.003 price, a 10-reads-per-IP-per-day free tier, and an explicit warning to treat returned page text and on-chain strings as untrusted data. That is exactly the value-add expected when annotations carry the safety burden.

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

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

Purpose and disambiguation are front-loaded, followed by a compact block of input, behavior, timing, price/quota, and safety notes. Every clause carries operational information and nothing is repeated.

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 paid, state-touching-adjacent decode tool this is complete: it covers inputs, no-signature behavior, latency, cost, quota, and untrusted-data handling, and an output schema already exists to carry return-value structure. No gaps an agent would need to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3 and the schema already documents both parameters. The description still adds semantics the schema does not: omitting `signature` triggers a selector lookup and returns every candidate that decodes cleanly, which materially changes how an agent should read the result.

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 gives a specific verb+resource ('decode EVM transaction calldata') and immediately positions it against sibling tools by pointing read calls to eth_call and transaction fetches to get_transaction. An agent can tell this apart from the many other decode_* siblings without opening a schema.

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

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

It explicitly routes two adjacent tasks elsewhere (eth_call for read calls, get_transaction for fetching a transaction), which is clear when-not-to-use guidance. However, the nearest sibling, decode_tx_logs, is never differentiated, so an agent decoding on-chain data still has to infer the boundary between calldata and logs.

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

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

Annotations already declare read-only/idempotent/non-destructive, but the description goes well beyond them: the exact read procedure (code, EIP-1967/1822/OZ legacy slots, slot 0, one multicall), the staleness caveat that an upgradeable proxy's implementation can change after the read, the 5xx-and-not-charged behavior on malformed node answers, typical latency (1-4 s), price (USD 0.002) and a free tier (10 reads per IP per UTC day).

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

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

Front-loaded with the purpose and the sibling exclusion, then a compact chain of procedural detail, caveats, and pricing. Dense but every sentence earns its place; the long `kind` enumeration is the only borderline element and it materially aids interpretation.

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 an output schema existing, the description covers everything an agent needs to call this correctly and interpret it: classification kinds, return fields, staleness caveat, failure semantics, cost, rate limits, and a docs link. Nothing material is missing.

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

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

Schema description coverage is 100% and the schema documents both `chain` (with enum) and `address` (with pattern/length), so the schema already carries the parameter burden. The description adds no parameter-level detail (no enum values restated, no address format guidance), so the baseline 3 applies.

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

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

States a specific verb+resource ('detect whether a contract is a proxy, and of which kind') and immediately distinguishes itself from the closest sibling: 'For code size and hash use get_contract_code.' An agent can pick it out of the very large sibling list without opening a schema.

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

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

It explicitly routes the code-size/hash use case to get_contract_code and describes the trigger context (you want proxy classification and implementation/admin/beacon). It does not, however, address when this is preferable to siblings like scan_contract_source, check_contract_before_interaction, or get_storage_at, so the guidance is clear but not exhaustive.

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 cover safety (readOnly, idempotent, openWorld, non-destructive), and the description adds context annotations cannot: 422 for non-readable ERC-20, 5xx for malformed node answers, that neither is charged, typical latency 0.2-1s, price $0.002, the 10 free reads/IP/day quota, and a prompt-injection caution about returned on-chain strings.

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

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

Purpose and the sibling routing are front-loaded in the first two sentences; the rest is dense but each clause carries distinct operational value (error codes, price, quota, security note). Slightly run-on, but nothing is filler.

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

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

For a paid, cross-chain read tool this covers everything an agent needs: scope, alternative, failure semantics, cost, rate limit, latency, and an output-trust warning. An output schema exists, so return-shape explanation is correctly omitted.

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 regex patterns and an enum, so all four parameters are already fully documented. The description adds only the chain list, which duplicates the enum. 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?

States a specific verb (read) and resource (ERC-20 allowance) plus the exact supported chains, and names the sibling to use for a different need (audit_token_approvals). An agent can tell it apart from get_balance or audit_token_approvals without opening a schema.

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

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

Explicitly routes the alternative case: 'For every live approval of a wallet use audit_token_approvals.' Combined with chain scope and the free-tier/price note, the agent knows when this tool is the right call and when it is not.

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?

Far beyond the readOnly/idempotent annotations, it discloses the privacy contract (text never logged or stored, never returned), the enforcement mechanism (only short fixed-pattern tokens can reach the caller's model), that auth results are read as-is and not verified, that a mail with no code is a normal charged answer, latency (<0.1 s), price (USD 0.002), free tier (10 calls/IP/UTC day), and an untrusted-data warning.

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

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

Purpose and the verify_email routing are front-loaded, but the body is one dense run-on sentence and repeats the same point three times ('without the email body', 'never the email body', 'the email body is never returned'), which wastes budget in an otherwise information-rich definition.

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

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

For a single-parameter, output-schema-backed read tool, the definition covers purpose, routing, extraction limits, privacy, pricing/rate limits, error semantics, and a prompt-injection caution. Nothing an agent needs to call and interpret it correctly is missing.

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

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

With a single parameter and 100% schema description coverage, the schema already explains that 'email' accepts raw RFC 822 text or body text and that the Authentication-Results header is needed. The description largely restates this ('from a raw email or text', 'never logged or stored and never returned'), adding little the schema does not carry.

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

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

The description states a precise verb and resource ('Get the verification code or magic link from an email'), plus the key scope constraint ('without the email body'), and names the sibling it is not ('To check an address before sending use verify_email'). An agent can distinguish it from verify_email and the phishing-URL siblings without opening any schema.

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

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

It explicitly routes one adjacent task to verify_email with the selecting condition ('before sending'), which is exactly the ambiguity an agent would face. It does not, however, spell out when-not-to-use this tool (e.g. for body summarization or general email reading), so guidance is clear but not exhaustive.

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?

Adds substantial context beyond the readOnly/idempotent/destructive annotations: the 1,000-transfers-per-direction truncation, stablecoin-at-1-USD pricing, 422/502 error semantics with no charge, 1-10s latency, USD 0.005 cost, and free-tier rate limits. Also warns to treat returned text as untrusted data.

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

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

Front-loaded with the core purpose and alternative before operational details. Dense and somewhat long, with the title phrase repeated, but every sentence carries usable information and there is no padding.

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

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

Covers purpose, scope (ERC-20 only, chains), limits, errors, latency, pricing and rate limits; output schema handles return fields. Nearly complete for a read tool, with only minor redundancy against the title.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters including ranges, default, enum and address pattern. The description largely restates these (days 1-90 default 30, ERC-20 only) and adds only marginal detail (stablecoin valuation), 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?

States a specific verb and resource: 'List a wallet's top counterparties: who an address sends to and receives from, by count and volume.' It also distinguishes itself from a related sibling by pointing to get_erc20_transfers for the raw transfer list.

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

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

Gives clear context ('A pre-send or due-diligence check') and names an alternative ('For the raw transfer list use get_erc20_transfers'). No explicit when-not conditions, but the usage context is well established.

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 cover the safety profile (readOnly, idempotent, non-destructive, open world), and the description adds substantial context beyond them: latency (1-3 s), price (USD 0.01 / 0.004 per section), a free tier of 5 per IP per UTC day, the heuristic caveat, and an explicit untrusted-input warning for returned page text and on-chain strings. That is rich operational disclosure.

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

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

Front-loads purpose, then alternatives, then returns, then cost/limits/caveats, then docs. Every clause carries information an agent needs; nothing is padding.

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

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

An output schema exists, yet the description still summarizes the return payload (records, SPF/DMARC/DKIM/MTA-STS, deliverability score_out_of_8, cert expiry/SANs/key/trust), and it covers cost, rate limits, latency, and safety caveats. Nothing material is missing for correct invocation.

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

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

Schema description coverage is 100% and both parameters are documented in-schema, so the baseline is 3. The description hints at section selection via 'single section' pricing and enumerates the three sections, but adds no syntax or constraints beyond what the schema already 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?

States a specific verb and resource ('inspect a domain's DNS, email authentication and TLS cert in one call') and explicitly differentiates from siblings rdap_lookup (registration data) and check_domain_availability (availability). An agent can route correctly without opening any schema.

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

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

Explicitly names the two adjacent tools and the conditions that select them, plus what the tool does not do ('Heuristic, not an audit'). When-to-use and when-to-use-something-else are both covered.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, and the description adds substantial context beyond them: found:false semantics, 422 (uncharged) for reserved addresses and RDAP-less TLDs, IANA bootstrap sourcing, redacted fields surfaced as null in `redacted` and never guessed, latency, price, free tier, and an untrusted-data warning.

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

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

It is dense and long, but front-loads the purpose, then routing, then return shape, pricing and safety. Nearly every sentence carries actionable information, though the breadth of detail could be trimmed.

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 a single-param tool with an output schema, the description still covers everything an agent needs: routing, input forms, return semantics (found, redacted), error behavior, cost, rate limit, and a prompt-injection caveat.

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 there is a single `query` parameter, so the schema already documents accepted formats. The description restates the domain/IP/AS forms but adds no syntax or edge-case detail beyond the schema, matching the baseline-3 rule.

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

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

States a specific verb and resource ('RDAP registration lookup' of a domain, IP, or AS number) and explicitly distinguishes itself from siblings inspect_domain and ip_lookup. An agent can tell exactly which tool to pick without opening a schema.

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

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

Names the alternatives and the conditions that select them: 'For DNS and TLS use inspect_domain; for an IP's ASN and reverse DNS use ip_lookup.' It also gives the when-not signal (found:false for unregistered domains, 422 for private/reserved addresses).

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

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

Goes well beyond the readOnly/idempotent annotations: 6-hour cache with data_synced_at, partial answers billed at 200, 404/503 unbilled, 429 rate limiting with retry_after_s, typical latency under 1 s (up to ~12 s on slow sources), and a prompt-injection caution about returned page text. Annotation-consistent and adds real behavioral context for billing and retry decisions.

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

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

Purpose and returned facts are front-loaded before the operational details, and every clause carries information an agent needs (cost, cache, error codes, latency). It is dense and semicolon-chained, with licence/attribution boilerplate and a docs URL adding bulk, but little is genuinely wasted.

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

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

With an output schema present, the description needn't explain return values, and it still covers cost, caching, failure modes, rate limits, latency, and trust handling. For a single-parameter read-only tool this leaves nothing material for an agent to discover by trial.

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

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

Schema description coverage is 100% and the schema already documents owner/name forms, github.com URLs, trailing .git or /, and renamed-repo resolution. The description adds only tangential semantics ("Unknown repo 404"), which doesn't meaningfully extend the accepted input formats. Baseline 3 applies.

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

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

Names a specific verb and resource ("Get health facts for a GitHub repository") and enumerates exactly which facts: stars, licence, activity, latest release, dependents, OpenSSF Scorecard. No sibling tool covers GitHub repository metadata (check_mcp_server and scan_agent_package target different artifacts), so an agent can select it unambiguously.

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

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

Usage is implied by the enumerated facts rather than stated: nothing says when to reach for this versus, say, check_mcp_server or scan_agent_package. The description does provide operational context (free tier of 10 calls/IP/day, USD 0.003 price, caching window), which helps an agent decide whether the call is worth making, but no explicit when/when-not guidance.

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

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

Goes well beyond the readOnly/openWorld/idempotent annotations: it describes the sandbox ('reads every file as text in a sandbox'), confirms it neither executes nor installs, warns that 'safe-looking' means only 'no rule matched', advises treating output as untrusted data, and adds latency bounds (2-15 s, up to 60 s) plus pricing/free-tier limits. This is unusually rich behavioral context.

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

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

Purpose is front-loaded and almost every sentence carries actionable information (alternative routing, limitations, timing, cost). It is dense and long, with pricing/free-tier and docs-link content that borders on non-essential, but nothing is redundant with structured fields in a wasteful way.

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

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

For a scan tool with an output schema already present, the description still adds value by naming the verdict/risk_score/findings shape and enumerating the finding categories. Combined with limitations, non-execution guarantees, timing, and cost, an agent has everything needed to decide and call 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 the schema already documents source, filename, and content_base64 formats in detail. The description adds no parameter-level detail (e.g. no syntax hints or source/content mutual-exclusion note) beyond what the schema provides, so the 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?

States a specific verb and resource ('Scan an AI-agent skill or MCP server package before installing it') and immediately distinguishes itself from the sibling check_mcp_server by naming the alternative and its purpose. An agent can tell exactly what this does and how it differs from the reachability-checking sibling.

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

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

Gives an explicit usage condition ('before installing it'), names the alternative tool with the condition that selects it ('To see whether a remote MCP server answers use check_mcp_server'), and enumerates the cases where it will not help (dynamic tool registration, runtime downloads, nested archives, obfuscated logic). When/when-not/alternative are all present.

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

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

Goes well beyond the annotations (readOnly, idempotent, non-destructive): it discloses pricing tiers, the free daily quota, that refused/unverified inputs are never charged, a 503+Retry-After queue behavior, and a candid disclaimer that results are heuristic and can produce false positives. This is exactly the extra context annotations cannot carry.

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

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

Dense but front-loaded: purpose and sibling routing come first, then mechanics, then pricing/safety caveats. Every sentence carries operational information, though the pricing/quota/latency block is long and could be trimmed slightly without loss.

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 complex, paid, networked analysis tool this is complete: it covers inputs, refusal conditions, latency, failure modes, cost, safety caveats, and a docs link. Return contents are summarized briefly and an output schema exists to carry the detail.

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

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

Schema description coverage is 100%, so every parameter (chain enum, address pattern, the three include_* booleans) is already documented in the schema. The description adds no syntax or format detail beyond it; the 'verified source fetched from Sourcify' line is contextual, not parameter-level. Baseline 3 applies.

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

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

States a specific verb and resource ('Scan a deployed, verified contract on Ethereum or Base for security bugs, by address') and explicitly names the sibling it is not ('For source you hold use scan_contract_source'). An agent can distinguish it from scan_contract_source and check_contract_before_interaction without opening any schema.

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

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

Gives explicit routing rules: use scan_contract_source for source you hold, and check_contract_before_interaction when the contract is unverified (which this tool refuses). It also states the tool's operational envelope (3-30s, 60s max, 503 on queue), so an agent knows exactly when this tool applies versus alternatives.

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

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

Annotations already establish read-only, non-destructive, idempotent, closed-world behavior, and the description layers on non-schema facts: the toolchain it runs (solc, Slither, custom DeFi detectors), output formats (JSON findings with severity/confidence/file:line/fix, plus Markdown), latency bounds (1-5 s typical, 60 s cap), rate limits, error semantics, and an honest false-positive disclaimer. That is unusually rich behavioral disclosure.

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

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

Front-loaded with purpose, then the routing rule, then mechanism, output, price, availability, timing, and caveats — a sensible priority order. It is dense and every clause carries information, but the pricing/free-tier/timing block makes it longer than most agents need in one pass.

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 7-parameter, zero-required tool with an output schema (so return shape needs no full exposition), the description still covers selection, cost, rate limits, latency, failure behavior, and the epistemic limits of the result. An agent has everything needed to decide and invoke.

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

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

Schema description coverage is 100% and each parameter (source vs standard_json, filename, the three include_* toggles, compiler_version) is already documented in the schema. The description adds no per-parameter meaning beyond the nSLOC pricing tiers loosely implying input size, so the baseline 3 applies.

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

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

States a specific verb and resource (scan Solidity source code for security bugs) plus the use context (before deploy, review, or dependency). It explicitly names the sibling it must not be confused with: 'For a deployed verified contract use scan_contract_address.' An agent can route correctly without opening either schema.

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

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

Gives explicit when-to-use ('before you deploy, review or depend on it'), the when-not/alternative ('For a deployed verified contract use scan_contract_address'), and operational guidance (free tier limits, 503 + Retry-After on a full queue, refused inputs never charged). Nothing about selection is left to inference.

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

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

Annotations cover safety (readOnly, idempotent, non-destructive), and the description adds substantive operational context beyond them: under 1 s latency, USD 0.001 price, 10 free calls per IP per UTC day, and an explicit privacy guarantee that submitted text is never logged or stored. It also enumerates the return categories (risk levels, positions, CVE references, confusables, normalization status).

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

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

Front-loads purpose, then sibling routing, then return detail, then pricing/privacy/docs — a logical order with no filler sentences. It is long, but each clause carries distinct information; only the pricing/rate-limit block extends it beyond strict necessity.

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

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

For a read-only, idempotent inspection tool with a full output schema and 100% parameter coverage, the definition leaves nothing material unstated: it covers what is detected, return shape, cost, limits, privacy, and performance.

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

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

Schema description coverage is 100% and every parameter is self-documented in the schema, so the baseline is 3. The description touches on normalize/strip behavior only in passing ('optionally the text normalized or with invisible characters stripped'), adding framing but no syntax or semantics beyond what the schema already states.

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

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

States a specific verb+resource ('Find invisible, bidi and homoglyph Unicode characters in text') and immediately distinguishes itself from the adjacent sibling check_text_for_prompt_injection. An agent can tell what it does and when not to reach for it without opening the schema.

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

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

Explicitly routes the injected-instruction case to check_text_for_prompt_injection, which is the closest competing sibling. It gives clear context but no further when-not guidance (e.g., vs text_stats or redact_pii), so it stops short of full alternative coverage.

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

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

Goes well past the annotations: cost (USD 0.01), free quota (10 chain reads/IP/UTC day), latency (3-9 s, up to ~25 s), error semantics (422 for non-token, 5xx not charged), and the paid-vs-free summary_source difference. It also flags the heuristic nature ('not an audit') and warns that returned page text and on-chain strings are untrusted data, which is exactly the kind of prompt-injection context an agent needs.

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

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

Front-loaded with purpose, then alternative, then return payload, then caveats, pricing and latency. Dense but every sentence carries signal; only the trailing docs URL and the security note feel bolted on rather than wasteful.

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

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

With an output schema and full annotation set already present, the description still covers cost, quota, latency, failure modes, verdict vocabulary, and data-handling cautions. Nothing an agent needs to decide and call correctly is missing.

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

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

Schema coverage is 100% with per-parameter descriptions and enums, so the baseline is 3. The description adds a little beyond it: the 'url' output persists for 24 hours and the file is the PNG verdict card, and it identifies summary_source as the template-vs-model switch.

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

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

Specific verb and resource: 'Token risk verdict in plain language for a Base or Ethereum token, with a shareable card,' with the returned verdict enum spelled out. It also names a sibling (check_token_honeypot) as the simulation-only alternative, so an agent can route without opening schemas.

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 carves out the alternative case: 'For the simulation alone use check_token_honeypot.' Beyond that it gives operational context (price, free tier, latency, error codes) rather than additional when/when-not guidance versus siblings like check_token_safety or scan_contract_address, so it stops short of a 5.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, but the description adds substantial context beyond them: DNS-only with no mail-server contact, that mailbox existence is explicitly not verified, typical latency 0.1-1 s, cost USD 0.001, and a free tier of 5 per IP per UTC day. It also warns to treat returned page text and on-chain strings as untrusted.

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

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

Front-loads the purpose, then layers scope, latency, pricing and safety guidance in distinct sentences with no filler. The one weak spot is the 'returned page text and on-chain strings' untrusted-data warning, which is generic boilerplate poorly matched to an email-verification tool.

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

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

An output schema exists so return values need no explanation, the single parameter is fully documented, and annotations cover the safety profile. Adding latency, price, rate limit and scope caveats makes it complete for correct 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?

Only one parameter with 100% schema description coverage, so the schema already carries the semantics. The description adds no format or syntax guidance for the email argument beyond what the schema states, making the baseline 3 appropriate.

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

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

States a specific verb+resource ('verify an email address') and enumerates exactly what is checked (syntax, MX, null MX, A/AAAA fallback, disposable list, role parts, free providers) and what is not (no SMTP/RCPT, mailbox existence unverified). It explicitly names the sibling inspect_domain as the tool for SPF/DMARC/DKIM, so the agent can separate them without opening either schema.

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

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

Gives concrete when-to-use contexts ('before you send to it or accept it at sign-up') and routes domain-level email auth checks to inspect_domain. The scope boundary (DNS-only, no mailbox probing) tells the agent when this tool is insufficient.

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