Real phone calls for AI agents: Spain, Mexico, US, Canada, Latin America, UK, EU. From 0.25 USD/min.
Scored across 4 tools
Each tool covers a distinct action on the call resource: make_call creates, get_call retrieves one by id, list_calls enumerates, and get_pricing returns static account/pricing metadata. There is no plausible way to confuse them, and make_call's description explicitly points to get_call for results.
All four names follow a clean snake_case verb_noun pattern (get_, list_, make_) with the noun consistently referring to calls or pricing. No mixed conventions or vague verbs.
Four tools is a tight, well-scoped surface for an outbound-calling service: create a call, poll it, list history, and check pricing/balance. Nothing appears redundant or gratuitous.
The create/read/list lifecycle is covered, but there is no cancel_call for terminating an in-flight or mistaken call, no scheduling for later calls, and no webhook/callback mechanism (agents must poll get_call). Balance is visible via get_pricing but there is no top-up or account operation, leaving some notable gaps.
Get the status, duration, summary, collected data and transcript of a call placed with make_call.
| Name | Required | Description | Default |
|---|---|---|---|
| call_id | Yes | The call_id returned by make_call |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description usefully enumerates what data comes back, but says nothing about whether status can be pending/in-progress (i.e., whether polling is required) or about latency/rate limits, which is the main behavioral unknown for a result-fetching tool.
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; every clause maps to a concrete piece of returned data or the call_id provenance.
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 carries the burden of describing return values and does so by listing the fields. The remaining gap is lifecycle context (what status values exist, whether a result may be incomplete), which is minor for a simple getter but would have made it fully self-sufficient.
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 call_id parameter is fully documented in the schema, including its origin ('returned by make_call'). The description restates that provenance but adds no syntax, format, or error semantics 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?
Names a specific verb (Get) and resource (a call) and enumerates the fields returned: status, duration, summary, collected data, transcript. The phrase 'a call placed with make_call' scopes it to a single call, which implicitly distinguishes it from the sibling list_calls.
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?
By tying call_id to 'returned by make_call,' it implies the call sequence (create with make_call, then retrieve with get_call). However, it never explicitly states when to use this instead of list_calls, nor does it mention whether repeated polling is expected while a call is in progress.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Show the price per call/minute, limits, allowed countries and calling hours, and your remaining balance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds the cost fact ('Free') and, critically, enumerates what the response contains since there is 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 cost fact and then a compact list of returned fields. Nothing is wasted and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read tool with no output schema, the description supplies the return contents and the cost trait, which is most of what an agent needs. It could say slightly more about format (e.g., currency or units), but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline-4 case. The description does not discuss parameters, and nothing about parameters needs explaining.
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 ('Show the price... and your remaining balance') and enumerates the exact data returned. None of the siblings (get_call, list_calls, make_call) deal with pricing or balance, so it is unambiguous which tool this is.
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 leading 'Free.' implicitly tells the agent this call costs nothing and is safe to make for pre-flight checks before make_call, but it never explicitly says when to use this versus the calling tools. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the most recent calls placed with your key (newest first).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many calls, default 10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so safety is covered. The description adds useful context — result ordering (newest first) and that results are scoped to the caller's key — but says nothing about truncation, pagination, or what a returned call record contains.
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; ordering and scope are stated before any detail.
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-optional-parameter read tool with full annotation coverage and full schema descriptions, this is close to sufficient. The one real gap is that an agent cannot tell from the description whether it can page beyond the 50-item cap.
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 the limit parameter documented as "How many calls, default 10" and bounded 1–50, so the description need not repeat it. Baseline 3 applies since the description contributes no additional parameter meaning.
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 (list) and resource (calls), plus scope ("placed with your key") and ordering ("newest first"). It is clearly distinct from make_call and get_call by implication, though it never explicitly names them.
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 "most recent calls" but there is no explicit when-to-use guidance versus get_call, and no mention of what happens when more calls exist than the limit allows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place a real outbound phone call with an AI voice agent and get a call_id. The agent introduces itself as an AI assistant of the business you name, pursues the goal you describe, collects the requested data and hangs up. Destinations: Spain (+34), Mexico (+52), United States and Canada (+1), Colombia (+57), Peru (+51) and United Kingdom (+44). With a prepaid key, at their own price per minute (see get_pricing): Argentina, Belize, Bolivia, Brazil, Chile, Costa Rica, Dominican Republic, Ecuador, El Salvador, Guatemala, Honduras, Nicaragua, Panama, Paraguay, Puerto Rico, Uruguay, Austria, Belgium, France, Germany, Ireland, Italy, Netherlands and Portugal. Calls are short (max 4 minutes). United States and Canada: informational calls only, every day 08:00-21:00 local time of the recipient, with prior_express_consent=true and call_type. Colombia, Peru and United Kingdom: service calls only, Monday to Saturday 09:00-21:00. Set call_purpose: service calls (appointments, reminders, surveys of your own customers, calls the person asked for) run Monday to Saturday 09:00-21:00 local time; commercial calls, only to Spain and Mexico, run Monday to Friday (Spain 09:00-21:00 and only from a 400 number; Mexico 09:00-19:00). In Spain and Mexico, no calls on Sundays or national holidays. You must confirm the recipient asked for or agreed to be contacted. The result is returned by get_call using the call_id. Pass website_url (the business website) and/or business_info so the agent can answer questions about prices, hours or services during the call.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Destination phone number in E.164 format, e.g. +34600111222 or +525512345678 | |
| goal | Yes | What the call must achieve, in plain language | |
| collect | No | Data points to collect, e.g. ['preferred date', 'email'] | |
| language | Yes | Language the agent speaks (ISO 639-1) | |
| call_type | No | Required for +1 destinations: informational calls only, never cold prospecting | |
| website_url | No | Website of the business you call for. It is read before the call (up to 10 pages) so the agent can answer questions about prices, hours, services or address | |
| call_purpose | Yes | service: appointments, reminders, surveys of your own customers, or a call the person asked for. commercial: selling or offering something to someone who did not ask for it. It sets the allowed calling hours; commercial calls to Spain require a 400 number | |
| business_info | No | Extra facts about the business the agent may need (prices, hours, services, policies). The agent answers only with this and the website, never invents | |
| business_name | Yes | Name of the business on whose behalf the agent calls | |
| consent_confirmed | Yes | Must be true: the recipient requested or agreed to be contacted | |
| consent_statement | Yes | How and when the recipient requested or agreed to be contacted | |
| prior_express_consent | No | Required true for +1 destinations: the recipient gave prior consent to be called (TCPA) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnly=false and openWorld=true; the description carries the real behavioral load: the call is a REAL outbound call to a human, capped at 4 minutes, the agent identifies as an AI, answers only from website_url/business_info, and hangs up. It also discloses cost implications via get_pricing and the legal precondition of recipient consent, which the annotations cannot express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose, but the remainder is one dense block mixing country lists, time windows, and consent rules. The content mostly earns its place, yet the regulatory matrix would scan far better as structured lines rather than a prose run-on.
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 12-parameter, non-idempotent, real-world side-effecting tool with no output schema, this is complete: it explains what is produced (call_id), where to retrieve the result (get_call), cost lookup (get_pricing), and every jurisdictional constraint an agent must satisfy before calling. Nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description still adds meaning: it explains why call_purpose matters (it drives allowed hours and the 400-number requirement in Spain), why website_url/business_info exist (up to 10 pages read pre-call, agent must not invent), and reinforces that consent must be genuinely obtained rather than just a boolean set.
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: "Place a real outbound phone call with an AI voice agent and get a call_id." It distinguishes itself from siblings immediately by noting the result comes back through get_call, and by pointing to get_pricing for destinations behind a prepaid key.
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 rich eligibility context: per-country destination support, calling windows, the +1 informational-only rule, and the prohibition on cold commercial calls outside Spain/Mexico. It routes follow-up reads to get_call and get_pricing. It does not explicitly frame these as "use this instead of X", but the operational conditions are clear enough that selection is unambiguous.
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.
make_call6 fields changedInput schema / properties / call_purposeAdded value: +{
+ "description": "service: appointments, reminders, surveys of your own customers, or a call the person asked for. commercial: selling or offering something to someone who did not ask for it. It sets the allowed calling hours; commercial calls to Spain require a 400 number",
+ "enum": [
+ "service",
+ "commercial"
+ ],
+ "type": "string"
+}Input schema / properties / call_typeAdded value: +{
+ "description": "Required for +1 destinations: informational calls only, never cold prospecting",
+ "enum": [
+ "appointment",
+ "reminder",
+ "collection"
+ ],
+ "type": "string"
+}Input schema / properties / language / descriptionPrevious value: -"Language the agent speaks"New value: +"Language the agent speaks (ISO 639-1)"Input schema / properties / language / enumPrevious value: -[
- "es",
- "en"
-]New value: +[
+ "es",
+ "en",
+ "pt",
+ "fr",
+ "de",
+ "it",
+ "nl",
+ "zh",
+ "ar",
+ "ru",
+ "ja",
+ "ko",
+ "tr",
+ "pl",
+ "hi",
+ "sv",
+ "uk",
+ "id",
+ "ms",
+ "vi",
+ "el",
+ "ro",
+ "cs",
+ "da",
+ "no",
+ "fi",
+ "bg",
+ "hr",
+ "hu",
+ "sk"
+]Input schema / properties / prior_express_consentAdded value: +{
+ "description": "Required true for +1 destinations: the recipient gave prior consent to be called (TCPA)",
+ "type": "boolean"
+}Input schema / requiredPrevious value: -[
- "to",
- "goal",
- "language",
- "business_name",
- "consent_confirmed",
- "consent_statement"
-]New value: +[
+ "to",
+ "goal",
+ "language",
+ "business_name",
+ "call_purpose",
+ "consent_confirmed",
+ "consent_statement"
+]make_call2 fields changedInput schema / properties / business_infoAdded value: +{
+ "description": "Extra facts about the business the agent may need (prices, hours, services, policies). The agent answers only with this and the website, never invents",
+ "maxLength": 4000,
+ "type": "string"
+}Input schema / properties / website_urlAdded value: +{
+ "description": "Website of the business you call for. It is read before the call (up to 10 pages) so the agent can answer questions about prices, hours, services or address",
+ "format": "uri",
+ "maxLength": 300,
+ "type": "string"
+}get_callget_pricinglist_callsmake_callReal US phone calls for AI agents: navigates phone menus, waits on hold, returns transcripts.
AI voice agents that make real phone calls: single calls or campaigns, with transcripts and notes.
Build and manage voice AI agents for real phone lines: assistants, calls, numbers and campaigns.
Let AI agents place real phone calls from your verified number, with transcripts and recordings.
Add one secure layer between your agents and this server.
