Skip to main content
Glama
ingalgi-krishna

Dunefox Voice MCP Server

Place an AI agent call right now

place_call

Dial a real conversational outbound call from your workspace number; enforces do-not-call, calling hours, wallet balance, and concurrency gates and returns refusal codes. Requires dial scope.

Instructions

Starts a real conversational call from this workspace's own number. Behind the same gates as the dashboard: the do-not-call list, calling hours, wallet balance and concurrency. A refusal carries a code (suppressed, outside_hours, wallet_low, ...) to branch on. Needs the "dial" scope, which no key holds by default. For a fixed script with no listening (an order update, a reminder), use send_announcement instead - it is far cheaper.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesE.164, e.g. +919876543210.
leadIdNo
agentIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare openWorldHint and idempotentHint; the description adds substantial context beyond them: the specific gates enforced (do-not-call list, calling hours, wallet balance, concurrency), the refusal-code branching surface (suppressed, outside_hours, wallet_low), and the non-default 'dial' scope requirement. This is exactly the behavioral disclosure annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Four sentences, each earning its place: what it does, the gating behavior, the error surface, and the routing alternative. The critical scope prerequisite and the cheaper sibling are front-loaded rather than buried.

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?

With no output schema, the description usefully explains the refusal-code return surface, and it covers gating and auth. The one gap is parameter meaning for leadId/agentId, which neither the schema nor the description explains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 33% — 'to' is documented as E.164, but leadId and agentId have no schema description. The description mentions none of the parameters, so it fails to compensate for the coverage gap; an agent gets no guidance on what agentId or leadId must reference.

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 ('Starts a real conversational call from this workspace's own number') and immediately distinguishes itself from the sibling send_announcement by contrasting listening conversation vs fixed script. An agent can differentiate this from send_announcement without opening either schema.

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?

Names the alternative explicitly ('For a fixed script with no listening... use send_announcement instead - it is far cheaper') with the condition that selects it. It also states the prerequisites (dial scope, gates) that gate a successful call, leaving nothing to inference.

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