CallMCP — Phone Call MCP Server

Set Branded Caller ID

set_branded_caller_id

Idempotent

File the business name that landlines show when the business's number calls out (caller ID name). Included with the business's own text registration once it is paid; charges nothing. Business owner only. The name must be at most 15 characters, start with a letter, and use only letters, numbers, periods, commas and spaces (get_text_registration returns a suggestion in branded_caller_id.suggestedName). Files with the carriers once the business profile is approved; review then takes a day or two and carriers show it within 72 hours. US local numbers only. The result confirms the filing, not that the name is showing on calls.

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>",
      "display_name": "<display_name>"
    },
    "name": "set_branded_caller_id"
  }
}

Input Schema

Name	Required	Description	Default
`business_id`	Yes
`display_name`	Yes	Up to 15 characters, e.g. SUMMIT ROOFING.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare a non-read-only, non-destructive, idempotent, open-world write, and the description adds substantially more: owner-only authorization, zero cost, dependence on an approved business profile, 1-2 day review plus 72-hour carrier propagation, and the crucial caveat that success confirms filing rather than live display. That is exactly the behavioral context annotations cannot convey.

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?

Leads with the purpose, then layers eligibility, format rules, cost, timing, and scope in a compact block with no filler. Sentences are dense but each carries information; a slight tightening of the multi-clause timing sentence would make it a 5.

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?

Despite an output schema existing, the description still clarifies what the result means (filing confirmation, not live display), which is the one thing the output schema cannot settle on its own. Combined with prerequisites, format constraints, US-local-only scope, and propagation timing, nothing an agent needs to call this correctly is missing.

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 coverage is 50%, with business_id undocumented, so the description does real work by spelling out the display_name rules (max 15 characters, must start with a letter, only letters/numbers/periods/commas/spaces) - a superset of the terse schema hint. It does not, however, shed any light on the business_id parameter.

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?

Names a concrete verb and resource: filing the caller-ID name (CNAM) that landlines display when the business calls out. This is sharply distinguishable from the other 'set_*' configuration tools in the sibling list, and an agent can identify the operation without opening the schema.

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 eligibility and timing context: it is included with a paid text registration, costs nothing, and is restricted to the business owner. It also points at get_text_registration for a suggested name, which routes the agent to a prerequisite sibling, though it stops short of explicitly stating when not to use this tool.

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.