Use Claude, Cursor, Windsurf, or any MCP-compatible AI assistant to receive SMS codes, rent virtual numbers, buy eSIM data plans and manage your account directly from a conversation. No installation needed.
Scored across 29 tools
The set spans three product lines (one-time SMS activations, virtual number rentals, eSIMs) and most tools are clearly differentiated by descriptions, e.g., order_number vs order_virtual_number vs order_esim and cancel_order vs cancel_virtual_number. Some overlap remains between check_sms, get_order, and get_number_messages for retrieving SMS, and between list_countries and list_number_countries, but descriptions mostly clarify the boundaries.
Nearly all tools use snake_case verb_noun (get_balance, list_services, order_number, cancel_order), giving a predictable pattern. Minor deviations like order_history (not verb-led) exist, but there is no camelCase mixing and the convention is largely consistent.
29 tools is heavy even for a server covering three product lines plus account management. While many tools earn their place, consolidation is possible for closely related operations like get_balance/get_profile/get_stats, list_countries/list_number_countries, and cancel_order/cancel_all_orders.
Core workflows are covered across all three product lines: ordering, checking messages, retrieving order details, cancellation, renewal, pricing, and account history. Minor gaps exist, such as no eSIM cancellation/refund tool and no bulk virtual number cancellation, but agents can work around them.
Cancel all currently active orders at once. Reports per-order success and refund details.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the bulk scope and that per-order success and refund details are reported, but it omits key behavioral facts for a destructive money-touching operation: whether cancellation is irreversible, whether refunds are automatic, and any permission or rate constraints.
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?
Two short sentences, zero waste, with the destructive bulk scope front-loaded before the return-value note.
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 no-parameter, no-output-schema tool, the description covers what it does and roughly what it returns (per-order results and refund details). What is missing is the irreversibility/authorization context that an agent would want before triggering a mass cancellation.
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 zero parameters, so there is nothing for the description to document and the baseline is 4. No parameter-related claims are made or needed.
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 ('Cancel all currently active orders') plus the bulk scope ('at once'), which implicitly distinguishes it from the sibling cancel_order that handles a single order. An agent can tell what the tool does without opening the (empty) 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?
Bulk-cancel usage is implied by 'all ... at once', but the description gives no explicit when-to-use guidance, no warning about when not to use it, and does not name cancel_order as the alternative for single-order cancellation. Implied context only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel an active order. Full refund if no SMS received; no refund if SMS already received.
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | The order ID to cancel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the refund consequence and its condition (SMS already received = no refund), which is real behavioral value, but it omits irreversibility, permission/auth needs, and what the call returns or errors on.
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?
Two tight sentences with the action stated first and the refund consequence second. No filler, nothing to trim.
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 cancellation tool with no output schema and no annotations, the description covers the essential action and the key financial side effect. It could go slightly further on whether cancellation is reversible or what happens on failure, keeping it from a 5.
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?
Only one parameter and schema description coverage is 100%, so the schema alone fully documents orderId. The description adds no parameter syntax or format detail, but the baseline for a fully-covered single parameter is 4.
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 ('cancel an active order') and constrains the target to active orders, which distinguishes it from read-side siblings like get_order. It does not explicitly differentiate itself from cancel_all_orders, so it falls short of a 5.
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?
Scope of 'active order' is implied, but there is no explicit when-to-use guidance and no mention of the closest alternative, cancel_all_orders, or the SMS/check_sms prerequisite hinted by the refund rule. Usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel an unlimited virtual number within 120 minutes of purchase (no SMS received) for a full refund.
| Name | Required | Description | Default |
|---|---|---|---|
| numberId | Yes | The number id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the refund outcome and the two eligibility constraints, but omits whether cancellation is irreversible, what happens to the number, and any authorization requirements.
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, zero filler, with the core action and its constraints front-loaded. 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?
For a single-parameter mutation with no annotations or output schema, the description covers eligibility and the refund result. Missing irreversibility and auth details keep it from being fully complete.
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% for the single numberId parameter, so the schema already carries the parameter documentation. The description adds no format, source, or lookup guidance beyond what the schema provides, 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?
States a specific verb (cancel) and resource (virtual number), plus the eligibility condition and outcome (full refund). It is distinguishable from cancel_order and cancel_all_orders by scoping to a single virtual number, though it never names those siblings explicitly.
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?
Gives clear qualifying conditions — within 120 minutes of purchase and no SMS received — which effectively define when the tool may be used. It stops short of naming alternatives (e.g. renew_virtual_number) or stating what to do if the window has passed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether an SMS has been received on an active order. Returns the message text and extracted verification code when available.
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | The order ID from order_number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the return payload ('message text and extracted verification code when available'), implying an empty result is possible, but says nothing about timing/polling behavior, whether it blocks, or what happens for an inactive/unknown order.
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?
Two tight sentences, zero filler, with the core purpose front-loaded and the return behavior second. Every sentence 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?
No output schema exists, so the description's mention of returned message text and verification code is valuable, but for a polling-style check tool with zero annotations the absence of timing, retry, or failure semantics leaves meaningful 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?
Only one parameter with 100% schema coverage, so the schema already fully documents orderId. The description adds no format or sourcing detail beyond the schema's 'order ID from order_number', so 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?
States a specific verb+resource+scope: 'Check whether an SMS has been received on an active order.' An agent can distinguish it from generic message retrieval, though it never names the closest sibling (get_number_messages) to sharpen the boundary.
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 'on an active order' implies the usage context (verifying SMS for an in-flight order), but there is no explicit when-to-use, when-not-to-use, or named alternative such as get_number_messages. Usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current account balance and username.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a safe read via 'Get' and clarifies the payload includes both balance and username, but it says nothing about authentication requirements, error conditions, or currency/format of the balance. For a zero-parameter read tool the disclosure burden is modest, so this is adequate but not rich.
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 with zero filler. Nothing could be removed without losing 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?
For a trivial zero-parameter read tool with no output schema, the description is nearly sufficient. The only mild gap is that it does not indicate the currency or structure of the returned balance, which an agent might want to know.
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 tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies no input is needed and instead describes what comes back, which is the only semantic content available.
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 ('Get') and specific resources ('current account balance and username'), which is more informative than the bare name. It does not explicitly differentiate itself from siblings like get_profile or get_transactions, which could also surface account-level data, so it falls short of a 5.
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?
There is no when-to-use guidance, no mention of prerequisites, and no reference to alternatives such as get_profile or get_transactions. The read-only nature is only implied by the verb 'Get'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One eSIM order with its profiles (activation code, QR, ICCID, usage). refresh=true pulls live usage from the provider.
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | The order id | |
| refresh | No | Refresh usage counters from the provider |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does useful work by disclosing that refresh=true triggers a live pull from the provider (implying extra latency or provider round-trip) and by listing the returned profile fields. It says nothing about auth requirements, error behavior, or whether refresh has cost/side effects.
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?
Two tight sentences, no waste, and the return payload is front-loaded before the refresh caveat. 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?
For a read-only, two-parameter lookup with no output schema, the description adequately covers what is returned (profiles and their key fields) and the one behavioral modifier (refresh). It is nearly complete; only permission/error context is absent, which is minor here.
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%, so the schema already documents orderId and refresh. The description's 'refresh=true pulls live usage from the provider' largely restates the schema's 'Refresh usage counters from the provider' with slightly more framing. 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?
States a specific verb (get) and resource (eSIM order) and enumerates what comes back (profiles, activation code, QR, ICCID, usage). It does not explicitly distinguish itself from the generic get_order sibling, so an agent must infer that this one is eSIM-specific.
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 the use case (fetch one eSIM order, optionally with live usage) and hints at refresh=true as the variant for fresh data, but it names no alternatives (get_order, list_esim_orders) and states no when-not conditions. Usage is implied rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the inbox of a virtual number from the provider, store anything new and return every message.
| Name | Required | Description | Default |
|---|---|---|---|
| numberId | Yes | The number id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose a meaningful side effect ('store anything new'), signaling this is not a pure read, which is valuable. However it says nothing about permissions, idempotency/duplicate handling, rate limits, or pagination.
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 fetch action and ending with the return behavior. No filler; every clause carries 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?
No output schema exists, so the description must cover the return value, and it does ('return every message'), plus it flags the persistence side effect. Missing only details like message shape, ordering, or limits for a full picture.
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% for the single numberId parameter, so the schema already documents it. The description's phrase 'of a virtual number' loosely maps to numberId but adds no format, ID-source, or validation 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?
Specific verb+resource with scope: fetches a virtual number's inbox, persists new messages, returns all messages. This distinguishes it from read-only siblings like check_sms or get_virtual_number, though it never names a sibling explicitly.
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?
No when-to-use, when-not-to-use, or alternative named. The agent must infer that this is the tool for retrieving messages for a given number id, and cannot tell from the text how it differs from check_sms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prices of virtual numbers in one country: every unlimited term (12h, 1d, 7d, 30d, 180d, 365d) and every dedicated-service offer with its terms.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ISO country code, e.g. "GB" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It usefully discloses the return contents (all unlimited terms plus dedicated-service offers with their terms), implying a read-only lookup, but says nothing about auth, currency, freshness, or whether pricing is live.
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 that leads with the resource and scope. The parenthetical term list (12h, 1d, 7d, 30d, 180d, 365d) is bulky but genuinely informative, so it 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?
With no output schema, the description must convey the return shape, and it does so partially by naming the pricing categories. It omits currency, pricing freshness, and whether all services are covered, leaving a moderate gap for a pricing lookup.
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% and the single 'country' parameter is documented as an ISO country code with an example, so the schema does the heavy lifting. The description only echoes the one-country scoping and adds no extra semantics.
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 resource (virtual numbers) constrained to one country and enumerates the pricing categories returned. It is distinguishable from sibling get_pricing only implicitly; there is no explicit statement of how it differs from get_pricing or get_number_renewal_options.
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 'in one country' implies this is the per-country pricing lookup, hinting at a contrast with the generic get_pricing sibling, but no when-to-use condition or alternative is ever named. Usage must be inferred from scope wording alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The terms a virtual number can be renewed for, priced.
| Name | Required | Description | Default |
|---|---|---|---|
| numberId | Yes | The number id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and largely fails it. It implies a read of renewal options but says nothing about authorization requirements, whether pricing is per-number or global, rate limits, or the shape of the returned terms, which is a meaningful gap for a tool with zero annotation coverage.
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?
It is a single compact phrase with no filler, which is appropriately sized. The only weakness is that it is a fragment rather than a front-loaded declarative sentence naming the action.
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 no output schema, the description does hint at the return content (renewal terms with prices). However, it omits any statement of return structure, ordering, or scope, leaving the agent to infer details that no output schema supplies.
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% for the single numberId parameter, so the baseline is 3. The description adds only the indirect notion that the terms are scoped to 'a virtual number', which the schema already conveys through numberId.
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 fragment 'The terms a virtual number can be renewed for, priced' conveys the resource (renewal terms) and that pricing is included, but it is a noun phrase rather than a verb+resource, so the retrieval action is only implied. It also does not explicitly distinguish itself from the nearby get_number_pricing or renew_virtual_number siblings.
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?
There is no statement of when to call this versus alternatives. An agent can infer it should be used before renew_virtual_number to see available terms, but nothing in the text confirms this, and no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details and complete SMS message history for a specific order.
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | The order ID to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses what is returned (order details plus complete SMS message history), which is meaningful given there is no output schema. However, it says nothing about permissions, error behavior for invalid order IDs, or rate limits, leaving notable gaps for a mutation-free but data-heavy read.
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 with no wasted words; the resource and the returned payload are both stated immediately.
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 no output schema, the description covers the essentials by naming what is returned (details plus SMS history) and scoping it to a single order. It lacks any guidance on failure modes or related tools, which keeps it short of a 5.
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% with a single, well-documented 'orderId' parameter, so the schema already does the heavy lifting. The description confirms retrieval is scoped to a specific order but adds no format, prefix, or validity 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?
States a specific verb ('Get') and resource ('order') and goes beyond a bare lookup by specifying scope: 'full details and complete SMS message history.' This differentiates it from list-style siblings like order_history and list_active_orders. It stops short of naming an alternative sibling explicitly, so not a 5.
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 'for a specific order' implies the tool is used when an orderId is known, but there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as order_history or get_number_messages. The agent must infer selection criteria from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time pricing for a country and/or service. At least one of "country" or "service" must be provided. Each operator row carries the provider alias and operator to pass to order_number, with its price, stock count and deliverability.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Country code (e.g. "US"), full name, or slug | |
| service | No | Service slug (e.g. "whatsapp", "telegram", "google") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full burden, and it delivers real value by describing the returned rows: provider alias, operator, price, stock count and deliverability — exactly what an agent needs to chain into order_number. It omits auth requirements, rate limits and pagination behavior, which keeps it short of a 5.
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, no filler, and the core operation is front-loaded ahead of the constraint and the response-shape note. Every sentence contributes a distinct fact.
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 two-parameter read tool with no output schema, the description covers the key constraint and the shape of returned rows, which is enough to invoke and consume it correctly. Auth and error/timeout behavior remain unstated, leaving a minor gap.
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% and both parameters are documented (country code/name/slug, service slug), so the baseline is 3. The description's mutual-dependency rule ('at least one of country or service') is genuinely beyond the schema, which marks both as optional, but it doesn't clarify formats or disambiguation beyond that.
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 real-time pricing for a country and/or service') and names the scope dimensions. However, it does not differentiate itself from close siblings like get_number_pricing or quote_esim, which an agent could easily confuse with this 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?
It supplies one concrete usage constraint ('At least one of country or service must be provided') and points to order_number as the downstream consumer of the returned operator rows. But it never says when to prefer this over get_number_pricing, quote_esim, or get_number_renewal_options, so alternative selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full account profile: id, username, email, balance, and creation date.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It usefully discloses the exact fields returned (id, username, email, balance, creation date), which is meaningful behavior since there is no output schema, but it says nothing about permissions, read-only nature beyond the verb 'Get', or failure modes.
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 that enumerates the payload with zero filler. Every clause earns its place by naming the resource and its contents.
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 no output schema and no annotations, the description compensates well by listing the returned fields for this simple no-arg read. The remaining gap is only the lack of auth/prerequisite context, which is minor for a straightforward profile fetch.
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 tool takes zero parameters, so the baseline of 4 applies. There is no parameter syntax or semantics that could be clarified further.
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 ('Get') and resource ('full account profile') and enumerates the returned fields, so the agent knows exactly what this retrieves. It does not explicitly differentiate itself from near-neighbors like get_balance or get_stats, though 'full profile' implies a superset.
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?
There is no when-to-use guidance, no mention of prerequisites (e.g. authentication), and no routing to or away from siblings such as get_balance or get_transactions. The agent must infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get account statistics: total orders, success rate, total spent, and total deposited.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. Calling this an account-statistics read is consistent with the 'Get' verb, but the description never says whether figures are all-time or period-scoped, whether authentication is required, or how 'success rate' is computed — real ambiguity for an agent interpreting the numbers.
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 with the verb and resource first and the returned metrics enumerated. No filler or redundancy.
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 no output schema, the description usefully acts as a return-value summary by listing the four metrics, which is the key information an agent needs. The remaining gap — the time window over which totals and success rate are computed — is minor but real for a metrics 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 tool takes zero parameters, so the schema imposes no semantic burden and the baseline of 4 applies. The description correctly implies the call needs no arguments.
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 (Get) and resource (account statistics) and enumerates the four metrics returned (total orders, success rate, total spent, total deposited), which helps separate it from siblings like get_balance and get_transactions. It does not explicitly name which sibling to prefer, so it falls short of the top mark.
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?
There is no statement of when to use this tool versus alternatives such as get_balance, get_transactions, or get_profile, all of which overlap with account-level data. Usage is only implied by the metric names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List transaction history (deposits, purchases, refunds). Supports pagination and filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| type | No | Filter by type | |
| limit | No | Results per page (default: 20, max: 100) | |
| status | No | Filter by status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It mentions pagination and filtering support, but that largely restates the page/limit/type/status parameters already visible in the schema, and it says nothing about ordering, result size, permissions, or default behavior.
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 with no filler; the core action comes first and supporting capabilities follow. It is efficient, though it may be undersized given the omitted behavioral context.
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 four optional parameters and no output schema, the description covers the basic read operation but leaves gaps: no return shape, ordering, or guidance on combining filters. Adequate but with clear room to add value.
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 each parameter is already documented in the schema; baseline 3 applies. The description's mention of deposits/purchases/refunds loosely maps to the type enum but adds no syntax or semantics beyond it.
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 ("List transaction history") and enumerates concrete record kinds (deposits, purchases, refunds), which makes the scope clear. It does not, however, distinguish itself from similar retrieval siblings such as order_history or get_balance.
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?
There is no statement of when to use this tool versus alternatives like order_history or get_balance, and no prerequisites or exclusions. Usage is only implied by the phrase "transaction history".
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One virtual number with every stored message.
| Name | Required | Description | Default |
|---|---|---|---|
| numberId | Yes | The number id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing. It implies the response bundles all stored messages for one number, but says nothing about pagination, message count limits, permissions, or whether the messages are the same set returned by get_number_messages.
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?
It is a single short clause with no padding, so nothing is wasted. But this is brevity through under-specification rather than efficient structure — there is no lead verb and no elaboration where elaboration is needed.
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 no output schema, the description should at least clarify what comes back and how it differs from get_number_messages. As written, an agent cannot confidently choose between the two, so the definition is incomplete despite the tool's simplicity.
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 the single numberId parameter is already documented in the schema (albeit minimally as 'The number id'). The description adds no format, type, or lookup semantics beyond that baseline.
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 phrase identifies the resource (a single virtual number) and hints at its contents (stored messages), which distinguishes it from list_virtual_numbers. However, it is a noun fragment with no verb, leaving the actual operation (fetch/retrieve) implicit, and it overlaps ambiguously with the sibling get_number_messages.
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?
There is no statement of when to use this tool, when not to, or which sibling to prefer. Given several overlapping siblings (get_number_messages, list_virtual_numbers, get_number_renewal_options), the absence of routing guidance is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all currently active orders (numbers waiting for or having received an SMS).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| limit | No | Results per page (default: 20, max: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It usefully defines what counts as 'active', which is real behavioral context, but it says nothing about whether this is a read-only operation, pagination behavior beyond the schema defaults, or ordering of results. Adequate but not rich.
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 with the core purpose front-loaded and the parenthetical definition of 'active' appended economically. 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?
For a simple zero-required-param read/list tool with a fully documented schema and no output schema, the description covers the essential semantic gap (what 'active' means). It lacks only routing guidance relative to order_history, which keeps it from a 5.
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% with only two optional pagination params (page, limit) fully documented with defaults and max. The description adds no parameter meaning beyond the schema, 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?
States a specific verb (List) and resource (active orders) and clarifies the domain meaning of 'active' as numbers awaiting or having received an SMS. It distinguishes itself from the broader order_history/get_order siblings by the 'currently active' qualifier, though it never names an alternative explicitly.
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 only implied: the word 'currently active' suggests this is the live/in-flight view as opposed to order_history, but there is no explicit when-to-use or when-not-to-use guidance and no sibling is named. An agent can infer intent but must guess at the boundary with order_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all countries where virtual SMS numbers are available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'List' implies a non-mutating read, and the scope qualifier usefully discloses that only SMS-enabled countries are returned rather than all countries. It says nothing about return format, ordering, or pagination, though for a zero-parameter listing that gap is minor.
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 verb and resource and adds the scope constraint with zero filler. Nothing could be removed without losing 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?
For a trivial zero-parameter, no-annotation listing tool, the description says enough to call it correctly and sets expectations about what the list contains. The absence of an output schema means the exact return shape is unspecified, but the content is unambiguous from the sentence.
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 tool takes zero parameters, so there are no parameter semantics to explain; per the baseline this scores 4. Nothing in the schema is left ambiguous by the description.
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 (List) and resource (countries) with a scope qualifier: only countries where virtual SMS numbers are available. However, it does not distinguish itself from the closely named sibling list_number_countries, leaving the agent to guess which listing is which.
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?
There is no explicit when-to-use statement, no prerequisites, and no named alternative. Usage is only implied by the description's scope (discovering destinations before ordering a virtual number), so the agent must infer the trigger condition from the response shape.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eSIM destinations: countries, regions and global plans with a "from" price. Requires the esim scope.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose a genuine behavioral trait — the required 'esim' scope (an auth requirement) — and that results include a 'from' price, which is useful context. However, it says nothing about pagination, result volume, or response shape.
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 tightly packed sentence plus the scope requirement, with the most important content (what is listed and the price signal) front-loaded. Zero waste.
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 no-parameter, no-annotation lister with no output schema, the description covers what it returns and the access requirement. The main omission is any hint about result size or pagination, which is minor for this simple 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 tool takes zero parameters, so per the rubric the baseline is 4. There is no parameter meaning for the description to clarify, and it adds no misinformation.
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 the resource (eSIM destinations) and enumerates its contents — countries, regions, and global plans with a 'from' price — which separates it from siblings like list_esim_packages and list_countries. It is a noun phrase rather than an explicit verb, but the listing intent is unambiguous.
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?
There is no explicit when-to-use guidance and no named alternative among the many esim siblings (list_esim_packages, quote_esim, order_esim). Usage is only implied by context — browsing destinations before ordering. The only usage-adjacent statement is the scope prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your eSIM orders, newest first, with their profiles.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| limit | No | Results per page (default: 20, max: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two behavioral facts beyond the schema: results are sorted newest-first and each order includes its profiles. However it says nothing about default scoping (presumably the authenticated account), whether cancelled/completed orders are included, or pagination behavior.
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 that packs the action, sort order, and attached data with zero filler or repetition of the tool name.
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 simple read-only list tool with two fully documented optional params and no output schema, the essentials are present, but with no annotations the description should have covered scoping and what set of orders is returned. It is adequate but has clear 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%, so page and limit are fully documented with defaults and max, and the description adds no parameter detail. Baseline 3 applies since the schema does all the work.
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 clear verb+resource ("List your eSIM orders") and adds scope detail (newest first, includes profiles). It does not differentiate itself from close siblings like order_history or get_esim_order, so an agent must still infer which one to pick for a single order versus a full list.
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?
No when-to-use guidance, no exclusions, and no reference to alternatives such as list_active_orders or order_history despite a crowded sibling set of order-related tools. The agent gets no routing help at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eSIM data plans for one destination at retail. pricingUnit per_day means you choose the number of days when ordering.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | A locationCode from list_esim_destinations, e.g. "ES" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose a meaningful trait beyond the schema — that pricingUnit is 'per_day' and the customer chooses the day count at ordering time — but it omits whether this is a read-only catalog, whether auth is required, and currency or availability caveats.
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?
Two short sentences, front-loaded with what the tool returns, and the pricing note is supplementary rather than buried. Slightly telegraphic wording but nothing 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?
For a one-parameter, read-only catalog tool with no output schema, the description conveys the essential shape of the result (retail eSIM data plans for one destination) and the pricing model. What is still missing is any note on read-only status, currency, or what fields a package record contains.
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 single parameter is documented there ('A locationCode from list_esim_destinations, e.g. "ES"'), so the schema does the heavy lifting. The description adds no syntax or format detail for the location parameter, matching the baseline of 3 when the schema is complete.
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 resource ('eSIM data plans') and scopes it to one destination at retail pricing, which lets an agent distinguish it from order_esim or quote_esim. However, it never uses an explicit listing verb and does not name any sibling, so differentiation is inferred rather than stated.
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?
There is no explicit when-to-use or when-not-to-use guidance. The only routing hint is indirect: the schema says the location value comes from list_esim_destinations, implying this tool is a follow-on step, but the description itself gives no context about when to call it versus quote_esim.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Countries where virtual numbers (rentals for days or months) are sold, with dial codes. Requires the numbers scope.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose a required authorization scope, which is genuinely valuable, and 'list' plus 'sold' implies a safe read, but it says nothing about pagination, result size, or ordering.
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 compact sentence with the subject front-loaded and no filler. Every clause (virtual numbers, rental duration, dial codes, scope) adds 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?
For a no-parameter, no-output-schema read tool this covers the essentials: what is returned and the permission needed. The one gap is that it never clarifies how it differs from the neighboring list_countries 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 tool takes zero parameters, so there is no parameter semantics to convey; the baseline of 4 applies. The description's mention of dial codes is return-value context rather than parameter guidance.
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 resource (countries where virtual numbers are sold) and adds useful scope detail ('with dial codes'), making the returned data predictable. It does not, however, contrast itself with the sibling list_countries, so an agent must infer the distinction from the 'virtual numbers' qualifier alone.
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 supplies one prerequisite ('Requires the numbers scope'), which is actionable context, but gives no when-to-use guidance or explicit routing versus list_countries or list_esim_destinations. Usage is only implied by the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available SMS verification services (e.g. WhatsApp, Telegram, Google, TikTok).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List all available' does convey a complete, unfiltered, read-only enumeration, which is useful. However, it says nothing about authentication requirements, whether availability is region-dependent, or the shape of the response for a tool whose output schema is absent.
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 naming the action, the resource, and representative examples. Every element earns its place with 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?
For a zero-parameter listing tool with no output schema, the description is minimally adequate but leaves the agent guessing what a returned service looks like (name only? ID needed for order_number? availability flags?) and how it connects to the ordering siblings. Given the sibling-rich toolset, a sentence tying the result to the ordering flow would materially improve 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 tool takes zero parameters, so there is no parameter semantics to convey and the baseline is 4. The description correctly does not invent filtering options that the empty schema does not support.
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 ('List') and resource ('SMS verification services') and grounds it with concrete examples (WhatsApp, Telegram, Google, TikTok), which helps distinguish it from siblings like list_countries or list_number_countries. It is clear on its own, though it never explicitly contrasts itself with those similarly-named sibling list tools.
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 only implied: an agent can infer this is the discovery/entry-point call for figuring out which services are orderable, but the description never says when to call it versus alternatives such as get_pricing or get_number_pricing, nor does it route the agent forward after the call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your virtual numbers, newest first, with a message count each.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| limit | No | Results per page (default: 20, max: 100) | |
| status | No | Filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the sort order and that each entry includes a message count, but says nothing about pagination behavior, authentication requirements, or rate limits for what is clearly a paginated list endpoint.
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, tightly written sentence that front-loads the action and resource, then adds the two most decision-relevant details (ordering and per-item message count). 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?
For a simple read-only list tool with three optional parameters and no output schema, the description covers the essentials of what is returned and in what order. The main omission is any note on pagination defaults or how to page through results, though the schema partly covers that.
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 the page, limit, and status parameters are already documented in the schema (including the status enum and the limit max of 100). The description adds nothing about parameter usage, 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 states a specific verb and resource ('List your virtual numbers') and adds the ordering ('newest first') and payload detail ('message count each'), which clearly separates it from the singular get_virtual_number sibling. It stops short of naming the alternatives it is not, so it is clear but not explicitly differentiated.
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?
There is no when-to-use or when-not-to-use guidance, no mention of prerequisites, and no pointer to alternatives such as get_virtual_number for a single number or list_number_countries. The listing intent is implied only by the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy an eSIM plan from the balance. The response carries the activation code and QR when ready; otherwise poll get_esim_order.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Day passes only: term in days, 1–365 | |
| quantity | No | How many eSIMs, 1–10 (default 1) | |
| packageCode | Yes | The plan code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It usefully discloses that this is a balance-funded purchase and that the result may be asynchronous (activation code/QR 'when ready', else poll). It omits irreversibility, cost deduction semantics, and auth/permission requirements for a money-spending mutation.
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?
Two tight sentences with the core action front-loaded and the async/polling caveat immediately after. 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?
With no output schema, the description valuably explains what comes back (activation code and QR) and the polling escape hatch. That covers the main unknowns for a 3-param purchase tool; only permission/cost behavior is left unstated.
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 days, quantity, and packageCode are already fully documented in the schema. The description adds no parameter-level detail beyond 'from the balance', 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?
States a specific verb ('Buy') and resource ('an eSIM plan'), plus the funding source ('from the balance'), which cleanly separates it from order_number, order_virtual_number, and quote_esim among the siblings. An agent can identify the operation 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?
It gives clear context for the normal path and names an explicit fallback: poll get_esim_order when the activation code/QR is not yet ready. It does not mention prerequisites such as quote_esim or balance checks, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List past SMS activation orders. Supports pagination, status filter, and date range.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Orders up to this date (ISO 8601) | |
| from | No | Orders from this date (ISO 8601) | |
| page | No | Page number (default: 1) | |
| limit | No | Results per page (default: 20, max: 100) | |
| status | No | Filter by order status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose useful behavior beyond the schema: pagination is supported and the result set can be narrowed by status and date range. However, it says nothing about auth/permission requirements, the default ordering of results, or the shape of what is returned, which matters for a history endpoint with no output schema.
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?
Two short sentences, front-loaded with the primary purpose and followed by capability summary. Every clause earns its place; 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?
For a read-only list tool with 0 required params and no output schema, the description covers the filtering and paging surface adequately. Still missing is anything about result ordering, overall volume, or whether the resource requires an authenticated context, leaving modest gaps for an agent to call 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 100%, so all five parameters (from, to, page, limit, status) are already documented with types, ISO 8601 hint, defaults and max. The description only restates the capability categories ('pagination, status filter, date range') without adding syntax or constraints beyond the schema, so the baseline of 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?
States a specific verb and resource ('List past SMS activation orders'), and the word 'past' implicitly separates it from the sibling list_active_orders. It stops short of explicitly naming or contrasting with that sibling, so an agent still has to infer the boundary.
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 by 'past orders' plus the filter list, but there is no explicit when-to-use statement, no exclusion of active orders, and no pointer to list_active_orders or get_order as the alternative for a single order. The agent must infer selection from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy a one-time SMS activation: a number that receives the verification code for one service. The price is taken from the balance at once and refunded automatically if the provider fails. Call get_pricing first and pass the provider and operator it returns. The response id is the orderId for check_sms, get_order and cancel_order. For a number kept for days or months, use order_virtual_number instead.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Country code (e.g. "US"), full name, or slug | |
| service | Yes | Service slug (e.g. "whatsapp", "google") | |
| operator | No | Operator from get_pricing (optional; any operator when omitted) | |
| provider | Yes | Provider alias from get_pricing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load and does so well: it discloses upfront balance charging, automatic refund on provider failure, the prerequisite workflow, and that the response id is the orderId consumed by check_sms/get_order/cancel_order. It stops short of permissions or failure-mode detail, but the financial behavior is clearly surfaced.
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?
Four sentences, each front-loaded with a distinct concern (purpose, cost/refund behavior, prerequisite, downstream id, alternative). Nothing is redundant against the schema or annotations.
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 purchase tool with no output schema, the description covers purpose, prerequisites, cost behavior, the returned id and its consumers, and the sibling alternative. An agent has everything needed to invoke it 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 coverage is 100%, so the baseline is 3, but the description adds cross-tool meaning: provider and operator must come from get_pricing, and operator is optional ('any operator when omitted'). That is genuine value beyond the schema's own field descriptions.
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 ('Buy a one-time SMS activation: a number that receives the verification code for one service') and explicitly contrasts itself with the sibling order_virtual_number. An agent can distinguish it from order_virtual_number, get_virtual_number, and renew_virtual_number without opening any 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?
Gives an explicit prerequisite ('Call get_pricing first and pass the provider and operator it returns') and an explicit when-not with the alternative named ('For a number kept for days or months, use order_virtual_number instead'). No inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rent a virtual number from the balance. type "unlimited" receives SMS from every service; type "service" is dedicated to one service (pass its id from get_number_pricing).
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | Rental term | |
| type | No | Number type (default unlimited) | |
| country | Yes | ISO country code | |
| service | No | Service id for a dedicated number | |
| nickname | No | Unlimited only: a label | |
| autoRenew | No | Unlimited only: renew from the balance before expiry |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose that the rental is paid from the balance, which is a meaningful cost/auth signal. It omits whether the order is reversible, what happens at term expiry, and the consequences of autoRenew (recurring balance deduction), which matter for a paid mutation.
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?
Two tightly packed sentences with no filler; the core action and its cost source lead, and the mode semantics follow. Every clause carries 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?
For a 6-parameter paid mutation with no annotations and no output schema, the description covers type semantics and payment source but leaves out lifecycle behavior (expiry, renewal, cancellation path via cancel_virtual_number) and what is returned. Adequate but with clear 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 coverage is 100%, so baseline is 3, but the description goes beyond the terse schema text by explaining the semantic difference between the two enum values and where the "service" id must come from. It adds real meaning rather than restating field descriptions.
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 verb+resource ("Rent a virtual number") and adds a scope detail ("from the balance"). It does not, however, differentiate itself from the sibling order_number, which appears to be a near-identical action an agent must choose between.
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 gives conditional guidance on the two modes (unlimited vs service) and routes to get_number_pricing to obtain a service id, which is genuine usage steering. It says nothing about when to prefer this tool over order_number, nor about prerequisites (balance sufficiency, country availability).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price an eSIM order without buying: shows the term and multi-eSIM discounts.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Day passes only: term in days, 1–365 | |
| quantity | No | How many eSIMs, 1–10 (default 1) | |
| packageCode | Yes | The plan code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the critical trait: this is a non-mutating quote ('without buying'), so no order is created. However, it says nothing about auth requirements, rate limits, or what the pricing response actually contains, leaving real behavioral gaps.
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 with the core action first and the differentiating qualifier second. No filler or repetition of the tool name.
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 pricing tool with no output schema and no annotations, the description should say more about the returned figure (total, currency, per-unit breakdown). It covers the discount drivers but leaves the response shape unspecified, which is a meaningful gap given nothing else documents 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?
Schema coverage is 100%, so the baseline is 3; the description earns above that by tying pricing behavior to specific inputs, noting that term and multi-eSIM quantity drive discounts, which the schema descriptions do not state. It adds genuine semantic meaning about how days and quantity affect the quote.
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 (price/quote an eSIM order) and the key modifier 'without buying', which immediately distinguishes it from the sibling order_esim. An agent can tell what it does and what it does not do without opening a 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?
'Without buying' clearly frames the use case as pre-purchase price checking, which implies the alternative (order_esim) is the follow-up action once a price is accepted. It stops short of explicitly naming that sibling or stating exclusions, so it is clear context rather than full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Renew a virtual number for one more term, paid from the balance.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | A term from get_number_renewal_options | |
| numberId | Yes | The number id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose one meaningful trait beyond the schema: the renewal is charged against the account balance. However, it omits what happens on insufficient balance, whether the new term starts now or at expiry, and whether the number must be active or renewable, which are the real questions for a paid mutation.
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 with no filler; the action, scope, and payment source are all in the first clause. It is efficient, though slightly too terse for a balance-charging operation.
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 two-parameter tool with fully documented schema this is minimally adequate, but as a paid mutation with no annotations and no output schema, an agent still lacks prerequisites and failure-mode context. The payment disclosure is the main thing keeping it above a 2.
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%, so both numberId and term are already documented, including the pointer to get_number_renewal_options. The description adds no syntax, format, or constraint detail beyond the schema, 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?
States a specific verb and resource ("Renew a virtual number") plus the exact scope ("one more term, paid from the balance"), which clearly distinguishes it from order_virtual_number and cancel_virtual_number. It stops short of explicitly naming those siblings, so it lands at 4 rather than 5.
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?
There is no explicit when-to-use guidance: nothing says the number must be near expiry, that a balance is a prerequisite, or how this differs from ordering a new number. The only implicit routing, that the term value comes from get_number_renewal_options, lives in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
cancel_all_orderscancel_ordercancel_virtual_numbercheck_smsget_balanceget_esim_orderget_number_messagesget_number_pricingget_number_renewal_optionsget_orderget_pricingget_profileget_statsget_transactionsget_virtual_numberlist_active_orderslist_countrieslist_esim_destinationslist_esim_orderslist_esim_packageslist_number_countrieslist_serviceslist_virtual_numbersorder_esimorder_historyorder_numberorder_virtual_numberquote_esimrenew_virtual_number
Add one secure layer between your agents and this server.