calls_wait
Block until a voice call ends (status changes from 'active') or timeout elapses. Returns ended=true with final state when the call has ended; ended=false on timeout (re-issue to keep waiting). The returned state includes outcome so callers can branch on pickup vs. no-answer (answered/no_answer/bu...
This record as markdown: /tools/io-github-saloprj-dialogbrain/calls-wait.md
What calls_wait does on Dialogbrain
AI agents invoke calls_wait to trigger actions in Dialogbrain. What it does depends on the arguments the agent supplies, and its effects often reach beyond the immediate call: builds kicked off, notifications sent, workflows started.
| Parameter | Type | Required | Description |
|---|---|---|---|
call_id | string | Yes | Call ID returned by calls.make in _meta.call_id. |
timeout_seconds | integer | — | Max seconds to wait. Default 90, cap 110 (bounded below nginx 120s proxy_read_timeout). On expiry returns ended=False with status='active' so the caller can re- |
Parameters from the server's own tool schema.
Why calls_wait is rated High
This tool executes a blocking operation on an external system (voice call infrastructure) and monitors state changes. While it doesn't directly make calls, it actively engages with and controls the timing of voice call operations, making it an Execute action rather than a passive Read.
From the tool's definition Tool blocks execution until a voice call ends and returns call state/outcome. It triggers external operations (voice call monitoring) whose effects depend on call arguments and state.
Attacks that exploit this kind of access
The rule that runs calls_wait safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Dialogbrain, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For calls_wait, this is the rule to start with:
calls_wait stays usable, but rate-capped: a runaway agent can't fire it dozens of times a minute. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Dialogbrain, apply this rule, and every calls_wait call is checked against it from then on.
Questions about calls_wait
Block until a voice call ends (status changes from 'active') or timeout elapses. Returns ended=true with final state when the call has ended; ended=false on timeout (re-issue to keep waiting). The returned state includes outcome so callers can branch on pickup vs. no-answer (answered/no_answer/busy/declined/failed/unknown). Default timeout 90s; cap 110s — bounded by nginx proxy_read_timeout 120s on /mcp. It is categorised as a Execute tool in the Dialogbrain MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.
calls_wait accepts 2 parameters: call_id, timeout_seconds. Required: call_id. The full parameter table on this page comes from the server's own tool schema.
Register the Dialogbrain MCP server in PolicyLayer and add a rule for calls_wait: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Dialogbrain. Nothing to install.
calls_wait is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.
Yes. Add a rate_limit block to the calls_wait rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for calls_wait. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
calls_wait is provided by the Dialogbrain MCP server (https://api.dialogbrain.com/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Dialogbrain, and thousands of servers like it.
Across the catalogue