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

Annotations already cover safety (readOnlyHint) and scope (openWorldHint), so the bar is lower, yet the description adds genuinely new behavioral context: per-call cost of $0.002 USDC via x402, and the shape of the returned data (recommended, all levels, total fee in SOL). It stops short of stating latency, caching, or fallback behavior.

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?

A single front-loaded sentence with the core purpose first and the return content and pricing trailing after a colon; no filler. It runs a little dense and the pricing parenthetical could be its own sentence, but nothing is wasted.

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 2-param read tool with no output schema, the description covers what is returned, the cost model, and the semantic tie between inputs and the fee total, so an agent can call it without guessing. The main residual gap is the undocumented compute_units parameter and the absence of any guidance on interpreting the fee levels.

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 only 50% schema description coverage, the description must partly compensate. It clarifies that 'accounts' accepts programs or accounts (matching the schema's 'program or account addresses') and ties 'compute_units' to 'your compute budget' so the fee total is interpretable, but it gives no default, format, or unit guidance for compute_units beyond the schema's own type.

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+resource ('Live Solana priority fee estimate') and scopes it to the accounts or programs a transaction touches, which cleanly separates it from chain-generic siblings like btc_fees, gas, or defi_fees. It even enumerates what it returns (micro-lamports per CU, min-to-very-high levels, total fee in SOL).

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 phrase 'for the accounts or programs your transaction touches' implies the use case (fee selection before building/submitting a transaction), but the description never explicitly says when to call it versus alternatives, nor states prerequisites or ordering relative to swap_build or tx_simulate. Usage is inferable rather than spelled out.

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