Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Voxloom MCP Server transcribe https://youtu.be/VIDEO_ID and find what they say about consensus"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Model Context Protocol server for Voxloom. Lets an assistant transcribe a video or podcast, then read, search and summarise the result.
Works with Claude Desktop, Claude Code, Cursor, Cline, and anything else that speaks MCP over stdio.
You need a Voxloom API key from API keys in your dashboard. API access is included from the Studio plan upwards.
claude_desktop_config.json:
{
"mcpServers": {
"voxloom": {
"command": "npx",
"args": ["-y", "@voxloom/mcp"],
"env": { "VOXLOOM_API_KEY": "sk_prod_..." }
}
}
}claude mcp add voxloom --env VOXLOOM_API_KEY=sk_prod_... -- npx -y @voxloom/mcpBoth read the same shape of config as Claude Desktop. Add the voxloom entry
above to the MCP settings.
Related MCP server: MCP Audio Server
Tool | Charges | What it does |
| No | What a recording would cost, and whether the balance covers it |
| Yes | Transcribes a recording and returns the transcript |
| No | Reads a transcript by job id, or reports progress |
| No | Finds where something was said, with timestamps |
| No | Abstract, key points, quotes and chapters |
| No | Recent transcripts and their job ids |
| No | Who is in a transcript and for how long |
| No | Renames a speaker everywhere, exports included |
| No | Stops a running job; refunds the remainder |
| No | The 101 languages, and which can be translated into |
Transcription costs money. transcribe prices the job before submitting it
and refuses anything above a ceiling (30 standard minutes by default) unless it
is passed confirm_spend: true. So an assistant cannot quietly spend your
balance on a three-hour video: it has to tell you the cost and ask.
Raise or lower the ceiling with VOXLOOM_MAX_CREDITS_PER_CALL. 120 credits is
one standard minute.
Transcripts are large. Nothing returns a whole one by default. Reads are
budgeted and say plainly when they truncated, so the assistant knows it is
looking at an excerpt. For a question about one moment, search_transcript is
both cheaper and more accurate than reading everything.
Variable | Default | What it does |
| required | Your API key |
|
| Override for self-hosting |
|
| Spend ceiling per |
|
| How long |
|
| Text budget for a transcript read |
You: Transcribe https://youtu.be/VIDEO_ID and tell me what they say about consensus.
The assistant estimates the cost, transcribes it, then searches the transcript for "consensus" rather than reading all 9,000 words, and answers with timestamps you can check.
npm install
npm run typecheck
npm test # builds, then runs the tests against dist/Tests run against the compiled output rather than the sources, because that is what ships and it means the NodeNext module specifiers resolve as they will at runtime.
MIT.
Stops a running job. The unprocessed remainder is refunded; the part already transcribed stays charged, because that work was done.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is covered. The description adds real value beyond that: the billing consequence (unprocessed remainder refunded, completed portion still charged). It does not state irreversibility or auth requirements, but the cost semantics are a meaningful 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?
Two short sentences with the action front-loaded. The trailing clause 'because that work was done' is mild justification, but the whole thing is tight and easy to parse.
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 simple one-parameter destructive operation whose annotations already flag the mutation, the description covers both the action and the billing outcome. Missing only secondary details like permissions or behavior on an already-finished job, which are minor for this tool's complexity.
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?
There is a single parameter (job_id) with 100% schema coverage, so the schema already documents it fully. The description implicitly constrains it to a running job but adds no format or syntax detail. Baseline 3 applies when the schema does the heavy lifting.
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: 'Stops a running job,' matching the cancel_transcription name and title. It is clearly distinguishable from read/list siblings such as get_transcript or list_transcripts. It does not explicitly contrast against transcribe or estimate, but 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?
Usage is implied rather than stated: 'a running job' signals the tool only applies to in-flight jobs and not to completed ones. There is no explicit when-to-use guidance, no mention of prerequisites or permissions, and no named alternatives. Adequate but with clear gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What a recording would cost and how long it would take, without transcribing it or charging anything. Call this first whenever the recording might be long, or the user has not already agreed to spend. Returns the media length, the price in minutes, whether the balance covers it, and an ETA that accounts for the queue.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A YouTube, Vimeo, Twitch, podcast or direct media URL. | |
| model | No | thread is fastest and cheapest, weave is the default, tapestry is most accurate and costs four times thread. Defaults to auto. | |
| features | No | Optional extras, each adding a per-second surcharge. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that: it explicitly states nothing is transcribed or charged, and enumerates the returned fields (media length, price in minutes, balance coverage, queue-aware ETA), which is meaningful behavioral context for an agent deciding whether to call it.
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 tight sentences: the first front-loads the value proposition and non-charging guarantee, the second gives the call condition and the return summary. No filler or 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?
With no output schema, the description carries the burden of describing return values and does so concretely (length, price, balance coverage, ETA), and the usage condition is unambiguous. Nothing an agent needs to call it correctly is missing.
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% and the schema fully documents url, model (with per-model cost/speed tradeoffs) and features. The description adds no parameter-level detail of its own, so the baseline 3 is appropriate – the schema does the heavy lifting.
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+resource (estimate what a recording would cost and how long it would take) plus an explicit negative scope ('without transcribing it or charging anything'). This clearly distinguishes it from the transcribe sibling without needing to open either schema.
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?
Gives an explicit trigger: 'Call this first whenever the recording might be long, or the user has not already agreed to spend.' That is a concrete when-to-use condition, and the 'without charging' framing implicitly names the alternative (transcribe) and why an agent would pick this one instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who is in a transcript, how long each one speaks, and their speaker ids for renaming. Free. Speaking time is usually the quickest way to tell an interviewer from an interviewee.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover readOnlyHint and openWorldHint, so the safety profile is already known. The description adds genuinely new behavioral context — 'Free' (cost) and the shape of the returned data (speaker ids, speaking durations) — which is valuable since there is no output schema.
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 tight sentences, front-loaded with what you get, then the cost qualifier, then a practical heuristic about the data. Every clause earns its place and nothing is padding.
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 no output schema and no annotations about return content, the description usefully describes what comes back (participants, speaking time, speaker ids). It omits anything about ordering, pagination, or transcript-size limits, but for a simple single-param read tool this is largely complete.
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?
Only one parameter (job_id) and schema coverage is 100%, so the schema fully documents it. The description adds no syntax or format detail about job_id, matching the baseline 3 when the schema does the heavy lifting.
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 clearly what the tool returns: who is in the transcript, how long each speaker talks, and their speaker ids. This is specific enough to distinguish it from get_transcript or list_transcripts, but it does not explicitly name a sibling or frame itself as a verb+resource.
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?
Implies usage via 'their speaker ids for renaming' (routing toward rename_speaker) and the interviewer/interviewee tip, but gives no explicit when-to-use/when-not or named alternatives. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The abstract, key points, verbatim pull quotes with timestamps, and timestamped chapters for a finished transcript. Free.
The cheapest way to find out what a long recording is about. Only present if the job was run with the summary feature.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=true, openWorldHint=true), yet the description adds two traits not in annotations: it is 'Free' (cost behavior, relevant given a sibling named 'estimate') and it may be unavailable unless the job ran with the summary feature. It does not describe error behavior when the feature was not enabled or any rate limits.
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, each earning its place: what you get, why to use it, and the availability constraint. The most decision-relevant content (the return content and the 'cheapest' framing) is front-loaded.
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 no output schema, the description carries the burden of describing the return payload, and it does so explicitly by enumerating the abstract, key points, quotes, and chapters. Combined with the availability precondition and annotation-covered read-only nature, an agent has enough to decide and invoke 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?
There is a single parameter with 100% schema description coverage, so the schema baseline applies. The description adds nothing about job_id semantics (where it comes from, format, or how it relates to sibling tools), so it neither compensates nor detracts.
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 specific artifacts returned (abstract, key points, timestamped pull quotes, timestamped chapters) for a finished transcript, which is far more concrete than a tautology. It positions itself implicitly against get_transcript by framing itself as the cheap way to learn what a long recording is about, but it never names a sibling, so it stops short of full differentiation.
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 a clear use case ('the cheapest way to find out what a long recording is about') and a hard precondition ('only present if the job was run with the summary feature'), which tells the agent when this tool will actually return data. It does not name alternative tools (e.g., get_transcript, search_transcript) for when the summary is absent or when you need the full text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches a transcript by job id, or reports progress if it is still running. Free, and does not charge anything.
Returns a budgeted excerpt rather than the whole transcript, and says so when it truncates. For a question about a specific moment, use search_transcript instead; for the gist, get_summary.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job id. | |
| verbatim | No | Return the raw decode instead of the cleaned text, including fillers and false starts. Use for research or legal work, where the disfluencies are the data. | |
| max_chars | No | Text budget. Defaults to 12000. | |
| timestamps | No | Include a timestamp on each turn. Defaults to true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations, it discloses three non-obvious traits: the call is free, an in-flight job yields progress rather than content, and the return is a budgeted excerpt that self-reports when it truncates. The truncation and cost disclosures materially change how an agent should interpret the response.
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 dense, front-loaded sentences that lead with purpose, then budget/cost behavior, then disambiguation. Slightly marred by the redundant 'Free, and does not charge anything', which says the same thing twice.
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 essential unknowns for a read-only fetch tool with no output schema: cost, async progress, and truncation. It omits edge behavior such as what is returned for an invalid, failed or expired job id, which is the remaining gap for an agent operating on a job-id-keyed resource.
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 verbatim, max_chars and timestamps are already fully documented in the schema. The description alludes to the text budget via 'budgeted excerpt' but adds no syntax, units or defaults beyond what the schema states, 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 and resource ('fetches a transcript by job id') and adds the dual-mode behavior of reporting progress when the job is still running. It names the sibling tools it is not (search_transcript, get_summary), so the agent can place it immediately.
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 explicit routing rules: use this for the full transcript, `search_transcript` for a question about a specific moment, and `get_summary` for the gist. Both alternative tools and the conditions that select them are spelled out rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every language that can be transcribed, and which of them can be translated into. Free. Check a target here before asking for a translation: more languages can be transcribed than translated into.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds information annotations cannot convey: the call is 'Free' and the returned set distinguishes transcribable from translatable languages, which is behavioral context an agent needs before calling a translation 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 tight sentences with no waste; the resource definition leads and the actionable 'check before translating' guidance follows.
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 no output schema, the description usefully characterizes what is returned (the language set and translation coverage), which is exactly what an agent needs from a zero-parameter reference 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?
The tool takes no parameters, so per the baseline this scores 4. There is nothing for the description to clarify about inputs.
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 precisely defines the resource: every transcribable language plus which of them accept translation. It goes beyond the name/title by exposing the transcribe-vs-translate distinction, though it never states a verb ('returns...') or explicitly contrasts with sibling tools.
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 a concrete trigger: 'Check a target here before asking for a translation,' which tells the agent exactly when to consult this tool. No explicit when-not condition is given, but no genuine alternative exists among the transcription siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The account's transcripts, newest first, with their job ids. Free. Use this to find the id of something transcribed earlier.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Defaults to 20. | |
| search | No | Match against the media title. | |
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint) and open-world scope, so the bar is lower, yet the description still adds real context: the ordering ('newest first'), the cost model ('Free'), and the fact that job ids are included. It does not mention pagination behavior, which is the main remaining behavioral gap.
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 with zero waste; the resource, ordering, and returned id are front-loaded before the usage hint. Every clause 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?
With no output schema and three optional parameters, the description carries real burden; it discloses the ordering and the job id field but not the remaining record shape, pagination behavior, or how limit interacts with the newest-first ordering. Adequate but incomplete for a listing 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 coverage is only 67% — limit and search have descriptions but the status enum is bare — so the description is expected to compensate, and it says nothing about filtering. It never signals that the result set can be narrowed by title text or transcription status, leaving the agent unaware of the tool's actual filtering power.
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?
Names the resource (transcripts), the scope ('the account's'), the ordering ('newest first'), and a key returned field ('their job ids'). It is clear what the tool returns, but it never distinguishes itself from the sibling search_transcript, so the agent must infer the difference between listing and searching.
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?
'Use this to find the id of something transcribed earlier' gives an implied use case, which is more than nothing. However, it names no alternatives and no exclusions, so the likely confusion with search_transcript or get_transcript is left unresolved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replaces a speaker's label across the whole transcript in one operation, including in every export. Free. Get the speaker ids from get_speakers first.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | The name to use. | |
| job_id | Yes | The job id. | |
| speaker_id | Yes | A speaker id, e.g. "speaker_0". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false and openWorldHint=true; the description goes further by disclosing the blast radius (every occurrence in the transcript, including exports) and that the operation is free. It stops short of saying whether the rename is reversible or what happens to exports already generated.
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 compact clauses, each carrying distinct information: effect, scope, cost, prerequisite. Front-loaded with the mutating action and no 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?
For a mutation tool with no output schema and no destructiveHint annotation, the description covers effect, scope, cost, and the id prerequisite. Only reversibility/undo behavior and the return value are unaddressed, which is a minor gap rather than a blocking one.
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. The description only adds provenance for speaker_id (from get_speakers); it says nothing extra about label format, length limits, or job_id beyond what the schema already documents.
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 (replaces) plus the exact resource and blast radius: a speaker's label across the whole transcript and every export. That scope statement is what separates it from the read-only sibling get_speakers, which it explicitly routes to for ids.
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?
Gives a concrete prerequisite ('get the speaker ids from `get_speakers` first') and a cost fact ('Free'), so the agent knows what to call before and what this call costs. It does not state when not to use it or that it is irreversible, so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches a finished transcript and returns matching turns with their timestamps and speakers. Free.
Prefer this over reading a whole transcript when the question is about a specific topic or moment. Note it is a literal text search, not a semantic one, so search for words that were actually spoken rather than a paraphrase.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Text to look for, matched case-insensitively. | |
| job_id | Yes | The job id. | |
| max_results | No | Matches to return. Defaults to 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower. The description adds genuinely useful behavior beyond that: the search is literal rather than semantic, results carry timestamps and speakers, and the operation is free. It does not cover pagination or result-limit behavior, which is the one remaining gap.
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 sentences plus a cost note, all front-loaded: return shape first, then the routing decision, then the critical matching-mode caveat. No sentence is 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?
No output schema exists, and the description compensates by naming the return contents (matching turns with timestamps and speakers). Combined with the routing guidance and the literal-vs-semantic warning, an agent has everything needed to select and invoke it 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 coverage is 100%, so the baseline is 3. The description earns above baseline by clarifying the nature of the 'query' parameter — literal spoken-text matching, not paraphrase — which materially changes how an agent should construct the query. The max_results default is left to 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?
States a specific verb and resource ('searches a finished transcript') plus what it returns ('matching turns with their timestamps and speakers'). It also implicitly distinguishes itself from the sibling get_transcript by framing itself as the targeted alternative to reading a whole transcript.
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 prefer this tool over the alternative ('Prefer this over reading a whole transcript when the question is about a specific topic or moment'). This names both the alternative behavior and the selecting condition, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcribes a recording and returns the transcript. This charges the user's account, by the length of the recording.
Waits for the result and returns it if the job finishes in time. For a long recording it returns a job id instead; call get_transcript with it shortly afterwards.
Refuses anything costing more than 30m of minutes unless confirm_spend is true. When it refuses, tell the user the cost and ask before retrying with confirm_spend.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A YouTube, Vimeo, Twitch, podcast or direct media URL. A playlist or channel URL is rejected; this tool handles one recording. | |
| model | No | Defaults to auto. | |
| features | No | diarization labels the speakers, cleanup removes fillers, summary gives an abstract and key points, chapters gives timestamps (free alongside summary), translation needs translate_to, word_timestamps is free and improves subtitle timing. | |
| language | No | BCP-47 code of the spoken language. Detected when omitted. Set it if you know it: detection reads the opening of the recording, so a video starting with music can be misdetected, and that produces a confidently wrong transcript rather than an error. | |
| vocabulary | No | Names, products and jargon the model would otherwise mishear. Free, and the largest accuracy improvement available on specialised audio. | |
| translate_to | No | BCP-47 target. Adds the translation feature automatically. | |
| confirm_spend | No | Set true only after the user has been told the cost and agreed to it. | |
| speaker_count | No | How many speakers there are, if known. More reliable than letting the clusterer guess; for an interview, this is 2. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false and openWorldHint=true; the description adds the material traits: the call charges the user's account by recording length, it blocks waiting for the result, it may return a job id instead of a transcript, and it has a spend guardrail at 30 minutes of audio. That is exactly the cost/permission context an agent needs before invoking.
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?
Front-loaded with the verb and the cost warning in bold, then the return-shape caveat, then the spend guardrail. Every sentence carries a distinct, actionable fact with no restatement of the name or title.
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 no output schema, the description still covers both return shapes (inline transcript vs job id for follow-up) and the cost/consent flow. Combined with a fully documented 8-parameter schema, nothing an agent needs to call this correctly is missing.
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 schema already documents url, model, features, language, vocabulary, translate_to, speaker_count and confirm_spend in detail. The description only adds meaning to one parameter — the 30-minute threshold and user-consent requirement behind `confirm_spend` — so it sits at the baseline rather than adding much 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?
States a specific verb+resource (transcribes a recording, returns the transcript) and immediately differentiates itself from list/search siblings by describing the async job-id path through get_transcript. An agent can tell it apart from get_transcript, list_transcripts and search_transcript without opening any schema.
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?
Explicit conditionals: long recordings return a job id and require a follow-up call to `get_transcript`; jobs over 30 minutes of audio are refused unless `confirm_spend` is true, and the refusal path tells the agent to surface cost and ask the user first. The main gap is that `estimate` (a sibling) is never named as a pre-flight cost check, but the when/when-not guidance present is unusually complete.
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.
v1.0.0cancel_transcriptionestimateget_speakersget_summaryget_transcriptlist_languageslist_transcriptsrename_speakersearch_transcripttranscribeScored across 10 tools
Each tool has a clearly distinct role: estimate (free pricing/preview), transcribe (charges), get_transcript (fetch by id), search_transcript (literal search), get_summary (abstract), plus account/list/speaker lifecycle tools. Descriptions even cross-reference each other to steer selection (e.g., search vs get vs summary). No meaningful overlap.
Most tools follow a verb_noun pattern (get_transcript, search_transcript, get_summary, list_transcripts, get_speakers, rename_speaker, cancel_transcription, list_languages). The two bare verbs 'estimate' and 'transcribe' deviate slightly, but the style remains readable and predictable.
Ten tools for a transcription service is well-scoped: pricing, execution, retrieval in several modes, speaker management, cancellation, and language listing each earn their place without redundancy.
Full lifecycle is covered: estimate → transcribe → retrieve/summarize/search → manage speakers → cancel, plus language discovery. Minor gap: list_languages references translations ('check a target before asking for a translation'), implying a translate operation that no tool exposes.
Transcribe audio and video with Speechmatics speech-to-text from Claude and any MCP client.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
MCP server for RiverScript, an AI transcription platform - fetches transcripts shared via a link.
Memoket — access your recording transcripts, summaries, and key takeaways over MCP.
