Automaton Token Safety

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

With no annotations, the description carries the full behavioral burden and does so well: it declares read-only behavior, pricing (0.01 USDC/call), a free trial limit (3/day/IP), and the exact 402 payment retry protocol. This is unusually rich context for invocation and error handling.

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

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

Three sentences are front-loaded with pricing, then purpose, then the 402 retry procedure. The output-field list is dense but informative; no sentence is wasted, though it could be slightly 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?

No output schema or annotations exist, so the description must carry safety, payment, and return-value context. It lists the audited outputs (spender, allowance, contract vs EOA, verified flag, drainable amount, drain-risk verdict) and payment flow, though it does not describe response structure or pagination.

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

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

Schema coverage is 75%, and the description clarifies the relationship between 'owner' and 'token' while explaining the otherwise undocumented 'payment' parameter as the payment transaction hash used on retry. It adds meaningful semantics beyond the schema, though the 'spenders' parameter is only covered by the schema itself.

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 ('audit') and resource ('ERC-20 approvals an owner granted for a token'), and names the exact scope (owner + token). It clearly distinguishes itself from sibling tools like token_scan or security_scan by focusing on approval exposure and drain risk.

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

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

The description explains the payment and retry flow but gives no guidance on when to choose this tool over alternatives such as token_scan, security_scan, or liquidity_risk. No when-to-use conditions or exclusions are provided, leaving selection 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?

With no annotations, the description carries the full burden and does well: it discloses immutability (append-only, hash-chained), signing, the 0.05 USDC cost, the 3/day/IP trial, and the exact payment-recovery path on 402. It omits what the created attestation returns, which is a small gap given no 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?

Three tight sentences: purpose first, then pricing/limits, then the payment-retry procedure. No filler, and the most important information is front-loaded.

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

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

For a 2-param, no-output-schema tool with no annotations, the description covers purpose, cost, rate limits, and the payment recovery path well. It could say more about the shape of the returned attestation or how to later verify it, but nothing critical to 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?

Schema coverage is 100%, so both params are documented, giving a baseline of 3. The description adds value by explaining the payment param's role in the 402 retry flow, linking the tx hash to a concrete recovery scenario rather than leaving it as a bare 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?

Names a specific verb (Create) plus a precisely characterized resource: a signed, hash-chained, append-only attestation defined as verifiable proof-of-existence. This clearly separates it from siblings like verify_attestation, attestation_pubkey, and hash_sha256, which serve different roles.

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

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

Provides strong operational context (cost, free trial, 402 retry flow) but never states when to choose this over verify_attestation or hash_sha256. Usage is implied by 'proof-of-existence' rather than explicitly contrasted with 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?

With no annotations, the description carries the full burden. It usefully discloses that the call is 'FREE' (implying no payment/auth flow, notable among paid siblings like simulate_base_transaction) and names the exact payload returned. It does not state read-only semantics, caching, rotation behavior of the key, or rate limits.

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

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

One sentence, front-loaded with the cost signal 'FREE' followed by the exact resource and return format. Nothing is padded or repeated from the schema.

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 and no parameters, so the description's job is to describe what is returned — it names both the PEM public key and the keyId. For a zero-input read endpoint this is sufficient 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is no parameter surface for the description to clarify, and it correctly implies a parameterless lookup.

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 ('Get') plus a precisely named resource: the ECDSA P-256 public key in PEM form and the keyId used for signing ledger entries. An agent knows exactly what comes back. It does not explicitly contrast itself with siblings like verify_attestation or attest, 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?

There is no statement of when to call this versus verify_attestation, attest, or merkle_prove. The only routing signal is 'FREE', which implies no payment/x402 step is needed, but that is a cost hint rather than usage guidance and no conditions or exclusions are given.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the paid cost of 0.001 USDC/call and the output format (hex), but omits payment mechanics, error behavior, and whether payment is mandatory despite the schema marking the payment parameter as optional.

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

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

Two short, waste-free fragments. Payment is front-loaded and the operation is stated immediately after. Slightly telegraphic, but appropriately sized for a simple utility.

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

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

