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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds substantial behavioral context beyond annotations: it explains the 24-hour cap, per-purchase limit, how many more calls can be afforded, the distinction between receiving and spending addresses, and that it works without an open business. This enriches the agent's understanding of what the tool does and how to interpret its output, though it could be slightly more explicit about the absence of side effects.

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 description is dense but well-structured: it opens with a high-level purpose, enumerates return contents, explains the wallet block details, and then offers usage advice. Each sentence contributes relevant information needed for correct invocation. While it is longer than average, the complexity of the returned data and the important nuances (e.g., funding addresses, business_start interaction) justify the length. No sentence is wasted, and key info is front-loaded.

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 no output schema, the description carries the full burden of explaining return values, and it does so thoroughly: it lists available balance, held-back amounts, cap, limit, call estimates, wallet block, on-chain USDC, reserved amounts, seed headroom, and both address sets. It also explains the purpose of each address type and the relationship to business_start. An agent has all necessary information to call this tool and interpret its output correctly.

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?

The tool has zero parameters, and the description explicitly states 'Takes no arguments,' which is helpful for the agent to know it can be invoked without any input. Since there are no parameters to explain, the baseline is 4, and the description adds value by reinforcing the no-arguments requirement and clarifying the call context. This fully satisfies the dimension.

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 clearly states it reports on remaining budget and wallet contents, with explicit details about what is returned (available, held back, 24h cap, per-purchase limit, call estimates, wallet block). It uses a specific verb ('returns', 'call it') and identifies the resource (wallet/budget). However, it does not explicitly differentiate from the sibling 'budget_status', leaving some ambiguity about which status tool to use, though the wallet-specific focus provides some distinction.

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?

The description gives explicit usage guidance: 'call it whenever you are about to plan work or spend money' and 'Read it before committing to work rather than discovering a limit by hitting it.' It also provides a concrete workflow when no business is open: 'Works with no business open, which is when you should call it first: business_start refuses a seed the wallet cannot back, so check the headroom before proposing a number.' This clearly indicates when to use it and how it relates to business_start, making alternates explicit.

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