Skip to main content
Glama
Sign In
MCP Yandex Voice

MCP Yandex Voice

by dimaanj
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Голосовой ответ

speak_response

Speaks a GPT-generated response to a user question or adapts provided text for voice output, with contexts for brief, coding interview, or architecture discussions.

Instructions

Озвучить ответ через Yandex GPT + TTS. Режимы: 1) message — вопрос пользователя, GPT генерирует и озвучивает развёрнутый ответ; 2) textToSummarize — текст ответа ассистента, GPT адаптирует для озвучивания. Контексты: default (краткое), coding_interview (алгоритмы, сложность), architecture (system design, trade-offs).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "speak_response"
  }
}

Input Schema

NameRequiredDescriptionDefault
contextNoКонтекст: default — краткое озвучивание; coding_interview — развёрнуто с алгоритмами и Big O; architecture — развёрнуто с trade-offs и компонентами
messageNoВопрос пользователя — Yandex GPT генерирует развёрнутый ответ и озвучивает
systemPromptNoКастомный системный промпт. Переопределяет контекстный промпт
textToSummarizeNoТекст ответа ассистента — Yandex GPT адаптирует под контекст (default: кратко; coding_interview/architecture: развёрнуто) и озвучивает

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses use of Yandex GPT and TTS, and explains the two modes. However, it does not mention the output format (audio stream, file, or direct playback), side effects, required permissions, or behavior when both message and textToSummarize are provided (likely exclusive). The description is basic but not misleading.

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?

The description is very concise: three sentences front-loaded with purpose, followed by mode and details. No extraneous words. Every sentence adds value.

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

Completeness2/5

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

Given the tool's complexity (4 parameters, no output schema, no annotations), the description is incomplete. It does not specify the output type (e.g., audio URL, base64, stream), whether the tool is synchronous, or what happens on parameter conflicts. Sibling tools hint at playback, but this tool's integration with them is unclear. The description could be enhanced to cover missing behavioral contracts.

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 baseline is 3. The description summarizes the modes and contexts, which aligns with schema comments. It does not add significant new meaning beyond the schema for each parameter. The high-level overview is helpful but not additional semantic depth.

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 clearly states the tool's purpose: 'Озвучить ответ через Yandex GPT + TTS' (voice response via GPT and TTS). It explains two main usage modes (message and textToSummarize) and three context options. This distinguishes it from sibling tools like health_check, playback_control, and play_sound, which are about audio system status or playback control, not generating speech from text.

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?

The description provides clear guidance on when to use each mode (message for user questions, textToSummarize for assistant text) and context (default for brief, coding_interview/architecture for detailed). However, it does not explicitly state when NOT to use or compare with alternatives. Since siblings are unrelated, the guidance is adequate but not exhaustive.

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

Deploy Server

Other Tools