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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Search' and 'leaked databases,' which implies a read-only lookup, but it does not disclose what data sources are searched, whether results are presence-only or include captured records, any rate limits, or whether the tool performs an external lookup.

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 efficient sentence with no redundant filler. The 'Phone Leak Check' prefix is slightly redundant with the title but not harmful, and the core action is front-loaded.

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 is simple and has an output schema, so return values do not need elaboration. However, with no annotations and no parameter documentation, the description leaves out important context such as accepted phone-number formatting, data coverage, and how to select this tool over the many adjacent leak and phone-related sibling tools.

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 input schema only provides 'q' with a default of '' and no description, so the description compensates by indicating that the tool searches for a phone number. This lets an agent infer that 'q' is the phone number, but it does not specify expected formatting, normalization, or how to handle an empty default value.

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 action ('Search') and a specific resource ('phone number in leaked databases'). This distinguishes it from generic leak-related siblings like leakcheck or breach_aggregator, though it does not explicitly name any alternative.

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 implied use case is when a user wants to check if a phone number appears in leaked databases, which is clear enough from the description. However, it provides no explicit guidance about when not to use it or how it differs from sibling tools such as leaklookup, breachsearch, or credential_stuffing.

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