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

Annotations declare readOnlyHint=false and destructiveHint=false, but the description adds the crucial fact that no monitoring is configured and no funds are sent — effectively negating any side effects despite the non-read-only annotation. It does not specify the error shape or whether the parameters are validated before failure, which is the only remaining gap.

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?

Three short sentences with the unavailability stated first, then the behavior, then the fallback path — well front-loaded and free of filler. The final sentence is slightly dense, packing a balance check and two alternatives into one clause.

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 stub tool with no output schema, the description covers everything an agent needs: it always fails, it has no side effects, and there is a named replacement workflow. Nothing necessary for correct invocation is missing.

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%, so threshold_trx, deposit_amount_trx and max_daily_deposits are already documented in structured form. The description adds nothing about them and, notably, does not say the parameters are ignored because the call always errors — that would have been genuinely useful added meaning. 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 opens by declaring the capability unavailable and then defines the tool's actual behavior: a compatibility stub that returns an error without configuring monitoring or sending funds. That is a specific, non-tautological statement that lets an agent distinguish it from the real funding tools. It stops short of 5 only because it never states why the stub exists beyond the word 'compatibility'.

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 explicitly says when not to rely on this tool and names the concrete alternative path: check get_balance, then use get_deposit_info or an explicitly requested deposit_trx. Sibling names are given verbatim, so no inference is required to route correctly.

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