Transcribe audio from a URL or base64 encoding into timestamped text. Select a language code to get timed transcription segments.
Transcribe audio to text with timestamps. Cost: 2 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language code. | en |
| audio_url | No | URL to audio file. | |
| audio_base64 | No | Base64-encoded audio. |
Changes observed during successful MCP inspections.
v0.3.1Input schema / properties / audio_base64Added value: +{
+ "description": "Base64-encoded audio.",
+ "type": "string"
+}Input schema / properties / audio_url / descriptionPrevious value: -"URL to audio file"New value: +"URL to audio file."Input schema / properties / language / descriptionPrevious value: -"Language code"New value: +"Language code."v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It usefully discloses the cost (2 credits), but says nothing about which audio input to supply when both audio_url and audio_base64 are optional, permission/auth needs, size limits, or error 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 compact sentences, front-loaded with the action and appended with the cost. No filler, and both facts are immediately useful to an agent.
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?
There is no output schema, so the description should cover the return shape; 'with timestamps' hints at it but doesn't describe the format. It also doesn't resolve the zero-required-parameter input ambiguity, though the cost disclosure is a helpful addition.
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 the baseline is 3 and the schema already documents all three parameters. The description adds nothing about the parameters, and notably neither schema nor description explains whether audio_url and audio_base64 are mutually exclusive alternatives.
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 and resource ('Transcribe audio to text') plus an output trait ('with timestamps'), which is clear on its own. However, with a sibling literally named 'transcribe' in the same toolset, it does nothing to distinguish itself from that tool, leaving ambiguity about which to pick.
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?
There is no indication of when to use this tool versus the 'transcribe' or 'subtitle' siblings, nor any prerequisites. Given the near-duplicate sibling name, the absence of routing guidance is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.