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., "@lazy-media-mcp prepare /Users/me/demo.mp4 for AI vision"
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.
Local Model Context Protocol (MCP) server that compresses images/videos and prepares media for AI vision agents.
Designed for coding agents (Claude Code, Codex, Grok, and other MCP clients): returns file paths only (no inline base64), so large screenshots and demos stay within tool limits.
Keywords: MCP server, image compression, video compression, ffmpeg, sharp, AI vision prep, frame extraction, Claude, Codex.
Large screenshots and long demos burn context and often fail tool limits. This server:
Shrinks images to a sensible size/quality
Turns videos into frame packs agents can actually open
Uses JPEG by default for widest agent compatibility
Format | Role | Default here? |
JPEG | Best universal image input for local agents | Yes |
PNG | Sharper for OCR / UI text / alpha |
|
WebP | Smaller files when the host supports it | Opt-in only |
MP4 | Storage/sharing re-encode | Video compress default |
WebM | Optional container | Opt-in via |
Format does not improve model understanding by itself. Resolution, blur, and compression artifacts matter more. Over-aggressive WebP/JPEG hurts OCR.
Local agents usually do not natively watch WebM/MP4. Prefer prepare_for_ai / video_extract_frames → JPEG paths.
Related MCP server: mcp-media-engine
Node.js ≥ 20
ffmpeg + ffprobe on PATH (video tools)
# macOS
brew install ffmpegnpx -y lazy-media-mcp
# or
npm install -g lazy-media-mcpgit clone https://github.com/leaf76/lazy-media-mcp.git
cd lazy-media-mcp
npm install
npm run build
npm test
node dist/cli.js # stdio MCP{
"mcpServers": {
"lazy-media": {
"command": "node",
"args": ["/absolute/path/to/lazy-media-mcp/dist/cli.js"],
"env": {
"MEDIA_ALLOWED_ROOTS": "/Users/you,/Users/you/WorkSpace",
"MEDIA_WORKDIR": "/Users/you/.cache/lazy-media-mcp/jobs"
}
}
}
}Tool | Purpose |
| Metadata only |
| Resize/compress image → workdir path |
| Re-encode video (default MP4) |
| Extract frames for vision |
| One-shot profile pipeline (recommended) |
| Delete a job directory by |
prepare_for_ai profilesProfile | Behavior |
| Image → JPEG ≤1536 edge; video → up to 10 JPEG frames |
| Prefer PNG / higher quality |
| Smaller edges, fewer frames |
| Higher quality + optional compressed MP4 |
Variable | Default |
|
|
|
|
| 500MB |
| 200MB |
| 24 |
| 120000 |
|
|
|
|
Path allowlist (realpath checks)
Input/output size caps
Process timeout
ffmpeg/ffprobe invoked with argv arrays only (no shell interpolation)
Outputs go to workdir; originals are not overwritten
Cleanup only deletes direct children of workdir by job_id
1. prepare_for_ai({ path: "/path/to/demo.mp4", profile: "ai_vision" })
2. Read returned outputs[].path frame files in the next vision step
3. media_cleanup({ job_id }) when done (optional)lazy-desktop-mcp — desktop computer-use MCP
lazy_mobile_mcp — Android/iOS mobile automation MCP
session-collab-mcp — multi-session collaboration MCP
MIT © leaf76
Compress/resize an image to a job workdir. Default format is JPEG for local agent compatibility. Returns output file paths only.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| format | No | jpeg | |
| job_id | No | ||
| quality | No | ||
| max_edge | No | ||
| strip_metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. It only discloses that it returns output file paths and defaults to JPEG. It does not mention destructiveness, permissions, or side effects, leaving key behavioral traits unclear.
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, focused sentence that is front-loaded with the action. It is concise and wastes no words, though it could be more informative without significant expansion.
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 complexity of 6 parameters and no output schema or annotations, the description is incomplete. It fails to explain parameter semantics or the workdir concept, leaving agents underinformed.
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 6 parameters with 0% description coverage. The description only relates to the format parameter and output. Most parameters like path, job_id, quality, max_edge, and strip_metadata are left unexplained, adding minimal 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?
The description clearly states the verb 'Compress/resize' and the resource 'image', and distinguishes from sibling tools like video_compress by specifying image. However, it does not elaborate on the scope or use case.
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?
There is no guidance on when to use this tool versus alternatives like video_compress or media_inspect. The mention of 'local agent compatibility' gives a hint but is not explicit enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a previous job directory under the media workdir by job_id.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states 'delete' implying irreversible action but does not mention consequences, required permissions, or error handling. The agent lacks critical safety context.
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 with no filler. It is front-loaded with the action. However, it could be more informative while remaining concise.
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 deletion tool with one parameter and no output schema, the description is insufficient. It lacks details on return values, error states, and prerequisites. The agent would need to infer too much context.
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 0% (no descriptions in schema). The description only says 'by job_id' without explaining the format, source, or validation of job_id. A single parameter with 0% coverage requires compensation, which is minimal here.
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 (delete), the resource (job directory under media workdir), and the identifier (job_id). This specific verb+resource combination distinguishes it from sibling tools that inspect or prepare media.
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 like prepare_for_ai or media_inspect. There is no mention of prerequisites or scenarios where deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect image or video metadata (dimensions, codecs, duration, size). Does not modify files.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively conveys that the tool is non-destructive ('Does not modify files') and lists the metadata fields inspected. However, it lacks details on supported file formats, size 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?
The description is minimal and to the point, with two sentences that add essential information without any redundant or extraneous content.
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 low complexity (single parameter, no output schema), the description covers the core functionality and non-modification behavior. It would benefit from mentioning the return format or supported file types for fuller guidance.
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 sole parameter 'path' has no schema description (0% coverage) and the tool description does not clarify its expected format (e.g., absolute/relative) or constraints beyond being a non-empty string.
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 inspects image or video metadata (dimensions, codecs, duration, size) and does not modify files, distinguishing it from sibling tools like image_compress or video_compress.
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 usage for metadata inspection without modification, but does not explicitly state when to use this tool over alternatives like prepare_for_ai or media_cleanup, nor provides exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-shot AI prep: images are resized/compressed; videos become a frame pack (default). Paths only — no inline base64.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| job_id | No | ||
| profile | No | ai_vision |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that only paths are accepted (no inline base64) and mentions default behavior. However, it does not cover side effects (e.g., file deletion), permissions, or output format. The transparency is moderate.
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 extremely concise with two sentences, each carrying essential information. It is front-loaded with 'One-shot AI prep' and efficiently covers key behavioral aspects.
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 3 parameters and no output schema, the description is insufficient. It does not explain return values, processing details, or prerequisites. The tool's behavior for job_id and non-default profiles is unclear. Completeness is low.
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 0%, but the description adds meaning: 'Paths only' for path, and 'default' for profile. It does not explain job_id or other enum values. The description partially compensates but is incomplete.
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's purpose: 'One-shot AI prep' for images and videos. It specifies actions (resize/compress for images, frame pack for videos) and distinguishes from sibling tools like image_compress and video_extract_frames by combining operations. The resource is well-defined.
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 usage for AI preparation but does not explicitly state when to use this tool versus alternatives. No when-not or prerequisite information is provided. The sibling context helps, but the description lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-encode a video (default MP4/H.264). WebM is optional. Prefer video_extract_frames or prepare_for_ai for agent vision.
| Name | Required | Description | Default |
|---|---|---|---|
| crf | No | ||
| path | Yes | ||
| job_id | No | ||
| container | No | mp4 | |
| max_height | No | ||
| audio_bitrate_k | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only says 'Re-encode' without explaining side effects (overwrites original file, creates new file, permissions needed). Lacks critical behavioral details 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?
Two sentences, zero waste. First sentence states primary purpose, second gives usage guidance. 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?
Given the complexity of video re-encoding (6 parameters, no output schema, no annotations), the description is too brief. It omits output format details, file handling behavior, and parameter explanations.
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 0%, but description only mentions default container format. Does not explain crf, max_height, audio_bitrate_k, or job_id. For 6 parameters, this is insufficient compensation.
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?
Description clearly states action ('Re-encode a video'), resource, and default format (MP4/H.264). It distinguishes from siblings by recommending video_extract_frames or prepare_for_ai for agent vision tasks.
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?
Explicitly advises when not to use this tool ('prefer video_extract_frames or prepare_for_ai for agent vision'). Could be more explicit about when compression is appropriate, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract frames from a video into JPEG/PNG/WebP files for AI vision agents. Returns file paths only.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | count | |
| path | Yes | ||
| format | No | jpeg | |
| job_id | No | ||
| quality | No | ||
| max_edge | No | ||
| max_frames | No | ||
| interval_sec | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions 'Extract frames' and 'Returns file paths only', implying it writes files and does not return binary data. However, it does not explain side effects (e.g., temporary file creation), permissions needed, 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?
The description is extremely concise—two short sentences with no redundancy. Every word adds value.
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 has 8 parameters (1 required) and no output schema, the description is insufficient. It does not explain the extraction modes, parameter constraints, or return format details. For a tool targeting AI vision agents, 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 0%, so the description must compensate for parameter explanations. It only mentions the output format (JPEG/PNG/WebP) but fails to describe key parameters like 'mode' (interval vs count), 'quality', 'max_frames', or 'interval_sec'. This leaves ambiguity for an AI agent.
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 extracts frames from a video into image files (JPEG/PNG/WebP) for AI vision agents, and specifies it returns file paths only. This distinguishes it from siblings like video_compress and media_inspect.
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 indicates the tool is intended for AI vision agents but provides no guidance on when to use it versus alternatives like media_inspect or when to choose different extraction modes. No explicit exclusions or when-not-to-use are mentioned.
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.0image_compressmedia_cleanupmedia_inspectprepare_for_aivideo_compressvideo_extract_framesScored across 6 tools
Each tool has a clearly distinct purpose: AI preparation, metadata inspection, compression for images and videos separately, frame extraction, and cleanup. No overlapping functionality.
Most tools follow a noun_verb pattern (media_inspect, image_compress, video_compress, video_extract_frames, media_cleanup), but prepare_for_ai breaks the pattern with a verb_preposition_noun structure. Still, all use snake_case and are readable.
With 6 tools, the server is well-scoped for media processing and AI preparation. Each tool addresses a specific need without redundancy or excessive granularity.
Covers core operations (compression, inspection, frame extraction, cleanup, and one-shot AI prep). Missing a list_jobs tool to retrieve previous job IDs, but the main workflow is supported.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
MCP server for Wan AI video generation
MCP server for QPost — lets AI agents publish video and image posts to YouTube, TikTok, Instagram.
