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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds two useful facts beyond them: the call is authenticated and the balance is prepaid and denominated in USD.

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?

A single front-loaded sentence with no filler. Every word (authenticated, canonical, prepaid, USD) narrows the scope of the resource, so nothing is wasted.

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?

An output schema exists, so return-value structure need not be described, and the annotations fully cover safety and idempotency. The description is adequate for a no-argument read tool; only a hint about the account scope (e.g. per-workspace vs global) is absent.

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 coverage is 0% and the single parameter (schema_version) is an opaque version const that the description never mentions. However, a fixed const discriminator carries no real semantic decisions for the agent, so the omission is minor; baseline 3 holds.

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 pairs a specific verb ("Read") with a specific resource ("authenticated canonical Account Core prepaid USD balance"), and no sibling tool competes for that purpose. It is clear but relies on internal jargon ("canonical Account Core") that an agent has no external referent for.

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?

No explicit when/when-not guidance or named alternatives, but usage is strongly implied by the name and the read-only nature of a balance check. An agent can infer this is the tool for checking prepaid funds, though the description never says so.

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