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

The annotations already mark this as read-only/idempotent/non-destructive, and the description adds substantial behavioral context: it reads an EAS attestation on Base, requires no wallet or API key, costs $0.03 per call with prepaid header or free daily tier, and returns a verdict plus trust score. It also warns that identity is a signal, not proof, which is valuable calibration for the agent.

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

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

The description is longer than average but information-dense and front-loaded with the core purpose before moving to verification details, usage pairing, pricing, and requirements. Every sentence adds operational or contextual value; minor redundancy exists around 'required input: address' given the schema already marks it required, but overall it is well structured.

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

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

The description covers what the tool does, how the verification works, what network it operates on, what it returns at a high level, how to pay for it, auth requirements, and sensible companion tools. With an output schema present, the absence of detailed return field documentation is acceptable. Nothing critical is missing for an agent to decide whether and how to invoke it.

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

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

The schema already documents 'address' as 'Address to check' with 100% coverage, so the baseline applies. The description only restates that address is the required input and adds the contextual framing of 'counterparty,' but it does not provide additional format, network, or validation details beyond what the schema and overall description already imply.

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 opens with a clear, specific question—'Is this counterparty Coinbase-verified or an anon/sybil?'—and names the exact resource and signal: Coinbase's ONCHAIN EAS attestation plus Basename. It clearly identifies the tool's distinct role as a counterparty identity/trust check, separating it from generic address or risk tools.

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

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

The description gives concrete usage context: it is the 'who am I dealing with?' pre-transaction check and explicitly suggests pairing with sign-guard/spend-audit for a full pre-transaction gate. It also includes a caveat that identity is not proof of honesty, but it does not explicitly name alternatives to avoid using this tool for.

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