send_inbox_message

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

With no annotations, the description's most valuable disclosure is deprecation status, and it delivers that plus a contrast implying this path carries an STX gas burden. However it never says whether calling it still works or fails, nor what it costs or destroys, so the behavior of this tool itself remains undocumented.

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 deprecation warning and the redirect are front-loaded and stated crisply in two sentences. The closing tip promoting earning_opportunities is unrelated to invoking this tool and is the one line that does not earn its place.

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 deprecation stub with a fully documented 3-parameter schema and no output schema, the essential information — don't call this, call that instead, here's why — is present. Only the absence of any statement about what happens if it is called anyway keeps it from being complete.

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 100% and all three parameters carry their own descriptions (BTC address, STX address, content max 500 chars), so the schema does the work. The description adds no parameter guidance — notably nothing about the recipient needing to match on both address fields — so the baseline 3 applies.

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 never states what this tool itself does — the reader must infer "send an inbox message" from the name alone. It is explicit that the tool is deprecated and does name the intended replacement, which disambiguates it from send_inbox_message_direct, but the actual operation is never described in words.

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?

It gives an unambiguous when-not-to-use ("⛔ DEPRECATED — do not use"), names the exact alternative, and supplies the reason a caller should prefer it (gasless, relay pays STX gas, only sBTC cost required, mainnet only). Nothing about tool selection 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.