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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld=false, so the safety profile is covered. The description does add behavioral substance beyond that: it pins the metric to versioned definitions (rank.independence.v1, rank.inflation.v1, cluster.ratio.v1), states the 30-day window, the three-operator-set threshold, the three-hop cap, and the 50-link bound. It never states units, error behavior, or how a missing/invalid agent is handled, so it is solid but incomplete.

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 content is front-loaded with the main return value, which is good, but it is delivered as one massive run-on sentence with deeply nested parentheticals that make the scoring rule hard to parse. No sentence is wasted, yet the packaging actively hinders readability.

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

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

With no output schema, the description correctly carries the burden of enumerating return fields, and it does list them. But it neither explains the '(free)' pricing signal nor the distinction between the published and cluster-aware L9 counts in a way an agent can act on, leaving meaningful gaps for a metric this opaque.

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

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

There is a single parameter with 100% schema coverage, and the schema already documents that it accepts an agent token id, slug, or bound wallet. The description adds nothing about the 'agent' argument beyond what the schema provides, 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?

The description states the exact outputs (independence score, path, L9 counterparty counts, inflation ratio, operator set size) for a single agent, which identifies the resource well. However, no verb is used ('For one ranked agent: its independence score...') and it never distinguishes this from close siblings such as agent_stability or ranked_agents. The purpose is discernible but not crisply stated.

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

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

There is no when-to-use, when-not-to-use, or alternative routing anywhere in the text. The title's '(free)' hints at a cost dimension but the description never tells the agent when to call this versus agent_stability or ranked_agents. An agent must infer usage entirely.

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 goes well beyond them: shadow mode means 'nothing is signed yet', the result is valid only three hours, unchecked checks are 'listed, never written as 0', and it explicitly disclaims safety/verification/trust and any forward-looking guarantee. That is exactly the behavioral context an agent needs to interpret the output honestly.

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 and the eight checks are front-loaded, followed by return shape and then the non-claim caveats. The check list is a dense run-on but every clause is load-bearing; a little pruning could improve readability 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?

With no output schema, the description fully carries the return contract: holds or not, which checks failed, which could not be taken, the checked-at and expiry timestamps, and the issuer public key. Nothing an agent needs to interpret or call the tool 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 already documents the single parameter with accepted forms (token id, act_8453_N, slug, bound wallet). The description adds no further parameter semantics, so the baseline 3 applies – the schema carries the burden.

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

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

The description names a specific resource (the ledger's measurement of one registration under agent.pass.v2) and enumerates exactly the eight checks it reports, so the agent knows precisely what comes back. It is distinguishable from generic siblings by scope, though it never names an alternative (e.g. agent_statement, gate_check) to sharpen the contrast.

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

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

There is no explicit when-to-use or when-not guidance, and no sibling is named as an alternative. The 'valid three hours' and shadow-mode notes imply a freshness/read-only context, but the agent must infer when a Pass lookup is the right call versus pay_check, gate_check, or agent_statement.

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

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

Annotations already establish readOnly, idempotent, non-destructive, non-open-world semantics, but the description adds genuine context beyond them: shadow mode means nothing is blocked, levels are non-authoritative patterns for humans, and every figure carries a measurement time and definition id. It also discloses the shape of what comes back (fired reasons, 30-day notable/major count, market rates). It stops short of describing caching or latency behaviour.

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, but the body is a single sprawling sentence with a deeply nested parenthetical list of eight signals, which is hard to parse on first read. The signal taxonomy is arguably definitional rather than decision-relevant for selecting the tool. Size is defensible for a tool with no output schema, but structure is weak.

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

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

There is no output schema, so the description must explain the return values, and it does: the score, the reasons that fired, the notable/major count over 30 days, the market rates, the none/notable/major levels, and the measurement time and definition id on every figure. Given one enum-free parameter and read-only annotations, 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% and the single `agent` property already documents accepted forms (token id, act_8453_N, slug, bound wallet), so the schema carries the parameter burden. The description adds no syntax or format detail beyond that. Baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific verb and resource: it scores an agent's newest counted payment against that agent's own earlier payments for out-of-character signals. The parenthetical enumerates the exact signals in the v2 definition, so an agent knows precisely what the output measures. It does not name any sibling (e.g. pay_check, detections, since_last) to differentiate scope, so 4 rather than 5.

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

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

There is no statement of when to call this versus the many sibling tools such as pay_check, detections, or since_last, nor any prerequisites or exclusions. The only interpretive note – that a level is a pattern for a human to read, never a verdict, and shadow mode blocks nothing – guides how to read results rather than when to select the tool. Usage is left entirely to inference.

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

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

Annotations already cover the read-only, idempotent, non-destructive, closed-world profile. The description adds real behavioral context on top: the exact content returned (rank, evidence, bindings, 25 newest payments) and the failure mode for unranked ids, which an agent needs to interpret an empty response correctly.

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

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

Two sentences, front-loaded with the resource and its contents, then the failure condition. Tight overall, though the closing 'to sell or show' is stylistic flourish rather than actionable 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?

With an output schema present, the description is not obligated to explain return values, and it still summarizes the payload plus the not-found case. Annotations carry the safety profile, so nothing essential 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 coverage is 100% and the single id parameter already documents accepted forms (token id, slug, wallet address). The description supplies an additional constraint the schema does not encode: the id must correspond to a ranked agent, otherwise the call returns not found.

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

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

The description names a specific resource with a precise scope: one ranked agent's rank with evidence, bindings, and its 25 newest payments with counterparties. The 'free' qualifier implicitly distinguishes it from paid siblings like evidence_pack_quote, but no sibling is named outright, so differentiation is left partly to inference.

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

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

Usage is implied rather than stated: it tells you the tool returns 'not found' for unranked ids, which implicitly tells an agent when this call will succeed. However, there is no explicit guidance on when to choose this over find_agent, agent_statement, or evidence_pack_quote.

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), but the description adds substantive context: the metric is a CUSUM over payments/USD/payees, a break is a change not a harm, and the false-break rate is published. This is genuine behavioural disclosure beyond the structured fields.

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

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

The primary measure is front-loaded, which is good, but the definition packs multiple nested parentheticals and jargon into a dense block. Every clause is informative, yet the run-on structure makes it heavier than it needs to be.

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

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

With no output schema, the description correctly compensates by enumerating the returned fields and their meaning (run_days, break date/feature, heartbeat classification with dispersion index and gap CV) and cites definition IDs. Only the absence of routing guidance to alternatives keeps it from being fully complete.

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

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

There is a single parameter with 100% schema description coverage ('Agent token id, slug or bound wallet'), so the schema carries the semantics. The description adds nothing about the agent argument, making this baseline adequate rather than enriched.

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

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

The description names the resource concretely — the behaviour clock for one ranked agent — and enumerates the returned measures (run_days, last break date/feature, 30-day heartbeat). It is clear what the tool produces, though it does not explicitly contrast itself with siblings like agent_record or since_last.

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

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

There is no statement of when to reach for this tool versus the many sibling metrics tools (agent_independence, since_last, metric_history). The reference to a published false-break rate hints at documentation but gives no usage conditions or exclusions.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantive behavior: the statement covers a closed 3-hour window, publishes a few hours after it closes, and therefore cannot show the last few hours. It also surfaces the staleness, chain_ok and flags refusal criteria and the Merkle/Ed25519 verification 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?

Front-loaded with the return payload, then the check-before-you-pay procedure, then the staleness caveat. The middle contents sentence is a long dense list, but each element is informative rather than filler; only minor tightening is possible.

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

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

With no output schema, the description carries the return-value burden and does so by naming each field group returned. It also supplies the staleness limitation and the verification workflow, so an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100% and the single 'id' parameter already documents that it accepts an agent token id, slug or bound wallet. The description adds no further parameter meaning, so the baseline of 3 for high-coverage schemas 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 retrieval verb and resource ('the latest 3-hour statement for one ranked agent') and enumerates exactly what the statement contains (payments out split into spend/routing/unread receipts, income, flags, prior hash, Merkle proof). The 3-hour-window and single-agent scoping distinguishes it from broader siblings like ranked_agents, agent_record and since_last.

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 gating rules: 'Check before you pay: refuse if stale, if chain_ok is false, or if flags is not empty', then chains to a named sibling ('then call find_agent and refuse if open_incidents is above zero'). This is a concrete when-to-use / when-to-refuse procedure with an alternative tool named.

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

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

Annotations already cover read-only/idempotent/non-destructive, and the description adds substantive behavior beyond them: data confirmed on chain, refreshed every six hours from free public nodes, allowances capped at balance per token, unpriced tokens listed by symbol only, and an explicit schema-version tag. It also rules out a common misuse (treating the result as a forecast).

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

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

Dense but front-loaded: the caller scope is stated first, then the returned fields, then the read cadence and the prediction caveat. Every clause carries information, though the single long middle sentence packs several concepts together and could be split for scanability.

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

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

With no output schema, the description does the heavy lifting by enumerating the return contents, their freshness, and their cost (free). It is close to complete for a read-only measurement tool; only edge behavior (e.g., what is returned for a wallet with no balances or allowances) is unaddressed.

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), so the baseline is 3; the description adds real value by clarifying they are alternatives — an agent id OR one bound 0x wallet address — which the flat schema does not express, along with the fact that neither is required.

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

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

Names a specific resource (an agent's or bound wallet's on-chain exposure at one block) and enumerates exactly what is reported: priced stablecoin/token/ETH balances in USD, the EIP-7702 delegate with code hash and sweeper family, and open ERC-20 allowances. This is clearly distinguishable from siblings like pay_check, gate_check, or agent_stability.

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?

States the eligible callers (an L8-or-above agent or one of its bound wallets) and frames the result's purpose ('A measurement of exposure at one block, not a prediction'). It does not name alternatives or say when another sibling such as pay_check or gate_check is the better call, so it stops short of full 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 annotations: it discloses the required Authorization: Bearer <Desk session> and that the session wallet is the operator, that private material is refused before validation, the freshness rule for bait keys, the two-minute chain polling cadence plus pushed ingest, that fires only go to the caller's canary log with nothing published, and a 25-canary shadow-period cap. These are exactly the side effects, auth needs, and limits an agent cannot infer from readOnlyHint=false / idempotentHint=true.

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 first sentence front-loads purpose, required fields, and auth, which is good, but the remainder is a single dense block mixing operator guidance, refusal rules, polling mechanics, and quota trivia in one paragraph. Much of it earns its place, yet the illustrative canary examples and repeated restatement of the public/private rule could be trimmed or split.

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 mutation tool with no output schema and a nested object parameter, the description covers auth, refusal behavior, polling cadence, and operational limits thoroughly. It is slightly incomplete on the return side: it never says what a successful registration returns, and canary_id (present in the schema) is not mentioned in the prose.

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, but the description adds real semantics the schema lacks: it lists the valid kind values (address|key|url|apikey|tool|x402) and the full watch trigger vocabulary (nonce, code, permit, siwe, inbound_transfer, http_hit, api_use, tool_call, x402_request), which are enums absent from the schema. It falls short of 5 only because it never explains which fields pair with which kind beyond a brief parenthetical.

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 ('Register the public part of a decoy you planted') and enumerates the accepted kinds, so the agent immediately knows this creates a canary record rather than reading one. It is clearly distinguishable from the sibling canary_status, which is a status/read 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?

Gives strong context for when to use it ('a canary is a decoy you plant where only an intruder or a misled agent would read it') and what to register (the PUBLIC part only, one target per canary). It does not explicitly name an alternative tool or state when not to use this one, but the conditions that select it are unambiguous.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: an Authorization Bearer session is required, the event window is capped at 20 per canary, and returned labels are untrusted text delivered in an untrusted envelope — a security-relevant 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?

Two sentences, front-loaded with the return payload before the auth and trust notes. The long parenthetical field lists are dense but each item is substantive rather than filler, so it stays close to earning every word.

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

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

With no output schema, the description carries the full burden of explaining return values, and it does: reading fields (nonce, code, balance, checks) and event fields (trigger, severity, evidence, test flag, plain-language reading, recommended action) are all named, plus auth and trust handling. Nothing needed 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The schema is trivially complete.

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

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

Names a specific resource (every canary you registered) and enumerates exactly what is returned: the watcher's last reading plus the newest 20 events per canary. The pairing with canary_register is implied by 'every canary you registered', but the sibling is never named, so an agent gets no explicit routing cue.

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

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

Usage is only implied: this is the read side of the canary lifecycle. There is no explicit statement of when to call it versus e.g. since_last or detections, and no exclusions or prerequisites beyond the auth requirement.

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 a safe, idempotent, read-only local operation, so the bar is lower. The description still adds real behavioral context beyond them: counts-only scope, the upsell boundary to the counterparty pack, and the counting rule that a routing-hop-only address is not a payee.

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

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

Dense but front-loaded: the primary use case and its returned fields come first, then the upsell boundary and the no-address fallback. Every clause carries information, though the list of counted fields is packed into one long sentence.

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

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

With no output schema, the description carries the burden of explaining return values and does so by enumerating the counts, time bounds, and exclusions. Domain terms (L7, Bazaar, binding confidence) are left undefined, but the shape of the response is clear enough to call and interpret 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 single optional parameter already documents both accepted forms (0x address, x402 URL) plus the omit-for-top-endpoints behavior. The description largely restates that dual mode, adding no format or validation detail the schema lacks, so baseline 3 applies.

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

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

States a specific resource (payments received by one Base address or x402 URL) and the exact quantities returned (counted payments, distinct agents, L7+ agents, first/last seen, excluded hops). It also distinguishes itself from the paid 'counterparty pack' that carries the payer list, so an agent can tell the two apart 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?

Clear context for use: it is a free counts-only preview, and the full payer detail lives in the counterparty pack. It also defines the no-address fallback (top endpoints paid by the most ranked agents). It stops short of explicitly naming a sibling tool to switch to, but the selection condition is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is covered. The description adds substantive domain context beyond that by describing exactly what the returned definition contains, including negative scope ('what it excludes and what it does not claim'), which tells the agent to expect disclaimers and limits rather than raw 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?

Two sentences, no filler, and the content of the returned definition is front-loaded ahead of the usage instruction. Every clause carries 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?

For a single-parameter, read-only, closed-world lookup with annotations covering safety and no output schema, the description covers what the tool is, what it returns conceptually, and where ids come from. It does not say what happens with an unknown or malformed id, which is the only notable gap.

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

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

Schema coverage is 100%: the single id parameter is fully documented with type and an example format ('pay.usd.total.v1'). The description only adds that ids originate from other tools, a sourcing note rather than added syntax or constraint meaning, so baseline 3 applies.

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

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

The description names the resource precisely ('the frozen definition of a metric') and enumerates its content (what it counts, method, exclusions, non-claims), which tells an agent this is a lookup of metric semantics, not a time series like metric_history. The verb is implicit ('returns') rather than stated outright, and no sibling is named explicitly, so it falls short of a 5.

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

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

'Use the definition ids returned by the other tools' gives concrete guidance on how to obtain the required id, which is the main usage question for this tool. There is no statement of when-not to use it or how it differs from metric_history, so it is clear context without 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 cover the safety profile (readOnly, idempotent, non-destructive, closed world), so the bar is lower. The description adds real behavioral context beyond them: results are ordered newest first, 'compact drops the glossaries,' and the framing 'a detection is a shape with evidence, never a verdict' tells the agent how to interpret (and not over-trust) the output. It does not discuss volume, pagination beyond the limit cap, or latency.

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

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

Two sentences, front-loaded with the resource and ordering, and every clause carries information (kind enumeration, evidence-not-verdict framing, filter surface). The dense comma list is slightly hard to parse but nothing is wasted or padded.

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, no-output-schema read tool with solid annotations, the description supplies what is needed to call it correctly: what a detection is, what kinds exist, what ordering to expect, and what the filters mean. It leaves out one kind gloss and any notion of result shape fields, but nothing critical for correct invocation 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 only 57% schema description coverage, the description has to compensate, and it largely does: it glosses six of the seven kind enum values in plain language (drain_pattern, retry_storm, mint_burst, layering_fan, bind_closed_after_nft_transfer, god_key_unknown_7702) and explains that drain detections carry the share of wallet balance taken. It omits the uri_timeout_streak kind and says nothing about limit/severity semantics, so it is not exhaustive.

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 resource precisely — a log of anomalies emitted by detectors, ordered newest first — and enumerates the detection shapes (drain-shaped payments, retry storms, mint bursts, layering_fan, bind closures, unknown 7702 delegation), which lets an agent map prose to the kind enum without opening the schema. It never contrasts itself against siblings such as agent_pattern, blast_radius, or since_last, which could plausibly be confused with an anomaly feed, so it stops short of a 5.

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

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

It states the filter surface ('Filter by agent, kind, severity, time or live incidents only') and the compact toggle, but those are restatements of schema parameters rather than guidance. There is no statement of when this tool is the right choice versus alternatives, nor any exclusion or prerequisite. Usage is only implied.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, and the description is consistent with them. It adds genuinely useful behavior beyond the annotations: the price range (1–25 cents), the USDC-on-Base x402 mechanism, and critically the two-step dance where the returned URL must be fetched by an x402 client and paid on retry. That mechanics disclosure is the reason this scores above baseline.

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-loading is good: price and the non-payment caveat come first. But the body is one ~250-word run-on paragraph with deeply nested parentheses (e.g. the exit and trace glosses), which is hard to parse. The length is partly justified by 14 enum kinds, but the structure actively hinders scanning.

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

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

