Skip to main content
Glama

call_business

Destructive

[UNAVAILABLE on this deployment: Voice calling is not enabled on this deployment yet: the outbound phone line has not been verified for placing calls.] Place a conversational voice-AI phone call to a business on a consumer's behalf; 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, not charged while no payment rail is on] [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. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing deployment unavailability, a per-call cost, a jurisdiction-based recording-consent compliance gate, and the async continuation pattern. Annotations already cover the safety profile (destructive/openWorld/non-idempotent), so this added operational context is a genuine supplement, though the return receipt of the async flow is not described.

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 critical deployment-unavailability warning, then the purpose, then constraints and pricing. Bracket-heavy formatting makes it dense but each bracketed segment (availability, cost, async) carries distinct, decision-relevant information with no filler.

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 an 8-parameter mutating async tool with no output schema and no annotations covering return values, the description supplies the missing operational pieces: availability, cost, consent gating, and the get_outcome follow-up. It does not explain the receipt/return shape, leaving a minor gap.

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 88%, so the schema already documents nearly every parameter. The description only reinforces 'give a plain-language objective' and does not add format, precedence (smb_id vs business_phone), or value-range guidance beyond the schema, matching the baseline for high 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?

States a specific verb (place a conversational voice-AI phone call), the target (a business, on a consumer's behalf), and the operating model (give a plain-language objective; it navigates the call and extracts the answer). This is clearly distinguishable from siblings like send_message or get_outcome.

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?

Gives clear context: it is business-directed (B2B), less restricted than calling consumers, and the async→get_outcome handoff tells the agent what to call next. It does not explicitly say when to prefer this over send_message or escalate_to_human, so it stops short of full alternative routing.

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.