Skip to main content
Glama

bvoiz_get_voice_details

Retrieve details and preview audio for a specific BVoiz voice by its ID, helping users evaluate and select the right Vietnamese text-to-speech voice.

Instructions

Xem chi tiết thông tin và nghe thử một giọng đọc BVoiz theo ID cụ thể.

Input Schema

NameRequiredDescriptionDefault
voice_idYesMã giọng đọc (ví dụ: 'bvoiz_nam_mb_muu_luoc')

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.4/5.0
Behavior3/5

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

No annotations exist, so the description carries the full behavioral burden. It does add one useful trait beyond the name — that the response includes a listenable demo, not just metadata — but it omits whether authentication is required, whether the call is read-only/side-effect free, and what the returned detail payload contains.

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?

A single compact sentence with no filler, front-loading the core action ('Xem chi tiết thông tin') and appending the preview capability. Nothing is wasted, though there is little structure to speak of beyond that one clause.

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

Completeness3/5

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

For a simple one-parameter read tool this is close to adequate, but with no output schema the description should hint at what 'chi tiết thông tin' actually includes (e.g., locale, gender, style, demo audio URL). As written, an agent knows the action but not the shape of the result.

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?

Only one parameter, and the schema documents it at 100% coverage with a concrete example ('bvoiz_nam_mb_muu_luoc'). The description's 'theo ID cụ thể' adds no meaning beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: retrieve detailed information about a BVoiz voice identified by ID, and additionally preview/hear it. This clearly separates it from list/search tools by emphasizing a single voice_id lookup, though it never names those siblings explicitly.

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 phrase 'theo ID cụ thể' signals it needs a specific voice_id, presumably obtained from bvoiz_list_voices or bvoiz_search_voices, but the description never says so. There is no explicit when-to-use versus alternatives such as bvoiz_test_cloned_voice or bvoiz_demo_synthesize, which also involve hearing a voice.

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