Check a phone number

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

With no annotations, the description carries the burden and does meaningful work: it discloses that the check is fully offline with no network access, and that it is a classification/read operation returning reputation signals rather than mutating anything. It stops short of stating whether blocklist/allowlist results depend on server-side configuration or how results are shaped, but the safety and execution profile is clear.

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?

A single front-loaded sentence led by the verb, with the 'offline / no network access' qualifier placed at the end as a compact caveat. Every clause adds discriminating information; nothing is wasted.

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?

There is no output schema and no annotations, so the description must convey what comes back, and it does by enumerating the classification dimensions. It is nearly complete for a two-parameter read tool; only the precise result shape and any config-dependent behavior are left implicit.

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 description coverage is 100%, so both parameters are already documented, which sets the baseline at 3. The description does add a little signal by noting sender IDs are accepted and that country/line-type classification depends on a region for national numbers, but it never explains the region parameter's role explicitly.

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 uses a specific verb pair ('parse and classify') on a clearly scoped resource ('a phone number or SMS sender ID') and enumerates the outputs (validity, E.164, country, line type, premium-rate, reputation). This distinguishes it from siblings like check_url and check_message, which operate on different artifacts.

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?

Usage is implied rather than stated: an agent can infer this is the right tool when it holds a raw number or sender ID, and 'offline / no network access' signals it is a fast local check. However, there is no explicit guidance on when to prefer check_message or check_url instead, nor any note on required vs. optional region usage.

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