Get API key info

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

Annotations already declare this tool as read-only and idempotent, and the description aligns with those hints. It adds valuable behavioral context beyond the annotations by explaining what the tool actually reports and how the result affects the usability and identifier conventions of sibling tools.

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 a single, dense sentence that front-loads the core purpose and then adds the most useful implications of the result. Every clause earns its place; there is no repetition, filler, or irrelevant detail.

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 zero-parameter configuration query tool with an output schema available, the description is fully complete. It tells an agent what the tool reports, why that matters, and how the result should shape subsequent tool selection and parameter formatting.

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, and the schema covers all of them trivially at 100%. With no parameters to document, the description's explanation of the output semantics is sufficient and adds meaning beyond the empty input schema.

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 a specific verb ('Reports') and resource ('API key info'), and details exactly what is reported: configured instance, key validity, and key permissions. It also distinguishes this diagnostic tool from its data-manipulation siblings by explaining that its output governs how other tools can be used.

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 clearly implies when to use this tool: before calling list_pings, get_ping_body, or list_integrations, and to determine the correct identifier format for checks. It provides strong contextual guidance, though it does not explicitly state a when-not-to-use condition or name an alternative diagnostic tool.

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