dialogbrain

calls_dispatch_translator

Read-onlyIdempotent

Send a live speech translator to a call. target decides where: a Google Meet or Microsoft Teams link → meeting bot; a Telegram @group / t.me link / chat_id → Telegram group voice chat; 'new' (or omitted) → creates a native DialogBrain meeting with translation on and returns the join + guest links; a native meeting call_id or /meeting/ URL → enables translation on that running meeting. Always pass target_language (ISO code); optional app_languages (extra subtitle-only languages), sentence_length (short|medium|long, native only), silent (subtitles without voice), source_language (the meeting's spoken language, ISO code — improves recognition; omit for autodetect), tts_provider + tts_voice (the translator's voice; omit for the workspace default).

Input Schema

TableJSON Schema

Name	Required	Description
`title`	No	native_new only: meeting title.
`silent`	No	Meeting routes only (Google Meet / Teams): true = subtitles without speaking into the call. OMIT for a normal speaking translator.
`target`	No	Where to send the translator: a Google Meet or Microsoft Teams link, a Telegram @group / t.me link / chat_id, 'new' for a fresh native meeting, or an existing native meeting call_id or /meeting/ URL. Omit for a new native meeting.
`agent_id`	No	Meeting routes ONLY (Google Meet / Teams), and required there: the active agent the bot session is recorded against (calls.send_to_meet needs one). Get it from agents.list. Telegram and native meetings ignore it — they arm translation on a call that already exists.
`tts_voice`	No	Specific voice id for tts_provider (e.g. 'alena', 'nova'). Omit for the provider default.
`in_workspace`	No	Run this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.
`tts_provider`	No	Translator VOICE provider (cartesia, openai, yandex, deepgram, ...). Omit for the workspace default translation voice. Meeting routes (Google Meet / Teams) + native new meetings.
`app_languages`	No	Extra subtitle-only languages (max 4).
`comeback_phrase`	No	Attention-recall phrase.
`sentence_length`	No	Native meetings only: short\|medium\|long buffering (default medium).
`source_language`	No	The call's spoken language (ISO code, e.g. 'en', 'ru'). When set, speech recognition runs in that language's dedicated mode for better accuracy. REQUIRED in practice for languages autodetect does not cover (e.g. 'vi', 'th', 'id', 'tl'). Omit when participants may speak multiple languages (autodetect). All routes.
`target_language`	Yes	Primary spoken translation target (ISO code, e.g. 'th').

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 6, 2026

addedInput schema / properties / in_workspace

Added value: +{
+  "description": "Run this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.",
+  "type": "integer"
+}

AddedSep 29, 2026
RemovedAug 1, 2026

Changed3 schema fields changedJul 26, 2026

addedInput schema / properties / source_language

Added value: +{
+  "description": "The meeting's spoken language (ISO code, e.g. 'en', 'ru'). When set, speech recognition runs in that language's dedicated mode for better accuracy. Omit when participants may speak multiple languages (autodetect). Google Meet + native meetings.",
+  "type": "string"
+}

addedInput schema / properties / tts_provider

Added value: +{
+  "description": "Translator VOICE provider (cartesia, openai, yandex, deepgram, ...). Omit for the workspace default translation voice. Google Meet + native new meetings.",
+  "type": "string"
+}

addedInput schema / properties / tts_voice

Added value: +{
+  "description": "Specific voice id for tts_provider (e.g. 'alena', 'nova'). Omit for the provider default.",
+  "type": "string"
+}

AddedJul 19, 2026

TDQS

A3.7/5.0

Behavior1/5

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

Annotations declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, yet the description says the 'new'/omitted route 'creates a native DialogBrain meeting with translation on' and that a native call_id 'enables translation on that running meeting' — both are environment mutations. The conflicting signal is severe for an agent deciding whether this call has side effects.

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 routing rule and structured with backticked parameter names and arrows, so the branching is scannable despite being one long paragraph. Some sentences duplicate schema text, which is waste given 100% coverage, but nothing else is padding.

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?

For a 12-parameter tool with no output schema, the description covers routes, defaults, conditional applicability ('native only', 'Meeting routes only') and notes the 'new' route returns join + guest links. It omits failure behavior and how to subsequently stop/mute translation, but the core calling contract is complete.

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% and the schema descriptions are themselves rich (route restrictions, 'OMIT' semantics, examples). The prose restates rather than extends the schema — it adds no format, unit, or validation detail beyond what the properties already document, so the baseline 3 applies.

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+resource ('Send a live speech translator to a call') and immediately differentiates the four routing surfaces for `target`. An agent can tell exactly what capability this exposes without opening the schema, and the routing table is far more specific than any sibling (e.g. calls_set_translation_language).

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?

The description is essentially a decision tree: Meet/Teams link → meeting bot; Telegram handle/link/chat_id → Telegram voice chat; 'new'/omitted → fresh native meeting; call_id or /meeting/ URL → arm translation on a running meeting. It also gives when-not guidance implicitly ('OMIT for a normal speaking translator', 'Telegram and native meetings ignore it'), which removes almost all inference.

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

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

calls_dispatch_translator

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources