CallMCP — Phone Call MCP Server

Buy Phone Number

buy_number

DestructiveIdempotent

Request a real phone-number purchase. This is APPROVAL-GATED: the carrier bills immediately on execution, so the tool only prepares a request for authenticated owner review. Caller-supplied human_confirmed, dashboard_session, or system_policy fields never authorize execution. Returns the stored request and a review URL for the owner; while approval is pending, no number has been purchased. Existing entitlement and carrier reservation checks still apply. In the acquisition flow this follows set_owner_phone, which saves a reachable owner number or records a decline.

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_number": "<phone_number>"
    },
    "name": "buy_number"
  }
}

Input Schema

Name	Required	Description
`actor`	No	Who is asking: { type: agent\|human\|system\|integration, id, display_name }.
`reason`	No	Optional reason recorded in the durable audit.
`dry_run`	No	Validate tenant, scope, and policy without buying anything.
`agent_id`	No	Agent ID to route this number to directly once purchased (optional; requires the number to also be voice-runtime-imported, which is not guaranteed at purchase time — a follow-up attach_number call routes it reliably).
`authority`	No	Attribution only. human_confirmed and other caller-supplied modes cannot authorize a purchase. Authenticated owner review of the exact stored request is required.
`source_ref`	No	External source reference, such as a ticket or automation run ID.
`business_id`	No	Business ID (optional only when the token can access exactly one business).
`phone_number`	Yes	The exact E.164 phone number to purchase, as returned by search_available_numbers.
`idempotency_key`	No	Stable key for the purchase request; repeating it returns the original outcome. Defaults to a key derived from the phone number — a new key retries a previously failed purchase.
`queue_for_approval`	No	Create a durable owner-review request (default true). Setting false returns needs_approval, but an authority-envelope retry still cannot execute.

Output Schema

Name	Required	Description
`code`	No
`error`	No	Present when success is false
`result`	No	On executed: { number, voice_agent_registered, agent_attached, compliance: { high_risk_category, disclosure_note } }.
`status`	No
`message`	No
`success`	Yes	Whether the tool completed successfully
`summary`	No
`approval`	No
`request_id`	No
`risk_level`	No
`business_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 12, 2026

changedOutput schema / properties / result / description

Previous value: -"On executed: { number, vapi_registered, agent_attached, compliance: { high_risk_category, disclosure_note } }."New value: +"On executed: { number, voice_agent_registered, agent_attached, compliance: { high_risk_category, disclosure_note } }."

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, it discloses important behavior: the carrier bills immediately on execution, the tool only prepares a request for authenticated owner review, caller-supplied human_confirmed/dashboard_session/system_policy fields never authorize execution, and no number is purchased while approval is pending. It also notes the stored request and review URL, existing entitlement and carrier reservation checks, and placement after set_owner_phone.

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

Conciseness5/5

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

The description is front-loaded with purpose and the approval-gated constraint, and each sentence adds operational context such as billing, authorization, return behavior, checks, and sequencing. It is dense but not padded; every sentence earns its place.

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 10-parameter, high-complexity purchase tool with an output schema and rich annotations, the definition supplies the critical behavioral context around approval, billing, authorization, and pending-purchase state. Parameter details are fully covered by the schema, so the description is complete enough for an agent to invoke the tool correctly.

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 description coverage is 100%, so the schema already documents all 10 parameters, including idempotency_key, dry_run, queue_for_approval, and authority. The description adds useful meaning about authority fields not authorizing execution, but it does not provide much additional parameter-level syntax or format detail beyond the schema baseline.

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 first sentence names a specific verb and resource ('Request a real phone-number purchase') and immediately clarifies that this is a request, not an immediate purchase. It also places the tool after set_owner_phone in the acquisition flow, but it does not explicitly distinguish this from sibling purchase-request tools such as request_number_purchase.

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?

The description gives clear usage context: this follows set_owner_phone in the acquisition flow and is approval-gated. It also states that caller-supplied authorization fields never authorize execution. However, it does not explain when to choose dry_run or how this differs from other number-purchase request tools, so it stops short of full when/when-not/alternative 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.