Skip to main content
Glama

call_business

Destructive

Place a conversational voice-AI phone call to a business on a consumer's behalf. NOT WIRED on this deployment (Vapi unconfigured): every call fails honestly with voice_not_provisioned before dialling, uncharged. Give a plain-language objective and it navigates the call, extracting the answer. Business-directed (B2B), far less restricted than calling consumers, but the compliance gate still enforces recording consent per jurisdiction. [$0.2/per_call] [async→get_outcome]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
smb_idNoKnown SMB identifier with a phone on record. Provide this OR business_phone.
objectiveYesWhat the call should accomplish, in plain language.
country_codeNoISO 3166-1 alpha-2 for compliance + recording-consent routing.
on_behalf_ofNoName of the consumer the call is placed for.
business_phoneNoBusiness phone in E.164 (e.g. +14045550123). Provide this OR smb_id.
extract_fieldsNoStructured fields to pull from the answer, e.g.…
idempotency_keyNoRetry key: a 24h replay returns the original receipt, not re-run or charged.
max_duration_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Optional client-supplied key for safe retries. Replaying the same key within 24h returns the original receipt - the operation is NOT re-executed and NOT re-charged."New value: +"Retry key: a 24h replay returns the original receipt, not re-run or charged."
  2. Changed1 schema field changed
    • changedInput schema / properties / extract_fields / description
      Previous value: -"Structured fields to pull from the answer, e.g. ['available_tomorrow','price_quote','earliest_slot']."New value: +"Structured fields to pull from the answer, e.g.…"
  3. Changed1 schema field changed
    • addedInput schema / properties / idempotency_key
      Added value: +{
      +  "description": "Optional client-supplied key for safe retries. Replaying the same key within 24h returns the original receipt - the operation is NOT re-executed and NOT re-charged.",
      +  "maxLength": 128,
      +  "type": "string"
      +}
  4. Added

TDQS

A3.5/5.0
Behavior1/5

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

The description discloses key behavioral traits: it's not wired and fails with voice_not_provisioned before dialling, is async via get_outcome, and has per-call pricing. However, it directly contradicts the annotation destructiveHint=true by stating calls fail before dialling and are uncharged, implying no side effects. This is a clear contradiction, so per rubric the score is 1.

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 compact yet dense, covering purpose, failure mode, usage, compliance, pricing, and async behavior in a few sentences. It front-loads the main action and then provides caveats. Each sentence adds value, though it could be slightly tightened.

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?

Given the tool's complexity (8 params, async, failure mode), the description covers essential operational aspects: it's not wired, async, pricing, compliance, and how to use it. It doesn't describe the success output, but that's handled by get_outcome. It could mention the requirement for either smb_id or business_phone, though that's in the schema.

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 coverage is 88%, so most parameters are already described. The description adds minimal parameter-specific info beyond saying 'Give a plain-language objective,' which maps to the objective field. It doesn't elaborate on smb_id vs business_phone or other parameters. Baseline 3 is appropriate given the high schema coverage.

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's specific action: placing a conversational voice-AI phone call to a business on a consumer's behalf. It also mentions it navigates the call and extracts answers, and it's distinguished from siblings like send_message or check_booking_link. The 'NOT WIRED' caveat adds context without obscuring the purpose.

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?

The description gives clear context for when to use it: it's business-directed (B2B), less restricted than consumer calls, and requires a plain-language objective. It also warns that the tool is not wired and will fail, which is crucial for an agent. However, it doesn't explicitly name alternatives or state when NOT to use it, so it's not a 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.