Audio for your agent: transcribe, speak, translate, summarise, plus sound effects and music.
Scored across 9 tools
Each tool targets a distinct audio task: music generation, sound effects, speaker identification, cost checking, voice listing, text-to-speech, recording summarization, transcription, and translation. Even similar tools like transcribe_audio and summarize_recording are clearly differentiated by usage guidance (short vs long recordings).
Most tools follow a clear verb_noun pattern (generate_music, list_voices, speak_text, transcribe_audio). The lone exception is last_call_cost, which is a noun phrase rather than verb-led, slightly breaking the established pattern.
Nine tools is well-scoped for an audio and speech API, covering generation, transcription, summarization, translation, TTS, speaker analysis, voice management, and cost tracking without being bloated or sparse.
The surface covers the core audio lifecycle: generating music and effects, speaking text, transcribing, summarizing, translating, and identifying speakers. Minor gaps exist (e.g., no audio editing or voice cloning), but nothing that causes major dead ends for common workflows.
A finished piece of music from a description. Up to 380 s.
Needs a paid plan (Startup and up). ⚠ BOTH controls cost: the price is
length multiplied by steps, so 380 s at 128 steps is about eight times a
60 s at 32. Naming style, instruments and BPM helps far more than asking
for «something upbeat».
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| steps | No | ||
| seconds | No | ||
| description | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds meaningful behavioral details beyond annotations: paid-plan requirement, 380-second limit, and the cost formula driven by seconds and steps. This is not present in readOnlyHint/destructiveHint/openWorldHint, and there is no contradiction with annotations. It stops short of describing output format or seed behavior.
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?
Compact and front-loaded: the core result and duration limit come first, followed by prerequisites and cost/prompt guidance. Every sentence adds practical value, with only minor typographic noise.
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?
Covers the key constraints an agent needs to invoke the tool safely: paywall, max duration, cost drivers, and prompt-quality advice. Gaps are the purpose of the seed parameter and the exact output format, but these are minor given the absence of an output schema.
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 0%, so the description must compensate. It partially does by explaining the cost relationship between length and steps and by advising description content (style, instruments, BPM). Seed is never mentioned, so one of the four parameters remains semantically undocumented.
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?
States the tool converts a natural-language description into a finished music piece, with an explicit maximum duration. The resource ('music') broadly distinguishes it from sibling generate_sound_effect, though it does not name alternatives explicitly.
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?
Provides useful invocation context: paid plan required, cost is length × steps, and better prompts name style/instruments/BPM. However, it never explicitly says when to use this tool instead of generate_sound_effect or other audio siblings, so alternative selection is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One sound effect from a description: a door, rain, footsteps. Up to 30 s.
Needs a paid plan (Startup and up). The description works better in English.
A fixed `seed` reproduces the same sound exactly.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| seconds | No | ||
| description | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behaviors beyond the annotations: it requires a paid plan (Startup and up), is language-sensitive (works better in English), enforces a 30-second maximum, and makes determinism explicit with a fixed seed. These details meaningfully shape expected behavior during invocation.
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 compact and front-loaded: the core purpose appears in the first sentence, followed by three critical constraints in a tight list. Every sentence adds necessary information, and there is no filler or repetition of the schema.
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?
For a generative tool with no output schema, the description covers input semantics, key limits, auth requirements, and reproducibility, which is strong. The only notable gap is the absence of any mention of what the tool returns (e.g., audio URL or file), but given the tool's straightforward action, this is not a major omission.
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?
With 0% schema description coverage, the description compensates well: it explains the seed parameter ('A fixed seed reproduces the same sound exactly') and the seconds limit ('Up to 30 s'). It also clarifies what the description parameter should contain via examples, though it doesn't explain the default seed value of -1 or units for seconds beyond the 's' inference.
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 starts with 'One sound effect from a description,' naming the exact verb (generate) and resource (sound effect), then gives concrete examples (door, rain, footsteps) that make the tool's scope unmistakable. The resource type 'sound effect' clearly differentiates it from the sibling generate_music.
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?
It provides clear context for when to use the tool: when a single sound effect is needed from a text description, with illustrative examples. It also gives practical usage guidance ('works better in English') and a prerequisite (paid plan), but does not explicitly say 'use generate_music for music' or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who speaks and when. Returns the segments with their speaker and times.
| Name | Required | Description | Default |
|---|---|---|---|
| audio | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already carry readOnlyHint=false, openWorldHint=true, and destructiveHint=false, and the description adds no further behavioral detail such as costs, audio-form restrictions, side effects, or label stability. 'Returns the segments...' restates the output rather than disclosing non-obvious behavior.
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 compact and front-loaded, but the first sentence ('Who speaks and when.') is essentially redundant with the second sentence's mention of segments, speaker, and times. Still concise and scannable.
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?
Although the output schema covers return values and the tool is simple, the definition is incomplete for invocation because the audio argument's format and provenance are entirely unspecified. An agent cannot confidently call this tool without external assumptions.
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 0% and the only parameter, 'audio', is a bare string field. The description never explains what the audio value should be (path, URL, base64, or previously uploaded file), so it adds no meaning beyond the schema.
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 verb ('returns') and a specific resource ('segments with their speaker and times'), clearly identifying speaker diarization. This distinguishes it from transcribe_audio (words), summarize_recording (summary), and translate_recording (translation).
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?
No usage guidance is provided. It does not say when to prefer identify_speakers over transcribe_audio or summarize_recording, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What the previous call actually cost, in credits, broken down.
Worth checking before running something many times: it is the honest way
to tell the user what a batch is going to cost them.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it reflects the 'previous call' and returns a credit breakdown, which is useful context, but it does not go beyond that into rate limits, accuracy, or reset behavior.
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?
Two short, purposeful sentences. The first states the core function immediately; the second gives a practical use case. No wasted words or schema repetition.
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?
For a parameter-less, read-only, output-schema-bearing tool, everything needed to call it correctly is present: what it returns, the unit, and when to use it. There are no missing prerequisites or edge conditions to document.
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?
The tool has zero parametersaren't any parameters to document, and the schema leaves no gaps.
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 clearly states what the tool does: it reports the credit cost of the previous call, broken down. This distinguishes it from all sibling tools, which are about audio generation, transcription, and voice operations.
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?
It gives explicit practical guidance: check this before running something many times to inform the user of batch cost. It does not mention alternatives, but no sibling tools serve this purpose, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The voice catalogue, with the language each one speaks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral detail beyond the content of the result (voices and their languages), which is useful but not a behavioral disclosure such as rate limits, authentication, or result-set volatility.
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 a single short sentence that wastes no words. It is concise and immediately identifies the core purpose, though it is structured as a noun phrase rather than a complete verb-led sentence.
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?
For a zero-parameter, read-only list tool with an output schema present, the description captures the essential information: what is being listed and what detail is included. It does not need to explain return values because the output schema exists, and the annotations cover safety.
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?
The tool has zero parametersainer, so there is nothing for the description to clarify about argument semantics. Baseline 4 is appropriate because no parameter information is missing and the schema coverage is effectively complete.
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 names the resource ('voice catalogue') and the key characteristic it exposes ('the language each one speaks'), making the tool's purpose understandable. It lacks an explicit verb like 'lists' or 'returns', which keeps it from a 5, but it is clearly distinct from the audio-generation and transcription siblings.
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 does not state when to use this tool versus alternatives such as speak_text or identify_speakers. There is no mention of using it to discover available voices before speaking or generating audio, so the agent receives no explicit usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read text aloud. Returns audio. voice defaults to a Spanish one;
call list_voices to see the catalogue.
⚠ Line breaks are billed: each one inserts a pause of about 1.3 s. Strip
them from formatted text before sending it.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| voice | No | dora | |
| language | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses a real behavioral and cost trait: line breaks are billed and insert ~1.3s pauses, with an explicit instruction to strip them from formatted text. It also reveals the voice default and the return type (audio), adding substantial context without contradicting the annotations.
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 compact: two sentences for the core behavior and one focused warning paragraph. The main action is front-loaded, and every sentence earns its place.
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?
For a tool with no output schema and a non-read-only annotation, the description supplies the essential return type (audio), the default voice behavior, and a critical billing caveat. The only notable gap is the language parameter, whose semantics are never stated.
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?
With 0% schema description coverage, the description must carry parameter meaning. It usefully clarifies voice (defaults to a Spanish voice; list_voices shows the catalogue) and warns about line breaks in text, but the language parameter is never explained. This is partial compensation for a fully undocumented schema.
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?
Opens with 'Read text aloud. Returns audio.' — a specific verb, resource, and output in one short sentence. This is unambiguously distinct from sibling audio tools like generate_music and transcribe_audio, even though no sibling names are called out.
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 clearly establishes the tool's role as text-to-speech and even routes the agent to list_voices for voice selection. However, it never states when to choose this over the other audio siblings or offers any exclusion criteria, so usage 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.
Summarise a long recording: summary, full transcript, tone, speaker profile and who spoke when — all in one request and one upload.
| Name | Required | Description | Default |
|---|---|---|---|
| audio | Yes | ||
| language | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive operation and an open world. The description adds useful behavioral context by highlighting the single-upload, all-in-one nature and the composition of the response. It does not contradict the annotations, though it omits details like upload format, size limits, or processing behavior.
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 a single, efficient sentence that front-loads the core action and then lists the outputs in a scannable series. No words are wasted, and the 'all in one request and one upload' qualifier adds meaningful differentiation rather than filler.
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?
Given poor input schema coverage and minimal annotations, the description is not complete enough for reliable invocation. It explains the high-level outcome but leaves critical invocation details—especially the semantics of the language parameter and expected audio input—unspecified. The output schema may cover return values, but the input side remains underdocumented.
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 coverage is 0%, so the description bears full responsibility for parameter meaning, but it only indirectly refers to the audio as a 'recording' and 'one upload'. The 'language' parameter is never mentioned, and no guidance is given on accepted formats, language codes, or defaults, leaving the agent to guess.
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 names a specific verb and resource ('Summarise a long recording') and enumerates the deliverables: summary, full transcript, tone, speaker profile, and who spoke when. The phrase 'all in one request and one upload' distinguishes it from single-purpose siblings like transcribe_audio and identify_speakers.
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 when this tool is appropriate—when a combined summary, transcript, tone, and speaker breakdown is needed in one call. However, it does not explicitly state when not to use it or name alternatives such as transcribe_audio for transcription-only needs, leaving usage mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcribe a recording. audio is an https URL or base64 audio.
Use this for short recordings when you want the literal text. For anything
past a few minutes prefer summarize_recording: it returns the transcript
too, plus who spoke and the tone, in ONE upload instead of two.
| Name | Required | Description | Default |
|---|---|---|---|
| audio | Yes | ||
| language | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the annotations: it accepts an https URL or base64 audio, is intended for short recordings, and involves one upload. However, it does not discuss auth, rate limits, maximum duration, or whether the audio is stored or discarded, so behavioral depth is still limited.
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?
Every sentence earns its place: the core purpose and input format come first, followed by a concise routing rule and alternative. There is no filler or redundant wording.
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?
For a 2-parameter tool with an output schema, the description covers the core invocation details and tool-selection context well. The only notable gap is the undocumented `language` parameter and the lack of a precise length threshold, but the available information is otherwise sufficient.
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?
The required `audio` parameter is well explained with its accepted formats (https URL or base64), which is genuinely useful since the schema only says it is a string. The optional `language` parameter is not explained at all, and with 0% schema description coverage the description should have compensated for both parameters.
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?
States a specific verb and resource ('Transcribe a recording') and clarifies the output is the literal text. It simultaneously differentiates from the sibling summarize_recording, which is the closest alternative.
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?
Explicitly says to use this for short recordings when literal text is wanted, and to prefer summarize_recording for anything past a few minutes because it also provides speaker and tone info in one upload. This gives the agent concrete selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate a recording into another language: text and, where the plan
allows it, voice. target_language is a code such as en, es, fr, de.
| Name | Required | Description | Default |
|---|---|---|---|
| audio | Yes | ||
| target_language | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate this is a mutable (readOnlyHint=false) but non-destructive operation, which the description does not contradict. The description adds that voice translation is conditional on the plan allowing it, which is useful behavioral nuance. However, it does not specify side effects (e.g., whether the original recording is modified) or any required setup, leaving gaps beyond what annotations cover. Given annotations exist, the description provides some added context but not comprehensive behavioral disclosure.
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 two concise sentences, with the core function front-loaded. The example language codes are immediately useful and the text avoids unnecessary details. Zero fluff.
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 has two required parameters and an output schema, yet the description leaves the audio parameter entirely undefined. It also does not mention any constraints or prerequisites (e.g., accepted audio formats, maximum duration). This is incomplete for an agent to invoke correctly without additional guesswork.
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?
The schema descriptions for parameters are absent (coverage 0%), so the description must compensate. It explains that target_language uses a language code format (e.g., en, es, fr, de), which adds meaning. However, the audio parameter is completely undocumented—no format, source, or requirements are given. This is a significant gap given the low schema coverage.
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 clearly states the tool's function: translating a recording into another language, covering both text and potentially voice. It specifies the resource (recording) and the action (translate), and gives a concrete example of the target_language code format. This distinguishes it from sibling tools like transcribe_audio or speak_text.
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 does not provide any guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as whether the audio must be transcribed first, or any conditions for when translation is appropriate. No explicit comparisons to sibling tools are given, so an agent must infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
generate_musicgenerate_sound_effectidentify_speakerslast_call_costlist_voicesspeak_textsummarize_recordingtranscribe_audiotranslate_recordingTranscribe audio & video to text for AI agents: 100+ languages, speaker labels, webhooks.
Video, audio, and image processing for AI agents: convert, transcribe, upscale - 150+ operations.
Audio AI tools: text-to-speech, voice cloning, music generation, stem separation, transcription.
Speech, transcription, voice agents, Trace, Recap, dubbing and narration with browser OAuth.
Add one secure layer between your agents and this server.
