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

The description depicts a network-publishing write action ('Relay ... to the network', returns {accepted, txid, chain, relayed}), yet the annotations declare readOnlyHint=true and openWorldHint=false. Broadcasting a signed transaction modifies network/mempool state and reaches an open network, so the read-only/closed-world annotations are contradicted by the described behavior. Despite otherwise rich context (non-custodial, availability flag, rejection handling), the contradiction triggers the rule.

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-loaded with purpose and cleanly structured under 'When to use', 'Do not use', 'Returns', and 'Availability' labels, so every section is scannable. Slight redundancy in restating the non-custodial point twice ('we never see a private key' and 'we never hold keys') keeps it just short of perfect.

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 broadcast tool with no output schema, the description covers the interaction model (non-custodial relay), success and failure return shapes ({accepted, txid, chain, relayed} vs {accepted:false, reason}), rejection semantics, and the critical deployment availability gate (RB_ENABLE_BROADCAST=1). An agent has everything needed to decide whether and how to call it.

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 50%: signed_raw_tx_hex is documented in the schema and 'chain' has an enum but no prose. The description reinforces that the transaction must be already signed locally ('we never hold keys'), adding marginal meaning, but provides no format or constraint details beyond the schema. Baseline 3 is appropriate.

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 ('Relay an already-signed raw transaction to the network through our own full node') plus the non-custodial scope, and explicitly distinguishes itself from siblings like btc_get_transaction. An agent can tell exactly what this does and what it does not.

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 explicit 'When to use' (an agent signed locally and wants a high-availability broadcast) and 'Do not use' cases (build/sign, look up a payment, naming btc_get_transaction as the alternative). Nothing is left to inference.

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