Spending policy

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description does add genuine context beyond that: the server enforces this policy as a gate before returning calldata, and the window is a rolling 24 h with a daily cap. It does not say what happens when the cap is exhausted (is calldata withheld? error returned?) or whether the window is per-key, which are the details that actually matter for a policy tool.

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?

It is a single sentence with no filler and the core concept (enforced spending policy plus current window usage) is front-loaded. The sentence is a comma-spliced list of noun phrases rather than a clean clause, which costs a bit of readability but wastes no space.

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 input parameters and no output schema, the description carries the burden of describing the return, and it does list three components: the policy itself, USD spent in the rolling 24 h window, and remaining daily cap. It stops short of saying what units/format the amounts use or whether the policy applies per call or per session, which are minor but real gaps for a zero-parameter reporting tool.

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 takes zero parameters, so the baseline of 4 applies. Schema coverage is 100% and there is nothing for the description to disambiguate on the input side.

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 names a specific resource (the server's spending policy) and enumerates what is reported: USD spent in the rolling 24 h window and what remains of the daily cap. The verb is implicit rather than stated ('returns' is inferred from 'before returning calldata'), and no sibling is named, but none of the listed siblings overlap with this resource, so an agent can still place it unambiguously.

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?

Usage is only implied: the phrase 'enforced before returning calldata' hints that this should be consulted before operations like quote or build_swap that produce calldata, but the description never says when to call it, when not to, or which sibling it substitutes for. An agent must infer the pre-flight-check role.

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