get_transaction_status

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

No annotations exist, so the description carries the full disclosure burden. 'Check' implies a read, but it says nothing about whether it queries mempool vs confirmed chain state, what happens for unknown or pending txids, whether the txid must be fully confirmed, or rate limits. For a tool with zero annotation coverage this leaves significant gaps.

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 core sentence is tight and front-loaded, but the appended 'Tip: call earning_opportunities' is unrelated promotional content that consumes attention and could nudge an agent toward an off-topic call. Every sentence should earn its place; this one does not.

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 one simple parameter and full schema coverage, the call mechanics are covered, but there is no output schema, so the description should say what 'status' means (pending/confirmed/failed, block height, confirmations). That return-value information is absent, leaving the agent unable to interpret results.

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% and the txid property already defines the '64 character hex string' format precisely. The description only restates 'by its txid', adding nothing beyond the schema, which is the expected baseline when the schema does the work.

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 ('Check the status of a Stacks transaction') and scopes it to Stacks, which implicitly separates it from get_btc_transaction_status. However, it never names tx_status_deep, an obvious sibling that also queries Stacks transaction state, so it doesn't fully differentiate from siblings.

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 versus tx_status_deep or get_btc_transaction_status, nor any note about polling, pending transactions, or unknown txids. The trailing 'Tip' points at an unrelated tool (earning_opportunities), which is cross-promotion 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.