squoosh-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DIRECTORIES | No | Absolute path(s) to the folder(s) the server may read and write, passed as positional CLI arguments (e.g. `npx -y squoosh-mcp /absolute/path/to/images`). If omitted inside a project, the server falls back to the project folder (CLAUDE_PROJECT_DIR), but never your home folder or a filesystem root. Anything outside these folders is refused. | |
| SQUOOSH_MCP_CONCURRENCY | No | Number of images processed in parallel (about 450 MB each for 4 MP images). | min(4, cores ÷ 2) |
| SQUOOSH_MCP_INLINE_SECONDS | No | How long `optimize_images` works before handing back a `jobId`. | 45 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| analyze_imagesA | Scan files, folders or globs and report what is there: format, size, dimensions, transparency, animation. With deep: true, also classify each image (photo, screenshot, graphic, icon, animated) and show the plan optimize_images would follow (candidate formats, sizes, quality target, output path). Read-only. Paged: use offset/nextOffset. Allowed directories: (none configured). |
| optimize_imagesA | Optimise images like an expert, deciding per image. Default policy "auto" writes WebP, which every current browser supports: lossy for photos, lossless or palette for screenshots and graphics, whichever is smallest at the visual target. policy "avif" also tries AVIF (smaller, needs Safari 16.4+); "picture" adds a JPEG/PNG fallback; "keep" keeps the source format. Resizing fits each image's own aspect ratio and never upscales; widths makes srcset sizes; crop makes exact shapes. Writes NEW files to "/optimized/" (or outputDir), never touching originals; re-runs skip unchanged files. Works up to 45s, then returns status "running" with a jobId: call get_job to wait for the rest. Use dryRun: true to preview decisions without encoding. Allowed directories: (none configured). |
| get_jobA | Progress and results of an optimize_images job. Waits up to waitSeconds for it to finish. Results are paged (offset/nextOffset). Jobs are kept in memory for an hour after they finish, until the server stops. |
| cancel_jobA | Stop an optimize_images job. Images already written stay, and are recorded in the manifest so a re-run skips them. |
| compare_imagesA | Visual similarity of an optimised image to its original, as a SSIMULACRA 2 score (100 = identical; 90+ visually lossless; 80+ very high; 70+ high; below 50 visibly degraded), plus both sizes. Use it to check results. Read-only. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool has a clearly distinct role: read-only inspection (analyze_images), mutation (optimize_images), async job control (get_job, cancel_job), and quality verification (compare_images). The get_job/cancel_job pair targets the same job resource but differs cleanly by action (wait/read vs stop). No plausible misselection risk.
All five tools follow a consistent snake_case verb_noun pattern: analyze_images, optimize_images, get_job, cancel_job, compare_images. Even the resource-oriented job tools fit the same verb-first convention, with no style mixing.
Five tools is well-scoped for an image optimization server: inspection, encoding, and verification are all explicit, and get_job/cancel_job exist because optimize_images can return a long-running jobId. Nothing feels padded or missing.
The analyze → optimize → verify → manage-job lifecycle is covered, including dryRun preview, per-policy formats, resize/srcset/crop, and SSIMULACRA 2 checking. Minor gaps: no tool to list/discover outstanding jobs (a jobId is only obtainable from a running optimize call) and no way to clean up or roll back written outputs.