fund_wallet

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

With no annotations, the description carries the full burden, and it usefully discloses the key behavioral trait: the funds are simulated and 'Not real money', so an agent won't mistake this for a real transfer. It does not disclose idempotency, per-call or cumulative limits, whether calling twice compounds the balance, or required permissions.

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?

Two short, front-loaded sentences with the sandbox warning and the non-real-money caveat first; nothing is wasted. It is arguably too terse for a tool with an ambiguous string amount, but there is no filler.

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?

Low-complexity tool with 2 params and no output schema, so the essentials are nearly covered: what it does and that it is fake money. The remaining gap is material—amount format and any faucet limits are undocumented anywhere.

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 there are two required parameters, yet the description explains neither. Critically, amount_usdc is typed as a string with no indication of format (decimal '10.50' vs base units) and no limits, so an agent must guess the unit and syntax.

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 action (add simulated test USDC) with the explicit qualifier 'SANDBOX faucet', which distinguishes it from real-value siblings such as pay or approve_payment. The resource (a wallet) is only implied via the wallet_id parameter rather than named in the sentence.

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?

'so demos and tests can run' implies test/demo contexts, and 'SANDBOX' signals non-production usage. However, it gives no explicit when-to-use vs when-not-to-use rule, no reference to the sibling tools (e.g., use pay for real transfers), and no statement about whether this is safe to call repeatedly.

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