Skip to main content
Glama

Latchbell

Have my AI agent call someone

place_phone_call

Owners only (needs sign-in): When the owner asks (or, on an agent's own line, when the agent needs to), the business’s AI agent phones a US number from the business’s Latchbell number (or, with a country code like +44, any number the business’s paired Android phone can call, from that phone), says it is the business’s AI assistant, and does what purpose says. Write purpose as its full brief: who it calls and for whom, the goal and what counts as done, what it may share or agree to, what to do on voicemail or if they can't help, and any tone or language; never secrets or card numbers. Only people and businesses there is a real reason to call: never marketing, sales, surveys or robocalls. Calls are recorded. At most 3 calls a day to one number, up to 10 minutes each from the plan’s call minutes. Returns call_id while the phone rings; follow it with phone_call. A request repeated within 10 minutes returns the first call. Details: https://latchbell.com/docs/phone.md.

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": {
      "to": "<to>",
      "purpose": "<purpose>"
    },
    "name": "place_phone_call"
  }
}

Input Schema

NameRequiredDescriptionDefault
toYesThe phone number to call: a US one, or one with its country code (+44 …) through the paired Android phone
purposeYesInstructions for the AI agent: who it calls, why, what to say or find out

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the annotations: requires owner sign-in, discloses that calls are recorded, states the agent self-identifies as an AI assistant, and caps usage at 3 calls/day per number and 10 minutes per call drawn from plan minutes. It also states the idempotency behavior (a repeat within 10 minutes returns the first call) and that a call_id comes back while ringing. Slightly short of 5 only because it doesn't say what happens when the daily cap or minute budget is hit.

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 gate ('Owners only (needs sign-in)') and every clause carries operational content, including the docs link. However it is delivered as one dense sentence with stacked parentheticals, which makes the routing rule and the purpose-brief checklist harder to scan than they need to be.

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 side-effecting outbound-call tool with an open-world hint and no output schema, the description covers the return value (call_id while ringing), the follow-up tool, rate and duration limits, recording, and identity disclosure. An agent has everything needed to call it correctly and safely without guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: `purpose` must be a full brief covering who is called and for whom, the goal, what counts as done, what may be shared or agreed to, voicemail fallback, and tone/language, with an explicit prohibition on secrets and card numbers. It also clarifies the `to` routing distinction (US vs. country-code via the paired phone) beyond the schema's summary.

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 ('the business's AI agent phones a US number from the business's Latchbell number') plus an explicit scope boundary (US numbers by default, any country-code number via the paired Android phone). It also distinguishes itself from the follow-up sibling by naming phone_call as the next step, so an agent can pick it apart from phone_call and call_brief without opening a 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 trigger conditions ('when the owner asks', or on an agent's own line 'when the agent needs to') and explicit exclusions ('never marketing, sales, surveys or robocalls'; 'Only people and businesses there is a real reason to call'). It also names the natural next tool (phone_call) and the deduplication rule for repeated requests.

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.

Resources