For a simple two-parameter paid utility, the description covers the operation, cost, and output format. However, it leaves the payment parameter undocumented and creates ambiguity by saying 'PAID' while the schema does not require the payment field.

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

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

Schema description coverage is 0%. The description implies the `input` parameter is a string and hints at a payment cost, but it does not document the `payment` parameter's expected format, how payment is attached, or any constraints on `input`.

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 operation: computing the SHA-256 hex digest of a string. The resource and output format are clear, though it does not explicitly distinguish itself from sibling utility tools beyond the unique name.

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

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

Provides no when-to-use guidance, no alternatives to consider, and no prerequisites beyond the stated per-call cost. An agent must infer the intended use case from the tool name alone.

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

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

No annotations are supplied, so the description carries the burden. 'FREE' usefully signals no cost/billing, and 'liveness' implies a non-mutating read, but it says nothing about auth requirements, latency, or what a negative result means.

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 fragments, front-loaded with the cost trait and the purpose. Nothing 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 zero params and no output schema, an agent still lacks a hint of the return shape (e.g., status string vs version object), which is the only meaningful gap for a tool this simple.

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 to disambiguate; per the baseline this scores 4 even with no parameter discussion.

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 the resource and outcome clearly: service liveness and version, which no sibling tool (all crypto/ledger/scan oriented) covers. It lacks an explicit verb, but 'liveness and version' unambiguously describes a health-check probe.

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 — an agent can infer this is a pre-flight/keepalive probe. No alternatives, exclusions, or prereqjson are given, but none of the siblings compete for this purpose.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the pricing model (0.01 USDC/call), the rate limit (3/day/IP free trial), the payment/auth flow on HTTP 402, and the honest inclusion of 'explicit coverage gaps.' These are exactly the behavioral traits an agent cannot infer from the schema.

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

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

Three dense sentences, front-loaded with cost/access terms before the capability and then the retry mechanics. Little waste, though the enumeration of outputs makes the middle sentence long.

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 no annotations, the description still tells the agent what is returned (pool data, price-impact USD, holder concentration, LP burn, coverage gaps) and how to complete payment. Only the response structure and non-402 error behavior remain unspecified, which is a minor gap.

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

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

Schema coverage is 67%: token and pair are documented in the schema, while 'payment' has no schema description. The description compensates by explaining the payment parameter's role ('retry with the payment tx hash'), adding meaning beyond the structured fields.

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 ('One-block liquidity audit of a Base token') and enumerates the concrete outputs (Uniswap V3/Aerodrome pools, USD to move price 1/2/5/10%, holder concentration, LP burn evidence, coverage gaps). It is far more specific than the terse sibling names like token_scan or security_scan, though it never explicitly names a sibling to contrast against.

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

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

Gives strong operational guidance for the payment flow ('On 402, pay the accepts[] terms then retry with the payment tx hash') and the free-trial limit (3/day/IP), but offers no guidance on when to choose this over token_scan, security_scan, or approval_risk. Usage is implied by the audit framing rather than contrasted with 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?

No annotations are provided, so the description carries the full burden. It does disclose a real behavioral trait beyond the schema: the tool is paid at 0.001 USDC/call. But it says nothing about how payment is settled, what happens on non-payment, or whether the operation is read-only vs mutating.

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

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

Two short sentences with the paid-price caveat front-loaded, so an agent sees the cost before anything else. No wasted words, though it is arguably under-specified rather than tightly written.

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 annotations, no output schema, an unexplained payment parameter, and an ambiguous target, the description does not supply enough for an agent to invoke this correctly. Payment mechanics and the target's meaning are the most damaging gaps.

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

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

Schema coverage is only 67% and the payment parameter has no description anywhere. The description's 'list of items and target element' merely restates the items/target properties and does not resolve the schema's own ambiguity about whether 'target' is an item value or an index.

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: generate a cryptographic Merkle inclusion proof from a list of items and a target element. That is clear. However it does not differentiate from the sibling merkle_verify, which an agent could easily confuse with this tool.

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

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

The description gives no when-to-use context and no comparison to merkle_verify, the obvious alternative. The only ancillary information is the price, which is cost, not usage guidance.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only check and flags zero cost, but says nothing about the verification result (boolean/throw), handling of malformed proofs, or whether it touches on-chain state.

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

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

