CallMCP — Phone Call MCP Server

Configure Agent Business Rules

configure_agent_business_rules

DestructiveIdempotent

Safely add or replace a named operational rules section inside an agent inbound prompt, then route the prompt patch through the governed agent.patch broker. It covers cross-business handoffs, callback language, alert promises, and client-specific operating rules, and leaves the rest of the prompt unchanged.

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>",
      "rules": "<rules>"
    },
    "name": "configure_agent_business_rules"
  }
}

Input Schema

Name	Required	Description
`mode`	No	replace (default) swaps the named section for these rules; append adds them to it.
`actor`	No	Do not set. Kept for older clients; the signed-in connection identifies you.
`rules`	Yes	Plain-language operational rules to insert as bullets, e.g. callback capture, sister-location boundaries, urgent alert handling.
`dry_run`	No	Validate and show the prompt patch metadata without writing.
`agent_id`	Yes	KaiCalls agent ID to update
`authority`	No	Do not set. It cannot approve a change: the owner approves through review_url or by being signed in.
`source_ref`	No	External source reference, such as a support ticket or assistant conversation ID.
`business_id`	No	Business ID. Required when the agent has multiple accessible assignments.
`section_title`	No	Prompt section heading to replace/append. Default: Operational handoff rules.
`idempotency_key`	No	Required for writes. A retry with the same key applies the same proposed prompt change only once.
`queue_for_approval`	No	When authority is missing, create a pending dashboard approval instead of returning needs_approval.

Output Schema

Name	Required	Description
`code`	No
`error`	No	Present when success is false
`result`	No
`status`	No
`success`	Yes	Whether the tool completed successfully
`summary`	No
`agent_id`	No
`approval`	No
`request_id`	No
`business_id`	No
`rules_count`	No
`section_title`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 12, 2026

changedInput schema / properties / actor / description

Previous value: -"Who is asking: { type: agent|human|system|integration, id, display_name }."New value: +"Do not set. Kept for older clients; the signed-in connection identifies you."

changedInput schema / properties / authority / description

Previous value: -"Attribution only. Caller-supplied authority cannot authorize live changes; authenticated owner review of the stored request is required."New value: +"Do not set. It cannot approve a change: the owner approves through review_url or by being signed in."

changedInput schema / properties / mode / description

Previous value: -"replace (default) or append."New value: +"replace (default) swaps the named section for these rules; append adds them to it."

addedInput schema / properties / mode / enum

Added value: +[
+  "replace",
+  "append"
+]

First observedNov 12, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the risk profile is carried structurally. The description adds genuine context about governance (patch goes through the governed broker) and blast radius (only the named section changes), but it does not disclose that 'replace' destroys the prior section contents, instead leaning on the word 'Safely' — a softening rather than a contradiction of the destructive annotation.

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?

Two sentences, front-loaded with the action and the mechanism, with no padding. The clause enumerating rule categories is slightly listy but earns its place by telling the agent what content belongs in the section.

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?

An output schema exists and the 11-parameter schema documents the approval, idempotency and targeting mechanics, so the description only needs to frame the action and its blast radius, which it does. The one gap is that the approval path (review_url / signed-in owner) is referenced only indirectly via 'governed', leaving the agent to infer it from parameter docs.

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 100%, including the replace/append enum, the 'do not set' actor/authority fields, the required idempotency key, and the approval-routing flag, so the schema does the heavy lifting. The description's rule examples duplicate what the rules parameter already says and add no new meaning about mode defaults, section_title behavior, or dry_run output.

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?

States a specific verb and resource: add or replace a named operational rules section inside an agent inbound prompt, with the mutation routed through the agent.patch broker. The scope statement ('leaves the rest of the prompt unchanged') implicitly separates it from a full config update, but it never names the adjacent siblings (update_agent_config, request_agent_update) that an agent would otherwise have to choose between.

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

Usage Guidelines3/5

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

Usage is only implied by the content list (cross-business handoffs, callback language, alert promises, client-specific rules) and by the 'rest of the prompt unchanged' framing. There is no explicit 'use this instead of update_agent_config when X', no precondition about required business_id for multi-assignment agents, and no statement of when a section should be created versus replaced beyond the schema enum.

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.