Country Calling Codes

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's added value is the clarification that it never returns live subscriber status and reports uncertainty/rule evidence. This is useful behavioral context that goes beyond the annotations without contradicting them.

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 two concise sentences with no filler. The primary purpose is front-loaded, followed by parameter guidance and a behavioral note. 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?

Given the presence of an output schema (as indicated in context signals), the description doesn't need to detail return values. It covers the main purpose, parameter usage, and a key behavioral limitation. The only minor gap is the lack of guidance on the 'detail' parameter, but overall it is sufficient for an agent to invoke the tool correctly.

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 0%, so the description must compensate. It explains the purpose of numberCountryCode and originCountryCode, but does not explain the 'detail' parameter (compact/full) or the format/constraints of phoneNumber. While phoneNumber is self-explanatory, the omission of detail is a gap given the low schema coverage.

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 ('Analyze a number') and a specific resource ('using versioned numbering metadata'), and it distinguishes itself from siblings by clarifying it reports uncertainty and rule evidence, not live subscriber status. This clearly differentiates it from tools like format_international_phone_number or get_phone_capabilities.

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?

It provides concrete parameter guidance: national numbers need numberCountryCode, exit prefixes need originCountryCode. This tells the agent when to supply which parameter. However, it does not explicitly name alternative tools or state when to prefer this over others, leaving some inference to the agent.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds useful behavioral warnings about indeterminate results from missing context and that equality does not imply ownership, going beyond the annotations.

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-loaded with the main action, with no redundant filler. The phrase 'after analysis' is slightly unclear but does not significantly harm conciseness.

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 has nested objects, optional fields, enums, and a default policy, but the description does not explain the output format, the meaning of 'missing context', or how country codes influence comparison. Important usage context is missing for an agent to call this reliably.

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 0%, and the description does not explain key parameters like left, right, detail, numberCountryCode, or originCountryCode. It only touches on extensionPolicy behavior, leaving most parameter meanings implicit and requiring inference from names.

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 the verb 'compare' and the resource 'two numbers', which clearly indicates the core function. It is distinguishable from sibling tools like normalize or analyze, though the phrase 'after analysis' adds slight ambiguity.

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 gives some conditional guidance about extensionPolicy and missing context, but it does not explicitly state when to use this tool versus sibling tools such as analyze_phone_number or normalize_phone_numbers. It implies comparison use cases but lacks direct alternative routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context by stating it 'propose[s] reviewed prefix repairs for confirmation,' indicating it is advisory and does not directly modify state, which aligns with the read-only hint. It also discloses a functional limitation (cannot determine network rejection), adding value beyond the annotations.

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 two concise sentences. The first sentence states the core function, and the second adds a key limitation. It is front-loaded and wastes no words, making it easy for an agent to quickly grasp the tool's purpose and constraints.

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?

Despite having an output schema, the description leaves out essential context for a tool with 7 parameters and 3 enums. It does not explain any parameter semantics, nor does it explicitly guide when to use this tool over its many siblings. The only usage cue is the limitation about network rejection, which is insufficient for an agent to fully understand when to invoke this tool.

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 0%, meaning the description provides no explanation of any of the 7 parameters. The description does not mention phoneNumber, symptom, detail, device, or any country code parameters. Since coverage is low, the description was expected to compensate but did not, leaving agents to rely solely on the schema's bare names and enums.

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 the tool explains formatting issues and proposes reviewed prefix repairs for confirmation, which is a specific verb+resource. It also adds a limitation (cannot determine why a network rejected a call), distinguishing it from related tools that might focus on network diagnostics. This is a precise purpose that differentiates it from siblings like analyze_phone_number.

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 provides a clear when-not case ('Cannot determine why a network rejected a call') but does not explicitly name alternatives or conditions for when to use this tool over others. The purpose implies usage for formatting issues, but there is no explicit comparison to siblings like format_international_phone_number or analyze_phone_number.

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

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

Beyond the readOnly/idempotent annotations, the description discloses important behavioral guarantees: it handles overnight shifts and DST, and it never contacts participants. This adds meaningful side-effect and edge-case context.

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 compact and well structured: it states the main action, key inputs, supported edge cases, and a negative guarantee in two sentences. No redundant wording is present.

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 description covers purpose, edge cases, and side-effect avoidance, but it omits output details and fails to reconcile the stated inputs with the empty input schema. This leaves an important contextual gap for an agent trying to invoke the tool correctly.

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 is empty, yet the description claims the tool uses 'explicit IANA time zones and dates.' This implies parameters that are not defined in the schema, and the description does not provide their names, types, formats, or example values. The parameter information is therefore incomplete and potentially misleading.

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 the tool's purpose: finding overlapping working hours. It also specifies the key inputs ('explicit IANA time zones and dates') and distinguishes the behavior from related phone-number tools by emphasizing it never infers location from phone numbers.

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 gives useful usage criteria: use explicit time zones and dates, and it explicitly warns against using this tool when only phone numbers are available. However, it does not mention alternative tools or provide a fuller when-to-use/when-not-to-use contrast.

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

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

