CallMCP — Phone Call MCP Server

Set Up Phone System

set_up_phone_system

DestructiveIdempotent

Turn the business's number into a hosted phone system: Kai is installed as extension 700, the owner's mobile joins the list of phones to ring first, and calls reach Kai when nobody picks up. Idempotent and resumable — a re-run reuses everything already created and reports it under reused. Needs a complete US street address on file (the emergency-services and tax location) and the owner's mobile: when either is missing the tool fails with code missing_address or missing_owner_mobile plus required_field and next_action naming exactly what is missing, which business_address or owner_mobile accepts. Returns the status shape (existing setup IDs, extension and the phone-system line) and next_step, the owner's next action in one line (forward your line here / dial 700 from any office phone).

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": "set_up_phone_system"
  }
}

Input Schema

Name	Required	Description
`persona`	No	Which phones the business runs on, if the owner said: cell_only (just the owner's cell) or office (desk phones / an existing office line that will forward in). Shapes next_step; optional.
`business_id`	No	Business ID (required when the token can access multiple businesses).
`owner_mobile`	No	The owner's own mobile number (US). Optional when set_owner_phone already saved one; required when the last attempt returned missing_owner_mobile.
`business_address`	No	The business street address to save before provisioning. Optional when a complete address is already on file; required when the last attempt returned missing_address.

Output Schema

Name	Required	Description
`ids`	No
`code`	No	Present when success is false.
`line`	No	The phone-system line (E.164), if a number is attached.
`error`	No	Present when success is false
`issues`	No	Address fields to correct when code is invalid_address.
`reused`	No
`created`	No
`success`	Yes	Whether the tool completed successfully
`warnings`	No
`next_step`	No	The one line to relay to the owner.
`business_id`	No
`next_action`	No	What to collect and how to retry, when blocked.
`provisioned`	No
`kai_extension`	No
`required_field`	No	Present when setup is blocked on a missing input.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations, the description states what is actually created, that a re-run reuses prior objects and reports them under `reused`, and the exact error contract (code plus required_field plus next_action). It also explains what the returned next_step means for the owner. That is substantive behavioral disclosure, and it is consistent with destructiveHint=true, idempotentHint=true and openWorldHint=true.

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?

It is front-loaded, starting with what the tool does before the failure modes and return shape. It is dense, one long paragraph with several clauses and backticked field names, so it rewards a careful read rather than a skim, but no sentence is filler.

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 multi-parameter nested-object mutation with an output schema, it still covers preconditions, failure codes and recovery, idempotency, and what to tell the owner next. Nothing essential to calling it correctly is missing, and the output schema carries the return details.

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 the baseline is 3, but the description adds real meaning: persona shapes next_step, owner_mobile is optional only when set_owner_phone already saved one, and business_address is required only after a missing_address failure. Those conditionals are not in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The verb-plus-resource is concrete: it turns the business's number into a hosted phone system, installs Kai at extension 700, rings the owner's mobile first, and falls through to Kai. It telegraphs the outcome so an agent can tell it apart from a pure configuration tool. It stops short of naming which sibling to use instead (set_owner_phone, add_team_phone, get_phone_system_status), so it is clear rather than differentiating.

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?

It gives clear context: this is the provisioning step, safe to re-run because it is idempotent and resumable, and the two parameters become required only after a specific failure (missing_address / missing_owner_mobile). It never says explicitly when to skip it (for example, check get_phone_system_status first, or call set_owner_phone separately), so there are no stated exclusions.

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

All CallMCP — Phone Call MCP Server tools Inspect

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.