Two short, front-loaded fragments with zero filler; the cost signal leads. However, the extreme brevity is part of why behavioral and parameter detail is missing.

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

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

For a tool with 3 required, wholly undocumented parameters, no annotations, and no output schema, the description omits too much: input formats, expected result, and failure behavior. An agent could infer the intent but not 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 description coverage is 0% for all three required parameters. The description only loosely gestures at 'proof' and 'root' and gives no format for 'item' (hex string? serialized leaf?) or the shape of the proof array elements, so it fails to compensate for the coverage gap.

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

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

States a specific verb ('Verify') and resource ('cryptographic Merkle inclusion proof against a root'), which cleanly separates it from the sibling merkle_prove (prove vs. verify). It does not explicitly name that sibling, but the direction of the operation is unambiguous.

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

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

There is no when-to-use, when-not-to-use, or alternative-tool guidance. The only contextual hint is 'FREE', which suggests a cost advantage over paid siblings but does not tell the agent which condition should select this 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?

With no annotations, the description must carry the full behavioral burden. It does disclose two key traits—a per-call USDC cost and that responses are signed with ECDSA P-256—but omits payment enforcement details, what happens if the optional payment hash is absent, and any auth or rate-limit information.

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

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

A single sentence with no redundant content; the cost and purpose are stated directly and efficiently. It is appropriately sized for a simple oracle tool.

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

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

The description covers the tool's output (gas estimates, asset prices) and mentions cost, which is helpful given the absence of an output schema. Yet it leaves the payment mechanism—when and how to supply the payment parameter—unaddressed, and provides no sibling context, so it is only partially complete for a paid tool.

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

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

Schema coverage is 100% for the single optional parameter, so the baseline is 3. The description mentions payment only at a high level ('PAID 0.001 USDC/call') and adds no format or usage details for the payment hash 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 ('Get') and resource (real-time Base L2 gas estimates and asset prices on listed tokens), which sets it apart from generic pricing siblings. However, it does not name or differentiate from any specific alternative tool, so a 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?

Provides the per-call cost, which is useful context, but gives no guidance on when to use this tool versus siblings like pricing or health, nor any prerequisites, exclusions, or alternatives. A 2 reflects the absence of explicit usage guidance.

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

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

With no annotations, the description carries the full burden, and it discloses almost nothing behavioral: no read-only guarantee, no auth requirement, no rate limits, no idempotency. 'FREE' implies no cost/charge for the call, which is marginal context, but the mutation/safety profile is entirely undisclosed.

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?

Extremely short and front-loaded ('FREE.'), with every word contributing information about the returned content. It is terse to the point of under-specification, but there is no 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 zero-parameter, no-annotation lookup tool with no output schema, the description at least names the content categories returned (terms, endpoints, payment mechanics), which partly compensates for the missing output schema. It still omits the return format and any call context, leaving it only minimally adequate.

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; the baseline of 4 applies. No parameter-level meaning is needed or missing.

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

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

The description enumerates the content the tool returns (pricing terms, endpoints, payment mechanics), which goes slightly beyond the bare name 'pricing'. However, it states no verb and no scope, so an agent cannot tell precisely what action it performs or what payload to expect. It is a vague but not tautological statement of purpose.

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 indication of when to call this tool, in what context (e.g., before payment or transaction simulation), or which sibling it relates to. The 'FREE' prefix hints at a cost condition but is not framed as usage guidance.

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

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

With no annotations at all, the description carries the full burden. It discloses that the call is cost-free and that results are paginated, which is genuinely useful, but says nothing about read-only guarantees, auth requirements, rate limits, or ordering of the ledger.

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

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

Two short sentences with the cost signal front-loaded, so nothing is wasted. However, the brevity reads as under-specification rather than disciplined conciseness given that it must carry the entire behavioral and parameter burden.

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

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

No annotations, no output schema, and 0% schema description coverage mean the description is the sole source of detail, and it supplies almost none. An agent cannot confidently form the call without guessing at 'from' semantics and the ledger's contents.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. '(paginated)' loosely hints at limit, but 'from' is left ambiguous — offset, ledger sequence, or timestamp is unknowable — and no units, defaults, or bounds are provided.

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

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