Beyond the annotations, the description adds that processing is 'ephemeral' and that the tool does not query live carrier databases. This is valuable contextual information about the tool's offline, non-validating nature, going beyond what readOnlyHint and idempotentHint already convey.

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 two concise sentences, with the primary purpose front-loaded in the first sentence and supplementary behavioral details in the second. There is no redundant wording or unnecessary information, making it efficiently structured.

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 description is complete for this simple tool: it covers purpose, privacy (ephemeral processing), and scope (carrier-query exclusion). Given the full schema, annotations, and output schema, no critical information is missing for an agent to decide whether and how to invoke the tool.

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 provides 100% coverage for both parameters with clear descriptions. The tool description does not significantly expand on the parameters, merely implying that countryCode supplies country context. Since the schema already does the heavy lifting, the description adds little parameter-specific 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 uses a specific verb ('Normalize') and clearly identifies the resource ('a phone number') and the outcome ('international format'). It also mentions 'reviewed country-specific rules,' which distinguishes it from the sibling tool that merely looks up country calling codes, avoiding confusion with validation or live 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 states what the tool does not do ('does not query carriers, HLR/HSS, MNP databases, or live subscribers'), providing a clear boundary for when not to use it. However, it does not explicitly name the sibling tool as an alternative, so the guidance is clear but not fully explicit.

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

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

The annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds a behavioral nuance about network-dependent results and placeholder patterns, but these are vague and do not fully disclose side effects or error conditions. Since the description does not contradict the annotations, a middling score reflects the partial extra information.

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 (three sentences) without fluff, but the structure is disjointed: it jumps from purpose to parameter hint to behavior note without logical flow. It is concise but not well organized enough to clearly convey the tool's functionality.

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?

Given the schema has 6 parameters, 2 required, and enums, the description fails to explain the role of each parameter or the meaning of the required fields. Even though an output schema exists, the parameter semantics and usage context are under-specified, making this description insufficient for reliable tool selection.

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?

With zero schema description coverage, the description must compensate. It mentions 'origin' and 'destination' and 'phone number' but does not map them to the six parameters or explain the enums (detail, device) or the format constraints. The agent would still be guessing about what each parameter expects.

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 verb ('prepare') and object ('dialing guidance') but does not concretely define what that guidance entails or what the output looks like. 'Origin-specific' and 'reviewed countries' are ambiguous, and the description does not differentiate it from sibling tools like 'format_international_phone_number' or 'lookup_country_calling_code'.

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 gives a partial hint about parameter usage ('no phone number returns safe placeholder patterns') but does not clarify when this tool is preferred over alternatives. It lacks any explicit mention of conditions or exclusions, leaving the agent to infer when to choose this tool.

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

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

The description's verb 'Discover' aligns with the readOnly and idempotent annotations, and no side effects are implied. While it does not add much behavioral detail beyond the annotations, it does not contradict them and reinforces the non-destructive nature.

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, compact sentence that lists the key returned categories in a clear sequence. There is no fluff or redundancy, and every phrase adds useful information.

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?

With an output schema present, the description does not need to detail the return structure. It names the main dimensions returned (supported countries, per-operation coverage, evidence, dataset versions, request limits) and gives a clear use case, making it complete enough for an agent to decide to call it.

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 has no parameter descriptions, and the description only loosely maps to the parameters: 'supported countries' hints at countryCode and 'per-operation' hints at operation. It does not explain optionality, allowed values, or how the parameters affect the result, so the description does not compensate for zero schema coverage.

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 the tool's purpose: to discover supported countries, per-operation review coverage, evidence, dataset versions, and request limits. This is distinct from the sibling tools, which perform analysis, comparison, normalization, or diagnostics rather than capability discovery.

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 phrase 'before choosing a phone workflow' gives a clear temporal and contextual trigger for when to use this tool. It does not explicitly name alternatives or exclusion criteria, but the intended use case is sufficiently clear.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds transparency about limitations: 'Examples are not validation masks' and 'English fallback and unsupported editorial coverage are explicit.' These clarify edge cases and fallback semantics beyond the annotations.

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 two sentences, front-loaded with the core purpose, and contains no fluff. Every sentence adds meaning: the first states what is retrieved, the second clarifies important caveats.

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?

