Click on "Install 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-probe-mcp probe /Users/me/videos/sample.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.
Let any MCP client inspect local video and audio files with
ffprobebefore it ships them.
A narrow Model Context Protocol server. It wraps one system, ffprobe, and does one job: return structured media metadata from a local file.
codex mcp add video-probe-mcp -- npx -y github:omidsaffari/video-probe-mcpExposes one tool, probe_media, backed by ffprobe.
Reads a local media file and returns JSON with format, duration, bitrate, file size, and stream metadata.
Uses the bundled ffprobe-static binary by default, or FFPROBE_PATH when you want to point at a system install.
It does not transcode, edit, upload, call a model, or reach a remote API.
Related MCP server: Video Quality MCP Server
codex mcp add video-probe-mcp -- npx -y github:omidsaffari/video-probe-mcpAdd to your MCP config (.mcp.json or the client's mcpServers block):
{
"mcpServers": {
"video-probe-mcp": {
"command": "npx",
"args": ["-y", "github:omidsaffari/video-probe-mcp"]
}
}
}git clone https://github.com/omidsaffari/video-probe-mcp
cd video-probe-mcp
npm install
npm run buildThen point your MCP client's command at:
node /absolute/path/to/video-probe-mcp/dist/index.jsNo API key is needed. By default the server uses the bundled ffprobe-static binary. To use a specific local binary, set FFPROBE_PATH:
{
"mcpServers": {
"video-probe-mcp": {
"command": "npx",
"args": ["-y", "github:omidsaffari/video-probe-mcp"],
"env": {
"FFPROBE_PATH": "/opt/homebrew/bin/ffprobe"
}
}
}
}See .env.example for local development.
probe_mediaInput:
{
"filePath": "/absolute/path/to/video.mp4",
"includeRawJson": false,
"timeoutMs": 15000
}Output is JSON text:
{
"format": {
"name": "mov,mp4,m4a,3gp,3g2,mj2",
"durationSeconds": 12.48,
"bitRate": 3091210,
"streamCount": 2
},
"streams": [
{
"type": "video",
"codec": "h264",
"width": 1920,
"height": 1080,
"frameRate": "30/1"
}
]
}Use absolute paths when possible. Relative paths resolve from the MCP server process cwd, which may differ by client.
Agentic video workflows are growing fast, but agents still need a small deterministic check before they publish a render: "what file did I actually make?" Broad media servers mix generation, editing, conversion, and provider APIs. This server is just the inspect step.
MIT - see LICENSE. Built by Omid Saffari.
Inspect a local video or audio file with ffprobe and return structured format and stream metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absolute path, or a path relative to the MCP server process cwd. | |
| includeRawJson | No | Include the raw ffprobe JSON payload. Defaults to false. | |
| timeoutMs | No | ffprobe timeout in milliseconds. Defaults to 15000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('Inspect') but does not explicitly state that the tool does not modify the file or system state. It also does not mention potential performance impact from running ffprobe. With no annotations to rely on, the description should be more explicit about safety and side effects.
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 17 words, extremely concise, and front-loaded with the core purpose. Every word is informative, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a high-level overview of the output ('structured format and stream metadata') but lacks detail about the exact fields or structure returned. Since there is no output schema, the description should offer more specifics to help the agent understand the return value. However, for a simple tool with 3 parameters, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all parameters. The tool description adds no additional parameter semantics beyond what the schema already provides. Per guidelines, baseline is 3, and no extra value is offered, so score remains 3.
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 inspects local media files using ffprobe and returns structured metadata. The verb 'probe' and resource 'media' are explicit, and the description differentiates from potential sibling tools by mentioning 'ffprobe' and 'structured format and stream 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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites, limitations (e.g., file formats), or when not to use it. Since no sibling tools are listed, the description misses an opportunity to clarify its specific role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0probe_mediaScored across 1 tool
With only one tool, there is no possibility of ambiguity. The agent can clearly identify its purpose.
A single tool trivially satisfies naming consistency, as there is no pattern to conflict with.
One tool is minimal but appropriate for a focused probing server. However, it feels thin compared to typical multi-tool servers.
The tool covers the core functionality of inspecting media files and returning metadata. Minor gaps might exist (e.g., no detailed stream selection), but it is sufficient for its stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Transform video, audio and images, and generate media from prompts. FFmpeg, captions, models.
Run FFmpeg and FFprobe in the cloud: convert, compress, trim and analyze video and audio.
Fetch transcripts, subtitles, chapters, metadata and frames from YouTube and 10+ video platforms
Geometry and CAD file metadata extraction for STL, OBJ, PLY, PCD, LAS/LAZ, glTF/GLB.
