mini-creative-toolkit

by Furkiozknn

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each 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.
Naming Consistency3/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.6/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mini-creative-toolkit MCP server](https://glama.ai/mcp/servers/Furkiozknn/mini-creative-toolkit/badges/card.svg)](https://glama.ai/mcp/servers/Furkiozknn/mini-creative-toolkit)

Score Badge

Copy to your README.md:

[![mini-creative-toolkit MCP server](https://glama.ai/mcp/servers/Furkiozknn/mini-creative-toolkit/badges/score.svg)](https://glama.ai/mcp/servers/Furkiozknn/mini-creative-toolkit)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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