Skip to main content
Glama

Preview a call (free, no account)

plan_call
Read-onlyIdempotent

Free preview before place_call, no account needed: the opening line, what the business will probably ask that you haven't provided (get it from the user BEFORE calling; every gap becomes a live question the business waits on), whether the business is open now, tips (best time to call, when to use transfer_to), and the cost. Takes the same arguments as place_call. Recognizes the free demo lines.

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": {
      "phone": "<phone>",
      "goal": "<goal>"
    },
    "name": "plan_call"
  }
}

Input Schema

NameRequiredDescriptionDefault
goalYesAs in place_call
phoneYesAs in place_call
call_atNoAs in place_call
detailsNoAs in place_call
if_askedNoAs in place_call
languageNoAs in place_call
questionsNoAs in place_call
after_hoursNoAs in place_call
constraintsNoAs in place_call
transfer_toNoAs in place_call
max_cost_usdNoAs in place_call
on_behalf_ofNoAs in place_call
business_nameNoAs in place_call
callback_numberNoAs in place_call
voicemail_messageNoAs in place_call

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / call_at
      Added value: +{
      +  "description": "As in place_call",
      +  "type": "string"
      +}
  2. Changed14 schema fields changed
    • changedInput schema / properties / after_hours / description
      Previous value: -"Only for places open late (24-hour pharmacy, hotel): call even 10pm-7am at the business"New value: +"As in place_call"
    • changedInput schema / properties / business_name / description
      Previous value: -"Business name, used in the greeting"New value: +"As in place_call"
    • changedInput schema / properties / callback_number / description
      Previous value: -"A number where the business can reach the user. Pass it when they may follow up (a quote after a visit, a callback): the assistant gives it as soon as they say they'll get back to the user."New value: +"As in place_call"
    • changedInput schema / properties / constraints / description
      Previous value: -"Limits, e.g. \"Don't agree to anything over $200\" or \"Only Saturday mornings\""New value: +"As in place_call"
    • changedInput schema / properties / details / description
      Previous value: -"Facts the assistant may share when asked: names, account or order numbers, the car, dates, preferences, budget. Never card numbers, SSNs or passwords."New value: +"As in place_call"
    • changedInput schema / properties / goal / description
      Previous value: -"What the call should get done and what counts as done, 1-3 plain sentences, e.g. \"Book a table for 4 this Friday between 7 and 8:30pm and get a confirmation number.\""New value: +"As in place_call"
    • changedInput schema / properties / if_asked / description
      Previous value: -"Pre-approved answers so the business doesn't wait on you, e.g. \"If they offer another time, anything 7 to 8:30pm is fine. A deposit up to $25 is OK.\""New value: +"As in place_call"
    • changedInput schema / properties / language / description
      Previous value: -"Language to open in (e.g. \"Vietnamese\", \"Korean\"). Default English, and the assistant switches to Spanish by itself if they answer in Spanish. Pass it when the business likely speaks another language (a Vietnamese nail salon, a Korean market), since other languages are only understood when set up front."New value: +"As in place_call"
    • changedInput schema / properties / max_cost_usd / description
      Previous value: -"Most this call may cost, e.g. 3 = about 7 minutes. The call ends by itself at that point, so a long hold can't run up the bill. Minimum $1. Omit for the normal 30-minute cap."New value: +"As in place_call"
    • changedInput schema / properties / on_behalf_of / description
      Previous value: -"The user's name, as the business should hear it. For a work call, add the company (\"Sam at Ridgeline Print Co\"): suppliers and vendors look accounts up by company. Just a name: it's said in the first sentence (\"calling for <this>\"), so account numbers or descriptions of the order go in details"New value: +"As in place_call"
    • changedInput schema / properties / phone / description
      Previous value: -"The business's phone number, US, any format, e.g. \"(469) 770-7412\""New value: +"As in place_call"
    • changedInput schema / properties / questions / description
      Previous value: -"Specific things to find out, one per item. Each comes back in answers, in this order, e.g. [\"How much is a large pepperoni?\", \"Is there parking?\"]"New value: +"As in place_call"
    • changedInput schema / properties / transfer_to / description
      Previous value: -"The user's own phone. If set and the goal says to connect them, the assistant patches them in once a person answers (after menus and hold). Best for banks, carriers and insurers that verify the account holder."New value: +"As in place_call"
    • changedInput schema / properties / voicemail_message / description
      Previous value: -"Message to leave on voicemail. Omit to hang up on voicemail (free when it goes straight to voicemail)."New value: +"As in place_call"
  3. Changed1 schema field changed
    • changedInput schema / properties / on_behalf_of / description
      Previous value: -"The user's name, as the business should hear it. For a work call, add the company (\"Sam at Ridgeline Print Co\"): suppliers and vendors look accounts up by company"New value: +"The user's name, as the business should hear it. For a work call, add the company (\"Sam at Ridgeline Print Co\"): suppliers and vendors look accounts up by company. Just a name: it's said in the first sentence (\"calling for <this>\"), so account numbers or descriptions of the order go in details"
  4. Changed1 schema field changed
    • addedInput schema / properties / max_cost_usd
      Added value: +{
      +  "description": "Most this call may cost, e.g. 3 = about 7 minutes. The call ends by itself at that point, so a long hold can't run up the bill. Minimum $1. Omit for the normal 30-minute cap.",
      +  "type": "number"
      +}
  5. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the annotations, which already declare readOnly/idempotent/non-destructive: it discloses that the preview is free, requires no account, and surfaces cost, business open status, and tips — exactly the cost/auth/behavioral context the rubric credits. It also warns about downstream consequences ('every gap becomes a live question the business waits on'), which no annotation conveys.

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-loaded with the free-preview framing and the sibling it precedes, then packed with concrete deliverables. It is a single dense sentence heavy with parentheses, which slightly hurts scannability but every clause carries 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?

With 15 parameters and no output schema, the description correctly carries the burden of describing what comes back, enumerating five distinct preview outputs. It is nearly complete, though the semantics of the 13 optional mirrored arguments remain delegated entirely to `place_call`.

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 100%, but every property description is the near-empty 'As in place_call', so the structured data itself carries little meaning. The description does compensate slightly by stating 'Takes the same arguments as place_call' and by flagging that `details`-style gaps must be gathered before calling, but it adds no per-argument semantics — baseline 3 is appropriate.

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 ('Free preview before place_call') and then enumerates exactly what the preview returns: opening line, likely questions, open-now status, tips, and cost. This is unmistakably distinct from the sibling `place_call` and from the other call-management siblings.

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?

Explicitly positions the tool relative to an alternative ('before place_call') and gives a concrete workflow instruction: collect missing details from the user BEFORE calling, because every gap becomes a live question. It lacks an explicit when-not-to-use condition (e.g., skip the preview when nothing is at stake), so it falls short of 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.