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

With no annotations, the description carries the full behavioral burden and discloses extensive traits: paid $0.010000 USDC per call, required recovery token handling for x402/MPP, idempotency key requirements, provider failure not becoming paid success, pending finalization semantics, and retention periods. It also explains trial versus paid credentials and 429 behavior. These details go well beyond the schema and are highly relevant to correct invocation.

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

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

The description front-loads the core purpose well, but then expands into a very long block of payment, prepaid, recovery-token, trial, and legal retention details. Much of this is operational and some is necessary, but the overall text is far too dense and not well structured for an agent to scan quickly. The volume exceeds what is needed to select and invoke the tool.

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

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

Given no annotations, no output schema, and a complex paid/recovery workflow, the description is largely complete on invocation behavior: payment model, auth headers, recovery token persistence, error semantics, and trial rules. It does not describe the returned token-facts structure or meaning of fields, which leaves some gaps because no output schema exists. Still, the critical behavioral context is present.

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

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

Schema description coverage is 100%, so the schema itself fully documents chain_id, address, block, and categories. The description only broadly references 'contract-reported token identity, metadata, supply and limited control facts' and does not add parameter-specific syntax, defaults, or edge cases beyond the schema. Baseline 3 is appropriate 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?

The opening sentence states a specific verb and resource: read contract-reported token identity, metadata, supply, and limited control facts at one pinned finalized Base block. It also clearly excludes safety scoring, honeypot simulation, and verified-source claims, helping distinguish it from safety-check tools. However, it does not name or contrast with any sibling tool explicitly.

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

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

The description implies usage through phrases like 'No safety score, honeypot/trading simulation, verified-source claim' and provides payment/trial operational context. But it never explicitly says when to choose this tool over fresh402_check or other siblings, nor does it name alternatives for the excluded safety-assessment use case. The practical usage guidance is therefore only implied.

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