CallMCP — Phone Call MCP Server

Start Own Caller ID

start_own_caller_id

Let Kai's outbound calls show a number the person already owns (their cell or an old main line) instead of a KaiCalls line, so people recognize who is calling. A verification call goes to that number and returns a code; the person answers and types the code on the keypad. Then get_own_caller_id confirms it. Ownership is proven only by that call. US and Canada numbers. Business owner only. Charges nothing. Callbacks to the shown number reach that phone, not Kai. use_by_default (default true) shows it on every call unless make_call asks for caller_id 'business_line'. Starting a new number replaces the old one.

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

Input Schema

Name	Required	Description
`business_id`	No
`phone_number`	Yes	The number to show, e.g. +19085551234. It must ring a phone the person can answer.
`use_by_default`	No	Show it on every call unless a call asks otherwise (optional, default true).

Output Schema

Name	Required	Description
`error`	No	Present when success is false
`charged`	No
`success`	Yes	Whether the tool completed successfully
`own_caller_id`	No
`validation_code`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 12, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well past the annotations: it explains the two-step verification flow (call placed, code typed on keypad), that the operation is free, that callbacks to the shown number ring that phone rather than Kai, that starting a new number replaces the previous one, and how use_by_default propagates to future calls. The annotations already mark it non-readOnly and openWorld, and the description reinforces the external side effect without contradicting it.

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?

Front-loads the purpose and is packed with useful detail, but the middle section mixes flow, eligibility, cost, and defaults in a run of short declaratives, including a sentence beginning with the lowercase parameter name. Nearly every clause earns its place; light restructuring would help scanning.

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 non-idempotent, externally-visible setup operation, the description covers the flow, prerequisites, cost, defaults, replacement behavior, and callback routing, and an output schema exists so return values need no explanation. An agent has everything needed to call it and set expectations.

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?

Adds real meaning beyond the 67%-covered schema: use_by_default's default and its downstream interaction with make_call's caller_id override, plus the constraint that phone_number must ring a phone the person can actually answer. business_id is left unexplained apart from the 'business owner only' eligibility note.

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 concrete verb and resource — make outbound calls display a number the person already owns rather than a KaiCalls line — and distinguishes it from the branded-line path by emphasizing ownership. The follow-up relationship to get_own_caller_id and the replacement semantics of a new number are stated outright.

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 clear preconditions (US/Canada numbers, business owner only) and the operational prerequisite that ownership is proven only by the verification call answered on that phone. It also notes the make_call interaction where caller_id 'business_line' overrides use_by_default, though it never states when to prefer set_branded_caller_id or attach_own_twilio_number instead.

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.