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

The description discloses substantial behavioral detail: tokens are locked into an escrow, an unsigned base64 transaction is returned, a claim_code acts as a bearer secret, expiry_days controls the claim window, unclaimed tokens return to sender, and anti-abuse limits apply. It also explains the optional idempotency_key replay semantics, which annotations alone do not capture. No contradiction with annotations is present.

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 a clear one-sentence purpose and then organizes related detail: escrow flow, claim code, expiry, gating, and idempotency. It is dense but every clause adds meaningful information; minor redundancy exists around the claim link and claim_code.

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 complex, state-changing tool with an output schema, the description covers the lifecycle, constraints, and idempotency behavior in enough detail for an agent to invoke it correctly in most cases. The main gap is the unexplained allow_unverified and caller_id parameters, which an agent may need to handle 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?

With 0% schema description coverage, the description compensates well by explaining amount as base units, token as mint, sender_wallet, expiry_days with default and range, referral binding, and idempotency_key. It does not explain allow_unverified or caller_id, and handle/wallet formats are left implicit, so it is strong but not 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?

The first sentence names a specific action and mechanism: 'Send tokens to an X handle via a claimable crank.ing link (non-custodial).' This is a specific verb+resource that clearly distinguishes the tool from bulk_send_social by the singular recipient and the claim-link mechanism, even without naming alternatives.

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 solid context for what the tool does, including the non-custodial flow, platform x, and anti-abuse gating. However, it does not explicitly state when to prefer this over bulk_send_social or when not to use it, leaving some routing decisions to inference.

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