voice_id_identify1:N identification — rank everyone enrolled in the group against this clip.
Returns: dict with keys: candidates (list of {speaker_id, similarity}, best first).
| Name | Required | Description | Default |
|---|---|---|---|
| audio | Yes | Base64-encoded WAV of the clip to identify | |
| top_k | No | How many candidate speakers to return | |
| group_id | Yes | The group/namespace to search within |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context about the ranking operation ('rank everyone... against this clip') and specifies return format including 'candidates (list of {speaker_id, similarity}, best first)', which goes beyond annotations. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that state the purpose and the return structure. It front-loads the core function and avoids any redundant details. Every word earns its place, making it an exemplary model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with three parameters and no output schema, but the description covers the return format, and the schema fully documents parameters. Annotations handle safety. The only minor gap is that the description does not explicitly mention constraints like audio format or group_id requirement, but these are in the schema and are straightforward. Overall, the information is sufficient for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (audio, group_id, top_k) are already documented in the input schema with descriptions. The description does not add any additional parameter semantics or clarify their usage beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: '1:N identification — rank everyone enrolled in the group against this clip.' It clearly identifies the resource (speaker) and the action (identify/rank) and differentiates from siblings like voice_id_verify (1:1) and voice_id_enroll via the '1:N' qualifier. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for multi-candidate identification via '1:N identification' and 'rank everyone', but it does not explicitly mention when to use this tool versus alternatives such as voice_id_verify for 1:1 matching or voice_id_list_speakers for listing. No exclusions or alternative conditions are given, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools map to clearly distinct actions, but transcribe_audio and transcribe_audio_pro are near-duplicates and the four check_*_service tools require careful reading. The detailed descriptions make the distinctions recoverable, so confusion should be rare.
The set overwhelmingly follows a snake_case verb_* pattern, and the voice_id_* family is internally consistent. Minor deviations like get_phoneme_inventory vs list_tts_voices and the _pro suffix on transcribe_audio_pro keep it from being perfect.
Fourteen tools is within a reasonable range, but the server bundles pronunciation, STT, TTS, voice ID, and four health checks, making it feel broader than the 'Pronunciation' name suggests. A few health checks could be consolidated, but nothing is excessive.
Core pronunciation, transcription, and synthesis workflows are present, but the voice ID portion has create/list/verify/identify with no way to delete or unenroll a speaker. That is a notable lifecycle gap in an otherwise fairly complete speech toolkit.