CallMCP — Phone Call MCP Server

Find Voices for an Agent

find_voices

Find the three voices that best match a plain description of what the owner wants (for example 'a Southern man who can also speak Spanish' or 'warm older woman, calm'), and get a page link where the owner can play each one in English and Spanish, pick one to switch the agent's voice, and undo within 24 hours. Show the owner the page link; nothing changes until they pick. The link expires in 7 days.

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>",
      "description": "<description>"
    },
    "name": "find_voices"
  }
}

Input Schema

Name	Required	Description
`locale`	No	Optional language hint like "es" when the description does not say.
`agent_id`	Yes	The agent whose voice the owner wants to change.
`business_id`	No	Business ID, needed only when the agent belongs to more than one business.
`description`	Yes	The owner's own words for the voice: gender, accent or region, age, feel, languages.

Output Schema

Name	Required	Description
`error`	No	Present when success is false
`voices`	No
`success`	Yes	Whether the tool completed successfully
`page_url`	No
`expires_at`	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 declare readOnlyHint=false and idempotentHint=false, which alone would leave the agent unsure what side effects to expect. The description fills that gap: it returns exactly three candidates plus a preview page, no change occurs until the owner selects, the switch is undoable for 24 hours, and the link expires in 7 days. That is substantial behavioral context beyond the 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core capability is front-loaded in the first clause, followed by the operational consequences in a logical order (show link, no change, undo window, expiry). Slightly redundant phrasing around 'page link' appears twice, but no sentence is expendable.

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?

With an output schema present, return values need not be explained, and the annotations and schema cover safety and parameters. The description still supplies everything an agent needs to act correctly: what it returns, what the owner must do, and the timing constraints on undo and link expiry.

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, but the description adds real meaning by illustrating what belongs in 'description' — gender, accent or region, age, feel, languages, phrased in the owner's own words. It also implies why 'locale' exists by showing a bilingual example, adding context the schema only states mechanically.

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?

The description opens with a precise verb and resource plus a bound on scope: 'Find the three voices that best match a plain description of what the owner wants.' Concrete example descriptions make the match-by-description semantics unmistakable, which distinguishes it from a plain catalog tool like list_voices.

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?

Usage context is clear: the owner wants to change the agent's voice and cannot express it in structured filters, so they describe it in their own words. It also instructs the agent to surface the page link and states nothing changes until the owner picks. It does not explicitly name a when-not condition or point to list_voices for browsing, so it stops short of full routing guidance.

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.