Turn any video or audio recording into text your AI can read, summarize and search. Say "transcribe my video", drop the file on the private link, and your AI reads the transcript. Free plan, nothing to install.
Scored across 5 tools
Each tool has a distinct role in the transcription workflow: upload-link creation, job-status polling, transcript retrieval, usage checks, and job listing. The descriptions explicitly sequence related tools, and get_job versus list_jobs is clearly separated by purpose (status check vs. finding recordings).
All tools use predictable snake_case verb_noun naming: create_upload_link, get_job, get_transcript, get_usage, and list_jobs. The pattern is consistent enough that an agent can infer tool behavior from the name.
Five tools is well-scoped for a transcription service, covering upload, polling, retrieval, history, and billing in a compact surface. Each tool has a clear role with no redundant entries.
The core lifecycle is covered: create an upload link, poll the job, retrieve the full transcript, list prior jobs, and check remaining usage. Minor gaps exist, such as canceling or deleting jobs, but these are not essential for the primary workflow.
Use when the user wants to transcribe a recording they have on their device. The link page accepts any video or audio file. Give them the link, ask them to drop the file there, then poll get_job.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| url | Yes | Single-use upload page URL. Open it and drop the file. |
| single_use | Yes | Always true; the link works once. |
| upgrade_url | No | Present when the user is nearly or fully out of minutes: where to add hours or upgrade. |
| remaining_seconds | No | Seconds of transcription the user has left (monthly minutes plus any hour pack). |
| expires_in_minutes | Yes | Minutes until the link expires. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is not read-only, not idempotent, and not destructive, so the safety profile is covered. The description adds useful behavioral context beyond that: the link accepts any video or audio file, the user must perform the upload, and the agent must subsequently poll get_job. It does not cover link expiry or reuse limits, which keeps it from a 5.
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-loaded with the usage condition and followed by the exact workflow. Every sentence carries actionable information with no repetition of schema or annotation data.
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 tool with an output schema, the description supplies what the structured fields cannot: the triggering situation, the fact that the user performs the upload, and the required next call to get_job. Nothing essential for correct invocation 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?
There are zero parameters, so there is no parameter semantics for the description to clarify. The baseline for a no-parameter tool 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?
The description identifies the action (give the user an upload link) and the resource (a link page accepting any video or audio file), and the follow-up poll of get_job separates it from the sibling read tools. It is clear, though the core verb 'create a link' is implied through 'Give them the link' rather than stated as a definition.
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 states an explicit trigger ('Use when the user wants to transcribe a recording they have on their device') and then gives the full operating sequence: hand over the link, ask the user to drop the file, then poll get_job. The sibling alternative for the next step is named directly, leaving little to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use to check whether a transcription is finished. Poll every ~10 seconds until status is done or failed.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Job id (UUID). |
| Name | Required | Description |
|---|---|---|
| id | Yes | Job id (UUID). |
| error | No | Failure message when status is failed, otherwise null. |
| status | Yes | queued, running, done or failed (more values may be added). |
| progress | Yes | Progress from 0 to 100. |
| upgrade_url | No | Present when the user is nearly or fully out of minutes: where to add hours or upgrade. |
| duration_seconds | No | Audio length in seconds, or null until known. |
| remaining_seconds | No | Seconds of transcription the user has left (monthly minutes plus any hour pack). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds the valuable behavioral detail that this is a polled, non-terminal operation with two terminal states (done/failed). It does not describe the returned status values, but an output schema exists to cover that.
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, zero filler, with the purpose front-loaded and the polling instruction second. 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 one-parameter read tool with full annotation coverage and an output schema, the description supplies exactly the missing piece: the polling contract and termination condition. Only a pointer to what to do after completion would add more.
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 a single required parameter at 100% schema description coverage ('Job id (UUID)'), the schema carries the semantics fully. The description adds nothing about the id, so the baseline 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 action (check whether a transcription is finished) which clearly identifies this as a status-polling tool for a job. It implicitly separates from get_transcript (content retrieval) and list_jobs (enumeration), though it never names those siblings 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?
Gives concrete operational guidance: poll every ~10 seconds and stop when status is done or failed. It does not say what to do once done (i.e., call get_transcript) or what to do on failure, so the routing to alternatives is left implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use after get_job shows done. For long recordings, keep calling with next_offset until it's absent, then answer from the full text.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Job id (UUID). | |
| format | No | txt, srt or json (default json). | |
| offset | No | Character offset to start at (default 0). | |
| max_chars | No | Max characters to return (default 50000). |
| Name | Required | Description |
|---|---|---|
| text | Yes | This page of the transcript (plain text, SRT, or the json format's text). |
| language | No | Detected language (json format only), or null. |
| next_offset | No | Offset to pass on the next call; absent on the last page. |
| total_chars | Yes | Total characters in the full transcript. |
| duration_seconds | No | Audio length in seconds (json format only), or null. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description's value-add is the ordering dependency and the pagination-until-exhausted behavior, which it does disclose. It stops short of saying what a truncated/absent page looks like, so it is good but not complete.
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, front-loaded with the prerequisite and then the loop; nothing is padded. The closing 'then answer from the full text' is task coaching rather than tool guidance, a minor bit of non-essential content.
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?
An output schema exists, so return values need not be explained, and the description correctly focuses on sequencing and pagination, the non-obvious parts. The unstated identity of 'next_offset' relative to the schema's 'offset' is the remaining gap for an agent driving the loop.
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 id, format, offset and max_chars are already documented, making 3 the baseline. The description adds pagination semantics but refers to 'next_offset', a field that does not exist in the input schema (which uses 'offset'), which risks confusing which parameter to advance.
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 never explicitly says what the tool returns; the reader must infer from the name 'get_transcript' and the phrase 'answer from the full text' that it fetches transcription text. It does implicitly separate itself from get_job by saying to use it after get_job reports done, so the purpose is recoverable but not stated.
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 names the prerequisite tool and condition ('after get_job shows done') and gives an explicit pagination loop ('keep calling with next_offset until it's absent'). That is a clear when-to-use rule with a named alternative, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks how many minutes they have left, or after an out-of-minutes error. Anyone, including free accounts, can add a one-time 5-hour pack for $10 at upgrade_url.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| plan | Yes | Plan id, e.g. free, starter, pro or power (more may be added). |
| period_end | No | ISO 8601 UTC end of the current period, or null. |
| upgrade_url | No | Where to add a one-time hour pack or upgrade the plan. |
| bonus_seconds | No | Seconds left in one-time hour packs (used after the monthly seconds). |
| monthly_seconds | No | Seconds included each period. |
| remaining_seconds | Yes | Seconds of transcription left this period. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered by structured data. The description adds genuinely non-obvious behavior: the result applies to anyone including free accounts, and there is a self-serve remediation path ($10 one-time 5-hour pack via upgrade_url). It does not say whether upgrade_url is a returned field versus an external link, which is the only ambiguity.
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 primary trigger front-loaded and no filler. The second sentence is somewhat tangential to what the tool does, sitting closer to remediation advice than tool definition, but it earns its place for the out-of-minutes recovery scenario.
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?
Zero required parameters, full schema coverage, an output schema, and annotations covering the read-only profile mean very little needs to be said. The description covers when to call and what to do with the result; only the nature of upgrade_url (returned field vs. static URL) is left slightly underspecified.
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 zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The mention of upgrade_url in the description could be misread as an input, but the schema makes clear no inputs exist.
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 conveys the resource clearly – remaining minutes/usage for the account – and the trigger condition makes the outcome unambiguous. It lacks an explicit verb like 'returns' and the second sentence pivots to upsell content, which dilutes focus slightly, but an agent can still tell what this tool yields.
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?
Two concrete invocation triggers are given: the user asking how many minutes are left, and recovery after an out-of-minutes error. No exclusions or alternative tools are named, but none of the siblings (create_upload_link, get_job, get_transcript, list_jobs) overlaps with usage lookup, so there is little to distinguish against.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use to find the user's recordings, e.g. 'my latest recording'. Newest first; no transcript text.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max jobs to return (default 20). |
| Name | Required | Description |
|---|---|---|
| jobs | Yes | The user's jobs, newest first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and closed-world safety, so the bar is lower; the description adds genuinely non-obvious behavior — result ordering (newest first) and the exclusion of transcript text, which tells the agent it must chain to get_transcript for content.
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 clauses; the selection trigger is front-loaded and the behavioral caveats follow without padding. 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?
An output schema exists, so return-value detail is unnecessary, and the description supplies the two facts an agent most needs (ordering, no transcript text). Only the missing differentiation from get_job keeps it short of a 5.
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 single 'limit' parameter is fully documented with its default of 20 in the schema. The description adds nothing about the parameter, so baseline 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?
The description states a concrete retrieval action ('find the user's recordings') and adds scope qualifiers ('Newest first; no transcript text'). Combined with the name/title it clearly identifies a jobs-listing tool, distinguishable from get_job/get_transcript, though it never explicitly says 'list jobs'.
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 trigger example ('my latest recording') implies the discovery scenario — use this when you don't have a job ID. However, it never names the alternatives (get_job for a known ID, get_transcript for content) or states when NOT to use it, so the routing is left to inference.
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.
create_upload_link2 fields changedOutput schema / properties / remaining_secondsAdded value: +{
+ "description": "Seconds of transcription the user has left (monthly minutes plus any hour pack).",
+ "type": "number"
+}Output schema / properties / upgrade_urlAdded value: +{
+ "description": "Present when the user is nearly or fully out of minutes: where to add hours or upgrade.",
+ "type": "string"
+}get_job2 fields changedOutput schema / properties / remaining_secondsAdded value: +{
+ "description": "Seconds of transcription the user has left (monthly minutes plus any hour pack).",
+ "type": "number"
+}Output schema / properties / upgrade_urlAdded value: +{
+ "description": "Present when the user is nearly or fully out of minutes: where to add hours or upgrade.",
+ "type": "string"
+}get_usage2 fields changedOutput schema / properties / bonus_seconds / descriptionPrevious value: -"Carried-over top-up seconds."New value: +"Seconds left in one-time hour packs (used after the monthly seconds)."Output schema / properties / upgrade_urlAdded value: +{
+ "description": "Where to add a one-time hour pack or upgrade the plan.",
+ "type": "string"
+}create_upload_link1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "expires_in_minutes": {
+ "description": "Minutes until the link expires.",
+ "type": "number"
+ },
+ "single_use": {
+ "description": "Always true; the link works once.",
+ "type": "boolean"
+ },
+ "url": {
+ "description": "Single-use upload page URL. Open it and drop the file.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "expires_in_minutes",
+ "single_use"
+ ],
+ "type": "object"
+}get_job1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "duration_seconds": {
+ "description": "Audio length in seconds, or null until known.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "error": {
+ "description": "Failure message when status is failed, otherwise null.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Job id (UUID).",
+ "type": "string"
+ },
+ "progress": {
+ "description": "Progress from 0 to 100.",
+ "type": "number"
+ },
+ "status": {
+ "description": "queued, running, done or failed (more values may be added).",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "status",
+ "progress"
+ ],
+ "type": "object"
+}get_transcript1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "duration_seconds": {
+ "description": "Audio length in seconds (json format only), or null.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "language": {
+ "description": "Detected language (json format only), or null.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "next_offset": {
+ "description": "Offset to pass on the next call; absent on the last page.",
+ "type": "number"
+ },
+ "text": {
+ "description": "This page of the transcript (plain text, SRT, or the json format's text).",
+ "type": "string"
+ },
+ "total_chars": {
+ "description": "Total characters in the full transcript.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "text",
+ "total_chars"
+ ],
+ "type": "object"
+}get_usage1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "bonus_seconds": {
+ "description": "Carried-over top-up seconds.",
+ "type": "number"
+ },
+ "monthly_seconds": {
+ "description": "Seconds included each period.",
+ "type": "number"
+ },
+ "period_end": {
+ "description": "ISO 8601 UTC end of the current period, or null.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "plan": {
+ "description": "Plan id, e.g. free, starter, pro or power (more may be added).",
+ "type": "string"
+ },
+ "remaining_seconds": {
+ "description": "Seconds of transcription left this period.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "plan",
+ "remaining_seconds"
+ ],
+ "type": "object"
+}list_jobs1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "jobs": {
+ "description": "The user's jobs, newest first.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "completed_at": {
+ "description": "ISO 8601 UTC time the job finished, or null.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at": {
+ "description": "ISO 8601 UTC time the job was created, or null.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "duration_seconds": {
+ "description": "Audio length in seconds, or null until known.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "Job id (UUID).",
+ "type": "string"
+ },
+ "status": {
+ "description": "queued, running, done or failed (more values may be added).",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "status"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "jobs"
+ ],
+ "type": "object"
+}create_upload_linkget_jobget_transcriptget_usagelist_jobsTranscribe audio and video and work with your transcript library from any AI app. 119 languages.
Transcribe audio and video into timestamped transcripts, and search and read your transcripts.
Summarize and transcribe videos, audio, documents and web pages; subtitles; search your library.
SubDownload exposes YouTube as an MCP-native data source. Connect via OAuth and your AI agent can summarize videos, fetch full transcripts (even for videos with no captions, via AI ASR), search across channels, and save everything into a private knowledge base. Works with Claude, ChatGPT, Cursor, and 40+ MCP clients. Free credits on signup, no card required.
Add one secure layer between your agents and this server.