States a specific verb and resource: read the attestation ledger, with the paginated qualifier. It is distinguishable from siblings like verify_attestation or sentinel_latest, though it never explicitly contrasts itself with them or explains what 'ledger' contains.

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

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

The only usage signal is 'FREE', implying a cost preference over paid alternatives, but no when-to-use condition, no prerequisites, and no named alternative are given. An agent gets no help deciding between this and the other attestation-related siblings.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the exact price (0.001 USDC/call), a free-trial rate limit (3/day/IP), the 402 payment flow and retry mechanism, and the specific risk categories analyzed. This is unusually rich behavioral context for an unannotated, mutation/cost-bearing 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 legacy/pricing context is front-loaded, followed by the analysis scope and the payment fallback. Every sentence carries distinct information with no redundancy.

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

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

For a paid tool with no output schema, the description covers cost, rate limits, error handling, and names the return artifacts (risk score, signed verdict). It stops short of describing the verdict fields or response shape, but is complete enough to invoke correctly.

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

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

Schema coverage is 100%, so both parameters are already documented (baseline 3). The description adds value by tying the optional payment parameter to the 402 workflow ('retry with the payment tx hash'), giving the agent context the schema alone does not.

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 (token safety analysis on Base contract bytecode) and explicitly identifies the tool as the legacy alias of token_scan with 'same route, same arguments'. An agent can immediately tell what it does and how it relates to the sibling 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?

It clearly frames when this tool exists ('kept so clients written against this server keep working'), which strongly implies new callers should prefer token_scan, and it provides the payment/retry workflow on 402. However, it never states the exclusion affirmatively ('use token_scan instead'), so the routing guidance is implied rather than explicit.

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

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

With no annotations, the description carries full burden; it does disclose that the call is paid (0.001 USDC) and returns a signed verdict, which is genuinely useful. However, it omits whether payment is required, what happens on non-payment, auth requirements, or how the verdict is signed.

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

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

Two short fragments with the price front-loaded, no filler. It is efficient, though the compressed style sacrifices the clarity it could have used elsewhere.

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

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

No output schema and no annotations mean the description should explain return shape, payment mechanics, and error behavior. It gives only a one-line hint ('signed verdict') and leaves the payment parameter and failure modes unexplained for a paid, multi-purpose 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 50%: 'asset' is documented in the schema, but 'payment' has no description anywhere. The mention of '0.001 USDC/call' hints that payment exists but gives no format, token address, or whether it is required (it is not in the required list), so the description fails to compensate for the gap.

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

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

The description bundles three functions ('token risk, security checks, and sentiment scoring') which are vague and overlap heavily with siblings like token_scan, security_scan, and liquidity_risk. It does not differentiate itself from those siblings, leaving the agent unable to tell which risk tool to pick.

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

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

No when-to-use guidance and no mention of alternatives, despite a crowded sibling set of risk/security tools (token_scan, security_scan, approval_risk, liquidity_risk). The only context given is pricing, which does not help selection.

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

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

With no annotations, the description carries the full burden and does so well: it discloses cost (0.001 USDC/call), a rate limit (3/day/IP free trial), and the auth/payment handshake on HTTP 402 including the retry-with-tx-hash step. These are exactly the operational traits an agent cannot infer from the schema.

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

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

Three tight sentences, front-loaded with the price and trial quota before the functional description. Every clause earns its place, though the payment sentence is compressed enough that the accepts[] reference assumes prior x402 familiarity.

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 still conveys the return payload (new pools plus a per-token bytecode risk score), and it covers cost and payment recovery. It omits ordering/pagination behavior for the pool feed, a minor gap given limit and since are schema-documented.

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 already 83%, so the schema documents dex, limit, since, minRisk and maxRisk. The description adds value the schema lacks: that all filters are optional and, importantly, what the undocumented 'payment' parameter is for (the tx hash supplied after settling the 402 terms).

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 and scope: 'Newest liquidity pools created on Base (Uniswap v3/v4, Aerodrome) with a bytecode risk score per new token.' An agent immediately knows this is a new-pool feed with risk scoring, distinct from static risk tools. It stops short of naming the overlapping siblings (liquidity_risk, token_scan) to route between them.

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 operational context: pay-per-call pricing, a free trial quota, that filters are optional, and the exact 402 recovery path ('pay the accepts[] terms then retry with the payment tx hash'). It does not state when to prefer this over liquidity_risk or token_scan, so the alternative-selection guidance is absent.

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

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