With no output schema, the description carries the burden of explaining the return, yet it only sketches what each pack contains conceptually and never describes the response shape (the returned URL, the 402 payload). Given the tool's complexity and 14 kinds, this is adequate but leaves a real gap around what the agent actually receives.

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 67% and the schema lists the 14 kind enum members with no per-value descriptions, so the description is doing real work by explaining what each kind returns (precheck, drain, exit, trace, counterparty, venue, etc.). It also ties payto to precheck in prose. It does not fully pin down the id parameter's accepted forms beyond the schema's "token id, slug or wallet".

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 (quote an evidence pack), gives the price range and payment rail up front, and explicitly says what the tool does NOT do ("This tool does not pay"), which distinguishes it from an actual fetch/pay tool. However, it never names a sibling tool, so the agent must infer how it relates to neighbors like agent_statement, counterparty_preview, or pay_check despite clear topical overlap.

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 rather than stated: the long enumeration of kind values tells the agent what each evidence pack contains, which guides kind selection, and the payment paragraph explains the two-step fetch flow. But there is no explicit when-to-use-this-vs-alternative guidance and no list of when NOT to use it, even though sibling tools cover overlapping topics.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds substantive context: batch limit of 25 ids, the ranked-only name matching scope, and the important caveat that a declared name is the agent's own unverified claim — a data-trust warning the annotations cannot 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?

Three sentences, zero filler: the lookup verb leads, the accepted forms follow, and the batch limit and name caveat close it out. Every sentence carries information an agent needs to construct a call.

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

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

With no output schema, the description carries the return-value burden and does so by enumerating the key fields (ranked status, L0-L9 liveness, bound wallet, float, payment totals, open incidents). It leaves the per-field detail unspecified, but for a single-parameter lookup this is sufficient to call the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by explaining that name resolution is restricted to ranked agents and that declared names are unverified claims. Those are semantic qualifications of the query parameter not present in the schema's format list.

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 (look up) and resource (ERC-8004 agent on Base) plus the four accepted identifier forms. An agent can distinguish this resolution/lookup tool from siblings like agent_record, ranked_agents, or agent_statement 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 concrete acceptance criteria — token id, slug, wallet, declared name, or up to 25 comma-separated ids — and a scoping rule ('a name is matched among ranked agents only'). It stops short of naming an alternative sibling or stating when this lookup is preferable to agent_record, so it is clear context rather than full when/when-not routing.

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/non-destructive annotations: it discloses fail-closed behavior for unknown policy keys, that nothing is ever blocked in log-only mode, that the client owns its own fail mode when the service is unreachable, and that every decision is recorded. These are exactly the operational traits an agent needs before wiring this into a payment path.

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 useful 'one call before an agent pays' hook, but the body is a single run-on sentence cramming policy keys, thresholds and modes together. Bulleted structure would make the parameter detail far more scannable; the content earns its place but the packaging does not.

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

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

With no output schema and nested policy objects, the description carries the return contract itself — block/warn/log/allow with every reason — and covers fail-closed semantics, default policy and unreachability. 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 coverage is 100%, so the baseline is 3, but the description adds real meaning by enumerating the nested policy vocabulary (budget periods, new_payee thresholds, refuse_conditions, signal) that the schema only gestures at as 'the AP2 vocabulary'. It gives an agent enough to construct a policy object rather than just pass an opaque blob.

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 action and timing — 'One call before an agent pays' — and enumerates exactly what the call returns (payee facts, ledger context, out-of-character score, policy decision). It combines several concerns that overlap with siblings like payee_facts, pay_check and counterparty_preview but never explicitly names an alternative, so an agent must infer which tool to reach for.

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 'one call before an agent pays' framing gives a clear moment to invoke it, and it explains the log-only posture ('we never block anything; your client decides'). It stops short of stating when NOT to use it or which sibling to prefer for payee facts alone, so routing among the overlapping tools is left implicit.

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, closed-world, so the safety profile is covered. The description adds meaningful behavior beyond that: it is an aggregate/whole-cohort document, reports numbers at risk, restricted mean time without an exit, 95% intervals, and applies a minimum threshold of 30 ranked agents per minting address. It does not, however, describe pagination or output shape beyond the version ids.

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

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

It is a single semicolon-chained sentence with an excellent front-loaded anchor ('The whole-cohort document:'), but the four embedded version identifiers and stacked jargon make it heavy going. It is dense rather than padded, so it earns most of its length, but structure could be improved with a short list.

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

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

With no input parameters and no output schema, the description carries the burden of telling the agent what is produced, and it does so for all four analyses plus thresholds and interval conventions. Minor gaps remain (time horizons for RMST, units), but it is complete enough to 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?

