Dial by Aloha Labs

set_call_answering

Set how the AI answers when someone calls your number. It always says it's an AI assistant and takes a message; these settings personalize it.

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": {
      "api_key": "<api_key>",
      "number_id": "<number_id>"
    },
    "name": "set_call_answering"
  }
}

Input Schema

Name	Required	Description
`voice`	No	Voice persona from list_voices, e.g. 'brian'
`api_key`	Yes	Your Dial API key (from sign_up)
`number_id`	Yes	id of your number
`owner_name`	No	Your human's name, e.g. 'Berk'. The greeting says '<assistant>, <owner>'s AI assistant'
`instructions`	No	Extra guidance, e.g. 'If it's about the Capri booking, ask for their confirmation number.'
`assistant_name`	No	Your own first name, e.g. 'Lloyd'

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 29, 2026

TDQS

B3.4/5.0

Behavior3/5

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

No annotations exist, so the description carries the full burden. It usefully discloses the baseline answering behavior (always identifies as an AI assistant, takes a message) that the settings personalize, which is real value beyond the schema. However, it omits whether this call replaces existing settings wholesale or merges partial fields, and says nothing about permissions or the response.

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 short sentences with zero filler, and the fixed-versus-customizable distinction is front-loaded. It is perhaps slightly under-specified rather than over-long, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter mutation tool with no annotations and no output schema, the description explains the concept but leaves key operational questions open: whether omitted fields are preserved or reset, and what a successful response looks like. The rich schema compensates for parameter detail, but the update semantics gap is notable.

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%, so all six parameters are already well documented with examples and constraints; the baseline is 3. The description adds no parameter-level detail beyond the vague framing 'these settings personalize it,' so it does not exceed the schema.

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 ('Set how the AI answers when someone calls your number') and immediately clarifies the fixed behavior versus the customizable part. An agent can distinguish it from list_voices or make_phone_call, though it never names those siblings explicitly.

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: an agent infers this is the configuration call for an already-provisioned number, but there is no explicit when-to-use guidance, no mention that list_voices should be called first to pick a valid voice persona, and no note about prerequisites like owning the number.

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

All Dial by Aloha Labs 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.

Resources

Need Help?