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

Annotations already mark it readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds two genuinely useful behavioral facts beyond the annotations: the tool is a paid call costing $0.002 USDC via x402, and it discloses the returned data surface (mempool vs confirmed, fee fields, RBF flag), which matters heavily since there is no output schema. It stops short of five because nothing is said about behavior for unknown/unconfirmed txids or caching.

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?

One densely packed sentence front-loads the core payload fields, then closes with the cost note. No filler, though the comma-separated return-field list reads more like a schema dump than a structured description.

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 usefully carries the return-value burden by enumerating every field an agent will get back, and it discloses the payment model. Gaps remain on input format and on how sibling tools should be chosen, but for a single-parameter read tool this is close to sufficient.

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 description coverage is 0% and the single parameter txid carries no schema-level detail, so the description must compensate — yet it never mentions txid at all. It gives no format (64-char hex hash), no note about ambiguity between chains or testnet, which is especially costly for a metered $0.002 call.

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 clearly establishes this as a Bitcoin transaction lookup tool by enumerating exactly what it returns: confirmation status, confirmations, fee in BTC and USD, fee rate, inputs/outputs, and RBF signaling. The verb is only implicit (it is a data-retrieval tool), and it never distinguishes itself from sibling transaction tools like tx_explain or tx_simulate, so it falls short of a 5.

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?

There is no guidance on when to use this tool versus the adjacent tx_explain, tx_simulate, or btc_fees tools, despite those siblings clearly overlapping in scope. The only contextual note is the per-call price, which is a cost fact rather than usage guidance.

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