The tool takes zero parameters, so schema coverage is moot and the baseline is 4. There is no parameter meaning for the description to add or omit.

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

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

The description names a specific resource (the whole-cohort document) and enumerates its four components by name and versioned schema id (ladder.exit_incidence.v1, platform.sdr.v1, ladder.transition.v1, survival.landmark.v1), so an agent knows exactly what comes back. It lacks an explicit verb ('returns'/'computes') and relies on domain jargon ('ladder', 'Standardised Drain Ratio'), but the content scope distinguishes it from siblings like ranked_agents and metric_history.

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

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

There is no statement of when to use this tool versus the many siblings (ranked_agents, agent_stability, market_state, etc.), nor any prerequisites or exclusions. The title's '(free)' hints at paid counterparts but names none and gives no selection condition.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds valuable context by enumerating the returned fields and explaining what comparable_since means, which compensates for the absent output 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 field list is front-loaded and the usage hint follows compactly in a second sentence. The long enumeration is dense but each item earns its place by documenting a return field; no filler text.

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

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

With no output schema and only one optional parameter, the description is the only source for return-value information and it supplies the key fields. Ordering, pagination, and result limits are not mentioned, which is a minor gap for a listing 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 is 3, but the description adds beyond the schema by noting that filtering also surfaces notes and clarifying that filter accepts a key fragment, a definition id, or a note word. That is genuine semantic value over the structured field.

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

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

The description states a specific resource (every metric the ledger measures or archives) and enumerates the returned fields, so an agent knows this is the metric catalog tool. It does not explicitly differentiate itself from close siblings like metric_history, which weakens it slightly.

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

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

