CallForMe

Call the same business again

redial

Destructive

Call the same business again with the same request, plus any changes: a missing detail, a new question, another day. Use after a call ended busy, unanswered, in voicemail, or with unanswered_questions, or when the user says "call them back and ask...". The assistant is told which phone-menu options the earlier call used and where they led, so it tries a different route to a person (any call to a number this account called in the last 24 hours gets the same). changes holds only the fields to replace. Same pricing and rules as place_call (it can also return needs_setup).

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": {
      "call_id": "<call_id>"
    },
    "name": "redial"
  }
}

Input Schema

Name	Required	Description
`call_id`	Yes	The earlier call's call_id
`changes`	No	Only the fields to change; everything else (and the number) stays the same as the original call.
`account_key`	No	Only for clients without OAuth: the cfm_ API key (from the account page or an earlier setup). Leave out when connected with OAuth.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the destructive/openWorld annotations: it discloses that the agent is told which phone-menu options the earlier call used and deliberately routes differently, that any call to the number in the last 24 hours shares that routing memory, that changes is a partial replacement, and that needs_setup can be returned. This is real behavioral context an agent cannot infer from annotations.

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?

Front-loaded with the action and the trigger conditions, then the routing and pricing caveats. Slightly dense in the middle ('The assistant is told which phone-menu options...'), but nearly every sentence carries non-redundant information.

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?

Covered end-to-end for a nested-object tool with no output schema: preconditions, merge semantics, routing behavior, pricing inheritance, and a known return signal (needs_setup). Minor gap: it doesn't say where call_id comes from (list_calls/get_call) for recovery after a failure.

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 100%, so the baseline is 3; the description earns extra by clarifying that 'changes holds only the fields to replace' and that everything else including the number stays as in the original call — the key merge-semantics fact the schema only states once in prose.

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 ('Call the same business again with the same request, plus any changes') and immediately scopes what 'changes' means. It is clearly distinguishable from place_call (fresh call) and call_around (multiple businesses) without needing their schemas.

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?

Explicit trigger conditions are enumerated: after busy, unanswered, voicemail, or unanswered_questions outcomes, or when the user says 'call them back and ask...'. It also names the baseline tool ('Same pricing and rules as place_call'), giving the agent a clear alternative reference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All CallForMe 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.