With no annotations to lean on, the description carries the full burden and does so well: it discloses the cost (FREE), execution locality (runs locally against Base Mainnet RPC), the exact RPC methods and block height (eth_call + eth_estimateGas at latest block), the non-mutating nature of the dry-run, and the specific revert decoding categories it can detect.

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 waste-free: the free/local nature is front-loaded, the mechanism and revert-decoding detail follow, and the return shape closes it out. Every clause conveys 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?

There is no output schema, but the description compensates by enumerating the return fields { ok, willRevert, revertReason, estimatedGas, returnData } and the revert-decode taxonomy. Given no annotations, the behavioral and return coverage is strong, though sender/permission prerequisites are left to the schema's from-field description.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, including defaults for data and value. The description adds no additional syntax or format guidance 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?

States a specific verb and resource: dry-run/simulate a transaction on Base, performed via eth_call + eth_estimateGas. However, it never distinguishes itself from the sibling tx_simulate, which appears to be a competing simulation tool, so an agent cannot tell the two apart from the text alone.

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?

"Dry-run a transaction before sending it" gives clear situational context for when to reach for this tool. It stops short of stating when NOT to use it or naming the alternative (tx_simulate) for cases it does not cover.

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

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

With no annotations, the description carries the full burden and does well: it discloses cost, a rate limit (3/day/IP), that the operation is read-only with no transaction sent, and the 402 payment-then-retry protocol. It stops short of describing output format or failure modes beyond the 402 path, so not a perfect 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?

Dense but front-loaded: cost and trial terms lead, followed by what the scan does and the payment retry mechanics. Every sentence earns its place, and the alias note is correctly parenthetical.

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

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

No output schema exists, so the description compensates by naming the return contents (risk score, verdict, capability flags). Payment flow, safety profile, and alias are all covered, leaving nothing an agent needs before calling 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 already 100%, so the baseline is 3. The description adds real meaning beyond the schema by explaining the payment parameter's role — the tx hash used to retry after a 402 — and constraining the address to a Base token contract.

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 ('Bytecode security scan of a Base token contract') and enumerates what it inspects (honeypot opcodes, mint/blacklist/pause/tax capabilities, risk score, verdict). This distinguishes it clearly from siblings like approval_risk and liquidity_risk. It also flags the security_scan alias, helping an agent reconcile the name.

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 operational invocation guidance (free trial 3/day/IP, or pay 0.001 USDC; on 402 pay accepts[] terms then retry), which is genuinely useful. However, it never states when to prefer this tool over approval_risk or liquidity_risk, nor any exclusions. Usage is implied rather than differentiated.

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

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

No annotations exist, so the description carries the full burden, and it delivers: read-only, no transaction sent, what is returned (reverts, measured transfer tax, honeypot verdict), pricing (0.01 USDC/call, 3/day/IP free trial), and the payment/auth flow on HTTP 402. This is unusually rich behavioral disclosure for a mutation-adjacent 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?

Three dense sentences, front-loaded with the core purpose and pricing, with the sibling disambiguation in a trailing parenthetical. Every sentence earns its place, though the information is packed tightly rather than 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?

With no output schema or annotations, the description must explain returns, cost, payment, and scope on its own, and it does: it names the concrete outputs, the pricing model, the retry path, and the sibling distinction. 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 80% (token, side, amount, wallet all documented). The one undocumented parameter, 'payment', is given meaning by the description's 402 flow ('pay the accepts[] terms then retry with the payment tx hash'), which adds value beyond the bare schema and compensates for the coverage gap.

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

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

States a specific verb and resource with scope: 'Read-only buy/sell simulation of a Base token through the Uniswap V2 WETH pool.' It even names the sibling it is not (simulate_base_transaction), so an agent can disambiguate the two 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?

