CallMCP — Phone Call MCP Server

Connect External Agent

connect_agent

DestructiveIdempotent

Connect an external agent to a business and its signed event outbox. Requires current business admin membership, an assigned Kai agent, and agents:write, sms:write, webhooks:write. New SMS/WhatsApp conversations route to the external agent; explicit handoffs win. Grants no additional permissions and does not activate unregistered channels. Use a stable idempotency_key; replacements require expected_revision. The signing secret is returned only for a non-replayed connect. External realtime voice and email execution are not connected by this operation.

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": {
      "agent_id": "<agent_id>",
      "external_agent_id": "<external_agent_id>",
      "webhook_url": "<webhook_url>",
      "idempotency_key": "<idempotency_key>"
    },
    "name": "connect_agent"
  }
}

Input Schema

Name	Required	Description
`a2a_url`	No	Optional existing native A2A endpoint; requires a2a_enabled. Omit to use the signed event receiver.
`agent_id`	Yes
`a2a_enabled`	No	Route public A2A message/send to the signed receiver, which must return a JSON-RPC A2A message. SDK handleA2ARequest/handle_a2a_request connects the receiver to your own agent.
`business_id`	No
`webhook_url`	Yes
`idempotency_key`	Yes	Required in the body or Idempotency-Key header.
`expected_revision`	No
`external_agent_id`	Yes
`external_reply_timeout_seconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing auth membership requirements, exact permission scopes, that the operation grants no additional permissions, that replacements require expected_revision, that a stable idempotency_key should be used, and that the signing secret is returned only for a non-replayed connect. This is precisely the operational context the destructiveHint/openWorldHint flags 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?

Dense but front-loaded: purpose first, then prerequisites, then routing side effects, then idempotency constraints, then exclusions. Every sentence carries information, though the final exclusion sentence is slightly clipped in phrasing ('External realtime voice and email execution are not connected by this operation').

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 destructive, open-world mutation with nine parameters and no output schema, the description covers permissions, idempotency, replacement semantics, and the signficant return value (signing secret). Remaining gaps are per-parameter detail on the four undocumented fields rather than missing behavioral context.

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 only 33%, so the description must compensate; it does explain idempotency_key stability and expected_revision on replacement, which are the highest-risk parameters. But webhook_url, external_agent_id, business_id, and external_reply_timeout_seconds get no meaning from the description, and a2a_url/a2a_enabled rely entirely on the schema text.

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?

Uses a specific verb and resource: 'Connect an external agent to a business and its signed event outbox,' which tells an agent this is an external-agent wiring operation rather than a channel hookup like connect_whatsapp. It does not explicitly name a sibling alternative, so it falls just short of full differentiation.

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?

States concrete prerequisites (business admin membership, assigned Kai agent, agents:write/sms:write/webhooks:write) and routing behavior ('New SMS/WhatsApp conversations route to the external agent; explicit handoffs win'). It also gives scope exclusions ('does not activate unregistered channels', no realtime voice or email execution), though it never names a sibling to use instead for those cases.

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.