Transcriptor MCP is an MCP server that extracts video transcripts, subtitles, and metadata from 11 major platforms using yt-dlp, with Whisper fallback for audio transcription when subtitles are unavailable.
Get cleaned transcripts (get_transcript): Fetch plain text transcripts from YouTube, Twitter/X, Instagram, TikTok, Twitch, Vimeo, Facebook, Bilibili, VK, Dailymotion, and Reddit — with auto-discovery of language and subtitle type.
Get raw subtitles (get_raw_subtitles): Retrieve raw SRT/VTT/ASS/LRC subtitle files with full pagination support, specifying language, type (official or auto-generated), and chunk size.
List subtitle languages (get_available_subtitles): Discover available official and auto-generated subtitle languages for any supported video.
Fetch video metadata (get_video_info): Get extended info including title, description, channel, duration, upload date, view/like/comment counts, tags, categories, thumbnails, and live status.
Get chapter markers (get_video_chapters): Extract chapter start/end times and titles from a video.
Batch playlist transcripts (get_playlist_transcripts): Fetch cleaned transcripts for multiple videos from a playlist in one call, with item selection and limits.
Search YouTube videos (search_videos): Search via yt-dlp with filters for result count, pagination offset, upload date, and output in JSON or Markdown format.
Whisper fallback: Automatically transcribes audio via local Whisper or the OpenAI Whisper API when native subtitles are unavailable.
Pagination: Large transcripts and subtitle files are paginated using response_limit and next_cursor parameters.
Production features: Optional Redis caching, Prometheus metrics, authentication support, and Docker containerization.
Flexible deployment: Available over stdio or HTTP/SSE, with direct integration for Cursor, Claude Code, n8n, Smithery, and Glama.
Enables the extraction of video transcripts and metadata from the Bilibili platform.
Allows for retrieving video transcripts and metadata from Dailymotion videos.
Supports fetching transcripts and metadata for videos hosted on Facebook.
Provides capabilities to extract transcripts and metadata from Instagram video content.
Integrates with OpenAI's Whisper API to provide audio transcription fallback when native subtitles are unavailable.
Enables fetching of transcripts and metadata from TikTok videos.
Supports extracting transcripts and metadata from Twitch videos and streams.
Allows for retrieving video transcripts and metadata from Vimeo.
Provides tools to fetch video transcripts, raw subtitles, and detailed metadata including chapters, tags, and thumbnails.
Connect one server. Then ask Claude, ChatGPT or etc about a video: the transcript, the chapters, the metadata, or a single frame. It works with 11 platforms, not only YouTube.
Connect · What to ask · Widgets · Platforms · Self-host
The hosted endpoint is:
https://transcriptor.gateway.mcpal.io/mcp
claude mcp add --transport http transcriptor https://transcriptor.gateway.mcpal.io/mcpThen run /mcp and approve the sign-in in the browser. After this, claude mcp list shows ✔ Connected.
Client | What to do |
Claude (web and desktop) | Open Settings → Customize → Connectors. Select Add → Add custom connector, paste |
ChatGPT | Open Settings → Security and login and turn on Developer mode. Then open Plugins, select +, and paste |
Codex | Add the block below to |
[mcp_servers.transcriptor]
url = "https://transcriptor.gateway.mcpal.io/mcp"
auth = "oauth"Note: ChatGPT developer mode is available on the web, for paid plans. Some releases show this control as Settings → Apps & Connectors → Advanced.
Note:
codex mcp addregisters stdio servers only, so a hosted server goes intoconfig.toml. See the Codex MCP docs.
If your client is not in the list above, add the server with this configuration:
{
"mcpServers": {
"transcriptor": {
"url": "https://transcriptor.gateway.mcpal.io/mcp"
}
}
}If you want to run the server yourself, read Self-host. The tools are the same and you need no account.
Related MCP server: YouTube MCP
Ask for this | Tool |
"Summarize this video for me" |
|
"Give me the subtitles as an SRT file" |
|
"Is there a German track for this video?" |
|
"Who published this and how many views?" |
|
"Go to the part about pricing" |
|
"Show me the screen at 4:12" |
|
"Get transcripts for the first 5 videos in this playlist" |
|
"Find recent videos about X" |
|
Long transcripts come in parts. Each response gives a cursor for the next part, so no text is lost.
Each tool that takes a video accepts url. This is a link from a supported platform or a plain YouTube ID. Each tool returns content (text for the chat) and structuredContent (typed JSON for your code).
get_transcriptClean plain text, without timestamps, HTML, or speaker names. The tool finds the type and the language for you.
Response: videoId, type, lang, text, is_truncated, total_length, start_offset, end_offset. When more text is available, the response also has next_cursor.
get_raw_subtitlesRaw SRT or VTT content, in parts.
Input:
type — official or auto
lang — a language code
response_limit — default 50000, minimum 1000, maximum 200000
next_cursor — the cursor of the previous response
Response: the fields of get_transcript, plus format (srt or vtt) and content.
get_available_subtitlesResponse: official and auto. Each field is a sorted list of language codes. Use this tool first, then give type and lang to the tools above.
get_video_infoExtended metadata from yt-dlp:
identity — videoId, title, description, webpageUrl
author — uploader, uploaderId, channel, channelId, channelUrl
numbers — duration, uploadDate, viewCount, likeCount, commentCount
classification — tags, categories, liveStatus, isLive, wasLive, availability
images — thumbnail and thumbnails
get_video_chaptersResponse: chapters. Each item has startTime, endTime, and title. When the video has no chapters, the list is empty.
get_video_frameInput:
timecode — "MM:SS" or "HH:MM:SS.mmm"
seconds — an alternative to timecode. Give one of the two, not both
format — jpeg (default) or png
width — default 1280, maximum 1920, never larger than the source
quality — 2 to 31, for jpeg only
Response: an image block, plus timestampSeconds, timestamp, mimeType, sizeBytes, and width. This tool needs ffmpeg. The Docker image includes it.
get_playlist_transcriptsInput:
url — a playlist URL, or a watch URL with list=
type, lang, format — the same as get_raw_subtitles
playlistItems — a yt-dlp -I value such as 1:5, 1,3,7, or -1
maxItems — the maximum number of videos
Response: results. Each item has videoId and text.
search_videosInput:
query — the search text
limit — default 10, maximum 50
offset — the number of results to skip
uploadDateFilter — hour, today, week, month, or year
response_format — json (default) or markdown
Response: results. Each item has videoId, title, url, duration, uploader, viewCount, and thumbnail.
Four tools have an interactive interface: get_transcript, get_video_info, get_video_frame, and search_videos. Clients that support MCP Apps and the ChatGPT Apps SDK show this interface in the chat. Other clients get the same data as text and JSON.
YouTube · Twitter/X · Instagram · TikTok · Twitch · Vimeo · Facebook · Bilibili · VK · Dailymotion · Reddit
Each tool that takes a video accepts a link from these 11 platforms. The tool search_videos works with YouTube only, through yt-dlp ytsearch.
The server does not download video or audio files for you. It returns text, metadata, and single frames.
The tools are the same as on the hosted endpoint. You need no account.
Run the server with Docker. The image serves Streamable HTTP on port 4200:
docker run --rm -p 4200:4200 artsamsonov/transcriptor-mcp:latestThen point your client at http://localhost:4200/mcp.
For stdio, give the image an explicit command:
docker run --rm -i artsamsonov/transcriptor-mcp:latest npm run start:mcp{
"mcpServers": {
"transcriptor": {
"command": "docker",
"args": ["run", "--rm", "-i", "artsamsonov/transcriptor-mcp:latest", "npm", "run", "start:mcp"]
}
}
}The server starts with no environment variables. Each variable below is optional.
Variable | Default | Function |
|
| The HTTP listener |
| — | A Netscape cookies file for videos that need an account. See cookies.example.txt |
|
| Set |
|
| Set |
| — | Timeouts, proxy, and JS runtimes. See .env.example |
The same port serves GET /health and GET /metrics. The metrics are in Prometheus format and include the mcp_* counters.
Transport. The server accepts POST /mcp only. GET and DELETE return 405. The server is stateless and sends no Mcp-Session-Id.
The Node process does not check bearer tokens. Put a reverse proxy or a gateway in front of it for authentication and TLS. The hosted endpoint works this way.
REST API. A second image gives the same extraction over plain HTTP:
docker run --rm -p 3000:3000 artsamsonov/transcriptor-mcp-api:latestThe Swagger interface is at http://localhost:3000/docs. For a full stack with the API and the MCP server, read docker-compose.example.yml.
Development.
npm ci
npm run build
npm run dev:mcp # stdio, hot reload
npm run dev:mcp:http # Streamable HTTP, hot reload
npm testYou need Node.js 20 or later, and yt-dlp in your PATH. Frame capture also needs ffmpeg. Other scripts: lint, type-check, format, test:coverage, test:e2e:api, and test:e2e:mcp.
Releases. The version comes from package.json at runtime, through src/version.ts. Change this version, move the [Unreleased] entries of the changelog into the new version, then push a v* tag. CI builds both images and publishes the MCP Registry entry from server.json.
Layout. src/mcp.ts (stdio entry), src/mcp-http.ts (Streamable HTTP), src/mcp-core.ts (tools, prompts, widgets), src/youtube.ts (yt-dlp), src/whisper.ts, src/cache.ts, src/index.ts (REST API), load/ (k6), and src/e2e/ (Docker smoke tests).
Pull requests are welcome. Fork the repository, make a branch, and make sure that npm test and npm run lint pass. Then open a pull request.
The hosted endpoint at transcriptor.gateway.mcpal.io is governed by the Terms of Service and the Privacy Policy.
A server you host yourself is not covered by those documents. It is governed by the MIT License only.
MIT © 2026 samson-art. Read LICENSE.
List available official and auto-generated subtitle languages.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Video URL (supported: YouTube, Twitter/X, Instagram, TikTok, Twitch, Vimeo, Facebook, Bilibili, VK, Dailymotion, Reddit) or YouTube video ID | |
| format | No | Subtitle format (default from YT_DLP_SUB_FORMAT or srt) |
| Name | Required | Description |
|---|---|---|
| auto | Yes | |
| videoId | Yes | |
| official | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds that it lists both official and auto-generated languages, which is minor behavioral context beyond annotations.
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 sentence of 8 words, concise and front-loaded with the action. Every word 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?
Given the presence of annotations and output schema, the description is nearly complete. It covers the core purpose, though it could briefly hint at the return format (e.g., 'returns list of language codes').
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%, with both parameters (url and format) described in detail. The description does not add any extra meaning beyond what the schema already provides, so 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 'List available official and auto-generated subtitle languages' clearly specifies the verb (List) and resource (subtitle languages), and distinguishes from sibling tools like get_raw_subtitles and get_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?
The description provides no guidance on when or when not to use this tool, nor does it mention alternatives. It lacks explicit context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch cleaned subtitles (plain text) for multiple videos from a playlist. Use playlistItems (e.g. "1:5") to select specific items, maxItems to limit count.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Playlist URL (e.g. youtube.com/playlist?list=XXX) or watch URL with list= parameter | |
| lang | No | Language code (e.g. en, ru). Default: en | |
| type | No | Subtitle track type: official or auto-generated (default: auto) | |
| format | No | Subtitle format (default from YT_DLP_SUB_FORMAT or srt) | |
| maxItems | No | Max number of videos to fetch (yt-dlp --max-downloads) | |
| playlistItems | No | yt-dlp -I spec: "1:5", "1,3,7", "-1" for last, "1:10:2" for every 2nd |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds value by specifying that subtitles are 'cleaned (plain text)', which is a behavioral trait not inferable from annotations. 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?
Two sentences, each serving a purpose: first describes the core function, second explains key parameter usage. No extraneous words. Highly efficient.
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 6 parameters, 100% schema coverage, output schema exists, and annotations present, the description covers the core functionality and critical parameters. Minor gap: no mention of return format or error conditions, but output schema likely covers that.
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 goes beyond by providing concrete examples for playlistItems and maxItems ('1:5', '1,3,7'), adding meaning to those 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 'Fetch cleaned subtitles (plain text) for multiple videos from a playlist.' It uses a specific verb ('Fetch'), identifies the resource ('cleaned subtitles for multiple videos from a playlist'), and distinguishes from sibling get_transcript (single video) by specifying 'multiple'.
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 usage hints for playlistItems and maxItems (e.g., 'Use playlistItems (e.g. "1:5") to select specific items, maxItems to limit count.'), but does not explicitly contrast with siblings like get_transcript or get_raw_subtitles. However, the context of 'multiple videos from a playlist' implies the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch raw SRT/VTT subtitles for a video (supported platforms). Optional: type, lang, response_limit (when omitted returns full content), next_cursor for pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Video URL (supported: YouTube, Twitter/X, Instagram, TikTok, Twitch, Vimeo, Facebook, Bilibili, VK, Dailymotion, Reddit) or YouTube video ID | |
| lang | No | Language code (e.g. en, es). When omitted with Whisper fallback, language is auto-detected | |
| type | No | Subtitle track type: official or auto-generated | |
| format | No | Subtitle format (default from YT_DLP_SUB_FORMAT or srt) | |
| next_cursor | No | Opaque cursor from previous response for pagination | |
| response_limit | No | Max characters per response. When omitted, returns full content. When set: min 1000 |
| Name | Required | Description |
|---|---|---|
| lang | Yes | |
| type | Yes | |
| format | Yes | |
| source | No | |
| content | Yes | |
| videoId | Yes | |
| end_offset | Yes | |
| next_cursor | No | |
| is_truncated | Yes | |
| start_offset | Yes | |
| total_length | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint true, confirming safe reads. The description adds valuable behavioral context: optional type/lang, response_limit behavior (full content when omitted), and pagination via next_cursor, which enhances transparency beyond annotations.
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 purpose and efficiently conveys key optional parameters and behaviors. No wasted words.
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 output schema exists (reducing need to explain returns), the description covers essential aspects: supported platforms, format handling, language/track type options, pagination, and response limit behavior. It is complete for the 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?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining response_limit's omitted behavior (returns full content) and notes pagination cursor, providing context not in the schema alone.
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 fetches raw SRT/VTT subtitles for a video, mentioning supported platforms and optional parameters. It distinguishes from siblings like get_available_subtitles (lists available tracks) and get_transcript (likely plain text).
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 advise when to use this tool versus alternatives. It implies usage for raw subtitle fetching but lacks exclusions or contextual guidance for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch cleaned subtitles as plain text for a video (YouTube, Twitter/X, Instagram, TikTok, Twitch, Vimeo, Facebook, Bilibili, VK, Dailymotion, Reddit). Uses auto-discovery for type/language when omitted. Optional: type, lang, response_limit (when omitted returns full transcript), next_cursor for pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Video URL (supported: YouTube, Twitter/X, Instagram, TikTok, Twitch, Vimeo, Facebook, Bilibili, VK, Dailymotion, Reddit) or YouTube video ID | |
| lang | No | Language code (e.g. en, es). When omitted with Whisper fallback, language is auto-detected | |
| type | No | Subtitle track type: official or auto-generated | |
| format | No | Subtitle format (default from YT_DLP_SUB_FORMAT or srt) | |
| next_cursor | No | Opaque cursor from previous response for pagination | |
| response_limit | No | Max characters per response. When omitted, returns full content. When set: min 1000 |
| Name | Required | Description |
|---|---|---|
| lang | Yes | |
| text | Yes | |
| type | Yes | |
| source | No | |
| videoId | Yes | |
| end_offset | Yes | |
| next_cursor | No | |
| is_truncated | Yes | |
| start_offset | Yes | |
| total_length | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint as true. The description adds behavioral context like 'cleaned subtitles', auto-discovery, and pagination via next_cursor, going beyond the annotations.
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-loading the main purpose and then listing optional parameters with their behavior. Every sentence adds value, and there is 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?
Given the presence of an output schema and rich annotations, the description adequately covers the tool's purpose, supported platforms, and parameter behavior. It could mention prerequisites like public access, but overall it is complete enough.
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 schema describes all parameters. The description adds value by clarifying that omitting response_limit returns the full transcript and that type/lang are auto-discovered when omitted.
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 fetches cleaned subtitles as plain text for videos from a wide range of platforms. It distinguishes from siblings like get_available_subtitles and get_raw_subtitles.
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 when to use the tool but does not explicitly state when or when not to use it compared to alternatives. It mentions auto-discovery for type/language, but lacks exclusions or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch chapter markers (start/end time, title) for a video.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Video URL (supported: YouTube, Twitter/X, Instagram, TikTok, Twitch, Vimeo, Facebook, Bilibili, VK, Dailymotion, Reddit) or YouTube video ID | |
| format | No | Subtitle format (default from YT_DLP_SUB_FORMAT or srt) |
| Name | Required | Description |
|---|---|---|
| videoId | Yes | |
| chapters | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds minimal behavioral context beyond stating the action, but does not contradict annotations. A score of 3 is appropriate as it does not significantly enhance transparency.
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?
A single, focused sentence with no unnecessary words. The essential information is front-loaded and efficient.
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 2 parameters and an output schema, the description is mostly sufficient. However, it could mention the return format (array of chapters) to improve completeness, but it is not missing critical information.
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 parameters are documented. The description adds minor context ('start/end time, title') that hints at output fields, but does not substantially improve parameter understanding beyond the schema. 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 verb 'Fetch' and the resource 'chapter markers', specifying what they contain (start/end time, title). This distinguishes it from sibling tools like get_transcript or get_video_info.
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 no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It merely states what the tool does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a single frame from a video at the given timestamp. Provide timecode ("01:23", "00:01:23.500") or seconds; defaults to the first frame. Optional: format (png|jpeg), width (max 1920), quality (jpeg, 2-31). Returns the image plus metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Video URL (supported: YouTube, Twitter/X, Instagram, TikTok, Twitch, Vimeo, Facebook, Bilibili, VK, Dailymotion, Reddit) or YouTube video ID | |
| width | No | Output image width in pixels (default: 1280, max: 1920). Never upscales. | |
| format | No | Image format (default: jpeg) | |
| quality | No | JPEG quality (ffmpeg -q:v): 2 (best) to 31 (worst). Default: 4. Ignored for png. | |
| seconds | No | Timestamp in seconds (alternative to timecode). Default: 0 (first frame) | |
| timecode | No | Timestamp as "MM:SS" or "HH:MM:SS(.mmm)", e.g. "01:23" or "00:01:23.500" |
| Name | Required | Description |
|---|---|---|
| width | Yes | |
| videoId | Yes | |
| mimeType | Yes | |
| sizeBytes | Yes | |
| timestamp | Yes | |
| timestampSeconds | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds useful details like 'Never upscales', format defaults, quality range, and that it returns image plus metadata, going beyond 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 efficient sentences covering key points. Could be slightly more structured but no fluff.
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 full schema coverage, annotations, and output schema, the description is sufficient. It mentions return value and constraints, though doesn't list output metadata fields (but output schema 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?
Schema coverage is 100%, baseline 3. Description enhances with examples (timecode format), defaults (width 1280), and notes (ffmpeg -q:v, ignored for png), adding value.
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?
Clear action ('Capture a single frame') and resource ('from a video') with specific details (at given timestamp). Differentiates from siblings like get_video_info or get_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?
Provides context on defaults (first frame) and optional parameters, but no explicit when-to-use or when-not-to-use compared to alternatives. Still clear enough for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch extended metadata for a video (title, channel, duration, tags, thumbnails, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Video URL (supported: YouTube, Twitter/X, Instagram, TikTok, Twitch, Vimeo, Facebook, Bilibili, VK, Dailymotion, Reddit) or YouTube video ID | |
| format | No | Subtitle format (default from YT_DLP_SUB_FORMAT or srt) |
| Name | Required | Description |
|---|---|---|
| tags | Yes | |
| title | Yes | |
| isLive | Yes | |
| channel | Yes | |
| videoId | Yes | |
| wasLive | Yes | |
| duration | Yes | |
| uploader | Yes | |
| channelId | Yes | |
| likeCount | Yes | |
| thumbnail | Yes | |
| viewCount | Yes | |
| categories | Yes | |
| channelUrl | Yes | |
| liveStatus | Yes | |
| thumbnails | Yes | |
| uploadDate | Yes | |
| uploaderId | Yes | |
| webpageUrl | Yes | |
| description | Yes | |
| availability | Yes | |
| commentCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent. The description adds that it fetches extended metadata and lists examples, but does not disclose potential behaviors like error handling or supported URL format details beyond what is in 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?
The description is a single, concise sentence that effectively communicates the tool's purpose without unnecessary words.
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 presence of an output schema and the tool's straightforward nature (fetching metadata), the description adequately covers what the agent needs to know, including examples of metadata fields and supported platforms.
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%, but the description adds value by detailing supported platforms for the 'url' parameter and specifying default subtitle format for 'format'. This enriches agent understanding beyond the schema alone.
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 fetches extended metadata for a video, listing examples like title, channel, duration, etc. This distinguishes it from siblings that focus on subtitles or chapters.
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?
No explicit guidance on when to use this tool versus alternatives like get_transcript or get_video_chapters. The description does not mention scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search videos on YouTube via yt-dlp (ytsearch). Returns list of matching videos with metadata. Optional: limit, offset (pagination), uploadDateFilter (hour|today|week|month|year), dateBefore, date, matchFilter (e.g. "!is_live"), response_format (json|markdown).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | yt-dlp --date, exact date e.g. "20231215" or "today-2weeks" | |
| limit | No | Max results (default 10) | |
| query | No | Search query | |
| offset | No | Skip first N results (pagination) | |
| dateBefore | No | yt-dlp --datebefore, e.g. "now-1year" or "20241201" | |
| matchFilter | No | yt-dlp --match-filter, e.g. "!is_live" or "duration < 3600 & like_count > 100" | |
| response_format | No | Format of the human-readable content: json (default) or markdown | |
| uploadDateFilter | No | Filter by upload date (relative to now) |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. Description adds parameter details but lacks behavioral context like rate limits or error handling.
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?
Single sentence front-loads purpose and lists key parameters with no wasted words.
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 output schema present, return values are covered. Description explains parameters adequately, though pagination and edge cases could be clearer.
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%. Description adds value with examples (e.g., '!is_live' for matchFilter) and clarifies pagination, though not all parameters gain meaning beyond 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?
The description clearly states the tool searches videos on YouTube via yt-dlp and returns a list with metadata, distinguishing it from siblings like get_video_info.
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?
No explicit guidance on when to use this tool versus alternatives like get_video_info or get_transcript. Usage is implied but not detailed.
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. Dates show when Glama detected each change.
v1.2.0get_video_frameEach tool has a clearly distinct purpose targeting specific aspects of video content processing: subtitles (available, raw, cleaned, playlist), chapters, metadata, and search. There is no overlap in functionality, with clear boundaries between subtitle retrieval methods and other operations.
All tools follow a consistent verb_noun pattern using snake_case (e.g., get_available_subtitles, search_videos). The naming is predictable and readable throughout the set, with no deviations in style or convention.
With 7 tools, the server is well-scoped for video transcription and metadata retrieval. Each tool earns its place by covering distinct operations like subtitle fetching, chapter extraction, info retrieval, and search, without being overly sparse or bloated.
The tool surface provides comprehensive coverage for video transcription and metadata, including CRUD-like operations for subtitles (list, get raw, get cleaned) and extended info. A minor gap exists in subtitle management (e.g., no update or delete tools), but agents can work around this as the focus is on retrieval.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that gives any LLM or agent clean YouTube transcripts on demand: a single video, a whole channel, or a playlist, plus AI cleanup of auto-generated captions. API-key auth, credit-based, same backend as the public v1 API. Get a free API key with 25 free credits at youtubetranscriptdownload.com/account.
MCP server for RiverScript, an AI transcription platform - fetches transcripts shared via a link.
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
An MCP server that provides congressional transcripts
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/samson-art/transcriptor-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
