CallMCP — Phone Call MCP Server

Set up CallRail

manage_callrail

DestructiveIdempotent

Connect CallRail call tracking to a business's line. Order: (1) connect {api_key, account_id?}; (2) get_callrail status lists the companies the key can see; (3) link_company {company_id, target_business_id?} once per business; (4) set_writeback {enabled}; (5) get_callrail list_trackers; (6) route_tracker only after the owner says yes. The API key: the person may paste their CallRail API v3 key straight into this chat. Take it and pass it as api_key; do not send them elsewhere to paste it. KaiCalls stores it encrypted and never returns it. One agency-level key serves every company that CallRail login can see, so connect once and link each firm with its own link_company. They create the key in CallRail under Integrations > API Keys > Create API V3 Key, signed in as a login that can see every company to link. CallRail shows the key only once. If they would rather paste it themselves: https://www.kaicalls.com/dashboard/settings/connections?connector=callrail. If connect answers choose_account, call it again with one of the returned account ids. link_company subscribes that CallRail company's calls: calls Kai answers get the CallRail source, campaign, keyword and landing page, and Kai's outcome is written back to CallRail as a KaiCalls tag, a summary note and good_lead when Kai qualified the caller. route_tracker {link_id, tracker_id, mode} changes where a live tracking number rings: mode kai_answers sends every call to Kai; business_first sends it to a KaiCalls line that rings the owner first so Kai takes only the misses. restore_tracker puts the earlier destination back. Leaving numbers unrouted is tracking-only. unlink_company {link_id}; disconnect. Requires current admin role on every business involved. Changing a tracker changes a live phone line: confirm with the owner first.

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": {
      "business_id": "<business_id>",
      "action": "<action>"
    },
    "name": "manage_callrail"
  }
}

Input Schema

Name	Required	Description
`mode`	No
`action`	Yes
`api_key`	No	CallRail API v3 key, as the person pasted it in chat. Stored encrypted; never returned.
`enabled`	No
`link_id`	No
`account_id`	No	Only when connect answered choose_account: one of the account ids it listed.
`company_id`	No	A company id from get_callrail status (companies[].id).
`kai_number`	No
`tracker_id`	No
`business_id`	Yes
`target_business_id`	No

Output Schema

Name	Required	Description	Default
`error`	No
`success`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 12, 2026

addedInput schema / properties / account_id / description

Added value: +"Only when connect answered choose_account: one of the account ids it listed."

addedInput schema / properties / api_key / description

Added value: +"CallRail API v3 key, as the person pasted it in chat. Stored encrypted; never returned."

addedInput schema / properties / company_id / description

Added value: +"A company id from get_callrail status (companies[].id)."

First observedNov 12, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and openWorldHint=true, but the description adds substantive context beyond them: the API key is stored encrypted and never returned, CallRail shows it only once, one agency-level key serves every visible company, link_company writes Kai outcomes back as a tag/note/good_lead, and routing changes affect a live phone line. That is exactly the behavioral disclosure a mutation tool needs.

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?

The numbered sequence is front-loaded and most sentences carry operational weight (key creation path, choose_account retry, mode semantics, confirmation rule). It is dense and runs long, with the key-handling and dashboard-URL material adding bulk, but nothing is plainly redundant.

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?

For a seven-action, eleven-parameter mutation tool the description covers workflow order, prerequisites, error branching, and safety confirmation, and an output schema exists so return values needn't be spelled out. Gaps remain around kai_number's role, what set_writeback toggles precisely, and whether disconnect deletes stored links.

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 description coverage is low (27%) across 11 parameters, so the description has to compensate, and it largely does: it explains api_key handling, account_id (only after choose_account), company_id (from get_callrail status), link_id, tracker_id, mode's two enum values, and enabled for set_writeback. kai_number and the business_id requirement are only implied, which keeps it short of a 5.

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?

Opens with a specific verb and resource ("Connect CallRail call tracking to a business's line") and then enumerates the seven actions it bundles (connect, link_company, route_tracker, etc.), while pointing at get_callrail for the read-only status/list side. The scope is a bit wider than "connect" (it also mutates live routing and can disconnect), but an agent can still tell what this tool is for versus its sibling.

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

Usage Guidelines5/5

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

Gives an explicit numbered order of operations and the conditions that gate each step: route_tracker only after the owner says yes, connect called again with an account id if it answers choose_account, link_company once per business, restore_tracker to revert, and leaving numbers unrouted means tracking-only. It also states the admin-role prerequisite and the confirm-with-owner rule before changing a live line.

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.