International calls from your AI agent: price per minute and a Call link to the browser dialer.
Scored across 2 tools
The two tools target clearly distinct inputs and use cases: get_call_price takes a specific E.164 number, while get_country_call_prices takes an ISO country code for a general overview. Descriptions make the number-vs-country distinction explicit, so misselection is unlikely.
Both names follow a consistent get_ + snake_case pattern (get_call_price, get_country_call_prices). Minor deviation in singular/plural (price vs prices) and the extra 'country' qualifier, but the convention is predictable.
Two tools is thin for a calling service; the pair covers only pricing/link lookup with no other lifecycle operations. It is borderline rather than wrong given the narrow pricing-focused scope.
The pricing domain is well covered from both angles (per-number and per-country), each returning a usable Call link. Dialing is delegated to the browser link by design, though there is no tool for account, balance, or call history.
Helps the person call a phone number anywhere in the world with Suparelay: returns the price per minute and a Call link that opens the Suparelay browser dialer with the number ready. Use it when the person wants to call a phone number or asks what a call to it costs. Pass the number in E.164 format with the country code, such as +33142868200. The person talks on the call in the browser; this tool does not dial.
| Name | Required | Description | Default |
|---|---|---|---|
| number | Yes | The phone number in E.164 format, such as +33142868200 | |
| context | Yes | Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution." | |
| llm_model | Yes | The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess. | |
| conversation_id | No | Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description nevertheless adds genuinely useful behavior beyond that: the tool does not dial, the person talks in the browser, and the return is a price plus a call link — real context for what invocation actually accomplishes.
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?
Purpose is front-loaded and every sentence carries weight — the when-to-use, format, and 'does not dial' clarifications all earn their place. The 'Helps the person call...' framing is slightly soft as an opener but not wasteful.
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 compensates by describing the return (price per minute and a Call link). The analytics-only context/llm_model params and the conversation_id continuation rule are covered by their schema descriptions, so the definition is complete enough to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description's E.164 guidance and example merely restate the schema's format/pattern, adding no meaning beyond it. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (call price for a phone number) and states two concrete outputs — price per minute and a Call link — plus the E.164 input. It is clear what the tool does, but it never references the sibling get_country_call_prices, so the agent gets no explicit signal distinguishing per-number pricing from country-level pricing.
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 an explicit trigger: 'Use it when the person wants to call a phone number or asks what a call to it costs.' That is clear usage context, but there are no exclusions and no pointer to the sibling for the country-level case, so the boundary remains inferential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Helps the person call a country with Suparelay: returns the landline and mobile prices per minute and a Call link that opens the Suparelay browser dialer. Use it when the person wants to call a country or asks what calls to it cost, without a phone number. Pass the two-letter ISO country code, such as IN. The person talks on the call in the browser; this tool does not dial.
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution." | |
| country | Yes | The two-letter ISO 3166-1 country code, such as IN | |
| llm_model | Yes | The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess. | |
| conversation_id | No | Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety is covered. The description adds genuine context beyond that: the returned Call link opens a browser dialer, the person talks in the browser, and crucially 'this tool does not dial' — clarifying the side-effect boundary the annotations only imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, all front-loaded with purpose before behavior. Each earns its place (what it returns, when to use, what to pass, what it does not do), though the closing dialer sentence is slightly redundant with the second.
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 tool with no output schema, the description explains the return payload (landline/mobile per-minute prices plus a Call link) and the no-dial behavior. Only minor gap is the conversation_id handshake workflow, which the schema already covers.
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 all four parameters including country, context, llm_model, and conversation_id are already documented in the schema. The description restates the two-letter ISO country code example ('such as IN') but adds no semantic detail the schema lacks, 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?
The description names a specific verb and resource: it 'returns the landline and mobile prices per minute and a Call link' for a country. The phrase 'without a phone number' implicitly separates it from the sibling get_call_price, which an agent can use to disambiguate without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the triggering conditions clearly ('when the person wants to call a country or asks what calls to it cost, without a phone number'). The 'without a phone number' clause serves as an implicit when-not that routes number-specific requests elsewhere, but the sibling get_call_price is never named explicitly.
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.
get_call_price4 fields changedInput schema / properties / contextAdded value: +{
+ "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\"",
+ "type": "string"
+}Input schema / properties / conversation_idAdded value: +{
+ "description": "Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.",
+ "type": "string"
+}Input schema / properties / llm_modelAdded value: +{
+ "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "number"
-]New value: +[
+ "number",
+ "context",
+ "llm_model"
+]get_country_call_prices4 fields changedInput schema / properties / contextAdded value: +{
+ "description": "Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\"",
+ "type": "string"
+}Input schema / properties / conversation_idAdded value: +{
+ "description": "Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.",
+ "type": "string"
+}Input schema / properties / llm_modelAdded value: +{
+ "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "country"
-]New value: +[
+ "country",
+ "context",
+ "llm_model"
+]get_call_priceget_country_call_pricesReal phone calls for AI agents: Spain, Mexico, US, Canada, Latin America, UK, EU. From 0.25 USD/min.
Let AI agents place real phone calls from your verified number, with transcripts and recordings.
AI voice agents that make real phone calls: single calls or campaigns, with transcripts and notes.
Give your AI agent a phone. Place outbound calls to US businesses to ask, book, or confirm.
Add one secure layer between your agents and this server.
