Skip to main content
Glama
hail-hq

hail

Official

Place a phone call

place_call

Place an outbound AI phone call with a saved agent or custom prompt, attest recipient consent, and configure language, recording, first message, tools, and metadata.

Instructions

Originate an outbound phone call.

    Provide ``system_prompt`` (mode A — Hail's bundled fallback LLM
    uses this prompt) or ``llm`` (mode B — bring your own
    OpenAI-compatible endpoint as
    ``{"base_url": ..., "api_key": ..., "model": ...}``), or both, or
    ``agent_id`` (a saved agent from ``list_agents`` supplies the
    prompt, first message, AI line, voice and tools; fields you pass
    here win). At least one is required. Passing both runs your prompt on your
    own endpoint: it receives Hail's voice preamble plus your prompt
    as the leading system message.

    ``to`` must be E.164 (e.g. ``+14155551234``). ``from_`` is
    optional and defaults to the first active number on your org.
    ``first_message`` is spoken verbatim on pickup; omit it to let
    the agent open the conversation itself — it reacts to how the
    call was answered, or introduces itself after silence.
    ``language`` sets the call's spoken language for speech-to-text,
    text-to-speech, and turn detection, as a lowercase ISO 639-1 code
    (e.g. ``"da"``); 39 languages are supported (server rejects others
    with 422); omit for English. STT provider selection is
    console-BYO-only (no per-call override); configure it on the
    organization to pin a provider.
    ``ai_disclosure=False`` skips the spoken "this is an AI
    assistant" line at the start of the call. Leave enabled unless
    the user has verified it is not required for this call — US
    artificial-voice calls (47 CFR 64.1200(b)(1)) and several AI
    bot-disclosure laws require it, and Hail does not verify this.
    The agent still identifies itself as an AI if asked.
    ``recording_enabled``: omit it to follow the agent, then the
    workspace recording setting. ``true`` records this call and
    ``false`` does not, whatever the workspace setting. Pass it only
    when the user asked for or against a recording.
    ``metadata`` is free-form JSON attached to the call record.
    ``tools`` are the agent tools to allow on this call. Omit for all
    available; pass ``[]`` to disable.

    ``recipient_consent`` is required and must be the JSON boolean
    ``true`` (strings and numbers are refused): attest that you (the caller
    triggering this request) have obtained the lawful consent needed
    to contact this recipient. The API rejects the request (422) if
    this is not ``true`` — Hail does not verify consent for you, you
    are responsible for having a lawful basis (TCPA / ePrivacy / GDPR
    as applicable). Set ``message_type="marketing"`` for promotional
    calls (this additionally requires a non-empty ``consent_source``
    describing how/where consent was obtained) — leave as the default
    ``"informational"`` for transactional/service calls.

    ``idempotency_key`` defaults to a fresh UUID per invocation
    and is returned in the response under ``idempotency_key`` — to
    retry *this* exact request (rather than dispatch a second call),
    pass the value back on the retry. A new key is a new call.

    Example:
        place_call(to="+14155551234",
                   recipient_consent=True,
                   system_prompt="You are scheduling a haircut.",
                   first_message="Hi, I'm calling on behalf of Alex.")

    Returns the API's ``CallResponse`` as a dict (id, status,
    from_e164, to_e164, ...). On failure returns
    ``{"error": "<message>"}`` instead.
    

Input Schema

NameRequiredDescriptionDefault
toYes
llmNo
from_No
toolsNo
agent_idNo
languageNo
metadataNo
message_typeNoinformational
ai_disclosureNo
first_messageNo
system_promptNo
consent_sourceNo
idempotency_keyNo
recipient_consentYes
recording_enabledNo
consent_obtained_atNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.29.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare it is a non-readonly, open-world, non-idempotent call, and the description adds substantial context beyond that: 422 rejection for bad language or missing consent, legal disclosure obligations from 47 CFR 64.1200(b)(1), recording setting precedence, idempotency-key retry semantics, and the error-dict failure shape. This is exactly the behavioral detail an agent needs before mutating anything.

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?

It is long but organized: purpose and mode selection first, then parameters in rough order of importance, then an example, then return shape. A few passages — the STT console-BYO note and repeated consent warnings — could be tightened, but almost every sentence carries operational or legal significance.

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 16-parameter, legally regulated outbound-call tool, the description covers mode selection, hard validation rules, compliance requirements, recording precedence, retry semantics, and an example. An output schema exists, so the added CallResponse/error explanation is a bonus rather than a necessity.

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?

Schema coverage is 0% across 16 parameters, so the description must carry the full burden and it does — it explains the system_prompt/llm/agent_id interplay and precedence, E.164 format for to, from_ default behavior, language ISO code constraints, ai_disclosure and recording_enabled precedence, tools defaults, metadata, consent_source, and idempotency_key semantics. Only consent_obtained_at goes undocumented.

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 first line states a specific verb and resource — 'Originate an outbound phone call' — which is unmistakable and inherently distinct from get_call, list_calls, send_sms, and the other siblings. No ambiguity about what the tool does.

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?

It gives rich conditional guidance: mode A vs mode B vs agent_id, when to pass recording_enabled ('only when the user asked for or against'), when to use ai_disclosure=False, and when message_type should be marketing. It does not explicitly compare against channel alternatives like send_sms, so it stops short of full when/when-not/alternatives coverage.

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