get_account

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful context by explaining the read yields account plan and capability constraints, and frames the result as the allowance boundary ('what you're allowed to set'). No contradiction 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 compact and front-loaded, stating the main purpose first and then listing the concrete return fields in a structured sequence. Both sentences earn their place, and there is no filler or repetition.

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 parameterless read-only account-information tool, the description fully covers what data will be returned and why the agent would call it. With an output schema present, return-value details are already structurally defined, and the description adds the needed semantic context.

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, so the baseline is 4. The description correctly omits parameter-specific guidance because none is needed, and the schema's empty object confirms no inputs are required.

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 opens with a specific verb and resource ('Show the account's plan and capabilities') and enumerates the exact fields returned (plan tier, container limit, memory sizes, storage limit, always-on count, auto-sleep). This clearly distinguishes it from identity-focused siblings like whoami or container-focused tools like get_container.

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 closing sentence 'Use this to see what you're allowed to set' gives clear context for when to invoke this tool. It does not explicitly exclude alternatives or mention when-not-to-use, but the tool's narrow account-capabilities scope makes that less critical.

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