Payment status of this local server (free)

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond annotations: it is 'Free, answered locally' and takes no arguments, and it enumerates the data returned (wallet address, USDC balance, caps, signed/settled items, tool prices). It does not explicitly state permissions or output format, but adds meaningful behavioral context.

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, front-loaded sentence that immediately states 'Free, answered locally' before listing returned data. The enumeration is somewhat long but each item earns its place by describing what the tool reports, and it remains focused.

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 compensates by listing the key return values (payment method, wallet address, USDC balance, spending caps, signed/settled activity, tool prices). Annotations cover safety traits, and 'No arguments' clarifies the empty schema. The definition is complete enough for an agent to call it correctly, though it could clarify its relationship to wallet_profile.

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?

There are zero parameters, so the baseline is 4. The description explicitly confirms 'No arguments,' matching the empty schema and removing any ambiguity about input requirements.

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 identifies the resource: local payment status, wallet address, balance, caps, settlement, and tool prices. It implies a read/status retrieval without a distinct verb, but an agent can tell it is about payment state. It does not differentiate from the sibling wallet_profile, which could also concern wallet information.

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 states it is 'Free, answered locally,' but gives no explicit guidance on when to use this tool versus alternatives like wallet_profile. No when-not conditions or exclusions are provided, leaving usage entirely to inference.

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