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

With no annotations, the description carries the behavioral disclosure burden. It reveals two important traits: the tool uses k-anonymity, implying the password itself is not exposed in full, and no API key is needed. It does not discuss rate limits or error behavior, but for a read-only check these are secondary.

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 brief and front-loads the core purpose. The leading 'HIBP Password Check:' prefix is slightly redundant with the tool name and title, but otherwise every clause 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?

For a one-parameter tool with an output schema, this is mostly adequate, but there are gaps: `q` is not explicitly documented as the password, the parameter is optional per the schema while the description implies a password is needed, and no usage example or expected input format is provided. The k-anonymity note adds useful context, though.

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%, so the description must compensate for the single generic parameter `q`, and it does infer that `q` is the password to check. However, it never explicitly labels `q` as the password, nor does it clarify whether a plaintext password or a hash should be provided, leaving some ambiguity.

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 action - 'Check if a password appeared in breaches' - and names the exact mechanism, HIBP k-anonymity, with a key differentiator: no key required. This makes it clearly distinct from sibling tools like hibp_email or hibp_breaches, which target different inputs or require credentials.

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 implies when to use this tool: when you need to check a password against breach data without an API key. However, it does not explicitly state when not to use it or name alternatives such as hibp_email, passwordcheck, or breach_aggregator, leaving some routing work to the agent.

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