Skip to main content
Glama

PlaceCall

by io.github.voygr-tech
OverviewDiscussionsAdmin

Place a phone call

place_call
Destructive

Place a real outbound phone call to a US business to carry out a stated task, such as making a reservation or asking a question, and return a call id. Every invocation dials: there is no lookup, preview or dry-run mode, and a question about a business is not answered by this tool. The call cannot be un-placed. It costs 10 credits when it obtains something (an answer, a refusal, a booking) and nothing when it obtains nothing; 30 credits are held while it runs, and the unused part is released. Poll get_call_result with the returned id for the transcript and outcome. A repeat of the same number, brief and language within two minutes is absorbed rather than placed again: it comes back as duplicate_call, carrying the id of the call that was already accepted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
briefYesThe task for the call in plain language: what to ask or arrange, and any detail the agent may give, such as the name a table is booked under or the party size. It becomes the agent's instructions for the call. Up to 4000 characters.
languageNoThe language the call is held in: auto (the default) or an ISO 639-1 code, one of en, es, fr, de, hi, ru, pt, ja, it, nl, sr, tr, pl. An auto call is held in English; es holds the whole call in Spanish. An unsupported code is refused.auto
target_phoneYesThe number to dial in E.164 form, with its country code, for example +14155550123. Spaces, dashes, dots and parentheses are accepted. A ten-digit number with no country code, an extension, and emergency or N11 service numbers are refused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / brief / description
      Added value: +"The task for the call in plain language: what to ask or arrange, and any detail the agent may give, such as the name a table is booked under or the party size. It becomes the agent's instructions for the call. Up to 4000 characters."
    • addedInput schema / properties / language / description
      Added value: +"The language the call is held in: auto (the default) or an ISO 639-1 code, one of en, es, fr, de, hi, ru, pt, ja, it, nl, sr, tr, pl. An auto call is held in English; es holds the whole call in Spanish. An unsupported code is refused."
    • addedInput schema / properties / target_phone / description
      Added value: +"The number to dial in E.164 form, with its country code, for example +14155550123. Spaces, dashes, dots and parentheses are accepted. A ten-digit number with no country code, an extension, and emergency or N11 service numbers are refused."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations with hard-to-infer traits: every invocation dials, the call cannot be un-placed, the credit cost model (10 when it obtains something, 30 held, remainder released), and the 2-minute duplicate-absorption behavior returning duplicate_call. This is exactly the operational context annotations alone cannot convey.

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 purpose and output, then layers behavior and cost; no sentence is wasted. It is dense and long, but every clause (dialing, cost, duplicate, polling) carries distinct information, so the length is justified rather than padded.

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 destructive, non-idempotent, open-world mutation tool with no output schema, the description covers everything an agent needs: what happens on invocation, cost, irreversibility, duplicate handling, and the required follow-up call to get_call_result. Nothing material is left undocumented.

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 100%, so brief, language, and target_phone are already fully documented in the schema with format rules and accepted codes. The description adds only a passing reference to 'same number, brief and language' in the duplicate rule, which is marginal. Baseline 3 is appropriate when the schema does the heavy lifting.

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 phone call to a US business'), names the output ('return a call id'), and explicitly distinguishes itself from answer_question ('a question about a business is not answered by this tool'). An agent can select it over siblings without opening any schema.

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-nots ('there is no lookup, preview or dry-run mode'), a routing instruction to the sibling get_call_result for polling, and a carve-out for question-answering. The conditions that select this tool versus alternatives are fully spelled out.

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

All PlaceCall toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources