CallMCP — Phone Call MCP Server

Get Activation Status

get_activation_status

Read-onlyIdempotent

Read current call readiness and persisted private-test proof for one accessible business. Only a currently entitled owner with a coherent assigned number gets the existing private-test setup link. Missing entitlement, incomplete setup or stale sessions do not authorize a call. It cannot assert or advance proof. A completed private test is separate from customer-route coverage; forwarding is optional and does not define whether the assigned phone works.

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_activation_status"
  }
}

Input Schema

Name	Required	Description
`business_id`	No	Business ID (optional only when the token reaches exactly one business).
`oauth_transaction_id`	No	Opaque OAuth transaction identifier used only to bind a completed receipt.
`activation_session_id`	No	Optional exact session ID. A superseded or foreign session is rejected.
`origin_conversation_id`	No	Opaque client conversation identifier used only to bind a completed receipt.
`receipt_idempotency_key`	No	Client key for replay-safe delivery of a completed activation receipt.

Output Schema

Name	Required	Description
`error`	No	Present when success is false
`proof`	No
`state`	No
`routes`	No
`success`	Yes	Whether the tool completed successfully
`business_id`	No
`next_action`	No
`call_readiness`	No
`activation_receipt`	No
`owner_phone_on_file`	No	Whether the owner's own mobile number is on file for SMS alerts or ring-first. Its absence does not invalidate an email-confirmed private test or require forwarding.
`activation_session_id`	No
`notification_attempts`	No
`command_center_unlocked`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely non-obvious behavior: it discloses that missing entitlement, incomplete setup, or stale sessions do not authorize a call, that the tool 'cannot assert or advance proof', and that a completed private test is independent of customer-route coverage and forwarding. These are semantic result caveats an agent could not obtain from the annotations or schema.

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?

Five front-loaded sentences with no filler; the scope statement comes first and the caveats follow. Density is high and some phrasing ('coherent assigned number', 'persisted private-test proof') costs readability, but each sentence carries distinct information rather than restating the name.

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?

An output schema exists, so return values need not be explained, and the annotations cover the safety profile. The description supplies the authorization preconditions and the interpretation caveats an agent needs; only the sibling differentiation and any hint about what happens when preconditions fail (empty vs. error) are missing.

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% and all five parameters are documented in the schema, including the conditional optionality of business_id and the rejection of superseded/foreign session IDs. The description adds nothing parameter-specific beyond the phrase 'one accessible business', so baseline 3 applies.

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 names a specific verb ('Read') and a specific compound resource: current call readiness plus persisted private-test proof for one business. It is clearly not a generic status or analytics read, but it never names or contrasts with the nearest sibling (check_call_status), so an agent must infer the boundary from the phrase 'activation'.

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 through preconditions ('only a currently entitled owner with a coherent assigned number'), which tells the agent what state the business must be in for a meaningful answer. However, there is no explicit when-to-use/when-not-to-use statement and no routing to alternatives like check_call_status or get_business_info, which is the main gap for a status-reading tool sitting among several status readers.

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.