VoiceStudio MCP

Official

Overview Schema Source Related Servers Discussions Admin

list_languages

Retrieve a sample of supported text-to-speech languages and see the full count, helping you choose a voice language before generating speech.

Instructions

List a sample of supported TTS languages.

VoiceStudio supports 646 languages. This returns the most popular ones plus a note about the full count.

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": "list_languages"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 3, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does disclose a genuinely important behavioral trait: the result is a curated sample, not the complete set of 646 languages, and it includes a count note. It does not need to describe return shape since an output schema exists. Read-only listing needs no auth/rate disclosure, so this is near-complete.

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?

Short and front-loaded, with the sampling caveat directly after the purpose. The second and third sentences overlap somewhat ("sample" vs "most popular ones plus a note about the full count"), which is mild redundancy rather than a structural flaw.

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

Completeness5/5

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

For a parameterless read tool with an output schema, the description supplies everything an agent needs: what it returns, that the list is partial, and that the total count is surfaced. No open questions remain that would affect invocation.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline is 4; there are no parameter semantics to add meaning to. Nothing in the description misrepresents the no-argument interface.

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 ("List ... supported TTS languages") and immediately qualifies the scope as a sample rather than the full 646-entry catalog. The resource is unambiguous against siblings like list_voices and list_personalities, so an agent can select it without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the agent can infer this is the discovery call for language codes, but there is no explicit when-to-use guidance, no mention of prerequisites, and no routing to alternatives. Adequate but with a clear gap.

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