transcribe
Transcribe audio with speaker diarization and timestamps. Cost: 3 credits.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language code. | en |
| audio_url | Yes | URL to audio/video file. | |
| speaker_labels | No | Enable speaker diarization. |
Transcribe audio with speaker diarization and timestamps. Cost: 3 credits.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language code. | en |
| audio_url | Yes | URL to audio/video file. | |
| speaker_labels | No | Enable speaker diarization. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It does add genuinely useful behavior: the credit cost and the fact that output includes diarization and timestamps. It omits format/size limits and whether the call is synchronous, leaving real gaps for a media-processing tool.
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 punchy sentences with zero filler; the core capability leads and the cost caveat follows immediately. Nothing to trim and nothing buried.
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?
No output schema and no annotations means the description must carry behavior on its own. Cost and output features are covered, but for a 3-parameter media tool it says nothing about supported formats, limits, or latency, so an agent lacks key operational context.
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 three parameters (language, audio_url, speaker_labels) are documented in the schema. The description's mention of diarization loosely maps to speaker_labels but adds no syntax or format detail 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.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Transcribe) and resource (audio) plus distinguishing features: speaker diarization and timestamps. However, the sibling list contains 'stt', which almost certainly overlaps with transcription, and the description makes no attempt to differentiate itself from that tool.
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 when-to-use guidance and no mention of the obvious alternative sibling ('stt'). The only selection signal is the credit cost, which a user might weigh, but the description never says when to choose this over stt or subtitle.
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.