Allows transcribing audio from YouTube links, with optional speaker diarization and language auto-detection, returning the transcript in one call.
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., "@orchard-mcp Transcribe /Users/me/call.mp3 and tell me who said what."
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.
Speech-to-text for real-world Spanish and Portuguese, as MCP tools.
Orchard is a transcription and speaker-diarization API built for LATAM audio: call centers, phone recordings, meetings, field audio. This server lets any MCP-capable assistant (Claude Desktop, Claude Code, Cursor, custom agents) transcribe audio conversationally.
tool | what it does |
| Transcribe a local audio file. Optional speaker diarization ( |
| Transcribe from a YouTube link or direct audio URL. |
| Fetch a job's transcript, optionally as |
| Account usage summary and remaining balance. |
Long audio is handled automatically: the tool enqueues the job, polls until it finishes and returns the final transcript in one call.
Related MCP server: MCP Audio Server
Get an API key at orchardrun.com (free tier, no card required).
Add the server to your MCP client config:
{
"mcpServers": {
"orchard": {
"command": "npx",
"args": ["-y", "orchard-mcp"],
"env": { "ORCHARD_API_KEY": "ork_..." }
}
}
}For Claude Code:
claude mcp add orchard -e ORCHARD_API_KEY=ork_... -- npx -y orchard-mcp"Transcribe /Users/me/call.mp3 and tell me who said what."
"Transcribe this YouTube interview and summarize each speaker's position."
"Transcribe meeting.wav with diarization for 3 speakers and give me the
action items per person."
"Get job abc123 as SRT subtitles."
Language is auto-detected when omitted; pass language: "es" (or pt,
en, ...) to pin it.
prompt biases the transcriber toward names, brands or domain jargon.
Set ORCHARD_API_URL to point at a different environment (defaults to
https://api.orchardrun.com).
MIT © Orchard
Fetch the status or final transcript of a previously started Orchard transcription job (use the job_id returned by the transcribe tools). Optionally return it formatted as srt, vtt, md or plain text.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | json | |
| job_id | Yes | Job id returned by a transcribe tool. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It discloses that it returns status or final transcript and supports formatting options, implying a read operation. However, it does not explicitly state that it is non-destructive, nor does it mention error behavior (e.g., job not found) or rate limits. This is a moderate gap for a tool with zero annotation coverage.
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, well-structured sentence that front-loads the core action ('Fetch the status or final transcript') and immediately follows with the required job_id context and optional formatting options. There is no wasted text; every clause adds value.
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 is a simple retrieval operation with no output schema and no annotations. The description covers the essential usage (job_id requirement), the return type (status or transcript), and formatting options. It does not detail the structure of the status object or error conditions, but these are minor for an agent that only needs to call it correctly. Overall, it is sufficiently complete for its simplicity.
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 50% (job_id has a description, format has only an enum). The description adds meaning to the format parameter by listing 'srt, vtt, md or plain text', which clarifies the enum values. For job_id, it merely restates the schema's description, so it does not add extra semantics. It partially compensates for the missing format description but does not fully explain all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'transcription job', and specifies it retrieves status or final transcript for previously started jobs. It distinguishes itself from siblings like transcribe_file and transcribe_url (which start jobs) and get_usage (which reports usage), making the purpose 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?
The description provides clear context by instructing to use the job_id returned by transcribe tools, establishing a prerequisite. It does not explicitly mention when not to use it or list alternatives, but the sibling names imply the distinction. It lacks explicit exclusions but is clear enough for an agent to decide when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the Orchard account's usage summary and remaining balance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'Show' implies a read-only operation with no side effects, but the description does not explicitly state safety or lack of mutation. It also does not disclose authentication or rate limits, though these are less critical for a usage query.
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, front-loaded sentence with no filler. It immediately states the action and the resource, making it both concise and effectively structured.
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 the tool's simplicity (no parameters, no output schema), the description sufficiently explains what the tool returns: a usage summary and remaining balance. It does not detail the format of the summary, but for a basic usage tool this is adequate. No output schema means the description must convey return information, and it does.
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 parameters, and schema description coverage is 100% vacuously. The baseline for no parameters is 4, and the description does not need to add parameter meaning. It provides a clear purpose without any parameter ambiguity.
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 ('Show') and a specific resource ('Orchard account's usage summary and remaining balance'), making its purpose unambiguous. It also distinguishes itself from siblings (transcribe_file, transcribe_url, get_transcription) which are all transcription-related, so no confusion is possible.
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 explicitly state when to use this tool versus alternatives. However, the siblings are all transcription tools, making it obvious that this tool is for account usage, but the guidance is implied rather than explicit. There is no mention of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcribe a local audio file (wav, mp3, m4a, ogg...) with Orchard. Handles Spanish and Portuguese real-world audio (calls, meetings, field recordings) especially well; language auto-detected when omitted. Set diarize=true to get speaker-labeled turns.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the audio file on this machine. | |
| prompt | No | Bias the transcriber toward domain terms, names or acronyms. | |
| diarize | No | Label who said what (speaker diarization). | |
| language | No | ISO code like 'es', 'pt', 'en'. Leave empty to auto-detect. | |
| num_speakers | No | Exact number of speakers, if known. Improves diarization on phone calls. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: language auto-detection, diarization option, and specialization in Spanish/Portuguese real-world audio. It does not mention output format or potential limitations, but for a transcription tool these are largely implied. It is honest and adds useful behavioral context beyond the 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?
Two sentences with no waste. The main action is front-loaded, supported formats are listed, language handling and diarize are explained efficiently. 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?
For a 5-param tool with no output schema and no annotations, the description covers the core functionality and the two most important behavioral options (language auto-detect and diarization). It does not explicitly state the return value (transcription text), but that is heavily implied by the tool name and action. Minor gaps like file size limits or error handling are not critical for correct invocation.
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 adds value for language (auto-detect when omitted) and diarize (speaker-labeled turns), which enriches understanding beyond the schema. It doesn't elaborate on prompt or num_speakers, but the schema already covers them adequately. The extra context justifies a 4.
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 action (transcribe) and resource (local audio file), lists supported formats, and clearly differentiates from the sibling transcribe_url by emphasizing 'local'. It is unambiguous and specific.
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 provides clear context: it is for local files, handles Spanish/Portuguese well, and language auto-detects when omitted. It gives usage tips like setting diarize=true, but does not explicitly name the alternative for remote files (transcribe_url) or state when not to use this tool. The 'local' qualifier strongly implies the URL tool, so it's close but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcribe audio from a URL (YouTube link or a direct audio file URL) with Orchard. Language auto-detected when omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | YouTube URL or direct audio URL. | |
| prompt | No | Bias the transcriber toward domain terms, names or acronyms. | |
| diarize | No | Label who said what (speaker diarization). | |
| language | No | ISO code like 'es', 'pt', 'en'. Leave empty to auto-detect. | |
| num_speakers | No | Exact number of speakers, if known. Improves diarization on phone calls. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry transparency. It mentions language auto-detection but does not specify side effects, output format, or rate limits. No contradictions.
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?
One concise sentence front-loaded with the action. No unnecessary details.
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 description is sufficient for a simple tool but lacks any mention of the return value or error conditions. Could be more complete with output expectations.
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 descriptions are comprehensive (100% coverage), so description adds little extra. The description does not clarify parameter relationships beyond what schema already states.
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 from a URL' (YouTube or direct audio). Clearly distinguishes from sibling tools like transcribe_file which presumably handles files.
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 for URL-based audio, but does not explicitly mention alternatives like transcribe_file for files. Lacks explicit when-not to use.
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.
v0.1.0get_transcriptionget_usagetranscribe_filetranscribe_urlScored across 4 tools
Each tool has a clear, non-overlapping purpose: transcribe_file and transcribe_url cover different input sources, get_transcription retrieves results, and get_usage handles account info. No ambiguity exists.
All tool names follow a consistent verb_noun pattern (transcribe_file, transcribe_url, get_transcription, get_usage), with clear and predictable naming.
Four tools is well-scoped for a focused transcription service—covering submission, retrieval, and usage—without unnecessary bloat or missing essentials.
The core lifecycle of transcription (start from file or URL, fetch result) and account usage is covered. A minor gap is lack of cancellation or listing jobs, but the surface is sufficiently complete for typical use.
Transcribe audio and video with Speechmatics speech-to-text from Claude and any MCP client.
AI transcription from URLs or files. 119 languages, diarization, SRT/VTT/text export.
Audio for your agent: transcribe, speak, translate, summarise, plus sound effects and music.
Transcribe audio & video to text for AI agents: 100+ languages, speaker labels, webhooks.
