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., "@Importly MCP Server Transcribe this talk and summarize the key points: https://www.youtube.com/watch?v=abc123"
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.
Give your AI agent the ability to download, transcribe, and inspect any video or audio URL — YouTube, TikTok, X, podcasts, and 1000+ other sites.
Importly runs yt-dlp, rotating residential proxies, ffmpeg, and speech-to-text server-side, so your agent (and you) never deal with IP bans, 429s, cookie rot, or extractor breakage.
Tool | What it does |
| Download media to hosted storage, get a direct link (optionally with a transcript) |
| Speech-to-text with timestamped segments |
| Full metadata: formats, uploader, thumbnails, stats |
| Fast title/duration/thumbnail lookup |
| Remaining credit balance |
Jobs are async: submit tools return a jobId, check tools poll it. Responses tell the agent exactly what to do next.
Related MCP server: yt-dlp-mcp-server
Get an API key at importly.io — $3.00 in free credits, no card required.
Add the server to your MCP client:
claude mcp add importly -e IMPORTLY_API_KEY=your_key -- npx -y importly-mcp{
"mcpServers": {
"importly": {
"command": "npx",
"args": ["-y", "importly-mcp"],
"env": { "IMPORTLY_API_KEY": "your_key" }
}
}
}(Claude Desktop: claude_desktop_config.json · Cursor: .cursor/mcp.json · Cline: MCP settings UI · Windsurf: ~/.codeium/windsurf/mcp_config.json)
"Transcribe this talk and summarize the key points: https://www.youtube.com/watch?v=…"
"Download the audio of this podcast episode and give me a link"
"How long is this video and who uploaded it?"
Usage-based credits (downloads ~$0.01/MB, transcription per media minute) — see pricing. New accounts get $3.00 free.
MIT licensed. The server is a thin wrapper over the Importly API.
Check the remaining Importly credit balance for the configured API key. Use this to diagnose failed jobs (insufficient credits) or as a pre-flight check before large imports/transcriptions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation via 'Check' and adds context that insufficient credits can cause failed jobs, but it does not state whether the operation is non-destructive, how the balance is returned, or any authentication/rate-limit nuances.
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 two sentences, front-loaded with the core action, and contains no extraneous information. It is efficiently structured 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?
Given the low complexity (0 parameters, no output schema), the description covers the essential context: what the tool does and when to use it. However, it does not explicitly describe the return format, which is a minor gap given the absence of an output schema.
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, so the input schema is trivially covered. The description adds no parameter-specific information, but none is needed. A baseline of 4 is appropriate given the absence of 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 tool's function: 'Check the remaining Importly credit balance for the configured API key.' It uses a specific verb ('Check') and resource ('credit balance'), and it distinguishes itself from sibling tools that handle imports, metadata, and transcription.
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 explicit use cases: 'Use this to diagnose failed jobs (insufficient credits) or as a pre-flight check before large imports/transcriptions.' This gives clear context on when to invoke the tool, though it does not mention when-not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a get_basic_metadata job. Returns title, duration, and thumbnail once completed.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | Job id returned by get_basic_metadata |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the returned fields (title, duration, thumbnail) once the job completes, implying a read-only status check. However, it doesn't describe the response before completion, error handling, or whether the job is consumed, leaving some behavioral 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?
The description is two short sentences, front-loaded with the main purpose, and every clause earns its place. No redundancy.
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 polling tool, the description covers the main purpose and final output, but lacks details about the intermediate status response and error behavior. With no output schema, this is a notable gap, though the tool's low complexity keeps it acceptable.
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% and the jobId parameter description already explains its origin. The tool description adds no additional meaning beyond confirming it's for a get_basic_metadata job, 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 clearly states the tool checks the status of a get_basic_metadata job, using a specific verb and resource. It distinguishes itself from sibling tools like check_metadata by explicitly scoping to get_basic_metadata jobs, and adds output details.
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 implies the tool is used after calling get_basic_metadata, and the parameter description reinforces that jobId comes from that call. However, it doesn't explicitly mention alternatives or when not to use, but the context is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of an import_media job. Returns the media download URL (and transcript, if requested) once the job completes.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | Job id returned by import_media |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behavior: it returns a media download URL and optionally a transcript 'once the job completes,' implying it may wait for completion. The read-only nature is evident from 'check the status.' It does not mention error handling, but the described behavior is sufficient for a status-check 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?
The description is a single, front-loaded sentence that states the purpose and return value without redundancy. Every word earns its place, and it is compact and clear.
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 simple (one parameter, no output schema), and the description covers the main return value (URL, optional transcript). It does not describe status values or failure modes, but for a lightweight polling tool, the description is sufficiently 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?
The schema has 100% description coverage for the only parameter (jobId), and its description ('Job id returned by import_media') already defines it clearly. The tool description adds no additional parameter details, but the schema handles the semantics, so the baseline 3 is appropriate.
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 tool's purpose: 'Check the status of an import_media job.' It uses a specific verb ('check') and resource ('import_media job'). This distinguishes it from sibling tools like check_metadata and check_transcription, which target different resources.
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 implies the tool is used to check jobs created by import_media, providing clear context. While it does not explicitly name alternatives, the sibling tools' names (check_metadata, check_transcription) indicate they serve different purposes, so there is no ambiguity about when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a get_metadata job. Returns the full metadata object once completed.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | Job id returned by get_metadata |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It states that the full metadata object is returned once completed, but omits what happens before completion (e.g., returns status, null, or throws). It also does not mention whether the operation is read-only, which is a notable gap for a status-check 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?
The description is two concise sentences, front-loaded with the primary action and followed by the key return behavior. Every word adds value, with no fluff or repetition of schema 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?
For a simple tool with one parameter and no output schema, the description covers the basic purpose and successful return, but it lacks critical detail about the pre-completion response or error handling. Since this is a status-check tool, the behavior when the job is still running is essential and not disclosed, making it minimally adequate.
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 input schema has 100% coverage with a clear description for the single parameter jobId as 'Job id returned by get_metadata'. The tool description adds no additional parameter semantics beyond the schema, so the baseline score of 3 is appropriate.
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 a specific verb ('check the status') and resource ('a get_metadata job'), distinguishing it from sibling tools like get_metadata (which likely initiates the job) and check_basic_metadata (for a different job type). It also specifies the return value, 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 that this tool is used to poll the status of a job started by get_metadata. It does not explicitly mention alternatives or exclusions, but the relationship to get_metadata is evident from the phrasing and parameter description, so the usage is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a transcribe_media job. Returns the transcript text and timestamped segments once completed.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | Job id returned by transcribe_media |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds value by disclosing that the tool returns 'transcript text and timestamped segments once completed,' which is helpful, but it does not mention behavior for incomplete jobs, error handling, or that it is a read-only polling operation. This leaves some gaps but is minimally adequate.
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 concise two-sentence summary, front-loaded with the primary purpose and followed by a key return-behavior detail. Every word earns its place, with no fluff 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?
For a simple one-parameter tool with no output schema or annotations, the description covers the essential purpose and return content. It does not explain exact statuses or output structure, but given the low complexity, the information is sufficient for selection and 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% for the only parameter 'jobId,' and the schema description already explains the origin of the value ('Job id returned by transcribe_media'). The tool description adds no further parameter detail, 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?
The description clearly states the tool checks the status of a transcribe_media job, with a specific verb ('check') and resource ('transcribe_media job'), and distinguishes it from sibling check_* tools by naming the exact job type.
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 context for when to use this tool is clear: it is for checking transcription jobs, and the schema parameter description ('Job id returned by transcribe_media') reinforces that it is used after transcribe_media. No exclusions or alternative tools are mentioned, but none are needed given the resource-specific scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast-path metadata for a video/audio URL: title, duration, and thumbnail only. Cheaper and quicker than get_metadata — use this to identify or validate a media URL before importing or transcribing it. Async: poll check_basic_metadata with the returned jobId.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Media page URL, e.g. https://www.youtube.com/watch?v=... |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the async nature via 'Async: poll check_basic_metadata with the returned jobId', the limited scope of data ('title, duration, and thumbnail only'), and cost-related traits ('Cheaper and quicker'). It does not explicitly state read-only behavior, but 'identify or validate' implies a non-mutating operation, which is sufficient for this context.
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 two sentences: the first states purpose and return scope, the second gives usage guidance and async note. It is front-loaded with the verb and resource, and every sentence adds value without redundancy.
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 must explain what is returned, which it does ('title, duration, and thumbnail'). It also covers the async workflow, differentiating from get_metadata, and provides a clear use case. Given the simple single-parameter schema, the description is complete for an agent to select and invoke the tool 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?
The only parameter (url) has 100% schema description coverage with a concrete example, so the schema already fully documents it. The tool description adds only contextual framing (video/audio URL) but no additional parameter semantics. Per the rubric, baseline 3 is appropriate when schema covers parameters well.
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 it provides 'Fast-path metadata for a video/audio URL' with specific return fields (title, duration, thumbnail), and distinguishes itself from the sibling tool get_metadata by noting it is 'Cheaper and quicker than get_metadata'. This gives a specific verb+resource+scope and differentiates from alternatives.
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 explicitly says 'use this to identify or validate a media URL before importing or transcoding it', providing a clear when-to-use context. It also implies when not to use it by contrasting with get_metadata for richer metadata. The async polling instruction ('poll check_basic_metadata with the returned jobId') further guides usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract full metadata for a video/audio URL (title, description, duration, uploader, formats, thumbnails, view counts) without downloading the media. Works on YouTube, TikTok, X, and 1000+ sites — no yt-dlp to run yourself. Async: poll check_metadata with the returned jobId. For just title/duration/thumbnail, prefer the faster get_basic_metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Media page URL, e.g. https://www.youtube.com/watch?v=... |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the async behavior (poll check_metadata), that no media is downloaded, and that it works across 1000+ sites. It does not mention auth or rate limits, but the core non-blocking pattern is well conveyed.
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 sentences, each earning its place: the first lists fields, the second covers site breadth, the third covers async flow and alternative tool. Front-loaded with the main verb and resource, no redundancy.
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 single-parameter tool with no output schema, the description is self-sufficient. It explains the full lifecycle (submit URL → get jobId → poll check_metadata), lists expected metadata fields, and gives context on which sites work.
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 schema already describes the url parameter with a concrete example, so baseline is 3. The description adds the 'video/audio URL' qualifier and lists supported sites, clarifying accepted input beyond the schema's generic 'Media page URL'.
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 starts with 'Extract full metadata for a video/audio URL' – a specific verb and resource followed by a list of returned fields. It differentiates from the sibling get_basic_metadata by emphasizing 'full metadata', making the tool's unique purpose clear.
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 instructs to prefer get_basic_metadata for lighter needs ('For just title/duration/thumbnail, prefer the faster get_basic_metadata') and tells the agent to poll check_metadata with the returned jobId for results. This is clear when-to-use and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download the video/audio at any URL (YouTube, TikTok, X, and 1000+ sites) to hosted storage and get back a direct download link. Importly runs yt-dlp, rotating residential proxies, and ffmpeg server-side — no local tooling needed. Async: returns a jobId immediately; poll check_import for the result. Optionally also produce a transcript in the same job with includeTranscript.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Media page URL, e.g. https://www.youtube.com/watch?v=... | |
| audioQuality | No | Default medium | |
| includeAudio | No | Include audio stream (default true) | |
| includeVideo | No | Include video stream (default true) | |
| videoQuality | No | Default 720p | |
| includeTranscript | No | Also transcribe the audio in the same job | |
| transcriptLanguage | No | ISO language hint for the transcript, e.g. "en" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses server-side execution via yt-dlp, residential proxies, and ffmpeg, hosted storage output, and async behavior. It lacks details on failure modes or rate limits but is transparent about the core workflow.
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 sentences with no filler: first states the purpose and output, second explains the technical implementation, third covers async behavior and the optional transcript. Information is front-loaded and every sentence 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 7-parameter async tool with no output schema, the description covers the main use case, direct link result, jobId polling, and optional transcript. It does not discuss cost or error handling, but is fairly complete for an import operation.
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 input schema has 100% description coverage, so the baseline is 3. The description adds a bit of meaning by calling out includeTranscript, but it does not elaborate on audio/video quality defaults or transcript language beyond what the schema already provides.
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?
Clearly states 'Download the video/audio at any URL' and lists supported sites (YouTube, TikTok, X, 1000+). This specific verb+resource distinguishes it from sibling check/status 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?
Explains the async pattern: 'returns a jobId immediately; poll check_import for the result.' It also mentions the optional transcript option, but does not explicitly contrast with the sibling transcribe_media tool for transcription-only jobs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcribe the audio of any video/audio URL (YouTube, TikTok, podcasts, and 1000+ sites) to text with timestamped segments. Importly handles the download, audio extraction, and speech-to-text server-side — no yt-dlp or ffmpeg needed. Async: returns a jobId immediately; poll check_transcription for the transcript. Costs scale with media length; set maxCostDollars to cap spend on long media.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Media page URL, e.g. https://www.youtube.com/watch?v=... | |
| language | No | ISO language hint, e.g. "en" | |
| maxCostDollars | No | Abort with a quote if the estimated cost exceeds this cap |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses server-side download/extraction, async behavior (returns jobId, poll check_transcription), and cost scaling with a cap mechanism. This goes beyond a simple 'transcribe' statement and provides useful operational context, though it could mention failure modes or 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 sentences, each earning its place: purpose, server-side handling with no external tools, and async/cost guidance. Information is front-loaded with the main action, and no fluff or repetition. Exceptionally concise for the amount of context provided.
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 covers the essential aspects for a complex async tool: what it does, how to handle the async pattern (jobId + polling), cost implications, and the lack of external dependencies. Even without an output schema, the agent knows how to initiate and retrieve results. This is highly complete for the given 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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining maxCostDollars as 'cap spend on long media,' which enriches the schema's generic description. It also clarifies the tool's output (timestamped segments) indirectly. Language and url are straightforward from schema, so the added context for cost is meaningful.
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 tool's function with a specific verb and resource: 'Transcribe the audio of any video/audio URL... to text with timestamped segments.' It explicitly differentiates itself from siblings by mentioning 'Async: returns a jobId immediately; poll check_transcription for the transcript,' which contrasts with the polling 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?
The description provides clear context for when to use this tool (to transcribe media from various sites) and explicitly names check_transcription as the alternative for obtaining results. It also advises setting maxCostDollars for long media. However, it does not explicitly mention when not to use it relative to other import tools, though the async/cost guidance largely covers usage.
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.0check_balancecheck_basic_metadatacheck_importcheck_metadatacheck_transcriptionget_basic_metadataget_metadataimport_mediatranscribe_mediaScored across 9 tools
Tools are clearly organized into four async operations (import, full metadata, basic metadata, transcription) each with a paired check tool, plus a balance check. The only ambiguity is between import_media with includeTranscript and transcribe_media, but descriptions clarify the intended use.
All tool names follow a verb_noun pattern with action verbs (import_media, get_metadata, transcribe_media) and check_ prefixed status tools (check_import, check_metadata, check_basic_metadata, check_transcription). The pattern is consistent and predictable.
With 9 tools, the server is well-scoped for its purpose: four async operations, four corresponding status checks, and a balance check. Each tool serves a distinct need without redundancy.
The server covers the core workflows of media import, metadata retrieval (full and basic), transcription, and balance monitoring. Minor gaps exist such as no job cancellation or listing, but these are not essential for the stated purpose.
15 media & data tools for AI agents: search, transcribe, subtitles, voiceover, translate & more.
YouTube transcripts, search, channels, playlists and bulk transcript jobs for AI agents. 14 tools.
Any video URL to LLM-ready transcript. ASR built in, no captions needed. TikTok, X, TED and more.
Video, audio, and image processing for AI agents: convert, transcribe, upscale - 150+ operations.
