CallMCP — Phone Call MCP Server

Get Phone System Status

get_phone_system_status

Read-onlyIdempotent

Read saved phone-system configuration: extension, resource IDs (never secrets), assigned line, and agreement. phone_system_configuration.configuration_allows_calls means provisioned resources plus a permitting agreement only; it does not verify calls can connect. ready_for_calls is null because operational availability is unknown. private_test_readiness uses the existing owner-private call setup authority only with agents:read; otherwise not_checked. Customer coverage and outbound call permission remain not_checked. This read differs from the shared phone-system API configuration flag and changes nothing.

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

Input Schema

Name	Required	Description	Default
`business_id`	No	Business ID (required when the token can access multiple businesses).

Output Schema

Name	Required	Description
`ids`	No
`line`	No
`error`	No	Present when success is false
`success`	Yes	Whether the tool completed successfully
`next_step`	No
`business_id`	No
`provisioned`	No
`kai_extension`	No
`provisioned_at`	No
`ready_for_calls`	No
`customer_coverage`	No
`private_test_readiness`	No
`outbound_call_permission`	No
`phone_system_configuration`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive/closed-world, yet the description adds real behavioral context: secrets are never returned, private_test_readiness depends on the agents:read scope (otherwise not_checked), ready_for_calls is null by design, and the call is guaranteed not to mutate anything. It does not cover error behavior or what happens without sufficient scope beyond the not_checked fallback.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose statement is front-loaded and useful, but the remainder is a dense block of internal field semantics (not_checked variants, null rationale) with heavy jargon and no structure, and much of it restates what the existing output schema already conveys. Nothing is off-topic, but the density raises reading cost for an agent scanning tools.

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?

Given a one-parameter read with annotations and an output schema, the definition supplies purpose, auth gating, and interpretation of ambiguous fields, which is enough to call it correctly. The only gap is absent routing versus the many other status tools, which is a guidance rather than a completeness issue.

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?

The single business_id parameter is fully documented in the schema (100% coverage), and the description adds nothing about it. This is the baseline case where the schema carries parameter semantics and the description neither compensates nor detracts.

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 description opens with a specific verb and resource ("Read saved phone-system configuration") and enumerates what it returns (extension, resource IDs, assigned line, agreement). It distinguishes this read from the "shared phone-system API configuration flag" and states "changes nothing", but never names a sibling status tool (e.g. get_activation_status) it is not, so sibling differentiation is only implied.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by "Read saved phone-system configuration" and by the caveats that configuration_allows_calls "does not verify calls can connect" and coverage/permission remain not_checked, which steers an agent away from using it as a live-connectivity check. However, with many near-identical status siblings in the catalog, there is no explicit when-to-use/when-not or alternative routing guidance.

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.