It gives one concrete usage hint: apply a filter to also receive notes. There is no guidance on when to use this versus metric_history or the other ledger tools, and no exclusions, so usage is implied rather than specified.

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, so safety is covered. The description adds genuine behavioral context beyond that: base-metric exclusions ('routing hops and pre-registration history excluded', the 'counted' qualifier), the L7+/L8/L9 ranking criteria, and the split between Base and other-chain coverage. It does not mention auth or rate limits, but for a read-only snapshot the added measurement semantics are substantial.

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 first sentence front-loads the purpose and the per-figure shape well, but the remainder is a long enumeration of metric names that reads like raw inventory rather than decision-relevant information, and it spills into a second paragraph on chain coverage with no structural separation.

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, and annotations cover the safety profile. The description is complete on scope and content; the main gap is guidance on when to reach for this versus the time-series or delta siblings.

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 `compact` parameter is fully documented in the schema (100% coverage) and the description says nothing about it, so no value is added on this axis. Per the high-coverage rule, 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 states a clear resource (the ledger's headline figures for AI-agent money) and enumerates the exact content, including the per-figure shape (value, unit, measurement time, definition id). It is specific but never contrasts itself with adjacent tools such as metric_history or since_last, so sibling differentiation is left to inference.

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

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

There is no explicit when-to-use or when-not guidance. With many siblings covering overlapping metric territory (metric_history, since_last, list_metrics, ladder_dynamics), the agent must guess that this is the whole-board snapshot rather than the historical or delta view; nothing in the text routes it.

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

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

Annotations declare readOnly, idempotent, non-destructive, closedWorld. The description adds valuable behavioral context beyond annotations: gaps are real gaps, never filled; unknown key returns similar keys and full archived list. This is useful operational 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?

Three sentences, front-loaded with purpose, then key behavioral traits. No wasted words, though 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 read-only metric history tool with no output schema, the description covers granularity, gap behavior, and error fallback. Missing: explanation of the 'range' parameter's effect, and return format details (though no output schema so some burden is on the description). Overall 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?

Schema description coverage is 50%. The 'key' parameter is described in the schema itself with examples. The 'range' parameter has no description in the schema and is not mentioned in the description. Baseline 3 is appropriate since the schema partially documents parameters and the description adds some context about the archive.

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 a specific resource ('history of one measured metric from the ledger's archive') and indicates the granularity (daily points, 5-minute points for last 48h). It distinguishes itself from vague siblings, though without explicit sibling differentiation.

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?

Implied usage: when you need historical metric data. But no explicit when-to-use vs alternatives, prerequisites, or exclusions. A reader knows what it does but not necessarily when to choose it over other 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description adds real context instead: it is free, it returns 'facts' rather than a verdict ('the decision stays with you'), and it discloses sampling limits (payments taken from the 25 newest, statement staleness). The refuse-condition framing is useful 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?

The purpose clause is front-loaded, but the middle is a single run-on chain of comma-linked returns that is hard to parse. The trailing upsell sentence is relevant but adds length; the content earns most of its space yet the structure could be tightened.

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

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

With no output schema, the description must carry the return contract, and it does enumerate the returned fields and the sampling caveat. Only minor gaps remain, such as the exact shape of 'flags' or the enumerated refuse conditions, which are referenced but not listed.

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

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

Schema coverage is 100% and the single 'agent' parameter is described there as 'Agent token id, slug or bound wallet.' The description adds no extra meaning about the identifier format, so the baseline of 3 for high schema coverage applies.

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

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

The opening states a specific verb, resource and scope: 'One free call before your agent pays or hires another,' and it enumerates exactly what facts come back (statement, incidents, 72h detections, approvals, last payment). It implicitly separates itself from agent_statement and detections by being an aggregate pre-payment check, though it never names those siblings directly.

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

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

It gives a clear triggering condition ('before your agent pays or hires another') and points to the paid precheck pack as the richer alternative for the counterparty address. It stops short of explicit when-not-to-use guidance (e.g. after payment, or when a full statement is needed).

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds real behavioral context beyond that: a 7-day Transfer-log window, per-fact value/evidence/method/measurement-time structure, and the explicit guarantee that an unavailable channel is reported rather than guessed. No permissions, latency or rate-limit detail is given, but for a read-only facts tool this is a solid addition.

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 definition is long and heavily semicolon-delimited, but it is front-loaded with the core purpose and every clause corresponds to a distinct fact, so little is padding. It reads as dense reference material rather than prose, which costs it the top mark but not much more.

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

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

There is no output schema, so the description carries the return-shape burden and does so explicitly, stating that each fact carries value, evidence, method and measurement time and that unavailable channels are disclosed. Given the three-parameter read-only scope and the fact enumeration, an agent has everything needed to call and interpret 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%, so the baseline is 3, but the description goes further by explaining why the optional parameters exist: 'given the paying agent and the amount, whether it is a never-paid destination at a size the agent never sent' ties agent and amount_usd to two named per-agent facts. It also clarifies the payee is 'the 0x address to be paid', reinforcing the schema description.

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

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

The description states a specific verb+resource ('what the chain and our ledger say about an address an agent is about to pay') and enumerates the concrete fact set: code kind, delegate/sweeper shape, relay shape, swap outflow, funding/exit paths, claim-on-proof selector, issuer freeze, payer count, and two per-agent facts. An agent can tell this is an address-due-diligence tool and distinguish it from judgment-style siblings such as pay_check or counterparty_preview.

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 'an address an agent is about to pay' and the title's 'before paying it', and the closing line 'Facts describe an address; they do not judge it' hints at the boundary with a verdict tool. However, no sibling is named and there is no explicit when-not-to-use or alternative-selection rule, so the agent must infer the routing.

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, closed-world behavior, yet the description adds real interpretation context: the 250 cap, that observed payers are a lower bound, and that payment-grounded reviews are not independent because a same-operator payer grounds its own reviews. Those caveats materially affect how an agent reads the result.

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

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

Three sentences, each carrying load, with the resource definition front-loaded. The first sentence is extremely dense and jargon-heavy, which slightly hurts scannability, but 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?

With no output schema, the description carries the return-shape burden and does so, naming payments, USD, first/last paid, and the feedback grounding measure. Combined with the cap and independence caveats, an agent has enough to call and interpret it, though the dense jargon leaves some ambiguity.

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 both agent and limit. The description restates the 250 ceiling and USD ordering rather than adding new syntax or format detail, 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?

The description states a specific verb+resource: the wallets observed paying one agent, plus how much of its ERC-8004 feedback is payment-grounded. An agent can tell it returns a payer set with USD/timestamps and a grounding ratio, distinct from siblings like agent_record or pay_check. Sibling differentiation is implicit rather than explicit, so it falls short of a 5.

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

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

It gives a downstream usage tip (pass the addresses as clientAddresses to getSummary to read only paid reviews) but never states when to choose payer_set over siblings such as counterparty_preview or agent_independence. Usage is implied by the returned data rather than framed as a decision rule.

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 carry the safety profile (readOnly, idempotent, non-destructive), so the description isn't burdened with that. It adds genuinely useful behavior beyond the annotations: the two-key sort order and how sort_by modifies the second key, the interpretation caveat about ranking, and the free-tier limit of 25. Minor gaps on pagination/return shape remain.

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

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

Three sentences, each earning its place: scope/definition, sort behavior, and the reliability caveat plus tier limit. It is front-loaded with what is returned. The parenthetical definition of L7 is dense, which slightly blunts readability but doesn't waste words.

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

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

An output schema exists, so return values needn't be explained, and the description focuses on what only prose can convey: the ranking semantics, the trust caveat, and the tier cap. Combined with the annotations it gives an agent enough to call and interpret this tool correctly. It could say more about how levels are derived or how to paginate past 25.

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

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

Schema coverage is 67%: sort_by and min_level are documented, but limit is not. The description compensates by explaining the level-first/second-key ordering (which the schema only hints at with 'within each level'), defining the liveness level used by min_level, and clarifying the 25 cap that bounds limit. That adds meaning beyond the schema, though limit itself is only indirectly addressed.

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 the resource precisely (top-ranked L7+ agents) and even defines what L7 means, so an agent knows exactly what set this returns. It explicitly distinguishes itself from the sibling agent_record by warning to read that first. It lacks an explicit verb and doesn't mention other ranking/list siblings, so it falls just short of a 5.

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

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

It gives real usage context: a high rank means 'a large counted spender... not a working service', and it routes the agent to agent_record before relying on the result. It also states the free-tier cap. There is no explicit when-not-would-this-be-wrong or comparison against the other ranking-adjacent siblings, so not 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 cover the safety profile (readOnly, idempotent, non-destructive, not open world), so the bar is lower. The description still adds real behavior: no prior sample in the window yields gap: true with no delta, and nothing is interpolated. That edge-case disclosure is exactly the kind of trait annotations cannot express.

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

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

Front-loaded with the return shape, then window modes, then the gap rule. Dense but every sentence earns its place, and no filler appears.

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

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

With no output schema and only two parameters, the description carries the full burden and does so well: it enumerates the returned fields and covers the missing-prior-sample case. The only shortfall is the absent routing against sibling metric tools.

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

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

Schema coverage is 50%: metric_id is documented in the schema, but window's enum values carry no per-value description there. The description compensates by defining each window mode, including the default 'sweep' meaning. The metric-key-or-definition-id note merely restates the schema's own description.

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 resource precisely: one measured figure plus its stored prior sample, with the exact fields returned (current, prior, delta, delta_ratio, timestamps, definition id, unit, materiality). An agent knows this is a latest-value-plus-prior comparison, not a historical series. It stops short of naming the obvious sibling metric_history, so differentiation is inferred rather than stated.

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

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

The window semantics ('sweep' = previous stored sample, the default; or 24h/7d/30d) imply when each mode applies, and the gap behavior explains an edge case. However there is no explicit when-to-use guidance versus metric_history or the other metric-oriented siblings, so the agent must infer the routing.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered structurally. The description adds real behavioral context beyond that: what the verification actually checks (Merkle-sum root, leaf-to-root proof, unchanged/changed/removed/added counts, consistency proof), and the operational requirement to retain and re-pass the returned heads. It omits auth/permission or failure-mode behavior, so it is not a 5.

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

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

The content mostly earns its place, but it is delivered as a long run-on sentence with the actual purpose buried behind a rhetorical opener ('Trust nothing you did not recompute'), so it is not front-loaded on the verb. Dense but not padded; structure is the weak point.

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

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

There is no output schema, so the description must carry the return semantics, and it does: it states that it reports unchanged/changed/removed/added leaf counts, returns heads to keep, and verifies consistency. Combined with full schema coverage on the three optional inputs, an agent has enough to call and chain it, though it says nothing about error/failure reporting.

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, but the description adds genuine meaning: it explains that 'agent' triggers climbing that agent's proof from leaf to root, that previous_head is 'the sum-log head you kept', and that previous_statement_head drives the consistency proof that history was not rewritten. That ties the nested objects to concrete cryptographic purposes rather than restating field names.

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

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

The description names a concrete verb and resources: it verifies the Ed25519 signature on the sum-log head, optionally climbs an agent's Merkle proof, diffs leaves against the previous head, and verifies the statement log's signed tree head and consistency proof. That is far more specific than a tautology and lets an agent distinguish it from siblings like agent_statement or since_last. It stops short of explicitly naming the sibling tools it supersedes, so it is not a 5.

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

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

Usage is implied by the title's '(skeptical client)' framing and by 'optionally climbs one agent's proof' plus 'Keep the heads it returns and pass them next time,' which tells the agent how to chain calls. However, there is no explicit when-to-use vs when-not statement and no named alternative among the sibling tools, so guidance remains inferred rather than stated.

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