SendMyCall public data

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 safety profile is covered. The description adds useful context beyond that: this is a per-area detail lookup that surfaces pricing, compliance documents, and a purchase link, which tells the agent it is an informational enrichment call rather than an action.

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 sentence that front-loads the action and id source, then lists returned data. It is a long run-on but every clause is substantive and none is filler, so it stays within a reasonable size.

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 read tool with a full output schema and complete annotations, this covers purpose, id provenance, and the shape of the payload. The only gap is the absence of sibling differentiation against get_calling_rate/get_forwarding_rate, which an agent comparing rate tools would find useful.

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 100% and the schema description already states 'Public area id from search_areas' with a format example. The description's '(from search_areas)' merely restates that, adding no new syntax, format, or constraint detail. Baseline 3 is correct when the schema carries the parameter documentation.

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?

States a specific verb+resource ('Get one number area by its id') and then enumerates exactly what is retrieved: prices, toll-free per-minute rates, number features, required documents, billing terms, and a purchase link. It also names the sibling search_areas as the source of the id, so an agent can place it in the workflow without opening the schema.

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 parenthetical '(from search_areas)' establishes the prerequisite step and implies the tool is used after a search to inspect a specific area. It does not state when NOT to use it or name alternative rate tools (get_calling_rate, get_forwarding_rate), so routing is implied rather than 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the bar is lower. The description adds genuinely non-structured context: the number is used for lookup only and is neither stored nor returned (a privacy guarantee), plus the longest-prefix matching rule.

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?

Three short sentences, front-loaded with the core action; the forwarded-call clarification and the non-storage note each earn their place as disambiguation and behavioral context. No 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?

An output schema exists, so return values need not be explained, and the single, fully documented parameter plus rich annotations cover most needs. It stops short of saying what happens when no prefix matches (error vs. fallback) or the currency/units of the returned price, which are the remaining gaps.

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% for the single parameter, including the E.164 pattern and an example, so the baseline is 3. The description adds only the marginal note that the number is not persisted, not any format or matching detail beyond the schema.

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 gives a specific verb+resource (per-minute price of a call to one phone number) and names the resolution mechanism (longest matching prefix). It is clear, but it does not explicitly distinguish itself from the sibling get_forwarding_rate, which it partially overlaps with by covering 'a call forwarded, to one 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?

Usage is implied rather than stated: the tool is for looking up a rate for a specific number. There is no explicit 'use this instead of get_area_pricing/get_forwarding_rate when...' routing, and the overlap with get_forwarding_rate is left unresolved for 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 declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely behavioral content beyond that — that the result is split into a free tier (SIP/VoIP/app) versus a paid per-minute range to real phone numbers — which tells the agent how to interpret the response, though it says nothing about price freshness, coverage gaps, or rate limits.

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?

One sentence, front-loaded with the action and the result shape, with the disambiguation parenthetical placed at the end. No filler, no restatement of the title.

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 is not obliged to explain return values, and the single required parameter is fully specified in the schema. It is complete enough to call correctly; only minor gaps remain, such as whether prices are cached or how often they refresh.

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?

There is a single parameter and schema description coverage is 100%, so the schema already documents the ISO 3166-1 alpha-2 format and example. The description only reinforces the semantics of 'country' as the forwarding destination, which is the baseline 3 when the schema does the heavy lifting.

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?

States a specific verb and resource ('get what forwarding calls to a country costs') and immediately enumerates the two price components returned: free destinations (SIP, VoIP, app) and a per-minute range for the country's phone numbers. The final parenthetical explicitly distinguishes it from the sibling get_calling_rate, so an agent can route between them without opening either schema.

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?

Names the alternative tool and the exact condition that selects it: 'use get_calling_rate for one exact number.' That is an explicit when-to-use-this-vs-that rule, the pattern that earns top marks for routing guidance, and it is placed inline where the ambiguity would otherwise arise.

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/idempotent/non-destructive, so the safety profile is covered. The description adds a real behavioral detail beyond that — the article is returned as Markdown — and enumerates the content domains covered, which tells the agent what kind of payload to expect. It does not discuss size or truncation, but the added value is genuine.

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?

