Shared fee-setting fingerprint

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

Annotations already cover read-only, idempotent, non-destructive, and open-world behavior. The description adds useful behavioral context: matches can occur days apart, EVM chains are rejected before any request is spent, and this is corroboration only. However, the claim that EVM chains are rejected conflicts with the schema's EVM enum and plan note, making that particular behavioral disclosure unreliable.

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

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

The description is front-loaded with the concept, then gives usage and invocation constraints. It is a bit repetitive around the Solana-only and not-proof-of-bundling caveats, but the warnings are important enough that the redundancy is minor.

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 tool is simple with only two parameters and one required, and an output schema exists, so the description does not need to explain return values. It covers purpose, usage, caveats, and cost, but the unresolved contradiction about EVM support between the description and the schema means an agent still cannot confidently invoke it for all advertised chain values.

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 narrows chain handling to 'solana or omitted' and says EVM chains are rejected, directly contradicting the schema's chain enum and its note about EVM chains requiring an All-Chains plan. This conflicting guidance makes it harder, not easier, for an agent to correctly set the chain parameter.

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

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

The description states a specific verb and resource: it identifies wallets that pin identical compute-unit prices or Jito tips, i.e. a shared fee-setting fingerprint. It also explicitly distinguishes this from a timing link and positions it as corroboration for get_lookalike_clusters, so an agent can tell what this tool uniquely does.

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 says exactly when to use it: corroborate get_lookalike_clusters and catch operators who re-entered through fresh wallets. It also gives explicit negative guidance: do not call for EVM addresses, do not read a match as proof of coordinated buying, and pass chain solana or omit it.

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