wallet_get_pockets

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

The description adds meaningful behavioral context beyond the readOnlyHint, idempotentHint, and openWorldHint annotations: it notes that Pro/Earn balances are excluded and warns that users may have multiple pockets for the same symbol, so the agent must check all pockets. The [PRIVATE] marker also signals sensitive data. No contradiction with annotations exists.

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 front-loaded with the core purpose and contains valuable admonitions about multiple pockets. It repeats some details already in the schema, such as the pocket_id filtering behavior, which slightly reduces efficiency, but the overall length is justified by the important usage caveats.

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 simple read-only wallet listing tool, the description covers the return contents, the default behavior, the optional filtering behavior, the exclusion of Pro/Earn balances, and a critical multi-pocket caveat. With annotations already covering safety characteristics, nothing essential is missing for correct invocation.

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 input schema already provides 100% description coverage for jwt, symbol, and pocket_id, including format and behavior. The description mostly repeats the pocket_id filtering behavior and does not add significantly beyond the schema, so baseline 3 is appropriate.

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 the tool's purpose: getting balances, UUIDs, and available funds from Simple Wallet pockets. It also explicitly excludes Pro/Earn balances, which distinguishes it from related balance tools in the sibling list.

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 explains that the tool returns all pockets by default or a single pocket when pocket_id is provided, and it explicitly rules out Pro/Earn balances, helping the agent choose the correct balance tool. It does not name sibling wallet tools as alternatives, but the resource and scope are clear enough.

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