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

With no annotations provided, the description carries the full burden and handles it well: it explains overlay_codes, the rate-centre-to-city matching, the non-legal-boundary caveat, and mobile-number portability. This goes well beyond a simple 'looks up area codes' statement.

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 dense but well-organized into three sentences: output fields, use cases, and caveat. Each sentence adds substantive information without filler, and the parenthetical overlay example makes the abstract concept concrete.

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—one required string parameter and no output schema—so the description's list of returned fields (states, top cities, ZIP/city counts, overlay_codes) is sufficient. It also includes the key caveat about city-level accuracy, making the tool safe and predictable to invoke.

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 schema already fully describes the only parameter as a 'Three-digit NANPA area code' with an example, so the description doesn't need to add much. It reinforces that this is a US/NANPA code and provides usage examples, but doesn't introduce new parameter-level constraints.

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, well-scoped resource—US telephone area codes—and enumerates the exact output: states served, top cities by ZIP count, total ZIP/city counts, and overlay_codes. Use-case examples like 'where is area code 310' make the tool's goal unmistakable, and the 'via the city’s ZIPs instead' phrasing helps separate its role from a postal-code-style lookup.

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 explicitly says 'Use it for' and provides concrete query types, plus a sanity-check use case. It does not name a specific sibling tool or an explicit when-not-to-use condition, but the ZIP-based aside implies the alternative route. The Denver example is slightly indirect since the tool takes an area code, not a city.

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