Explicitly distinguishes itself from the alternative tool by stating the other simulates 'arbitrary calldata for free,' which tells the agent which one to pick. It also describes the paid-vs-free-trial condition and the 402 retry procedure, covering the practical when/how to invoke.

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

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

With no annotations, the description carries the full burden, and it does disclose one key behavioral trait: this is a paid call costing 0.001 USDC. However, it says nothing about authentication, how payment is verified, rate limits, or failure modes when payment is absent.

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 terse fragments with zero filler. The main minor flaw is ordering: the payment note is front-loaded ahead of the actual purpose, so the primary function is not the first thing read.

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 trivial UUID generator with no output schema, the core function is adequately conveyed. The gap is the payment workflow, which is central here yet left underspecified, making the definition incomplete on the one non-obvious aspect of 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?

The single "payment" parameter has 0% schema description coverage. The description partially compensates by stating the call is paid and the price, implying payment is what the parameter carries, but it never explains the expected value or format (e.g., a signed payload, tx hash).

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?

"Generate a UUIDv4" states a specific verb (generate) and resource (UUIDv4), and the version specificity distinguishes it from siblings like hash_sha256. It is clear but only marginally elaborates on the tool name "uuid", so it sits just short of the differentiation bar for a 5.

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

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

The description gives no indication of when to use this tool versus the many crypto/attestation siblings, nor any prerequisites or exclusions. An agent is left to infer entirely from the name.

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

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

With no annotations provided, the description carries the full behavioral burden, and it does disclose concrete internal behavior: recomputes the hash, checks the ECDSA signature, and validates the chain link, plus flags the operation as free. It omits result semantics (what is returned on pass/fail) but the core verification mechanics are exposed.

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

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

A single front-loaded sentence: the free-cost signal comes first, then the action, then the resolution keys and checks. No wasted words.

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

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

For a tool with no output schema and no annotations, the description covers what is verified and how to identify the target, but says nothing about the return value or failure behavior. Adequate but leaves a gap an agent would need.

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 0% and the parameters have no descriptions, so the description must compensate. It does clarify that the two params are alternative lookups (index OR data hash), which adds meaning beyond the bare schema, but it does not address whether both can be supplied together or precedence rules.

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

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

States a specific verb (verify) and resource (ledger entry/attestation) and specifies the two ways to identify the target (by index or data hash). It is clearly distinguishable from siblings like merkle_verify and attest.

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

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

It explains how to invoke the tool (index vs data hash) but gives no guidance on when to use it versus sibling verification tools such as merkle_verify or attest, nor any prerequisites. Usage is implied rather than stated.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the check is free and runs locally (implying no remote side effects or data transmission) and that it returns verdict, grade and per-check results. It does not disclose whether the endpoint is invoked with live requests, whether the target can see the check, or any rate limits, which keeps it from a 5.

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

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

Front-loaded with the cost/local-execution constraint and the core action, then the check list and return values. It is a dense run-on list, but every clause names a concrete conformance aspect rather than filler, so little 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?

No output schema exists, and the description compensates by naming the return shape (verdict, grade, per-check results) along with the full check coverage and the free/local operating condition. Combined with a fully documented single required parameter, an agent has everything needed to invoke this 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% for the single 'url' parameter, so the schema already explains it fully; the description adds no format, auth, or endpoint-shape detail beyond 'any x402 paid endpoint'. Baseline 3 applies when the schema does the heavy lifting and the description does not compensate further.

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: lint x402 paid endpoints for protocol conformance, and enumerates exactly what is validated (402 challenge, x402Version, accepts[], Base network, EIP-712 domain, EIP-3009 payment rejection cases). This is clearly distinguishable from siblings like security_scan, token_scan, and tx_simulate, which address different concerns.

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?

'Lint any x402 paid endpoint' implies the usage context, and 'FREE, runs locally' removes cost/consent friction, but there is no explicit when-to-use versus when-not-to-use guidance and no named alternative among siblings. The agent must infer that this tool is for x402 protocol checks rather than generic endpoint scans.

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