multimodal-reader-mcp
Analyzes local audio and video files using Google's Gemini AI models to extract summaries, timelines, transcripts, and observations.
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., "@multimodal-reader-mcpanalyze /home/user/video.mp4 and summarize key moments"
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.
multimodal-reader-mcp
MCP server for reading local audio and video files with Google Gen AI and returning structured observations, timelines, and transcripts.
It analyzes a local media file and returns:
a short summary
a timeline of key moments
transcript snippets for spoken or visible text
key observations and notable signals
relevant clues tailored to the user's question
open questions plus a confidence level
Requirements
uvPython
3.14GOOGLE_API_KEY
Related MCP server: youtube-mcp
Model configuration
The default model is gemini-2.5-flash.
You can override the default model for all requests by setting:
MULTIMODAL_READER_MODEL
MCP client configuration
Example Cursor MCP config:
{
"mcpServers": {
"multimodal-reader": {
"command": "uvx",
"args": ["multimodal-reader-mcp"],
"env": {
"GOOGLE_API_KEY": "${env:GOOGLE_API_KEY}",
"MULTIMODAL_READER_MODEL": "gemini-2.5-flash"
}
}
}
}Tool
The package exposes one MCP tool:
read_media(file_path, question=None)
file_path must be an absolute path to a local media file.
Available Tools
1 toolread_mediaB
Read a local audio or video file and return structured analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| question | No | ||
| file_path | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| model | Yes | Gemini model used for the analysis. |
| summary | Yes | Short summary of the recording. |
| question | Yes | Optional user question that guided the analysis. |
| timeline | Yes | Ordered timeline entries for key moments. |
| file_name | Yes | Basename of the analyzed file. |
| file_path | Yes | Absolute path to the analyzed file. |
| mime_type | Yes | Detected MIME type for the analyzed file. |
| confidence | Yes | Confidence in the analysis based on media quality and clarity. |
| transcript | Yes | Spoken or clearly visible text content. |
| open_questions | Yes | Uncertainties or missing evidence. |
| relevant_clues | Yes | Details most relevant to the user's question or likely follow-up tasks. |
| notable_signals | Yes | Errors, transitions, repeated actions, or unusual signals. |
| key_observations | Yes | Most important direct observations from the media. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly indicates a read-only operation on local media files, which is a key behavioral trait. However, it does not mention supported formats, error conditions, or potential limitations, and with no annotations provided, the description only partially carries the transparency burden.
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 with no unnecessary words. It is concise and front-loads the core action and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and output type, but it leaves the 'question' parameter unexplained and provides no usage guidance. The presence of an output schema partially compensates for return value details, but overall the context is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description implicitly refers to the 'file_path' parameter by mentioning 'local audio or video file', but it says nothing about the 'question' parameter, leaving its purpose completely unexplained. With 0% schema description coverage, the description fails to compensate for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (read), the resource (local audio/video file), and the output (structured analysis). It is specific and unambiguous, and with no sibling tools listed, no differentiation is needed.
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 explicit guidance on when to use this tool, prerequisites, or when not to use it. There are no alternative tools mentioned, so the usage context is implied but not stated.
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.
1 tool update
v0.1.0- First observed
read_media
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of confusing it with another. The tool's purpose is clearly described as reading local audio/video files.
The single tool name 'read_media' follows a consistent verb_noun pattern, though with only one tool, consistency is trivially satisfied.
A single tool feels too thin for a server claiming to be 'multimodal.' The name implies broader media coverage, but only one generic reading operation is provided, which is too few for the apparent scope.
The tool only supports audio and video, leaving out images and other media types that multimodal implies. There are also no supporting operations like format listing or metadata retrieval, creating significant gaps for a reader.
Maintenance
Related MCP Connectors
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
MCP server for Google Veo AI video generation
MCP server for Wan AI video generation
OCR, transcription, file extraction, and image generation for AI agents via MCP.
Related MCP Servers
- AlicenseBqualityFmaintenanceMCP (Model Context Protocol) server that utilizes the Google Gemini Vision API to interact with YouTube videos. It allows users to get descriptions, summaries, answers to questions, and extract key moments from YouTube videos.410 npm6MIT
- AlicenseNot gradedqualityDmaintenanceA local MCP server for extracting YouTube video transcripts, metadata, and performing visual analysis using Gemini Vision or local Whisper models. It enables users to process video content through various tools for subtitle retrieval and frame analysis.10 npmMIT
- AlicenseAqualityFmaintenanceProduction-grade MCP server for image and video understanding and generation across Gemini, OpenAI, and Grok.5564 PyPI4Apache 2.0
- AlicenseNot gradedqualityDmaintenanceMCP server that connects Claude Desktop to Google Gemini, enabling multimodal analysis with file attachments (video, image, audio, PDF).72 npmMIT