Front-loaded with the action and resource ('Get one SendMyCall help article as Markdown'), followed by a topic list that doubles as slug-discovery aid. The enumeration is long but each group maps to real enum clusters, so it earns its space; no filler sentences.

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 structure needn't be explained, and annotations cover the safety profile. The description supplies the return format and the content inventory, leaving only minor gaps around article size/handling of the enumerated slug errors.

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 100% and the slug enum is fully spelled out with all 33 values, so the schema carries the parameter burden. 'Pick the slug from the list' reinforces that the value must come from the enum but adds no format or semantic detail beyond it. Baseline 3 applies.

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?

Specific verb ('Get'), specific resource ('one SendMyCall help article'), and it names the return format ('as Markdown') plus the topical scope. Against siblings that are all pricing/rate lookups (get_calling_rate, get_area_pricing), it is unmistakably the documentation-retrieval tool.

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 only routing instruction is 'Pick the slug from the list,' which is invocation mechanics rather than guidance on when to reach for this tool versus the pricing siblings. Usage is implied by the topical list, but there are no explicit when/when-not conditions or named alternatives.

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, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral detail beyond them: the shape and units of the response (monthly price expressed in US cents) and the availability signal ('whether new numbers can be bought now'), which an agent cannot derive from 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?

One dense sentence that front-loads the core purpose before the qualifiers, with every clause carrying information about the returned fields. It is slightly long for a single sentence and could be split, but there is no 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?

A read-only, zero-required-parameter listing tool with an output schema and full annotation coverage needs little more. The description supplies scope, response fields, units, and the optional filter, exceeding the bar for this complexity level.

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 100% schema description coverage and an enum fully enumerated in the schema, the schema already carries the parameter meaning. The description only restates the filter at a high level ('only countries with a given number type') without adding syntax or default behavior, so the baseline 3 applies.

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 gives a specific verb (List) and resource (countries) and goes further by enumerating exactly what each country record contains: number types, area count, lowest monthly price in US cents, and purchasability. This distinguishes it cleanly from siblings like get_area_pricing and search_areas, which operate on narrower scopes.

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 closing clause 'Optionally only countries with a given number type' communicates the one available filter, which is useful. However, it never states when this tool should be chosen over the pricing siblings (get_area_pricing, get_calling_rate) or that it is the discovery/entry point for those tools, leaving the routing decision to inference.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: it discloses the returned fields, the 'had numbers at the last snapshot' freshness caveat, and the two-step workflow with get_area_pricing. It does not mention pagination behaviour, though limit/offset in the schema largely cover that.

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?

Three sentences, zero filler, and the search scope is front-loaded before the return summary and the sibling routing. Every sentence carries distinct information: what it searches, what it returns, where to go next.

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 read-only, idempotent search with a full input schema and an output schema, the description covers the remaining gaps: what the results contain, the snapshot-freshness caveat, and the handoff to get_area_pricing. Nothing an agent needs in order to call this correctly is missing.

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 all five parameters are already documented, including the country pattern, number_type enum and query semantics. The description's 'such as London or 4420' gives a concrete illustration of the query parameter but adds little beyond what the schema already states, so the baseline 3 is appropriate.

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 names a specific verb and resource ('Search the number areas') and enumerates the searchable dimensions (country, number type, text) plus the covered range kinds. It also names the sibling get_area_pricing as the follow-up tool, so an agent can distinguish it from get_calling_rate and list_countries without opening schemas.

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 clearly routes the agent onward ('Use get_area_pricing with an id for the full details'), implying this is a summary/discovery call rather than a pricing-detail call. There is no explicit statement of when NOT to use it or which of the remaining siblings (get_calling_rate, get_forwarding_rate) to pick instead, so it stops short of full when/when-not coverage.

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