Skip to main content
Glama

start_outbound_call

Destructive

Place a REAL outbound call now: the agent calls the "to" number and talks to whoever answers. Bills voice minutes. Confirm the number with the user first. channel=phone (default) is a normal phone call from the agent's assigned number. channel=whatsapp is a WhatsApp voice call from one of the agent's WhatsApp numbers (it needs voice calling switched on, see whatsapp_numbers_write set_voice_calling). WhatsApp only lets a business call someone who has allowed it: if they have not, they are sent a permission prompt in the chat and NO call is placed (the result status is "permission_requested"; call again once they accept). WhatsApp allows 1 permission prompt per customer per 24 hours and 2 per 7 days, and the prompt only works within 24 hours of the customer last messaging the number. For many leads at once use contact_leads or a campaign (campaigns_write).

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": {
      "agentId": "<agentId>",
      "to": "<to>"
    },
    "name": "start_outbound_call"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYesNumber to call, E.164 (e.g. +15551234567).
fromNoOptional: one of the agent's numbers (a phone number for channel=phone, a WhatsApp number for channel=whatsapp), in E.164 with a leading +. Defaults to the agent's primary number.
modeNocompact (default) = light mode: long text is cut and bulky blobs are replaced by a size marker. full = complete API response.
agentIdYes
channelNoHow to place the call. phone (default): a normal phone call. whatsapp: a WhatsApp voice call; the customer must have allowed calls from your business, otherwise they get a permission prompt and no call is placed.
optionsNoOptional per-call agent overrides (e.g. initialPrompt, variables).
leadInfoNoOptional details about the person (username, email, address, company, notes…) the agent can use to personalize.
campaignIdNoOptional: attribute the call to a campaign.
permissionMessageNochannel=whatsapp only. Text of the permission prompt the customer sees, for example "May we call you about your booking?" (max 1024 characters). A default message is used when empty.
requestPermissionNochannel=whatsapp only. When the customer has not allowed calls yet, send them the permission prompt in the chat (default true). false sends nothing and returns status "no_permission".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / channel
      Added value: +{
      +  "description": "How to place the call. phone (default): a normal phone call. whatsapp: a WhatsApp voice call; the customer must have allowed calls from your business, otherwise they get a permission prompt and no call is placed.",
      +  "enum": [
      +    "phone",
      +    "whatsapp"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / from / description
      Previous value: -"Optional: one of the agent's numbers. Defaults to its primary number."New value: +"Optional: one of the agent's numbers (a phone number for channel=phone, a WhatsApp number for channel=whatsapp), in E.164 with a leading +. Defaults to the agent's primary number."
    • addedInput schema / properties / permissionMessage
      Added value: +{
      +  "description": "channel=whatsapp only. Text of the permission prompt the customer sees, for example \"May we call you about your booking?\" (max 1024 characters). A default message is used when empty.",
      +  "type": "string"
      +}
    • addedInput schema / properties / requestPermission
      Added value: +{
      +  "description": "channel=whatsapp only. When the customer has not allowed calls yet, send them the permission prompt in the chat (default true). false sends nothing and returns status \"no_permission\".",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare destructive, non-idempotent, and open-world behavior, but the description adds substantial context beyond them: real voice minutes are billed, user confirmation is required, and WhatsApp calls may not connect at all, returning status 'permission_requested'. It also discloses concrete rate limits (1 prompt per customer per 24 hours, 2 per 7 days) and the 24-hour messaging window, which are not in any structured field. It stops short of describing the overall response payload or failure modes beyond the WhatsApp case.

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?

Front-loads the highest-risk facts (real call, bills minutes, confirm first) before channel details, which is the right ordering. It is a long single block, and the WhatsApp channel behavior is restated in both the description and the schema's channel description, so some redundancy is present, but nearly every sentence carries operational information.

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

Completeness4/5

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

For a 10-parameter, non-idempotent, destructive tool with no output schema, the description covers the critical unknowns: cost, confirmation prerequisite, channel-dependent behavior, and the 'permission_requested' result status. The main gap is that agentId is never explained anywhere, and the general return shape is left unaddressed, though with no output schema that is a minor omission.

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

Parameters3/5

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

Schema description coverage is 90%, so the baseline is 3 and the schema already documents to, from, channel, options, leadInfo, campaignId, permissionMessage, requestPermission, and mode. The description reinforces channel semantics and the permission-prompt outcome, but adds no new syntax or format detail beyond what the schema provides, and never mentions agentId, which is undocumented in both places.

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?

States a specific verb and resource ('Place a REAL outbound call now') and immediately clarifies the mechanism: the agent dials the 'to' number and talks to whoever answers. It distinguishes this from bulk paths by naming contact_leads and campaigns_write, so an agent can tell it apart from sibling tools without reading schemas.

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?

Gives explicit when-to-use conditions ('Place ... now', 'Confirm the number with the user first') and explicit alternatives for high-volume cases ('For many leads at once use contact_leads or a campaign (campaigns_write)'). It also tells the agent how to choose between channel=phone and channel=whatsapp and what to do when a permission prompt is returned.

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.

Resources