This MCP server exposes 9 image/video utility tools that run mostly locally on CPU with no API keys, plus one free hosted generative image tool.
✨ generate_image_free: create an image from a text prompt via Pollinations.ai (free hosted, no API key/signup)
🖼️ remove_background: cut out the subject and save a transparent PNG (local, CPU)
📐 resize_image: high-quality Lanczos resize with optional aspect-ratio preservation
🔄 convert_format: convert between PNG, JPG, and WebP, flattening alpha for JPEG
🎬 video_thumbnail: extract a single frame from a video at a given timestamp
🎞️ video_to_gif: convert a video clip to an optimized GIF using two-pass palette
✂️ video_trim: fast lossless trim of a video without re-encoding
🔍 upscale_image: Real-ESRGAN upscaling via Vulkan (needs discrete GPU; otherwise very slow)
⚡ upscale_image_fast: CPU-only FSRCNN super-resolution for quick upscaling
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., "@mini-creative-toolkit Remove the background from this product photo and save as PNG."
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.
Related MCP server: media-mcp
Removing a background, fitting an image to 1080×1080, converting a folder to WebP, pulling three seconds out of a clip as a GIF, stripping GPS coordinates before you share a photo — none of this needs a model, and none of it needs somebody else's paid API. It is mechanical work, and it finishes on a laptop CPU in about the time it takes to read this sentence.
The interesting property of this project is not that it uses AI. It is how little of it needs to.
Of 23 tools, 22 run entirely on this machine. One — generate_image_free
— genuinely generates an image, so it genuinely has to call a hosted service,
and it says so in its own tool description, in its result payload, in the
capability matrix below, and in SECURITY.md. That tool lives alone in one
file, and a test asserts that no other module imports an HTTP client.
There is no global "CPU-only, no network" claim anywhere in this project, because two of its tools would make such a claim false. Requirements are declared per tool, in one table, from which both the MCP descriptions and the matrix below are generated.
Give an MCP client something like:
"Remove the background from this, make it 1080×1080 without cropping the subject, strip the metadata, and optimise it for the web."
and it has a tool for each step. Or ask it to inspect something first —
inspect_media reports what a file actually is rather than what its
extension claims — and decide from there.
Tool | Does |
| Every tool's requirements and whether this machine can currently run it |
| Format, dimensions, codecs, duration, fps, metadata presence |
| rembg models with size, speed, and licence status |
| Built-in dimension presets |
Tool | Does |
| Lanczos resize; fits inside the box without distorting by default |
| PNG / JPEG / WebP / AVIF, with quality and lossless controls |
| Rebuilds from raw pixels — EXIF, GPS, ICC, XMP, PNG text chunks all gone |
| Semi-transparent text at a corner or the centre |
| Subject cut-out to a transparent PNG |
| Tile many images into one review sheet |
| Byte equality, dimensions, and a coarse similarity score |
Tool | Does |
| FSRCNN — a real super-resolution CNN, CPU, sub-second |
| Real-ESRGAN via Upscayl — best quality, needs a discrete GPU |
| Picks between them and explains which and why |
Tool | Does |
| One frame as a PNG |
| Two-pass palette GIF, with frame-count guards |
| Lossless stream copy, re-encoding only when the copy lands short |
| Scale, always to even dimensions (H.264 requires them) |
| H.264/AAC at a chosen CRF |
| mp3 or wav |
Tool | Does |
| Inspect → choose a pipeline → apply → report every trade made |
| One operation over many files, bounded concurrency, failure isolated |
Tool | Does |
| Text → image via Pollinations.ai. Your prompt is sent to a third party. |
Generated from the same table the MCP tool descriptions use — run
mct capabilities for the live version, including what this machine is
actually missing.
Tool | Local | Network | GPU | External binary | Deterministic |
| yes | no | no | no | yes |
| yes | no | no | no | yes |
| yes | no | no | no | yes |
| yes | no | no | no | yes |
| yes | no | no | no | yes |
| yes | no | no | no | yes |
| yes | first run only | optional | no | per model |
| yes | no | no | no | yes |
| yes | no | required |
| yes |
| yes | no | optional | only if selected | yes |
| yes | no | no |
| yes |
| yes | no | no |
| yes |
| yes | no | no |
| yes |
| yes | no | no |
| yes |
| yes | no | no |
| yes |
| yes | no | no |
| yes |
| yes | no | no |
| yes |
| yes | no | no |
| yes |
| yes | no | no | per operation | yes |
| yes | no | no | no | yes |
| yes | no | no | no | yes |
| yes | no | no | no | yes |
| no | required | no | no | no |
"first run only" is not a hedge: rembg downloads a model's ONNX weights the
first time that model is used, then never again. "per model" means
remove_background is reproducible for a given model but different models
give different cut-outs.
mct capabilities distinguishes two kinds of unmet requirement, because
conflating them sends you looking for a problem you do not have:
blockers — the tool cannot run at all. video_thumbnail without ffmpeg.
limitations — the tool runs, on fewer inputs. inspect_media without
ffprobe still describes every image; it just cannot open a video.
uv syncThat installs the package and its five dependencies. The FSRCNN weights (~120 KB total) ship inside the package — nothing to download.
ffmpeg and ffprobe must be on your PATH for every video and audio tool,
and for inspect_media on non-image files:
sudo apt-get install ffmpeg # Debian/Ubuntu
brew install ffmpeg # macOSEverything else works without them. mct capabilities will tell you exactly
which tools are blocked and why.
upscale_image reuses a local Upscayl
install. Nothing is bundled and nothing is downloaded — point two environment
variables at your own copy:
export UPSCAYL_BIN_PATH=/path/to/upscayl/resources/linux/bin/upscayl-bin
export UPSCAYL_MODELS_PATH=/path/to/upscayl/resources/modelsIf they are unset or wrong, upscale_image raises a clear error naming both
variables — and every other tool keeps working. Skip this entirely and use
upscale_image_fast, which needs no setup at all.
claude mcp add --transport stdio mini-creative-toolkit -- uv run --project /path/to/this/repo toolkit.pytoolkit.py is preserved as a compatibility launcher, so existing
configurations need no change. The modern equivalents:
mct serve
python -m mini_creative_toolkitThe CLI calls the same functions the MCP server does — there is no second implementation of any rule.
mct inspect photo.jpg
mct resize photo.jpg --width 1080 --height 1080
mct convert photo.png --format webp --quality 85
mct optimize photo.png --goal web
mct optimize photo.png --goal social --preset square
mct strip-metadata photo.jpg
mct watermark photo.jpg --text "© 2026" --position bottom-right --opacity 0.4
mct remove-bg photo.jpg
mct upscale icon.png --scale 4 # picks a method and explains it
mct thumbnail clip.mp4 --at 00:00:05
mct gif clip.mp4 --start 00:00:02 --duration 3 --fps 12 --width 480
mct trim clip.mp4 --start 00:00:10 --duration 15
mct compress clip.mp4 --crf 26
mct audio clip.mp4 --format mp3
mct contact-sheet renders/*.png --columns 4
mct compare a.png b.png
mct capabilities
mct presets
mct modelsAdd --json for machine-readable output, --log-level verbose to see the
underlying ffmpeg log when something fails, -o PATH to choose a destination
(--overwrite to allow replacing an existing file).
Exit codes: 0 success, 1 operation failed, 2 usage error.
mct batch photos/*.jpg --operation optimize --options '{"goal":"web"}'
mct batch renders/*.png --operation resize --options '{"width":1080,"height":1080}'or as an MCP call:
{
"paths": ["a.png", "b.png", "c.png"],
"operation": "convert_format",
"options": {"target_format": "webp", "quality": 85}
}returning
{"total": 3, "succeeded": 2, "failed": 1, "results": [...], "errors": [...]}Three properties are enforced, not hoped for:
One bad file never loses the batch. Each item runs in its own
try/except; failures land in errors with their original index.
Concurrency is bounded and conservative. CPU-heavy operations
(remove_background, upscale_fast) get a lower cap than cheap ones —
saturating every core with ONNX sessions makes a batch of 20 slower than
doing them one at a time.
Outputs cannot collide. Generated names carry random bytes as well as a
timestamp, and passing an explicit output_path to a batch is refused
rather than silently ignored.
Nothing is required. Every variable exists to tighten a default or raise a limit your real workload legitimately exceeds.
Variable | Default | Meaning |
|
| Where generated files land |
| (unset) | Restrict file access to these directories |
| 512 | Largest input file |
| 1024 | Largest output file |
| 80000000 | Decompression-bomb guard |
| 3600 | Longest video, in seconds |
| 7680 | Largest video dimensions |
| 200 | Largest batch |
| 4 | Workers for standard operations |
| 2 | Workers for CPU-heavy operations |
| 60 | Hosted call timeout, in seconds |
| 64 | Largest hosted response |
| 900 | ffmpeg / Upscayl timeout, in seconds |
|
|
|
|
| Return a bare path string, as before 2.0 |
| — | Override a preset, e.g. |
| (unset) | Local Upscayl install |
A bad value fails loudly at startup with a message naming the variable, and every resource-limit error names the limit it hit.
Images, read: everything Pillow reads.
Images, written: PNG, JPEG, WebP, and AVIF if your Pillow build has it —
support is probed at runtime rather than assumed, because AVIF depends on how
Pillow was compiled. mct capabilities reports what this install can write.
Video and audio: whatever your ffmpeg build handles. video_resize and
video_compress output H.264/AAC in MP4; extract_audio writes mp3 or wav.
Full detail in SECURITY.md. The short version:
This project is a local media-processing tool, not a sandbox.
It runs as your user with your user's permissions, and MCP does not change that. What it does guarantee:
No shell=True anywhere. A test parses the AST of every module to
enforce it. Commands are argument lists; binaries come from shutil.which.
Every non-path value that reaches argv is shape-constrained.
Timestamps must match a digits-and-colons grammar much narrower than
ffmpeg's own, so a value like -ss or -i cannot be read as an option.
Rejected, never sanitised.
Paths are resolved before they are checked. resolve() collapses ..
and follows symlinks first, so neither traversal nor a planted symlink can
escape a configured allowed root.
Nothing overwrites your input. Writes are staged to a temporary sibling and renamed into place only on success, so a crashed ffmpeg leaves no truncated file and no orphaned GIF palette.
The hosted response is never trusted. Status, content type, a streaming
byte budget, and an actual decode — an HTML error page served with HTTP 200
is refused rather than written out as a .jpg.
If you are exposing this to a model you do not fully trust, set
MCT_ALLOWED_ROOTS. It is unset by default, and SECURITY.md says so
plainly rather than implying an isolation that does not exist.
src/mini_creative_toolkit/
├── config.py MCT_* settings, limits, allowed roots
├── errors.py domain errors; MCP-facing message vs verbose detail
├── validation.py everything that reaches an argv entry passes through here
├── paths.py untrusted-path resolution + staged output manager
├── capabilities.py one table: requirements, readiness, description footers
├── media_info.py the engine behind inspect_media
├── results.py structured result shape
├── log.py stderr, three levels, never logs secrets or prompts
├── engines/ ffmpeg · images (Pillow+OpenCV) · background · upscayl · pollinations
├── tools/ the business rules — MCP and CLI both call these
├── server.py MCP registration and descriptions, no logic
├── cli.py mct — same functions, different surface
└── models/ bundled FSRCNN weightsTwo rules hold the shape:
Business logic exists once. server.py and cli.py both call
tools/. A validation fix lands in both surfaces at the same moment.
Capabilities are declared once. Tool descriptions, the readiness report, and the matrix above all read the same table, so a description cannot drift away from what the tool actually needs.
uv run pytestReal files, real ffmpeg, real encoders — no mocked image libraries. The
exception is the hosted generator, which is tested entirely against an
httpx.MockTransport: CI never contacts Pollinations.ai, and a test suite
that quietly started making outbound requests would contradict the project's
central claim.
The suite covers unit tests for validation, path handling and configuration;
end-to-end image and video tests; security tests for traversal, symlink
escapes, shell metacharacters, unicode and awkward filenames, FIFOs, NUL
bytes, over-long paths and every resource limit; failure-mode tests for the
hosted engine (timeout, 4xx, 5xx, wrong content type, corrupt body, oversized
response); batch failure isolation; a real MCP stdio handshake; and static
checks over the repository itself — no shell=True, no developer-specific
paths, no outbound URL outside the hosted engine.
"ffmpeg was not found on PATH" — install it; the error names the command for your platform. Image tools are unaffected.
upscale_image fails with "UPSCAYL_BIN_PATH is not set" — expected if you
have not installed Upscayl. Use upscale_image_fast or upscale_image_auto.
An operation says a limit was exceeded — the message names the variable and its current value. Raise it if the file is legitimate.
AVIF conversion fails — your Pillow build has no AVIF encoder. Run
mct capabilities to see what it can write.
A GIF request is refused for frame count — fps × duration was too high.
GIF is a poor format above a few hundred frames; lower one of them.
Something failed and the message is short — that is deliberate. Re-run
with MCT_LOG_LEVEL=verbose or --log-level verbose for the underlying log.
Files appear in an unexpected place — set MCT_OUTPUT_DIR. The default is
output/ inside the repository, preserved from before 2.0.
Stated rather than hidden:
upscale_image needs a discrete GPU. Measured on Intel integrated
graphics: a single small icon reached 32% after seven minutes and did not
finish. This is not a bug and it is not being fixed — Vulkan-based
Real-ESRGAN needs real hardware. upscale_image_auto will not select it
unless a discrete GPU is detected.
FSRCNN is not Real-ESRGAN. It sharpens edges; it does not invent texture. Nothing in this project claims otherwise.
compare_images is not forensic. The similarity score is an average
channel difference on 64×64 thumbnails. It is a "same picture?" hint, not
evidence.
Presets are a convenience, not a certification. No platform's current requirements are encoded here and platform requirements change.
generate_image_free depends on a free public service with no
availability or privacy guarantee. If it changes or disappears, nothing
else here is affected.
Model licences are not all verified. Where one was not confirmed
against a primary source, list_background_models says not verified
rather than guessing.
This is not a sandbox. See SECURITY.md.
This repository is MIT. That covers this project's code and nothing else.
Model weights, external binaries and dependencies carry their own terms — and
one commonly-reachable rembg model is non-commercial. See
THIRD_PARTY.md before assuming MIT applies to what a tool
hands you.
Convert an image to another format (png, jpg, webp). Flattens transparency onto white when converting to jpg.
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | Yes | ||
| target_format | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 meaningfully discloses that transparency is flattened onto white when converting to jpg, which is a significant gotcha. It does not detail output file handling or overwrite behavior, but the disclosed conversion behavior is valuable and directly relevant.
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 two sentences long with no wasted words. It front-loads the core action and formats, then adds the critical jpg transparency caveat as a secondary sentence.
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 simple two-parameter conversion tool, the description covers the essential invocation info: what to convert, what formats are supported, and the key edge-case behavior. An output schema exists to explain return values, so the description does not need to repeat return details. Minor ambiguity about output file location remains, but overall it is sufficient.
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 the bare schema. It adds meaning by listing valid target formats (png, jpg, webp), but it does not clarify the exact accepted values for image_path or the output behavior. The parameter semantics are partially enriched but not fully documented.
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 uses a specific verb ('Convert'), identifies the resource ('image'), and names the target formats (png, jpg, webp). It clearly distinguishes this tool from sibling tools like resize_image or remove_background by focusing solely on format conversion.
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 the tool is for changing image formats, and the sibling list makes alternatives obvious, but it does not explicitly state when to use this tool versus others. There is no direct guidance about when not to use it, such as 'for resizing, use resize_image'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image from a text prompt via Pollinations.ai - genuinely free, no API key or signup required.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| width | No | ||
| height | No | ||
| prompt | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool is free, requires no API key or signup, and uses an external service (Pollinations.ai), which is useful behavioral context. It does not mention potential rate limits, output format, or failure behavior, leaving some 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?
One sentence with no filler; it front-loads the action ('Generate an image') and packs the key benefit (free, no auth) compactly. 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?
The description covers the core input (prompt) and the key differentiator (free/no-auth), and an output schema exists so return values are handled elsewhere. However, it omits guidance on dimensions/seeding and the implications of an external network call, leaving the definition incomplete for a 4-parameter tool.
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 only explains the 'prompt' parameter ('text prompt'). The seed, width, and height parameters are not described at all, and schema description coverage is 0%, so the description fails to compensate for the other three 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 uses the verb 'Generate' with the resource 'image' and specifies the input is a text prompt, naming the service Pollinations.ai. This clearly distinguishes it from the sibling manipulation tools (upscale, resize, etc.), though it doesn't explicitly reference them.
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 offers a clear reason to choose this tool—'genuinely free, no API key or signup required'—and the verb 'generate' implies it is for creating new images, not editing existing ones. However, it does not explicitly state when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove the background from an image, saved as a transparent PNG. CPU-only (ONNX via rembg), no API key or GPU needed.
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds meaningful context beyond the schema by stating the output is a transparent PNG and that processing is CPU-only via ONNX/rembg with no API key or GPU needed. It does not detail output file location or side effects, but for a simple image-processing tool this is reasonably transparent.
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 with no redundancy. The core purpose is front-loaded, and the implementation details (CPU-only, ONNX, no API key/GPU) are delivered efficiently in the second sentence.
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 tool has low complexity (one parameter) and an output schema exists, so the description need not explain return values. It covers purpose, output format, and computational constraints. The only notable gap is the lack of explicit guidance on where the output PNG is saved, but this is a minor omission given the simplicity.
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 one parameter, image_path, with 0% description coverage. The tool name and the phrase 'from an image' imply image_path is the input image, but the description does not add details about supported formats or path requirements. The parameter is simple enough that this is adequate but not exemplary.
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 states a specific verb ('Remove the background'), a specific resource ('an image'), and the output format ('saved as a transparent PNG'). This clearly differentiates it from sibling tools like upscale_image, resize_image, and convert_format, which have different purposes.
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 the tool should be used when background removal is needed, but it does not explicitly discuss when to use this tool instead of alternatives. There are no exclusions or comparisons to sibling tools, leaving the usage context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resize an image with high-quality Lanczos resampling. If keep_aspect is true, fits within width x height without distorting.
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | ||
| height | Yes | ||
| image_path | Yes | ||
| keep_aspect | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does add useful behavioral detail: the Lanczos algorithm and the aspect-ratio preservation behavior. However, it does not disclose what happens when keep_aspect is false, whether files are overwritten or written to a new output, or any permissions/limitations.
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 focused sentences, front-loaded with the core action and followed by the edge-case behavior. No filler or repetition, and every clause adds 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?
The core resizing behavior is complete enough for a basic call, and the output schema covers return values. Clear gaps remain around side effects (e.g., whether the input file is modified), supported formats, and the false branch of keep_aspect, which an agent may need to predict behavior.
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 compensates partially by explaining how width/height and keep_aspect interact ('fits within width x height without distorting'). It does not explain image_path semantics or the behavior when keep_aspect is false, leaving some parameter meaning to inference.
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 uses a specific verb-resource pair ('Resize an image') and adds a concrete behavior ('fits within width x height without distorting', 'Lanczos resampling'). It does not explicitly differentiate itself from sibling resize-related tools like upscale_image or convert_format, so it falls short of full sibling-level 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?
No guidance is given about when to choose resize_image over sibling tools such as upscale_image, remove_background, or convert_format. The usage context is only implied by the name and description, with no exclusions, preconditions, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upscale an image with real-ESRGAN via Vulkan (reuses Upscayl's bundled binary/models). Tested and confirmed CORRECTLY SLOW to the point of impracticality on Intel integrated graphics (minutes for a single small icon) - only use this if the machine has a real discrete GPU; otherwise prefer generate_image_free or accept the wait.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | upscayl-standard-4x | |
| scale | No | ||
| image_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does so effectively: it discloses the real-ESRGAN/Vulkan dependency, confirms the tool is tested and extremely slow on Intel integrated graphics, and warns about impracticality. It does not mention output file behavior or side effects, but the performance and hardware constraints are the most decision-critical traits.
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 compact and front-loads the core purpose before adding the critical caveat. The dramatic capitalization and long dash make it slightly less polished, but every sentence provides decision-relevant information and there is no 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 tool has one required parameter and sensible defaults for the other two, so a basic invocation is fully specified. The description adds hardware requirements, performance expectations, and an alternative. Remaining gaps are the semantics of model and scale, but these do not block correct usage when relying on defaults.
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 coverage is 0%, so the description needed to explain the model and scale parameters, but it only implies image_path by saying 'Upscale an image'. The model value 'upscayl-standard-4x' and the scale integer are not explained, leaving an agent unable to customize the operation confidently.
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 states a specific action: 'Upscale an image' using real-ESRGAN via Vulkan, and names the bundled technology. It clearly distinguishes itself from sibling tools like generate_image_free by focusing on upscaling rather than generation or format/resize 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 gives an explicit hardware criterion ('only use this if the machine has a real discrete GPU') and names the alternative route ('otherwise prefer generate_image_free or accept the wait'). This is direct, prescriptive guidance that helps an agent decide when to call this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Grab a single frame from a video as a PNG thumbnail. timestamp is HH:MM:SS.
| Name | Required | Description | Default |
|---|---|---|---|
| timestamp | No | 00:00:01 | |
| video_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It clearly indicates a non-destructive extraction ('Grab a single frame') and specifies timestamp format, but it does not mention failure modes, path requirements, or output handling. The read-only nature is implied rather than explicit.
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 short clauses with no filler; the main action is front-loaded and the timestamp format is a necessary detail. It could be slightly expanded with output or destination information but remains 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 two-parameter tool with an output schema, the description is nearly adequate, but it lacks usage context versus sibling video tools and doesn't state behavior on invalid timestamps or paths. Output result is presumably covered by the schema, so that is not penalized.
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 no property descriptions (0% coverage), so the description is the only explanation. It adds that timestamp uses HH:MM:SS and that the frame comes from 'a video', implying video_path is the source. This partially compensates for the missing schema descriptions but doesn't explain timestamp defaults or path format expectations.
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?
States the verb 'Grab', the resource 'a video', and the output 'PNG thumbnail', plus the timestamp format. This clearly distinguishes it from siblings like video_to_gif and video_trim, which produce animated or trimmed video output rather than a still frame.
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?
Provides no guidance on when to use this tool over alternatives such as video_to_gif or video_trim. An agent must infer from the name alone that this is for single-frame extraction, which is risky when multiple video-related tools are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a video clip to an optimized GIF using a two-pass palette for better quality/size.
| Name | Required | Description | Default |
|---|---|---|---|
| fps | No | ||
| start | No | 00:00:00 | |
| width | No | ||
| duration | No | ||
| video_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral burden. It does disclose a meaningful implementation behavior: 'two-pass palette for better quality/size.' However, it does not mention side effects, output file behavior, source preservation, or any limitations, which keeps this at a mid score.
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, front-loaded, efficient sentence. It wastes no words and gets the core purpose across immediately.
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?
With 5 parameters, 0% schema description coverage, and no annotations, the description is too thin for calling the tool correctly in varied cases. An output schema exists, so return values are covered elsewhere, but parameter semantics and usage context remain under-specified.
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%, and the description does not compensate by explaining any of the 5 parameters. An agent gets no additional meaning for video_path, fps, start, width, or duration beyond their names and defaults.
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 and resource: 'Convert a video clip to an optimized GIF.' It is specific about the output format and even adds a technical detail (two-pass palette). It does not explicitly differentiate itself from sibling tools like convert_format or video_trim, so it stops short of a 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 implies this tool is for turning video clips into GIFs, which gives reasonable context for when to use it. However, it provides no explicit guidance on when not to use it or which alternative (e.g., convert_format, video_thumbnail) would be better for other cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trim a video without re-encoding (fast, lossless cut on keyframe boundaries).
| Name | Required | Description | Default |
|---|---|---|---|
| start | Yes | ||
| duration | Yes | ||
| video_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 does convey the key non-obvious behavior: no re-encoding, lossless, and cuts aligned to keyframes. It could still mention side effects or output behavior, but the core behavior is transparent.
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?
One concise sentence with no filler. The key information is front-loaded and every clause earns its place.
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?
An output schema is present, so return values need not be explained. However, with zero parameter documentation and no annotations, the description leaves important details like timecode format and output behavior unstated. The core action is clear enough for a simple trim operation, but an agent may still guess parameter conventions.
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% and the description adds no meaning to the three required parameters. 'start' is a string with no format specified, 'duration' is a number with no unit, and 'video_path' has no detail about accepted formats or locations.
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?
Clearly states a specific verb and resource: 'Trim a video.' The qualifiers 'without re-encoding,' 'lossless,' and 'keyframe boundaries' add precision and distinguish this from sibling tools like video_thumbnail and video_to_gif.
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 use for fast, lossless video cuts but does not explicitly say when to use this tool versus alternatives or when keyframe snapping might be unacceptable. It provides context but leaves the decision to inference.
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. Dates show when Glama detected each change.
v0.1.0convert_formatgenerate_image_freeremove_backgroundresize_imageupscale_imagevideo_thumbnailvideo_to_gifvideo_trimEach tool targets a distinct media operation—image generation, upscaling, background removal, resizing, format conversion, video thumbnail extraction, GIF conversion, and trimming. No two tools have overlapping responsibilities, making selection straightforward.
Most image tools follow a clear verb_noun pattern (upscale_image, remove_background, resize_image), but the video tools diverge with patterns like video_thumbnail and video_to_gif. Names are readable and consistently lowercase snake_case, but the naming convention is not uniform across the set.
Eight tools is a well-scoped size for a creative media utility server. Each tool earns its place by covering a distinct, practical task without redundancy or unnecessary bloat.
The toolkit covers image generation, common image editing workflows, and core video conversions including thumbnails, GIFs, and trimming. Minor gaps such as cropping or more advanced video encoding exist, but the main creative workflows are well supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-powered image processing via GPU. Remove backgrounds and upscale images (2x/4x) directly from any MCP client. OAuth 2.1 authenticated, returns processed images inline with download links. Free credits on signup at maskr.io.
Hosted MCP tools for FFmpeg-style video and audio processing through FFMPEG API.
Video, audio, and image processing for AI agents: convert, transcribe, upscale - 150+ operations.
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Furkiozknn/mini-creative-toolkit'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
