Skip to main content
Glama

Preview voice

preview_voice
Read-only

Play ONE voice from find_voices' candidates — call once per candidate, up to three.

This tool does not search, and one call answers with one voice. Pass a candidate's catalog_voice_id, repeat for the others so the user can compare, and let them say which is theirs. language is a family (ko) or a locale (ko-kr).

Input Schema

NameRequiredDescriptionDefault
languageYesA family (`ko`) or locale (`ko-kr`) — one of the voice's preview_locales from find_voices.
catalog_voice_idYesA catalog_voice_id exactly as find_voices returned it.

Output Schema

NameRequiredDescriptionDefault
modelNo
localeNo
playedNo
next_stepNo
sample_urlNo
voice_nameNo
content_typeNo
catalog_voice_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: it does not search, one call returns one voice, and there is a soft cap of three previews. It stops short of stating latency/rate behavior, so a 4 rather than 5.

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-loads the key constraint (one voice per call) and is appropriately short. Slight redundancy between 'call once per candidate, up to three' and 'one call answers with one voice' costs it the top mark.

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 an output schema present, return values need no explanation, and annotations cover the safety profile. The description supplies the usage pattern and the source-tool linkage, so an agent has what it needs; only minor behavioral detail (e.g. what playback entails) is absent.

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 already explains that language is a family or locale derived from find_voices' preview_locales and that catalog_voice_id must match exactly. The description's restatement of the family/locale format adds no meaning beyond the schema, 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 ('Play') and resource ('ONE voice'), and immediately distinguishes itself from the sibling find_voices by declaring 'This tool does not search.' An agent can tell exactly what this does versus the search tool.

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?

Explicitly names the workflow: call once per find_voices candidate, up to three times, repeat so the user can compare and choose. The source (find_voices) and the intended iteration pattern are spelled out, 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources