Video Transcriber MCP Server

by nhatvu148

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: checking dependencies, listing supported sites, listing existing transcripts, and transcribing videos. The descriptions are specific and unambiguous, making it easy for an agent to select the correct tool for each task.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (e.g., check_dependencies, list_supported_sites, list_transcripts, transcribe_video). This uniformity enhances readability and predictability, making the tool set easy to navigate and understand.
Tool Count5/5
With 4 tools, the server is well-scoped for its purpose of video transcription. Each tool serves a distinct and necessary function in the workflow, from setup to execution and management, without being overly sparse or bloated.
Completeness4/5
The tool set covers the core video transcription workflow effectively, including dependency checks, site support listing, transcript listing, and transcription itself. A minor gap is the lack of tools for managing or deleting transcripts, but agents can work around this using the list_transcripts tool and external operations.
Average 3.7/5 across 4 of 4 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on July 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states that transcripts older than a given number of days are deleted, but does not mention permanence, undoability, effects on directories, or permission requirements. This is minimal for a delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that convey the core purpose and a hint of benefit. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with no output schema and no annotations, the description lacks important details such as whether deletions are permanent, what the default behavior is for output_dir, and how it interacts with sibling tools. While schema covers parameters, overall context for safe usage is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the description adds no new parameter semantics beyond what the schema provides. The description's mention of 'days' does not enhance understanding of the parameter's format or behavior beyond the schema's example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes transcripts older than a specified number of days, with a clear verb and resource. It implicitly distinguishes from sibling tools like delete_all_transcripts and delete_transcript by focusing on age-based deletion, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool vs alternatives like delete_all_transcripts or delete_transcript. The phrase 'helps manage disk space' provides some context, but without exclusion criteria or usage conditions, the agent has no decision framework.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions returning 'path and details' but does not specify read-only behavior, error handling for missing transcripts, or that it is non-destructive. The hint 'avoid old transcripts' is helpful but insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy, front-loaded with the core action. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description provides adequate context. However, it lacks details on what 'details' are returned, and no output schema exists to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional parameter 'output_dir', so the schema already explains it. The description adds no additional meaning beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'transcript', and clearly indicates 'most recently created/modified', distinguishing it from siblings like 'list_transcripts' (all transcripts) and 'transcribe_video' (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful to avoid accidentally reading old transcripts' implies when to use it, but it does not explicitly state when not to use it or provide alternatives like list_transcripts for selecting a specific version.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it downloads/extracts audio and uses whisper.cpp, but no annotations provided. Missing information on file size implications, time costs, or whether it overwrites existing files. Moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise two sentences, front-loaded with core function. Every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main functionality but lacks details on output structure, error handling, and prerequisites. Given no output schema and no annotations, description is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage; description adds speed and format details but does not explain parameter-specific behavior beyond schema. Baseline is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it transcribes videos from a wide range of platforms and local files. Uses specific verb 'Transcribe' and describes output formats. Distinguishes from sibling tools like delete/list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives. Does not mention when not to use or provide context for selection among siblings. The description mentions speed advantage but lacks clear usage directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions the output includes '1000+ sites' and examples, but does not describe how the list is formatted, if it's paginated, or any performance characteristics. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List all video platforms supported by yt-dlp') and adds useful context without waste. Every element (e.g., '1000+ sites', examples) earns its place by clarifying scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is adequate but has gaps. It explains what the tool does but lacks details on output format or behavioral traits, which are important for an AI agent to use it correctly. This meets minimum viability with clear room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, maintaining focus on the tool's purpose. Baseline is 4 for zero parameters, as it avoids unnecessary repetition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all video platforms') and resource ('supported by yt-dlp'), with explicit examples that distinguish it from sibling tools like 'check_dependencies' or 'transcribe_video'. It goes beyond a tautology by specifying scope and providing concrete examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'yt-dlp' and listing examples, suggesting this tool is for discovering supported platforms before using other video-related tools. However, it lacks explicit guidance on when to use this versus alternatives or any exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It only says 'check if all required dependencies are installed' but does not disclose the return format (e.g., boolean, list of missing modules) or potential side effects. This lack of detail could hinder an agent's understanding of how to interpret the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, 12-word sentence that immediately conveys the tool's purpose. No redundant or extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple with no parameters or output schema, the description omits any indication of the output format or how the agent should interpret the results. Given the absence of annotations, this is a moderate gap; however, the tool's simplicity partially mitigates the need for extensive detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (none needed). The description does not need to elaborate on parameters. With zero parameters, the baseline score is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'check' and identifies the resource as 'required dependencies', listing yt-dlp, ffmpeg, and whisper models. It is unambiguous and distinguishes itself from sibling tools that perform transcription or cleanup operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used before transcription tasks to verify dependency availability. However, it does not provide explicit guidance on when to avoid using it or mention alternatives, but given its straightforward nature, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of disclosure. It clearly indicates destructive behavior ('Delete ALL') and irreversibility ('cannot be undone'). While it does not detail permissions or other side effects, the core behavioral trait is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the action, the second adds a caution. No redundant words, front-loaded with key information, and every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool with two parameters and no output schema, the description covers all essential aspects: the action, confirmation requirement, and optional directory. It could elaborate on what files are affected (e.g., 'transcript files'), but the context is generally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description restates the schema's description for both parameters without adding new semantically meaningful information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Delete' with the specific resource 'ALL transcripts in the output directory', clearly distinguishing it from sibling tools like delete_transcript (single transcript) and cleanup_old_transcripts (older transcripts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns 'Use with caution' and states irreversibility, implying when to use (only when certain of deletion). However, it does not explicitly state when not to use or provide alternatives, such as using delete_transcript for selective removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 the sorting order and that it lists files from the output directory. It does not mention edge cases (e.g., missing directory) or confirm it is a read-only operation, but the name and action are self-evident.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action and includes key details (sorting order). No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not specify what the return value contains (e.g., filenames, full paths, or metadata). For a list operation, the agent would benefit from knowing the format of the results, especially when no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% – both parameters have descriptions that adequately explain their purpose and defaults. The description does not add additional semantic value beyond what the schema provides (e.g., no further detail on how 'limit' truncates the list).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list'), the resource ('all available transcripts in the output directory'), and the sorting behavior ('sorted by modification time, newest first'). This distinguishes it from sibling tools like 'get_latest_transcript' (returns one) and delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for browsing all transcripts in order, but does not explicitly state when not to use it or mention alternatives like 'get_latest_transcript' for a single result. However, the context is clear enough for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the schema by revealing that deletion removes associated files (txt, json, md). No annotations exist, so description carries full burden. It doesn't discuss reversibility or permissions, but the behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and scope. No wasted words; every sentence provides necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with two parameters and no output schema, the description is largely complete. It covers the main effect (file removal) but omits mention of return values or error handling. Still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to elaborate on parameters. It reinforces the video_id purpose indirectly. The description adds no extra param details, but that is acceptable given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (specific transcript by video ID), and the scope (removes associated files). It distinguishes from siblings like delete_all_transcripts and cleanup_old_transcripts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (delete a specific transcript) but does not explicitly state when not to use or mention alternatives like delete_all_transcripts. Context from sibling names helps, but lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![video-transcriber-mcp MCP server](https://glama.ai/mcp/servers/nhatvu148/video-transcriber-mcp/badges/card.svg)](https://glama.ai/mcp/servers/nhatvu148/video-transcriber-mcp)

Score Badge

Copy to your README.md:

[![video-transcriber-mcp MCP server](https://glama.ai/mcp/servers/nhatvu148/video-transcriber-mcp/badges/score.svg)](https://glama.ai/mcp/servers/nhatvu148/video-transcriber-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nhatvu148/video-transcriber-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server