Video Metadata MCP
Enables comprehensive video file metadata management including reading complete metadata information (format, resolution, duration, codecs), editing metadata fields (title, author, description, copyright), managing video tags, and performing batch operations on multiple video files
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., "@Video Metadata MCPread metadata from /videos/tutorial.mp4"
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.
📹 Video Metadata MCP
🚀 基于 Model Context Protocol (MCP) 的专业视频元数据管理服务器,提供完整的视频文件元数据读取、编辑和管理功能。
✨ 功能特性
📖 元数据读取 - 读取视频文件的完整元数据信息(格式、分辨率、时长、编解码器等)
✏️ 元数据编辑 - 修改标题、作者、描述、版权等元数据信息
🏷️ 标签管理 - 添加、删除、搜索视频标签
📦 批量处理 - 批量管理多个视频文件的元数据
🔍 智能搜索 - 根据多种条件搜索视频文件
⚡ 缓存优化 - 智能缓存机制提升性能
Related MCP server: YouTube MCP Server
📋 系统要求
Node.js 18+
FFmpeg (自动包含在依赖中)
🚀 安装
推荐方式(使用 @latest 标签)
npx @pickstar-2002/video-metadata-mcp@latest全局安装
npm install -g @pickstar-2002/video-metadata-mcp@latest🔧 使用方法
在 IDE 中配置 MCP 服务
Cursor / Claude Desktop
在您的 MCP 客户端配置文件中添加:
{
"mcpServers": {
"video-metadata": {
"command": "npx",
"args": ["@pickstar-2002/video-metadata-mcp@latest"]
}
}
}VS Code (使用 MCP 扩展)
{
"mcp.servers": {
"video-metadata": {
"command": "npx @pickstar-2002/video-metadata-mcp@latest"
}
}
}直接运行
# 使用 @latest 标签(推荐)
npx @pickstar-2002/video-metadata-mcp@latest
# 或者全局安装后运行
video-metadata-mcp🛠️ 可用工具
1. 📖 read_video_metadata
读取视频文件的完整元数据信息。
参数:
filePath(string): 视频文件的完整路径
返回: 包含视频完整元数据的JSON对象
2. ✏️ update_video_metadata
更新视频文件的元数据信息。
参数:
filePath(string): 视频文件的完整路径updates(object): 要更新的元数据字段
3. 🏷️ add_video_tags / remove_video_tags
管理视频标签。
参数:
filePath(string): 视频文件的完整路径tags(string[]): 标签列表
4. 🔍 search_videos
在目录中搜索视频文件。
参数:
directory(string): 要搜索的目录路径options(object): 搜索选项
5. 📦 批量操作工具
batch_update_metadata- 批量更新元数据batch_add_tags- 批量添加标签batch_remove_tags- 批量删除标签
📁 支持的视频格式
🎬 MP4 (.mp4)
🎞️ AVI (.avi)
📹 MOV (.mov)
🎥 MKV (.mkv)
📺 WMV (.wmv)
🌐 FLV (.flv)
🕸️ WebM (.webm)
📱 M4V (.m4v)
📝 使用示例
读取视频元数据
// 通过 MCP 客户端调用
{
"tool": "read_video_metadata",
"arguments": {
"filePath": "/path/to/your/video.mp4"
}
}更新视频元数据
{
"tool": "update_video_metadata",
"arguments": {
"filePath": "/path/to/your/video.mp4",
"updates": {
"title": "我的视频标题",
"artist": "pickstar-2002",
"description": "这是一个示例视频",
"tags": ["教程", "演示", "MCP"]
}
}
}🔧 开发
# 克隆仓库
git clone https://github.com/pickstar-2002/video-metadata-mcp.git
cd video-metadata-mcp
# 安装依赖
npm install
# 开发模式运行
npm run dev
# 构建
npm run build❗ 疑难解答
常见问题及解决方案
🚨 问题:遇到 Connection closed 错误
这通常是由于 npx 缓存问题导致的。请按以下顺序尝试解决:
解决方案 1(首选):确认使用 @latest 标签
npx @pickstar-2002/video-metadata-mcp@latest解决方案 2(备用):锁定到特定稳定版本
# 查看可用版本
npm view @pickstar-2002/video-metadata-mcp versions --json
# 使用特定版本(例如 1.0.0)
npx @pickstar-2002/video-metadata-mcp@1.0.0解决方案 3(终极方案):清理 npx 缓存
# 清理 npx 缓存
npx clear-npx-cache
# 或者手动删除缓存目录
# Windows: %USERPROFILE%\.npm\_npx
# macOS/Linux: ~/.npm/_npx
# 然后重新运行
npx @pickstar-2002/video-metadata-mcp@latest🚨 问题:FFmpeg 相关错误
确保系统已安装 FFmpeg:
# Windows (使用 Chocolatey)
choco install ffmpeg
# macOS (使用 Homebrew)
brew install ffmpeg
# Ubuntu/Debian
sudo apt update && sudo apt install ffmpeg🚨 问题:权限错误
在 Linux/macOS 上可能需要适当的文件权限:
# 给予执行权限
chmod +x node_modules/.bin/video-metadata-mcp
# 或使用 sudo(不推荐)
sudo npx @pickstar-2002/video-metadata-mcp@latest🤝 贡献
欢迎提交 Issue 和 Pull Request!
Fork 本仓库
创建您的特性分支 (
git checkout -b feature/AmazingFeature)提交您的更改 (
git commit -m 'Add some AmazingFeature')推送到分支 (
git push origin feature/AmazingFeature)打开一个 Pull Request
📄 许可证
本项目采用 MIT 许可证 - 查看 LICENSE 文件了解详情。
📞 联系方式
如有问题或建议,欢迎联系:
微信: pickstar_loveXX
⭐ 如果这个项目对您有帮助,请给个 Star!
Available Tools
8 toolsadd_video_tagsC
为视频添加标签
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | 视频文件的完整路径 | |
| tags | Yes | 要添加的标签列表 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. '为视频添加标签' implies a write operation but doesn't specify whether it appends tags to existing ones or replaces them, what permissions are required, whether the operation is idempotent, or what happens on failure. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.
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, efficient phrase that communicates the core purpose without any wasted words. It's appropriately sized for a simple tool and gets straight to the point. Every word earns its place in conveying the essential function.
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 this is a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns, what error conditions exist, how tags are formatted, or whether the operation modifies the video file itself. For a tool that presumably changes system state, more behavioral context is needed beyond the minimal purpose statement.
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 description coverage is 100%, with both parameters clearly documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema descriptions. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 action (添加/添加) and resource (视频), making the purpose immediately understandable. It distinguishes from siblings like remove_video_tags and update_video_metadata by focusing on adding rather than removing or updating. However, it doesn't specify whether this adds tags to existing ones or replaces them, which prevents a perfect score.
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. It doesn't mention when to choose add_video_tags over batch_add_tags for single vs. multiple videos, or how it differs from update_video_metadata which might also handle tags. There's no context about prerequisites, error conditions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
batch_add_tagsC
批量为多个视频添加标签
| Name | Required | Description | Default |
|---|---|---|---|
| filePaths | Yes | 视频文件路径列表 | |
| tags | Yes | 要添加的标签列表 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without behavioral details. It doesn't disclose whether this is a mutating operation (implied but not explicit), permission requirements, rate limits, error handling, or what happens if tags already exist. For a batch mutation tool, this is insufficient 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?
The description is a single, efficient Chinese sentence that communicates the core purpose without any wasted words. It's appropriately sized for a straightforward batch operation tool and gets directly to the point.
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 batch mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address what the tool returns, error conditions, side effects, or how it differs from similar tools. The agent would need to guess about important behavioral aspects despite the clear but minimal purpose statement.
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%, so both parameters are documented in the schema itself. The description adds no additional semantic context about parameter formats, constraints, or examples beyond what's already in the schema descriptions. This meets the baseline for high schema coverage.
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 action (添加标签 - add tags) and resource (多个视频 - multiple videos), making the purpose immediately understandable. It distinguishes from individual tagging tools like 'add_video_tags' by specifying batch operation, though it doesn't explicitly mention all sibling differences.
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 like 'add_video_tags' (for single videos) or 'batch_update_metadata' (for broader updates). There's no mention of prerequisites, constraints, or typical use cases, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
batch_remove_tagsC
批量从多个视频中删除标签
| Name | Required | Description | Default |
|---|---|---|---|
| filePaths | Yes | 视频文件路径列表 | |
| tags | Yes | 要删除的标签列表 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral information. It states it's a batch operation and removes tags, but doesn't disclose whether this is destructive (likely yes, but not confirmed), what permissions are needed, how errors are handled with multiple files, or what the response looks like. For a mutation tool with zero annotation coverage, this is insufficient.
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?
Extremely concise single sentence that gets straight to the point. No wasted words or redundant information. Could potentially benefit from slightly more context, but as a standalone statement it's 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 batch mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens when tags don't exist, whether operation is atomic across files, what success/failure responses look like, or any side effects. Given the complexity of batch operations and complete lack of structured metadata, more descriptive context is needed.
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%, so both parameters are well-documented in the schema. The description adds no additional parameter semantics beyond implying the batch nature (multiple videos). It doesn't explain tag format, path requirements, or interaction between parameters. Baseline 3 is appropriate when schema does the heavy lifting.
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 action ('批量删除' - batch remove) and target resource ('标签' - tags) from '多个视频' (multiple videos). It distinguishes from sibling 'remove_video_tags' by specifying batch operation, but doesn't fully differentiate from other batch operations like 'batch_add_tags' beyond the verb.
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 guidance on when to use this tool versus alternatives. It doesn't mention when to choose batch_remove_tags over remove_video_tags (presumably for single video), or when to use this versus batch_update_metadata which might also handle tags. No prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
batch_update_metadataC
批量更新多个视频文件的元数据
| Name | Required | Description | Default |
|---|---|---|---|
| filePaths | Yes | 视频文件路径列表 | |
| updates | Yes | 要更新的元数据字段 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does ('批量更新多个视频文件的元数据') without disclosing behavioral traits. It doesn't mention whether this is a destructive operation, what permissions are required, how errors are handled, what happens to existing metadata not mentioned in updates, or any rate limits. For a batch mutation tool with zero annotation coverage, this is insufficient.
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?
Extremely concise single sentence with zero waste. Every word earns its place - '批量' specifies batch operation, '更新' is the action, '多个视频文件' identifies the resource scope, and '元数据' specifies what's being updated. No redundant information.
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 batch mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address critical context like: what permissions are needed, whether updates are partial or complete replacements, how errors are handled in batch operations, what the return value looks like, or any limitations. The description alone is insufficient for safe and effective use.
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%, so the schema already fully documents both parameters (filePaths and updates). The description doesn't add any meaning beyond what the schema provides - it doesn't explain parameter relationships, constraints, or usage patterns. Baseline 3 is appropriate when schema does all the work.
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 action ('批量更新' - batch update) and resource ('多个视频文件的元数据' - multiple video files' metadata). It distinguishes from siblings like 'update_video_metadata' (singular) by specifying batch operation, but doesn't fully differentiate from 'batch_add_tags' or 'batch_remove_tags' which are also batch operations on video metadata.
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 guidance on when to use this tool versus alternatives like 'update_video_metadata' (for single files) or 'batch_add_tags'/'batch_remove_tags' (for specific metadata operations). The description implies batch context but doesn't provide explicit when/when-not instructions or mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_video_metadataC
读取视频文件的完整元数据信息
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | 视频文件的完整路径 |
TDQS
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 states the tool reads metadata but does not specify what '完整元数据信息' includes (e.g., format, duration, resolution), whether it's a read-only operation (implied but not explicit), potential errors (e.g., file not found), or performance aspects. This leaves significant gaps in understanding the tool's behavior.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, though it could be slightly more structured if it included usage context or output 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?
Given the tool's moderate complexity (reading metadata from files), lack of annotations, and no output schema, the description is incomplete. It does not explain what metadata is returned, how it's formatted, or any limitations (e.g., supported video formats), making it inadequate for full contextual understanding.
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, with 'filePath' clearly documented as '视频文件的完整路径' (complete path to the video file). The description does not add any additional meaning beyond this, such as file format support or path validation rules, so it meets the baseline for high schema coverage without compensating further.
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 action ('读取' meaning 'read') and resource ('视频文件的完整元数据信息' meaning 'complete metadata information of video files'), making the purpose understandable. However, it does not explicitly differentiate from siblings like 'search_videos' or 'update_video_metadata', which might also involve metadata access or modification, so it lacks sibling distinction.
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. It does not mention when to choose it over 'search_videos' for metadata retrieval or 'update_video_metadata' for modifications, nor does it specify any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_video_tagsC
从视频中删除标签
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | 视频文件的完整路径 | |
| tags | Yes | 要删除的标签列表 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('删除/remove') which implies mutation/destructive behavior, but doesn't specify whether changes are permanent, if there are permission requirements, error conditions, or what happens if tags don't exist. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence in Chinese that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential information.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or behavioral constraints. Given the destructive nature implied by 'remove' and the lack of structured safety information, the description should provide more context about the operation's effects and limitations.
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%, with both parameters clearly documented in the schema itself. The description adds no additional parameter information beyond what the schema provides. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 '从视频中删除标签' (remove tags from video) clearly states the action (删除/remove) and target resource (视频标签/video tags). It distinguishes from siblings like 'add_video_tags' by specifying removal rather than addition. However, it doesn't explicitly differentiate from 'batch_remove_tags' which handles similar functionality in bulk.
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. There's no mention of when to choose this over 'batch_remove_tags' for single vs. batch operations, or how it relates to other metadata tools like 'update_video_metadata'. The agent must infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_videosC
在指定目录中搜索符合条件的视频文件
| Name | Required | Description | Default |
|---|---|---|---|
| directory | Yes | 要搜索的目录路径 | |
| options | No | 搜索选项 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions searching '符合条件的' (meaning 'matching conditions') but doesn't specify search behavior (e.g., recursive vs. shallow, case sensitivity, performance characteristics, or error handling). For a search tool with zero annotation coverage, this leaves critical operational aspects undocumented.
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, efficient sentence in Chinese that front-loads the core purpose. There's zero wasted verbiage—every word contributes to stating what the tool does. It's appropriately sized for a straightforward search function.
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 no annotations, no output schema, and a search tool with complex filtering options (nested 'options' object), the description is inadequate. It doesn't explain return format (e.g., list of file paths, metadata), search scope, or error cases. For a tool with 2 parameters (one nested) and rich filtering capabilities, more context is needed.
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%, so the schema fully documents both parameters ('directory' and 'options' with its sub-properties). The description adds no additional parameter semantics beyond implying filtering via '符合条件的'. Baseline 3 is appropriate when the schema does all the heavy lifting.
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 action ('搜索' meaning 'search') and resource ('视频文件' meaning 'video files') with a scope ('在指定目录中' meaning 'in a specified directory'). It distinguishes from sibling tools like 'read_video_metadata' or 'add_video_tags' by focusing on file search rather than metadata operations. However, it doesn't explicitly differentiate from hypothetical similar search tools (e.g., 'search_videos_by_metadata'), so it's not a perfect 5.
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. It doesn't mention sibling tools like 'read_video_metadata' for single-file inspection or 'batch_update_metadata' for modifications. There's no context about prerequisites (e.g., directory accessibility) or limitations (e.g., search depth).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_video_metadataC
更新视频文件的元数据信息
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | 视频文件的完整路径 | |
| updates | Yes | 要更新的元数据字段 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While '更新' implies a mutation operation, it doesn't specify whether this requires write permissions, if changes are reversible, what happens to existing metadata not mentioned in updates, or potential side effects. The description lacks critical behavioral context for a mutation 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, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information.
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 mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns, error conditions, or important behavioral aspects. Given the complexity of metadata updates and the presence of sibling tools with overlapping functionality, more context is needed.
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, so all parameters are documented in the structured schema. The description doesn't add any meaningful parameter semantics beyond what's already in the schema - it doesn't explain the relationship between filePath and updates, provide examples, or clarify edge cases.
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 ('更新' meaning 'update') and resource ('视频文件的元数据信息' meaning 'video file metadata'), providing a specific purpose. However, it doesn't distinguish this tool from its sibling 'batch_update_metadata', which appears to serve a similar function but for batch operations.
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 like 'batch_update_metadata' for multiple files or 'read_video_metadata' for reading instead of updating. There's no mention of prerequisites, constraints, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
8 tool updates
v1.0.0- First observed
add_video_tags - First observed
batch_add_tags - First observed
batch_remove_tags - First observed
batch_update_metadata - First observed
read_video_metadata - First observed
remove_video_tags - First observed
search_videos - First observed
update_video_metadata
TDQS
Scored across 8 tools
Most tools have distinct purposes, but there is some overlap between add_video_tags/remove_video_tags and their batch counterparts, which could cause confusion about when to use which. The core operations (read, update, search) are clearly separated, and the batch operations are logically grouped, but the single vs. batch distinction might not always be obvious to an agent without careful reading of descriptions.
All tools follow a consistent snake_case pattern with clear verb_noun structure (e.g., add_video_tags, read_video_metadata). The naming is predictable and readable, with batch operations prefixed appropriately, making it easy to understand the tool's function at a glance.
With 8 tools, this server is well-scoped for video metadata management. It covers essential operations (read, update, search) and includes both single and batch variants for common tasks, which is reasonable and efficient for the domain without being overwhelming or too sparse.
The toolset covers key CRUD-like operations for video metadata (read, update, search, tag management), with good support for batch processing. A minor gap is the lack of a tool for deleting video files or metadata entirely, which might be needed in some workflows, but the existing tools handle most common use cases effectively.
Related MCP Connectors
social media video downloader: A comprehensive API for extracting video details, metadata, and.
Connect your video workflows to cloud storage. Organize and access video assets across projects wi…
Video, audio, and image processing for AI agents: convert, transcribe, upscale - 150+ operations.
Edit video by talking to your AI — search footage, cut timelines, apply effects, add captions.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables video editing using natural language commands powered by FFmpeg, supporting operations like trimming, merging, format conversion, and more with real-time progress tracking and error handling.51-
- AlicenseBqualityDmaintenanceEnables interaction with YouTube videos by extracting metadata, captions in multiple languages, and converting content to markdown with various templates.1145MIT
- FlicenseNot gradedqualityDmaintenanceManages sports video metadata with CRUD operations for game information, teams, scores, and statistics. Enables advanced search filtering by game type, teams, league, season, and date ranges through PostgreSQL integration.-
- FlicenseNot gradedqualityDmaintenanceWeb-based video editing platform that provides direct editing functionality through a Model Context Protocol server, supporting media file management, timeline editing, and advanced transformation effects.7-