CallMCP — Phone Call MCP Server

Configure Staff Alerts

configure_staff_alerts

DestructiveIdempotent

Save the business's alert contacts and post-call escalation rules. Read get_operational_settings first: each list you send (notification_phone, notification_email, escalation_rules) replaces the whole saved list, so include the entries to keep. Listed phones get after-call summary texts and escalation texts (one-recipient alerts go to the first phone); listed emails get escalation emails. Saving does not prove delivery.

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

Input Schema

Name	Required	Description
`dry_run`	No	Validate and show the proposed settings without writing.
`business_id`	No	Business ID (optional only when the token has exactly one accessible business)
`escalation_rules`	No	Post-call escalation rules checked against each finished call. Replaces the saved rules. Each rule is { id?, when, then, enabled? }.
`sms_notifications`	No	Enable or disable SMS staff alerts for this business.
`notification_email`	No	Email addresses that get escalation emails. Replaces the saved list. Comma-separated string or array.
`notification_phone`	No	Phones that get alert texts; the first also gets one-recipient alerts. Replaces the saved list. Comma-separated string or array.
`email_notifications`	No	Enable or disable email staff alerts for this business.

Output Schema

Name	Required	Description
`error`	No	Present when success is false
`dry_run`	No
`success`	Yes	Whether the tool completed successfully
`settings`	No
`business_id`	No
`current_settings`	No
`proposed_settings`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 12, 2026

changedInput schema / properties / escalation_rules / description

Previous value: -"Post-call escalation rules evaluated against completed transcripts. Each rule is { id?, when, then, enabled? }. v1 action then includes text_owner."New value: +"Post-call escalation rules checked against each finished call. Replaces the saved rules. Each rule is { id?, when, then, enabled? }."

changedInput schema / properties / escalation_rules / items / properties / then / description

Previous value: -"Action keys. v1 supports text_owner."New value: +"Action keys. text_owner (the only one) texts and emails every alert contact above, not only the owner."

changedInput schema / properties / notification_email / description

Previous value: -"Comma-separated string or array of staff email addresses that receive escalation emails."New value: +"Email addresses that get escalation emails. Replaces the saved list. Comma-separated string or array."

changedInput schema / properties / notification_phone / description

Previous value: -"Comma-separated string or array of staff phone numbers that receive SMS escalation alerts."New value: +"Phones that get alert texts; the first also gets one-recipient alerts. Replaces the saved list. Comma-separated string or array."

First observedNov 12, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds the crucial mechanics: three parameters are full-list replacements rather than merges, which entries receive which alert channel, and that first-phone routing applies to one-recipient alerts. The caveat 'Saving does not prove delivery' is a genuine behavioral disclosure not available in structured fields.

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?

Four dense sentences with the destructive replacement rule front-loaded immediately after the purpose statement, followed by channel routing and a delivery caveat. No filler and no restatement of the title.

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 7-parameter, zero-required mutation tool with an output schema and full annotation coverage, the description supplies everything an agent needs to call it safely: prerequisite read, replacement semantics, recipient routing, and the delivery caveat. Nothing material 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 description coverage is 100%, so baseline is 3; the description earns an extra point by adding cross-parameter meaning the per-field schema cannot express — that notification_phone, notification_email, and escalation_rules are wholesale replacements and must be resent in full. It does not explain the boolean toggles (sms_notifications, email_notifications) or dry_run, but the schema covers those adequately.

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 specific verb and resource — saving alert contacts and post-call escalation rules for a business — and implicitly contrasts with the read path by telling the agent to call get_operational_settings first. An agent can tell exactly what this tool writes 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 Guidelines5/5

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

Gives an explicit prerequisite (read get_operational_settings first) and a concrete usage rule: each list sent replaces the whole saved list, so include entries to keep. It also names the read sibling as the alternative for inspection, leaving nothing about ordering to inference.

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.