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

Annotations already declare read-only, idempotent, open-world, and non-destructive traits. The description adds concrete details about returned content (plan, credit balance, rate limits, tools) and the purpose of verifying setup, which goes beyond the annotations without contradicting them. It doesn't cover error cases, but the safety profile is already well documented.

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?

Two sentences with no wasted words: the first states the core function, the second gives usage guidance. Content is front-loaded and every word earns its place.

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?

The tool has an output schema, so return values are covered separately. The description provides a high-level summary of the return content and explicit usage instruction, sufficient for an agent to call it correctly. No missing context for this simple 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 has zero parameters, so no parameter documentation is needed. Schema coverage is effectively 100% because there are no params to describe. The description appropriately omits parameter details, aligning with the baseline for param-less tools.

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 states a specific verb 'Identify' and a clear resource: account, user, credential, plan, credit balance, rate limits, and tools. It distinguishes itself from siblings by focusing on connection identity and setup info, and adds a directive to call it first. No ambiguity.

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?

Explicitly instructs 'Call it first to verify the setup,' giving a clear when-to-use directive. As a self-identification tool, it has no competing alternatives, and the instruction establishes its role in the toolset unambiguously.

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