Audio for your agent: transcribe, speak, translate, summarise, plus sound effects and music.
Scored across 13 tools
Most tools have clearly distinct purposes, with only minor overlap between transcribe_audio and summarize_recording (both return transcripts) and between identify_speakers and summarize_recording (both provide speaker info). However, descriptions explicitly differentiate use cases (short vs long recordings, dedicated speaker identification), so ambiguity is low.
Tool names mostly follow a consistent verb_noun pattern (e.g., generate_music, list_voices, transcribe_audio), all in snake_case. The only deviation is last_call_cost, which is a noun phrase rather than a verb action, but it's still clear and doesn't disrupt readability.
13 tools is well-scoped for an audio platform covering generation, speech processing, and utilities. Each tool serves a distinct function, and none feel redundant or missing for the apparent domain.
The tool surface covers the full audio lifecycle: generation (music, effects, scenes), analysis (transcription, summarization, pronunciation, speaker ID), synthesis (TTS, translation), and supporting utilities (voice list, cost check, report verification). No obvious gaps for the stated domain.
Compare a recording against the sentence it was meant to say, phoneme by phoneme.
Returns the accuracy, both IPA strings — what should have been said and what
was heard — and the grouped errors. `explain=False` skips the written
explanation and is much cheaper: the comparison is quick, but the
explanation calls a language model and costs around thirty times more.
Each entry in `errors` has `type` (substitution | missing | extra),
`expected`, `heard`, `times` and the `words` it happened in.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| audio | Yes | ||
| explain | No | ||
| language | No | es |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state that the operation is read-only/open-world, so the description carries the behavioral burden. It candidly discloses that explanation invokes a language model, costs roughly 30x more, and can be skipped, and details exactly what the result contains.
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 dense with no filler: purpose first, then return shape, then the cost tradeoff, then the error entry structure. Every sentence contributes behavior an agent would otherwise not know.
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 two-required-param tool with an output schema, the description is nearly complete and even enriches the output shape. The main gap is undocumented language behavior and audio encoding, which could matter for a pronunciation scorer.
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 must compensate; it maps audio to the recording, text to the intended sentence, and explain to the cheaper no-explanation mode. However, language is left entirely to the schema's bare default, and there is no guidance on accepted audio format/value type.
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 first sentence names a specific verb ('Compare') and resource ('a recording against the sentence it was meant to say, phoneme by phoneme'), making the tool's job unmistakable. This also distinguishes it from transcription siblings like transcribe_audio, which have no known reference 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 implies the tool is for pronunciation comparison against known expected text, but never explicitly contrasts it with alternatives in the sibling set. It does provide valuable in-tool guidance: set explain=False when you want to avoid the expensive LLM explanation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Generate every event of a plan and mix them into one scene.
`plan` is the JSON that plan_sound_scene returned, edited if you want: you
can move an event, change its wording or drop it. This is the step that
costs, because each event is a generation. Needs a paid plan (Startup up).
Returns the mix. The separate pieces come back too, but only the mix can be
handed over as audio here; call the HTTP API directly if you need them.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: each event is a generation and therefore costs money, a paid plan is required, and only the mix is deliverable as audio here while separate pieces require the HTTP API. These details are not conveyed by readOnlyHint or destructiveHint.
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 first sentence states the tool's purpose, and each subsequent sentence adds a necessary operational fact: plan source/editability, cost/paid requirement, and delivery limitation. There is no filler or redundant restatement of the name.
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 single-parameter tool with no output schema, the description covers input provenance, editability, cost implications, output contents, and how to obtain the separate pieces. An agent has all the information needed to invoke the tool correctly and interpret the result.
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% and the parameter is just named 'plan,' so the description carries the full burden. It explains that plan is the JSON returned by plan_sound_scene, that it can be edited by moving/changing/dropping events, and why the content matters. This fully compensates for the bare 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 opens with a specific verb and resource: 'Generate every event of a plan and mix them into one scene.' It clearly identifies the output and references plan_sound_scene, distinguishing this execution step from the planning sibling.
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 explicitly ties the plan parameter to plan_sound_scene's output, indicating when in the pipeline to use this tool. It also states this step costs and requires a paid plan, and offers the HTTP API as an alternative when separate pieces are needed. It doesn't explicitly contrast with generate_sound_effect or generate_music, but the context is clear.
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.
Turn a long description into sound events placed in time. Generates NO audio.
Use this before generate_sound_scene when you want to see — or let the user
correct — what is going to be made. It costs almost nothing because no audio
is produced: only a language model reads the description. Returns JSON with
`events`, each one `start`, `duration` and `prompt`.
| Name | Required | Description | Default |
|---|---|---|---|
| seconds | No | ||
| description | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint and openWorldHint, the description discloses that no audio is produced, that only a language model reads the description, and that the output is JSON with events containing start, duration, and prompt. This gives the agent concrete behavioral expectations.
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?
Three short sentences front-load the core action and the no-audio caveat, then add the sibling routing and output shape. Every sentence contributes without redundancy.
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?
With rich annotations and an output schema already present, the description supplies the missing context: when to use it, why it is cheap/safe, and what the result looks like. No essential call-time information is absent.
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 description compensates for 'description' by calling it a long description and explaining how it is consumed. However, the 'seconds' parameter is never explained, even though it has a default and affects placement of events in time.
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?
Description states a specific verb and resource: 'Turn a long description into sound events placed in time.' It also explicitly disambiguates from the sibling generate_sound_scene by saying 'Generates NO audio' and framing this as the planning step.
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 explicitly instructs to use this 'before generate_sound_scene when you want to see — or let the user correct — what is going to be made,' which identifies the alternative and the triggering condition. The cost note further clarifies when it is a safe and discriminating choice.
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.
A file attached to the conversation, or a path on the user's machine,
CANNOT be used: this server runs elsewhere and never receives those bytes.
Ask the user for an https URL instead. Do not try to work around it by
splitting the audio or re-encoding it -- the obstacle is the transfer, not
the size, and chunking multiplies the cost for a result that still fails.
| 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?
Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true) by disclosing the critical failure mode: the server never receives conversation-attached files or local paths. It warns that chunking/re-encoding is futile because 'the obstacle is the transfer, not the size,' which prevents the agent from wasting effort on doomed workarounds. No contradiction with 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?
Roughly 120 words, but every sentence earns its place: purpose, parameter format, usage condition, sibling alternative, hard constraint, remediation, and an anti-pattern warning. Content is front-loaded with purpose and progresses in a logical paragraph structure.
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?
Since an output schema exists, return-value details are not needed. The description handles the tool's complexity well and even covers failure modes. The lone gap is the language parameter, which is undocumented in both the schema and the description — a minor miss for a two-parameter tool.
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 carries the burden, and it does fully define the audio parameter as 'an https URL or base64 audio' — meaning beyond the schema's bare 'string' type. However, the language parameter is never mentioned; its purpose, format, and effect are left entirely to 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?
Opens with a clear verb+resource statement, 'Transcribe a recording,' and defines what the audio input accepts. It distinguishes itself from the closest sibling, summarize_recording, by noting this tool returns literal text for short recordings while the sibling adds speakers and tone.
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 states when to use this tool ('Use this for short recordings when you want the literal text') and when not to ('For anything past a few minutes prefer summarize_recording'). It also names the sibling, explains the cost difference, and instructs the agent to ask the user for an https URL when a local file is involved.
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.
Check whether a signed Uttera report is genuine and unmodified.
`report` is the report's JSON. Verifying is a public-key operation, so this
proves the document came from Uttera and has not been altered since.
| Name | Required | Description | Default |
|---|---|---|---|
| report | Yes |
| 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 beyond that by explaining that the operation is a public-key verification and that it proves provenance and integrity, which is useful behavioral context and does not contradict 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 two brief, front-loaded sentences: the first states the action, the second defines the parameter and adds the key operational fact. There is no filler, repetition, or unnecessary detail.
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 single-parameter, read-only verification tool with an output schema, the description gives enough to call it correctly: what to pass, what it checks, and what the result proves. No hidden side effects, prerequisites, or additional inputs are implied.
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 adds meaning by saying `report` is the report's JSON, clarifying the format beyond 'string', but it does not describe the JSON structure or required fields, so it only partially compensates for the schema gap.
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 clear verb ('Check whether') and a specific resource ('a signed Uttera report'), and defines the success criteria ('genuine and unmodified'). This distinguishes it clearly from the audio-related sibling tools, none of which perform verification.
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 phrasing 'Check whether...' makes the intended use obvious, and the public-key explanation clarifies what the verification proves. It does not explicitly name alternatives or exclusions, but no sibling tool overlaps with this verification function, so the context is sufficient.
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.
analyze_pronunciationgenerate_sound_sceneplan_sound_sceneverify_reportgenerate_musicgenerate_sound_effectidentify_speakerslast_call_costlist_voicesspeak_textsummarize_recordingtranscribe_audiotranslate_recordingAudio and video tools for your AI assistant: remove noise, enhance voices, transcribe, and more.
Transcribe audio & video to text for AI agents: 100+ languages, speaker labels, webhooks.
Text to speech and transcription for any AI model: MP3 voiceovers, audio and YouTube to text.
Video, audio, and image processing for AI agents: convert, transcribe, upscale - 150+ operations.
Add one secure layer between your agents and this server.