Given the tool is simple (two parameters, no nested objects) and has an output schema, the description adequately covers purpose and behavioral caveats. The missing parameter explanations are a minor gap given the self-evident names, but the description does not fully cover all relevant aspects for an agent to use it confidently.

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 0% and the description provides no explanation of the 'locale' and 'countryCode' parameters. While parameter names are somewhat self-explanatory, the rubric requires the description to compensate for missing schema descriptions; it does not.

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 the specific verb 'Get' and identifies the exact resource: 'reviewed display placeholders and trunk-prefix guidance.' This clearly distinguishes it from sibling tools like get_dialing_instructions or get_phone_capabilities by stating its unique output focus.

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 usage (when placeholders or trunk-prefix guidance are needed) but does not explicitly state when to prefer this tool over alternatives or provide exclusion criteria. The cautions about validation masks and fallback behavior give context but not directive guidance.

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

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

The description adds useful context beyond the readOnly and idempotent annotations: examples are 'reviewed, source-linked', and it explicitly warns that live numbers are not verified. This is genuine behavioral disclosure, though it doesn't go into details like rate limits or response structure.

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 two sentences long and front-loaded with the core action. The optional examples feature is briefly mentioned, followed by the limitation. Every sentence earns its place with no redundancy or filler.

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 a simple lookup with a full output schema and 100% schema coverage for parameters. The description adds the key limitation (no live number verification) and the nature of the examples. Given its simplicity and rich structured metadata, the description is complete enough for correct selection and invocation.

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 provides 100% parameter coverage with detailed descriptions for all six parameters. The description maps high-level search methods (free text, ISO code, dial code, region) to corresponding parameters but doesn't add deeper syntax or format details beyond what the schema already states.

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 specifies exactly what the tool does: 'Look up international country calling codes' with supported search methods (free text, ISO code, dial code, region). This clearly distinguishes it from the sibling tool 'format_international_phone_number', which formats rather than looks up.

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 gives clear context: use this tool to look up country calling codes. It also notes an important exclusion: 'This tool does not verify live subscriber numbers.' However, it does not explicitly name the sibling tool as an alternative when formatting is needed, so it misses the 'alternatives' criterion for a 5.

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

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

The annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that no contacts are changed or stored and that invalid records produce individual errors, which is useful. However, it does not explain error formats, rate limits, or other side effects beyond what annotations already imply.

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 concise and front-loaded, using two sentences to convey the core operation, input constraint, error behavior, and optional capability. There is no extraneous information.

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 description leaves out critical context: the exact input format, the output structure, how records are identified, and what 'canonical duplicate candidates' means. While an output schema is said to exist, it is not provided, and the empty input schema combined with vague parameter references makes the tool incomplete for an agent to invoke correctly.

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 is empty, yet the description refers to 'records with unique IDs' and 'optionally identify canonical duplicate candidates,' implying parameters that are not defined. The agent is given no information about how to specify the records or enable the optional duplicate-candidate mode, making the tool effectively unusable from the description alone.

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 that the tool normalizes up to 100 records with unique IDs and can optionally identify canonical duplicate candidates. However, it does not explicitly mention phone numbers in the description, relying on the tool name, and it does not differentiate itself from the sibling tools beyond a general batch-normalization role.

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 does not provide explicit guidance on when to use this tool versus the sibling phone-related tools. It mentions optional duplicate identification but gives no criteria for choosing this batch operation over single-record tools like analyze_phone_number or format_international_phone_number.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds valuable behavioral context: it clarifies that results are 'numbering assignments' and explicitly excludes current location and carrier. This tells the agent that the tool does not perform real-time geolocation, which is a meaningful behavioral disclosure beyond the annotations.

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 two sentences long and wastes no words. It front-loads the primary action and then immediately adds the key limitation. Every sentence earns its place: the first states what the tool does, the second clarifies what it does not, both essential for correct invocation. The structure is efficient and clear.

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?

An output schema exists, so return-value details are not required. However, with 0% parameter coverage, the description leaves the agent without any understanding of how the optional parameters alter behavior. The tool is not trivial—it has four parameters and returns candidate objects—and the description does not explain the meaning of 'metadata-backed' or the role of country codes. This incompleteness could lead to misconfiguration, especially since 'originCountryCode' has no obvious purpose from the description alone.

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 0%, meaning the schema itself provides no descriptions for the parameters. The description offers zero information about what 'detail', 'numberCountryCode', or 'originCountryCode' mean or how they affect the result. Since the schema is the only other source and it lacks explanations, the description completely fails to compensate. An agent would have to guess the semantics of these optional parameters, which is a significant gap.

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 ('Resolve') and a clear resource ('phone number to metadata-backed country candidates or non-geographic numbering'). It also explicitly states what the tool does NOT do (current location or carrier), which sharply distinguishes it from sibling tools like analyze_phone_number or get_phone_capabilities. This leaves no ambiguity about the tool's core purpose.

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 usage: use this tool when you need country candidates based on numbering plan metadata. It also provides a negative guidance (not location/carrier) that helps avoid misuse. However, it does not explicitly name alternative tools or state conditions like 'use analyze_phone_number for deeper analysis' or 'use lookup_country_calling_code for a single code'. The guidance is clear but not prescriptive about when to choose this over siblings.

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