Skip to main content
Glama

CallMCP — Phone Call MCP Server

Make Call

make_call
Destructive

Place an outbound call through a KaiCalls AI agent: call back a customer who previously called this business, give the owner a voice preview, or call on the owner's behalf (a landlord, clinic, pharmacy, school or utility) with the task in context. For a customer callback, pass the existing lead_id and callback goal in context. Kai verifies the business's inbound-call consent for the exact destination; a verified callback can go directly to a cell phone without connecting the owner. Contact existence alone is not callback permission, and opt-outs still block calls. A call never proves inbound routing or advances activation. report_language sets the language the result is reported in, and Kai then confirms exact details for that reader; Kai speaks call_language (English by default) on the phone. A new account's first call to a US or Canada business line is free; after that the account needs a plan. Kai calls businesses, not personal cell phones, on a free call. For a business that answers on a cell phone, connect_me has Kai ring the person's own saved phone and connect them, so they do the talking. While the call runs, check_call_status shows its live_transcript and send_call_note steers Kai. hold_for_me has Kai wait on hold at a business and connect the person when someone answers. An idempotency_key makes the request safely retryable. Only to is required: with no agent_id the account's one agent places the call.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "to": "<to>"
    },
    "name": "make_call"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYesPhone number to call (E.164 format, e.g. +19085551234)
nameNoCaller/lead name (optional)
contextNoCall context or reason (optional)
lead_idNoExisting lead ID to associate (optional)
agent_idNoKaiCalls agent ID to use for the call (optional). Leave it out when the account has one agent: Kai uses that one. With several agents and none named, no call is placed and the answer lists them
caller_idNoWhich number the other side sees (optional). 'own' shows the person's own verified number (start_own_caller_id) so they recognize who is calling; with none verified, no call is placed. 'business_line' shows the KaiCalls line. Left out, the account's saved choice applies. A free first call always shows the KaiCalls line
connect_meNoTrue when the person wants to talk to `to` themselves, for example a business that answers on a cell phone: Kai rings the person's own phone saved on the account (set_owner_phone), says one line and connects them to `to`. Kai never speaks to `to`. Takes no lead_id and cannot be listen-only (optional)
hold_for_meNoTrue when the person wants Kai to wait on hold for them: Kai calls `to`, gets through the phone menu and hold queue, and the moment a live person answers, says one line and connects the person's own phone saved on the account (set_owner_phone) so they do the talking. If they don't pick up, Kai does the task in context itself. Needs a saved phone and a plan (not on the free first call). Takes no lead_id and cannot be listen-only or connect_me (optional)
listen_onlyNoTrue to only listen: Kai calls a business, stays silent, records what answers (voicemail, answering service, phone menu or no answer) and hangs up within about 75 seconds without leaving a message. Takes no lead_id; context is ignored (optional)
external_refNoYour own reference for the conversation or task this call belongs to (up to 200 characters, optional). It comes back unchanged on check_call_status and on every webhook event for this call (call.question_pending, call.completed), so your agent can return the result to the right conversation.
call_languageNoLanguage Kai speaks on the call (optional, default en)
first_messageNoOverride the agent greeting message (optional)
idempotency_keyNoClient-chosen key that makes this call exactly-once: retries with the same key never place a second call (optional but recommended)
report_languageNoLanguage the person asking reads, as a code or name (e.g. ar, ht, tr, bn, es, zh, vi). Kai confirms names, dates and numbers so the result can be relayed in this language (optional)
connector_activation_callNoTrue only for the one-time connector activation call the recipient explicitly requested in this conversation. This is not permission for marketing, SMS, or future calls.

Output Schema

NameRequiredDescriptionDefault
callNo
errorNoPresent when success is false
successYesWhether the tool completed successfully
replayedNo
intent_idNo
external_refNo
preview_onlyNo
call_languageNo
idempotency_keyNo
report_languageNo
counts_toward_activationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / caller_id
      Added value: +{
      +  "description": "Which number the other side sees (optional). 'own' shows the person's own verified number (start_own_caller_id) so they recognize who is calling; with none verified, no call is placed. 'business_line' shows the KaiCalls line. Left out, the account's saved choice applies. A free first call always shows the KaiCalls line",
      +  "enum": [
      +    "own",
      +    "business_line"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / hold_for_me
      Added value: +{
      +  "description": "True when the person wants Kai to wait on hold for them: Kai calls `to`, gets through the phone menu and hold queue, and the moment a live person answers, says one line and connects the person's own phone saved on the account (set_owner_phone) so they do the talking. If they don't pick up, Kai does the task in context itself. Needs a saved phone and a plan (not on the free first call). Takes no lead_id and cannot be listen-only or connect_me (optional)",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only say destructive/openWorld/non-readonly; the description goes far beyond that by disclosing consent verification on the exact destination, that opt-outs block, billing behavior (free first US/Canada business call, plan needed after), that a call never proves inbound routing or advances activation, and that listen_only hangs up within ~75 seconds. The only minor tension is 'idempotency_key makes the request safely retryable' against idempotentHint=false, but that is a conditional guarantee, not a contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the body is one dense paragraph that mixes consent policy, pricing, mode selection, and sibling-tool pointers, with a few convoluted clauses ('Kai calls businesses, not personal cell phones, on a free call'). The information is valuable but would scan far better as short segmented lines per mode.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter, destructive, open-world tool with an output schema and annotations, the description covers the risky edges: consent, opt-outs, billing gating, retry safety, and how the three conversation modes interact. Nothing an agent needs before firing a real phone call appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, and the description earns more by explaining cross-parameter semantics the schema only partially states: callback requires lead_id plus context, report_language (reader's language) is distinct from call_language (spoken on the phone), and omitting agent_id falls back to the account's single agent. Some of this overlaps the schema text, keeping it from a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and resource ('Place an outbound call through a KaiCalls AI agent') and immediately enumerates the three legitimate scenarios: customer callback, owner voice preview, and calling on the owner's behalf with a task in context. An agent can distinguish this from campaign-level siblings like launch_call_campaign because the scope is explicitly one call.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Guidance is unusually rich: it names the precondition for a callback (existing lead_id plus goal in context), states that contact existence is not callback permission, notes opt-outs still block, and explains when to prefer connect_me or hold_for_me instead of a plain AI-placed call. It stops short of telling the agent when to use this versus batch alternatives such as launch_call_campaign, so a 4 rather than 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.