Skip to main content
Glama

Phone Call (Live)

phone_call_create

Place a live phone call and have a real conversation. The tool stays open for the entire call duration. As the caller speaks, you receive live transcript chunks via progress notifications; when the caller finishes a turn (server emits isFinal: true), an elicitation prompt asks you what the agent should say next. You respond with say (the exact text to speak) and optional endCallAfterSpoken: true to hang up after the line. Returns the full transcript when the call ends. Requires the connecting MCP client to support elicitation — without it, the tool errors out immediately.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesDestination phone number in E.164 format.
agentIdNoRequired when the API key / OAuth grant is user-bound (no agentId in the auth context, e.g. a master key or a user-consented Anima Connect grant) — picks which of the org's agents places the call. Ignored when the auth is already agent-bound (the bound agent wins; mismatches are rejected with AGENT_MISMATCH). Use agent_list to find valid IDs.
voiceIdNoOptional voice override. Use voice_list for valid IDs; the catalog is multilingual and each entry carries an audio preview.
fromNumberNoOptional source phone in E.164. Default: the calling agent's primary phone identity.
agentConfigNoOpt in to the server-side conversation loop. When present (even as `{}`), the Anima API runs the LLM-backed conversation loop on each caller turn and speaks the reply — the MCP tool just records both sides of the transcript and returns it when the call ends. **Required when the connecting MCP client doesn't implement elicitation** (e.g. Claude Code returns `-32600 Elicitation not supported`). Omit ONLY if you have your own bot ready to subscribe to MCP elicitation requests and reply via the `say` field per turn.
firstMessageYesOpening line the agent speaks when the call is answered. Be natural — this is what the human hears first.
maxDurationSecNoHard cap on total call duration in seconds. Default 600 (10 min). Max 1800 (30 min).
silenceTimeoutSecNoIf no caller utterance arrives within this many seconds (measured from the last agent utterance), the call hangs up automatically. Default 30.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when `endedReason` is `error` or `elicitation_unsupported` — carries the underlying code+message so callers can distinguish capability gaps from real failures.
callIdYesID of the placed call. `null` if the call ended before the carrier assigned an ID (e.g. WS auth failure or pre-ring termination) — use `endedReason` to understand why.
transcriptYesFull transcript with role labels in chronological order.
durationSecNoTotal call duration in seconds.
endedReasonYesWhy the call ended (hangup, timeout, error, etc.).
latencyTurnsNoPer-turn latency breakdown captured by the API's LatencyTracker. Each entry is a turn; the t_*_ms fields are absolute millisecond timestamps. Diff adjacent marks to compute stage durations — common ones: perceived_latency_ms = t_speak_dispatch_ms - t_caller_speech_end_ms (basic) or t_tts_first_tx_ms - t_caller_speech_end_ms (premium), endpoint_wait_ms = t_final_ms - t_caller_speech_end_ms, ws_round_trip_ms = t_ws_recv_ms - t_ws_send_ms. Omitted if the API didn't send latency data (pre-Wave-3K servers).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

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

The description discloses that the call stays open, that the tool returns the full transcript, and that it errors out if elicitation is unsupported. It adds meaningful behavioral detail beyond the readOnly/destructive/idempotent annotations, though it does not mention potential costs or billing implications of placing an outbound call.

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

Conciseness4/5

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

The description is long but well-structured and information-dense; every sentence adds useful detail. It could be slightly more concise, but the complexity of the tool justifies the length.

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?

The description covers the tool's purpose, live behavior, parameter nuances, error conditions, and return value (full transcript). It is complete enough for an agent to use the tool safely and effectively without additional external documentation.

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

Parameters5/5

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

All 8 parameters are fully documented, including defaults, max lengths, valid formats, and conditional behavior. The agentId and agentConfig parameters receive especially thorough explanations that go well beyond the raw schema.

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 description clearly states the tool places a live phone call and manages a real conversation, which is a specific verb and resource. It distinguishes itself from sibling tools like phone_call_get, phone_call_list, and phone_call_recording_get by focusing on call creation and live interaction.

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

Usage Guidelines5/5

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

The description explains when to use the server-side agentConfig loop versus when to rely on client elicitation, and explicitly references agent_list and voice_list for valid IDs. It also notes the requirement for the MCP client to support elicitation, giving clear operational guidance.

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.