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

Goes well beyond the readOnly/idempotent annotations: discloses pricing (0.003 USDC per call), the x402 payment mechanism with no account or API key, that invalid input is refused before payment, that failed runs are never charged, and that an unpaid call returns PaymentRequired. These are exactly the runtime traits an agent needs to avoid surprise failures.

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-loads the capability and output contents in the first two sentences, then layers on commerce and error behavior. The free-sample pointer and HTTP endpoint URL are useful but push the tail toward promotional weight; nothing is strictly wasted, but it is on the long side.

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 compensates by listing the decoded fields the agent will receive, plus status, fee and balance deltas. Combined with the payment and failure semantics, an agent has everything needed to call it and interpret the result.

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?

Only one parameter with 100% schema coverage, so the schema already carries the meaning. The description adds a real base58 signature in the example URL that implicitly illustrates the expected format, but never states format or constraints explicitly.

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 (decode a Solana transaction into plain language) and enumerates the exact output fields: type, program/DEX, transfers with token symbols and amounts, SOL balance changes, fee and status. This clearly separates it from siblings like solana_portfolio (holdings) and solana_token_check (token 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?

Gives concrete use cases — 'confirm a payment or audit what a wallet did' — which tell the agent when to reach for it. It does not explicitly name an alternative tool or state when not to use it, so it stops short of a full routing rule.

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