Skip to main content
Glama

Set up how calls are answered

phone_setup_assistant
Idempotent

Choose how the business's numbers are answered; Conecto hears and speaks, you are the brain. answer_with webhook: each thing a caller says is POSTed to webhook_url (signed with the webhook_secret returned once: X-Conecto-Signature is sha256= the HMAC of the body) with the conversation so far, and you answer {"say": "...", "end_call": false} within about 2.5 seconds (the caller hears "one moment" after that; after 8 seconds the line takes a message instead). answer_with messages: the line takes the caller's message. Either way the whole call reaches you afterwards as a phone.message_left or phone.call_ended event. Only the fields you pass change; the first time pass greeting and timezone. Answered calls cost $0.25 per started minute; each call holds max_call_minutes × $0.25 while it runs. Costs $0.001 per call; nothing if it fails.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "phone_setup_assistant"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoThe line's name.
hoursNoWhen to answer, in the timezone; empty answers around the clock. Outside these hours callers get a busy signal.
voiceNoA voice id or name from phone_get_assistant.
greetingNoWhat callers hear right after Conecto's short notice, in the line's language, that the AI call is recorded and transcribed. It must say they reached an automated line or an AI, e.g. "Hi, you've reached Acme. This is our automated line: how can we help?" Taking messages, ask for their message, name and number.
languageNoThe language it speaks.
timezoneNoIANA time zone of the business, e.g. America/New_York. Needed the first time.
answeringNofalse pauses answering; true resumes it.
answer_withNomessages (the default) or webhook.
cant_answerNoWhat the line says when your webhook did not answer in time.
message_ackNoTaking a message: what the line says after each thing the caller says.
webhook_urlNoYour https endpoint for each turn.
open_ticketsNomessages: each message left opens a help desk ticket with the transcript (or joins the open one the caller has); calls: every call the caller spoke on. $0.01 per ticket opened. Default off.
rotate_secretNoMake a new webhook_secret (the old one stops working).
max_call_minutesNoCalls end after this long (default 5).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Far exceeds the annotations: discloses the webhook contract (X-Conecto-Signature = sha256 HMAC of body), the ~2.5s reply deadline, the 'one moment' fallback, the 8s message-taking cutoff, the post-call phone.message_left/phone.call_ended events, partial-update semantics, and exact billing ($0.25/started minute, max_call_minutes hold, $0.001 per failed-free call). Consistent with idempotentHint=true, destructiveHint=false — no contradiction.

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?

Purpose and mode choice are front-loaded, and nearly every clause carries load-bearing facts (timings, signature scheme, costs). The second half is a long run-on chain of parentheticals that would read faster as short sentences, but nothing is padding.

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 14-parameter, no-required, no-output-schema configuration tool, the description covers the decisions an agent cannot infer: mode selection, secret handling, timeout behavior, event delivery, and cost exposure. Remaining parameters are fully documented in the schema.

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 a 3 is the floor; the description earns more by explaining answer_with's two modes and the webhook_url contract in prose that the schema only names. It leaves rotate_secret, open_tickets, cant_answer, and message_ack to their schema text, which is adequate but not enriched.

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 ('Choose how the business's numbers are answered') and immediately names the two operating modes, answer_with webhook vs messages. An agent can tell this configures call answering, distinct from phone_get_assistant (read) or phone_list_calls (history).

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 real guidance: when to pick webhook (you respond per turn) vs messages (line takes a message), and 'the first time pass greeting and timezone' plus 'only the fields you pass change' for incremental updates. It stops short of explicitly routing to sibling tools such as phone_get_assistant for reading current config or phone_list_numbers for assigning numbers.

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