Hosted MCP server for Retro Diffusion. Generate authentic, grid-aligned pixel art — sprites, characters, animations, and tilesets — from Claude, Cursor, VS Code, Windsurf, or any MCP client. 90+ styles, free cost estimation, pay-per-generation with no subscription and credits that never expire.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 19 of 19 tools scored. Lowest: 3.3/5.
All tools have clearly distinct purposes. Even closely related inference tools (create_inference vs start_inference_job) are well differentiated by synchronous vs async usage. No overlapping functionality.
Tool names follow a consistent verb_noun pattern in snake_case (e.g., create_inference, list_available_styles, run_edit_tool). Only 'logout' deviates slightly but is a common exception.
19 tools cover a full pixel art generation workflow (auth, inference, style management, edit tools, info). The count is well-scoped for the domain without being overwhelming or sparse.
Covers core operations: CRUD for styles, sync/async inference, job management, edit tools, and status. Minor gap: no tool to list user's own styles, though public styles are listable. Otherwise complete.
authenticateAuthenticateAAuthenticate this MCP session with a RetroDiffusion public API key.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | RetroDiffusion API key (rdpk-...), created free at https://retrodiffusion.ai/app/devtools. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which effectively communicate the tool's behavioral traits. The description adds the context of using a public API key, which is consistent with annotations.
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 sentence of 10 words. Every word is meaningful, with no extraneous 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?
Given the simple nature of the tool and the comprehensive parameter description in the schema, the description is largely complete. The output schema (not shown) likely provides success/error details. Some context about when authentication is needed could improve completeness, but it is adequate.
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 input schema has 100% descriptive coverage for the single parameter 'api_key', specifying its format and creation URL. The tool description does not add further semantic meaning, so a baseline score of 3 is appropriate.
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 'Authenticate' and the resource 'this MCP session' with a RetroDiffusion public API key. It distinguishes the tool from its sibling 'logout' by being the opposite operation.
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 to authenticate a session but does not explicitly state when to use it (e.g., before other tools) or provide guidance on alternatives. The parameter description hints at key creation but no direct usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_inferenceGenerate Pixel ArtAInspectGenerate images using the public /v1/inferences endpoint.
For the highest quality prefer RD Pro styles (rd_pro__*); they support reference_images for
character/style consistency. For animation styles prefer start_inference_job + get_inference_job
instead — animations are long-running. Use input_image for the main source image,
reference_images for extra per-inference guidance, and style_reference_images only on
create_user_style/update_user_style.
The response excludes raw base64 image payloads to keep MCP outputs compact.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Seed for reproducible results; reuse the same seed to iterate on one composition. | |
| width | Yes | Output width in pixels. Each style enforces its own limits; check list_available_styles or get_style_usage. | |
| height | Yes | Output height in pixels. Each style enforces its own limits; check list_available_styles or get_style_usage. | |
| prompt | Yes | Describe the SUBJECT only (e.g. 'a knight resting by a campfire'). Never write 'pixel art' — the selected style handles all rendering. | |
| tile_x | No | Make the result tile seamlessly on the horizontal axis. | |
| tile_y | No | Make the result tile seamlessly on the vertical axis. | |
| strength | No | How strongly to change input_image, 0-1 (default 0.75). Lower values keep more of the original. | |
| remove_bg | No | Remove the background for transparent output. | |
| num_images | No | How many images to generate in one batch. Style-specific maximums apply. | |
| rd_api_key | No | RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth. | |
| input_image | No | Base64 PNG used as the main source image for edits, variations, tilesets, animations, or styles that require a starting frame. Raw base64 or a data URL. | |
| extra_prompt | No | Secondary prompt for styles that use one (e.g. the transition texture in advanced tilesets). | |
| prompt_style | Yes | Style id from list_available_styles (e.g. 'rd_fast__default', 'rd_pro__isometric', or a custom 'user__...' style). | |
| input_palette | No | Base64 image of a color palette; output colors are constrained to it. | |
| upload_outputs | No | Host outputs and return URLs in output_urls (recommended for MCP clients) instead of only base64 payloads. | |
| frames_duration | No | Animation frame count for animation styles: 4, 6, 8, 10, 12, or 16. | |
| timeout_seconds | No | Read-timeout override in seconds for this call; increase for animations or large batches. | |
| reference_images | No | Extra per-inference guidance images (base64), only for styles where supports_reference_images is true. Not for defining custom styles. | |
| extra_input_image | No | Second base64 input image for styles that use one (e.g. the second texture in rd_tile__tileset_advanced). | |
| return_pre_palette | No | Also return the render from before palette constraints were applied. | |
| return_spritesheet | No | For animation styles: return a PNG sprite sheet instead of a GIF. | |
| return_non_bg_removed | No | Also return the render from before background removal was applied. | |
| upscale_output_factor | No | Integer upscale factor for the output image; 1 returns the native pixel size. | |
| bypass_prompt_expansion | No | Skip the automatic LLM prompt enrichment and use the prompt verbatim. | |
| include_downloadable_data | No | Include extra structured assets when available (e.g. tileset atlas JSON, animation frame data). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate openWorldHint=true and non-destructive. The description adds that responses exclude raw base64 payloads to keep outputs compact, providing behavioral context beyond annotations.
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?
Five sentences with clear structure: main purpose, quality/alternative guidance, parameter usage note, and output format note. No unnecessary words.
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 25 parameters and output schema present, the description covers usage patterns, alternatives, key constraints, and parameter distinctions. Comprehensive for agent selection and invocation.
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 100%, but the description adds value by explaining parameter usage (e.g., 'Never write pixel art', reference_images only for per-inference guidance). It elaborates on when to use certain 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 title 'Generate Pixel Art' and description clearly state the tool generates images via the /v1/inferences endpoint. It distinguishes from sibling tools like start_inference_job by noting animation styles should use that instead.
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?
Explicit guidance: prefer RD Pro styles for quality, use start_inference_job for animations, and clarifies when to use reference_images vs style_reference_images. Also advises on prompt construction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_user_styleCreate Custom StyleAInspectCreate a user style from the public RD Pro template using /v1/styles.
Use style_reference_images and style_reference_caption for style-level references.
These are baked into the custom style and are not the same as per-inference reference_images.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Display name for the custom style. | |
| min_width | No | Force a fixed width (96-256); must be provided together with min_height. | |
| min_height | No | Force a fixed height (96-256); must be provided together with min_width. | |
| rd_api_key | No | RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth. | |
| style_icon | No | Icon name for the style (e.g. 'sparkles'). | |
| description | No | Short description of the custom style. | |
| force_palette | No | Always apply palette constraining for this style. | |
| force_bg_removal | No | Always remove backgrounds for this style. | |
| llm_instructions | No | Instructions for the prompt-expansion LLM when this style is used. | |
| reference_images | No | Alias for style_reference_images on this tool; prefer style_reference_images and never provide both. | |
| reference_caption | No | Alias for style_reference_caption on this tool; prefer style_reference_caption and never provide both. | |
| apply_prompt_fixer | No | Let the API tidy prompts automatically for this style (default true). | |
| user_prompt_template | No | Prompt template for the style; must contain the {prompt} token. | |
| style_reference_images | No | Style-level reference image(s), base64, baked into the custom style (max 1 via the public API). | |
| style_reference_caption | No | Caption describing the style reference image(s). | |
| expanded_llm_instructions | No | Extended instructions for the prompt-expansion LLM. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a mutating, non-idempotent, non-destructive operation. Description adds that the style is created from a public template and that references are baked in. However, it does not disclose potential side effects like name uniqueness, whether existing styles are overwritten, or auth requirements beyond the API key parameter.
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?
Three sentences, no wasted words. First sentence gives purpose and endpoint, second provides usage guidance for key parameters, third clarifies an important distinction. 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 rich input schema (descriptions for all 16 parameters) and presence of an output schema, the description provides the core context needed. It could mention the min_width/min_height pairing requirement, but the schema's descriptions already cover that. Overall adequate.
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?
With 100% schema description coverage, the baseline is 3. The description adds value by clarifying the purpose of style_reference_images/caption (baked into custom style vs per-inference) and noting that reference_images/caption are aliases but to prefer the style_ prefixed ones. This goes beyond the schema's descriptions.
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 the tool creates a user style from a public RD Pro template. The verb 'create' and resource 'user style' are specific, and it distinguishes style-level references from per-inference references, differentiating it from sibling tools like create_inference.
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 guidance on using style-level parameters (style_reference_images/caption) and distinguishes them from per-inference reference_images. However, it does not explicitly name alternative tools like update_user_style or delete_user_style for when modification or deletion is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_user_styleDelete Custom StyleBDelete a user style using /v1/styles/{style_id}. style_id can be either internal id or prompt_style/public_id.
| Name | Required | Description | Default |
|---|---|---|---|
| style_id | Yes | Style id — the internal id or the prompt_style/public id (e.g. user__mystyle_ab12). | |
| rd_api_key | No | RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and idempotentHint=true. The description adds minimal behavior context (use of specific endpoint, style_id format). It does not discuss side effects, error states, or confirmation requirements. No contradiction with annotations, but little added value beyond what annotations convey.
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 and immediately conveys the core action. No redundant or extraneous information. Ideal conciseness for a simple delete operation.
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 an output schema (presumably covering return values) and annotations that define safety. However, the description lacks context on success/failure behavior, idempotency consequences (e.g., deleting already deleted), or any follow-up actions. Adequate but not thorough for a destructive action.
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 100%, so the schema already fully documents both parameters. The description mentions style_id can be internal or public id, but this is also in the schema description. The endpoint path clue adds negligible extra meaning. Baseline 3 is appropriate since schema does the heavy lifting.
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 'Delete a user style' with the endpoint reference. The verb 'delete' and resource 'user style' are specific and unambiguous, though it doesn't explicitly differentiate from sibling tools like 'update_user_style' or 'create_user_style'. However, the action is distinct enough given the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., update vs delete). There is no mention of prerequisites, irreversible consequences, or conditions under which deletion is appropriate. Instructions for when to choose delete over other actions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_edit_tool_costEstimate Edit Cost (Free)AValidate an edit-tool request and estimate its cost and duration without running it. Always free.
| Name | Required | Description | Default |
|---|---|---|---|
| width | No | k_centroid_downscale: target width in pixels (required for that tool). | |
| height | No | k_centroid_downscale: target height in pixels (required for that tool). | |
| prompt | No | What to generate or change (required by image_edit and inpainting; optional for outpainting). | |
| tile_x | No | seam_tiling: repair the horizontal seam (tool default applies when omitted). | |
| tile_y | No | seam_tiling: repair the vertical seam (tool default applies when omitted). | |
| tool_id | Yes | Edit tool id. One of: image_edit, inpainting, outpainting, seam_tiling, background_remover, color_style_transfer, color_reducer, palette_converter, pixel_correction, k_centroid_downscale, rotate. Use list_edit_tools for authoritative fields, costs, and limits. | |
| expand_top | No | Outpainting: pixels to add on the top edge. | |
| mask_image | No | Base64 mask for inpainting: white pixels are regenerated, black pixels are kept. | |
| rd_api_key | No | RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth. | |
| seam_width | No | seam_tiling: width in pixels of the seam band to repair. | |
| color_count | No | color_reducer: target number of colors. | |
| dither_mode | No | color_reducer/palette_converter: dithering mode. | |
| expand_left | No | Outpainting: pixels to add on the left edge. | |
| input_image | Yes | Base64 PNG of the image to edit (raw base64 or a data URL). Required by every edit tool. | |
| expand_right | No | Outpainting: pixels to add on the right edge. | |
| soft_inpaint | No | Inpainting/outpainting: blend edits softly with the surrounding pixels. | |
| expand_bottom | No | Outpainting: pixels to add on the bottom edge. | |
| input_palette | No | Base64 image of a color palette; output colors are constrained to it. | |
| dither_strength | No | color_reducer/palette_converter: dithering strength. | |
| timeout_seconds | No | Read-timeout override in seconds for this call; increase for animations or large batches. | |
| rotation_degrees | No | rotate: rotation angle in degrees (clean-edge pixel rotation). | |
| extra_input_image | No | Second base64 input image for styles that use one (e.g. the second texture in rd_tile__tileset_advanced). | |
| force_solid_pixels | No | background_remover: force fully solid or fully transparent pixels (tool default applies when omitted). | |
| repair_window_size | No | seam_tiling: size of the repair window. | |
| transparency_threshold | No | background_remover: alpha threshold for treating pixels as transparent. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and not destructive. Description adds that it is free and estimates without running, which is consistent and adds value beyond annotations.
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?
Single sentence front-loads purpose and key trait ('Always free'). Every word earns its place; no fluff.
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 high parameter count (25) and full schema coverage, plus existing output schema, the description is sufficient. It could mention that it returns cost and duration details, but the output schema covers that.
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 100% with detailed parameter descriptions in schema. The tool description itself does not add parameter semantics, so baseline 3 applies.
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 it validates and estimates cost/duration for an edit-tool request, and distinguishes from actually running it ('without running it'). This differentiates it from sibling run_edit_tool.
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?
Emphasizes 'Always free' implying cost preview before execution, but does not explicitly state when not to use or list alternatives. Good implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_inference_costEstimate Cost (Free)AEstimate generation cost using the public /v1/inferences endpoint with check_cost=true.
Use input_image for the main source image, reference_images for extra per-inference guidance,
and style_reference_images only on create_user_style/update_user_style.
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | Output width in pixels. Each style enforces its own limits; check list_available_styles or get_style_usage. | |
| height | Yes | Output height in pixels. Each style enforces its own limits; check list_available_styles or get_style_usage. | |
| prompt | Yes | Describe the SUBJECT only (e.g. 'a knight resting by a campfire'). Never write 'pixel art' — the selected style handles all rendering. | |
| strength | No | How strongly to change input_image, 0-1 (default 0.75). Lower values keep more of the original. | |
| num_images | No | How many images to generate in one batch. Style-specific maximums apply. | |
| rd_api_key | No | RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth. | |
| input_image | No | Base64 PNG used as the main source image for edits, variations, tilesets, animations, or styles that require a starting frame. Raw base64 or a data URL. | |
| extra_prompt | No | Secondary prompt for styles that use one (e.g. the transition texture in advanced tilesets). | |
| prompt_style | Yes | Style id from list_available_styles (e.g. 'rd_fast__default', 'rd_pro__isometric', or a custom 'user__...' style). | |
| input_palette | No | Base64 image of a color palette; output colors are constrained to it. | |
| frames_duration | No | Animation frame count for animation styles: 4, 6, 8, 10, 12, or 16. | |
| timeout_seconds | No | Read-timeout override in seconds for this call; increase for animations or large batches. | |
| reference_images | No | Extra per-inference guidance images (base64), only for styles where supports_reference_images is true. Not for defining custom styles. | |
| extra_input_image | No | Second base64 input image for styles that use one (e.g. the second texture in rd_tile__tileset_advanced). | |
| return_pre_palette | No | Also return the render from before palette constraints were applied. | |
| return_spritesheet | No | For animation styles: return a PNG sprite sheet instead of a GIF. | |
| return_non_bg_removed | No | Also return the render from before background removal was applied. | |
| upscale_output_factor | No | Integer upscale factor for the output image; 1 returns the native pixel size. | |
| bypass_prompt_expansion | No | Skip the automatic LLM prompt enrichment and use the prompt verbatim. | |
| include_downloadable_data | No | Include extra structured assets when available (e.g. tileset atlas JSON, animation frame data). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which inform the agent of safe, non-destructive behavior. The description adds context about using check_cost=true and parameter guidance but does not disclose additional behaviors like rate limits or retries. Since annotations cover the safety profile, a score of 3 is appropriate.
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: first sentence states the core purpose, second provides key parameter usage. No wasted words, front-loaded with the essential action. Highly concise and structured.
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 20 parameters and an output schema existing, the description provides a high-level overview and parameter grouping. It does not explain return values (covered by output schema) or mention the 'Free' aspect from the title. Still, it is complete enough for an agent to use the tool effectively.
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 100%, each parameter is well-documented in the schema. The description adds group-level meaning (e.g., the three image parameters) but does not add per-parameter details beyond the schema. Baseline 3 is correct.
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 explicitly states it 'estimate[s] generation cost using the public /v1/inferences endpoint with check_cost=true.' This is a specific verb+resource that clearly defines the tool's function. It also distinguishes from sibling tools like create_inference (actual generation) and estimate_edit_tool_cost (edit tool cost).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the three image parameters: 'Use input_image for the main source image, reference_images for extra per-inference guidance, and style_reference_images only on create_user_style/update_user_style.' This helps the agent choose the right parameters. However, it does not explicitly state when to use this tool versus alternatives like create_inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fix_pixel_artFix Pixel ArtARecover the native pixel grid from enlarged, softened, AI-rendered, or compressed pixel art.
Standard uses the native Rust detector. Neural uses the neural reconstruction engine and accepts optional target width and height values. This repairs existing art—it does not generate a new image. Both engines are free and share a limit of 10 requests per minute per API token. Provide exactly one source as base64 input_image or a public HTTPS image_url. URL input avoids the ALB request-body limit. Decoded images may contain up to 16 megapixels. Successful response JSON is limited to 850,000 bytes for AWS ALB compatibility.
| Name | Required | Description | Default |
|---|---|---|---|
| width | No | Optional neural target dimension in pixels. Accepted only with engine='neural'. | |
| engine | No | Fixer engine. Standard uses the native Rust detector; neural uses the neural reconstruction engine. | standard |
| height | No | Optional neural target dimension in pixels. Accepted only with engine='neural'. | |
| image_url | No | Public HTTPS PNG or JPEG URL to reconstruct. Provide this or input_image, not both. URL downloads may contain up to 20 MB and bypass the API request-body limit. | |
| rd_api_key | No | RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth. | |
| input_image | No | Base64 PNG or JPEG to reconstruct at its native pixel grid. Raw base64 or a data URL; provide this or image_url, not both. Decoded input may contain up to 16 megapixels, and complete base64 request JSON must stay within 900,000 bytes. | |
| timeout_seconds | No | Read-timeout override in seconds for this call; increase for animations or large batches. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, non-destructive behavior, which the description confirms by stating it 'repairs existing art—it does not generate a new image.' The description adds details beyond annotations: rate limits (10 req/min), image size limits (16 MP), response size (850KB), and URL input benefits. No contradictions. Could mention synchronous/asynchronous behavior, but overall strong.
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 paragraph of 7 sentences, starting with the core purpose. It is informative without extraneous details. Could be slightly more structured (e.g., bullet points for limits) but is efficient and front-loaded.
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 tool with 7 parameters, complete schema coverage, annotations, and an output schema, the description covers purpose, engines, input options, and important limits. It does not explain the output format, but that is reasonable given the output schema exists. Minor gaps: no mention of error handling, but overall comprehensive.
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 100%, so the description's added value over the schema is minimal. It repeats that width/height are for neural engine and that input_image and image_url are mutually exclusive. This is helpful but does not provide new meaning beyond what is already in the structured fields. Baseline 3 is appropriate.
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 identifies the tool's action—recovering the native pixel grid from various degraded pixel art—and distinguishes the two engines (standard and neural). It is specific and differs from sibling tools, which cover authentication, inference, style management, etc. No ambiguity.
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 explains when to use each engine and how to provide input (URL vs base64), including the rate limit. While it doesn't explicitly list alternatives or exclusions, the sibling tools are very different, making usage context clear. Missing explicit 'when not to use' keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_balanceGet BalanceAGet credits/balance using the public /v1/inferences/credits endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| rd_api_key | No | RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and no destructive hint. The description adds the specific endpoint and that it is 'public', which is relevant context beyond the annotations.
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?
Single sentence, front-loaded with the core action, no redundant words. Efficient and clear.
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 a single optional parameter, output schema present, and minimal complexity, the description covers the essential action. However, it could mention that the endpoint returns the current balance value.
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 100% with a detailed parameter description for the API key. The tool description does not add additional meaning to the parameter, so baseline score of 3 is appropriate.
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 ('Get credits/balance') and names the exact endpoint. It clearly distinguishes from sibling tools, none of which retrieve balance.
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 on when to use this tool vs alternatives (e.g., estimate_inference_cost for cost estimation). It simply states what it does without usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_inference_jobCheck Async JobACheck the status of an async generation started with start_inference_job.
Statuses: pending, running, succeeded, failed. On success the result carries hosted output_urls (raw base64 payloads are excluded to keep MCP outputs compact).
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Async job id returned by start_inference_job. | |
| rd_api_key | No | RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. Description adds valuable context about output_urls and omission of base64 payloads, enhancing transparency.
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, front-loaded with purpose, no fluff. Every sentence 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 output schema exists, description covers statuses and output details adequately. No gaps for this simple 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?
Schema coverage is 100%, and description adds helpful context for task_id (links to start_inference_job). Slight added value beyond schema.
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 it checks async job status, using specific verb and resource. Distinguishes from sibling tools like start_inference_job and list_inference_jobs.
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 links to start_inference_job and mentions statuses, but could more explicitly differentiate from list_inference_jobs for batch queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_service_statusService StatusACheck RetroDiffusion subsystem health (/v1/status, no auth). Useful before bulk generation runs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds endpoint path and 'no auth' beyond annotations which already indicate readOnly, idempotent, and non-destructive. No contradictions; full transparency for a simple query 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 action and endpoint, second provides usage context. Perfectly 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?
Tool has no parameters and an output schema (not shown here, but referenced). Description covers the functional purpose and usage scenario adequately; no gaps.
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?
No parameters exist, and schema coverage is 100%. Description adds no param info because none is needed; it's already complete.
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 uses specific verb 'Check' and resource 'RetroDiffusion subsystem health', includes endpoint and auth info. Clearly distinguishes from sibling tools that perform actions like creating or listing.
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?
States it is 'useful before bulk generation runs', providing clear when-to-use context. Does not explicitly mention when not to use or alternatives, but the simple health check task is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_style_usageGet Style UsageAExplain how to use a public prompt_style from the RetroDiffusion API.
Use this before create_inference if you are unsure whether a style expects input_image,
supports per-inference reference_images, or whether you meant style-level style_reference_images.
| Name | Required | Description | Default |
|---|---|---|---|
| rd_api_key | No | RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth. | |
| prompt_style | Yes | Style id from list_available_styles (e.g. 'rd_fast__default', 'rd_pro__isometric', or a custom 'user__...' style). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, idempotent, non-destructive. The description adds behavioral context about what the tool explains (style expectations), going beyond annotations to clarify its role as a consultation 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: first states purpose, second gives usage guidance. No superfluous words; every sentence earns its place. Front-loaded with the essential action.
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 presence of output schema and comprehensive annotations, the description provides all necessary context: it explains the tool's purpose and when to use it, fitting the complexity of a style usage query.
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?
Input schema has 100% coverage with descriptions for both parameters. The description does not repeat param details but adds meaningful context about how the tool's output informs the usage of those parameters in create_inference, thus enhancing semantic understanding.
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 'Explain how to use a public prompt_style', using a specific verb and resource. It distinguishes from sibling tools like 'create_inference' and 'list_available_styles' by focusing on usage explanation.
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?
Directly advises 'Use this before create_inference if you are unsure...' and lists specific scenarios (input_image, reference_images, style_reference_images). Provides explicit when-to-use guidance and implies alternative by referencing create_inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_available_modelsList ModelsAReturn unique public model identifiers available in /v1/styles/selector.
| Name | Required | Description | Default |
|---|---|---|---|
| rd_api_key | No | RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only and idempotent; the description adds value by specifying the endpoint and that identifiers are unique and public, providing useful behavioral 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 sentence with no wasted words, efficiently conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema, the description is sufficiently complete, though it could mention the nature of the identifiers (e.g., string format) for extra clarity.
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 100% for the single parameter; the description does not add additional meaning beyond what the schema already provides, so baseline score applies.
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 returns unique public model identifiers from a specific endpoint, distinguishing it from sibling tools like list_available_styles.
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 does not explicitly state when to use this tool over alternatives, but the context of sibling tool names implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_available_stylesList StylesAList publicly available styles from /v1/styles/selector. Use this to discover valid prompt_style values plus style metadata such as require_input_image and supports_reference_images.
| Name | Required | Description | Default |
|---|---|---|---|
| tab | No | Filter styles by tab: tab:image, tab:animation, tab:advanced-animation, or tab:tileset. | |
| model | No | Filter styles by model: rd_fast, rd_plus, rd_pro, or rd_mini. | |
| rd_api_key | No | RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide read-only, idempotent, non-destructive hints. The description adds valuable context by naming the specific endpoint and the type of metadata returned (e.g., require_input_image), which enhances transparency beyond annotations.
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 only two sentences, concise and front-loaded with the main action. Every word serves a purpose, no unnecessary details.
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 optional filters and an output schema, the description covers the essential purpose and output values. It could mention that filtering by tab and model is possible, but that is covered by the schema. The description is complete enough for an agent to correctly use the 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?
Schema coverage is 100% with each parameter having a description. The description does not add parameter-specific details, but the baseline is 3 since the schema is comprehensive. The description's mention of 'style metadata' indirectly relates to output, not input parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists publicly available styles from a specific endpoint and is used to discover valid prompt_style values and style metadata. This purpose is specific and distinguishes it from sibling tools like create_user_style.
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 explicitly states when to use this tool: to discover prompt_style values and metadata. While it doesn't list alternatives or when not to use, the context of sibling tools makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_edit_toolsList Edit ToolsAList the enabled canvas edit tools from /v1/edit/tools with their fields, costs, and limits.
Edit tools are the recommended way to post-process generated pixel art: background removal, palette conversion, color reduction, pixel correction, rotation, inpainting, outpainting, seam tiling, and prompt-driven edits.
| Name | Required | Description | Default |
|---|---|---|---|
| rd_api_key | No | RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint true and destructiveHint false. The description adds that the tool returns fields, costs, and limits, and lists example edit tools, providing behavioral context beyond annotations. No contradiction.
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: first sentence gives the core action and endpoint, second sentence elaborates on the category of tools. No superfluous words, front-loaded with verb and resource.
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 list tool with output schema implied, the description covers key aspects: what is returned (fields, costs, limits) and the domain (edit tools). It lacks details like pagination or sorting, but those are not essential for a basic list.
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 100% for the single optional rd_api_key parameter. The description does not add any parameter semantics beyond what the schema already documents. Baseline 3 is appropriate.
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 lists enabled canvas edit tools from a specific endpoint, enumerating fields, costs, and limits. It distinguishes from siblings like run_edit_tool and estimate_edit_tool_cost by focusing on listing rather than executing or estimating.
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 positions edit tools as recommended for post-processing pixel art, giving context for when to use them. It does not explicitly exclude alternatives or state when not to use this tool, but the purpose is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_inference_jobsList Async JobsAList your most recent async jobs, newest first (GET /v1/inferences/tasks).
Recovery path: if a submission response was lost (timeout, disconnect) before the task_id arrived, the job was still accepted — find it here instead of re-submitting and being charged twice. Then poll it with get_inference_job.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of recent jobs to return (1-100, default 20). | |
| status | No | Optional: only return jobs with this status. | |
| rd_api_key | No | RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds the 'newest first' ordering and recovery context but no new behavioral traits beyond annotations.
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 that are efficient and front-loaded, with no waste. The description 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?
The tool has an output schema (unseen but acknowledged), so return values need not be explained. The description covers purpose, usage scenario, and recovery path adequately for a simple list 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?
Schema coverage is 100% with well-described parameters. The description adds context linking parameters to the recovery use case, but does not provide additional semantic detail beyond what the schema offers.
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 'List your most recent async jobs, newest first' with the endpoint, distinguishing it from siblings like get_inference_job and start_inference_job.
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 describes a recovery scenario when a submission response is lost, telling when to use this tool and what to do next (poll with get_inference_job), thus providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
logoutLog OutAClear the authenticated RetroDiffusion API key for this MCP session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations: it specifies the exact behavior of clearing the API key per session, confirming idempotency and non-destructiveness. No contradictions.
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?
Single sentence, no waste, front-loaded with the action and resource.
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 zero-parameter tool with an output schema, the description is complete and leaves no ambiguity about its function.
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?
No parameters exist; baseline 4 is appropriate. The description covers the tool's purpose sufficiently.
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 ('clear') and the specific resource ('authenticated RetroDiffusion API key' for this MCP session). It effectively distinguishes from sibling 'authenticate'.
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 ending an authenticated session but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_edit_toolRun Edit ToolAInspectRun a canvas edit tool on an image via /v1/edit/tools/{tool_id}.
Free tools: color_reducer, palette_converter, pixel_correction, k_centroid_downscale, rotate. $0.01 tools: background_remover, color_style_transfer. Premium ($0.18): image_edit, inpainting, outpainting, seam_tiling. Use estimate_edit_tool_cost first for anything that charges — estimation is free. The edited image is returned in base64_images.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Seed for reproducible results; reuse the same seed to iterate on one composition. | |
| width | No | k_centroid_downscale: target width in pixels (required for that tool). | |
| height | No | k_centroid_downscale: target height in pixels (required for that tool). | |
| prompt | No | What to generate or change (required by image_edit and inpainting; optional for outpainting). | |
| tile_x | No | seam_tiling: repair the horizontal seam (tool default applies when omitted). | |
| tile_y | No | seam_tiling: repair the vertical seam (tool default applies when omitted). | |
| tool_id | Yes | Edit tool id. One of: image_edit, inpainting, outpainting, seam_tiling, background_remover, color_style_transfer, color_reducer, palette_converter, pixel_correction, k_centroid_downscale, rotate. Use list_edit_tools for authoritative fields, costs, and limits. | |
| expand_top | No | Outpainting: pixels to add on the top edge. | |
| mask_image | No | Base64 mask for inpainting: white pixels are regenerated, black pixels are kept. | |
| rd_api_key | No | RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth. | |
| seam_width | No | seam_tiling: width in pixels of the seam band to repair. | |
| color_count | No | color_reducer: target number of colors. | |
| dither_mode | No | color_reducer/palette_converter: dithering mode. | |
| expand_left | No | Outpainting: pixels to add on the left edge. | |
| input_image | Yes | Base64 PNG of the image to edit (raw base64 or a data URL). Required by every edit tool. | |
| expand_right | No | Outpainting: pixels to add on the right edge. | |
| soft_inpaint | No | Inpainting/outpainting: blend edits softly with the surrounding pixels. | |
| expand_bottom | No | Outpainting: pixels to add on the bottom edge. | |
| input_palette | No | Base64 image of a color palette; output colors are constrained to it. | |
| dither_strength | No | color_reducer/palette_converter: dithering strength. | |
| timeout_seconds | No | Read-timeout override in seconds for this call; increase for animations or large batches. | |
| rotation_degrees | No | rotate: rotation angle in degrees (clean-edge pixel rotation). | |
| extra_input_image | No | Second base64 input image for styles that use one (e.g. the second texture in rd_tile__tileset_advanced). | |
| force_solid_pixels | No | background_remover: force fully solid or fully transparent pixels (tool default applies when omitted). | |
| repair_window_size | No | seam_tiling: size of the repair window. | |
| transparency_threshold | No | background_remover: alpha threshold for treating pixels as transparent. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cost tiers, payment model, and return format (base64_images). This adds behavioral context beyond annotations (readOnlyHint=false, etc.) with no contradictions.
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?
65 words, front-loaded with purpose, includes a call to action, no redundant information. Every sentence is useful.
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?
Covers the main points: operation, tool categories, cost guidance, and output format. With 26 parameters and an output schema, more detail could be provided but the description is adequate.
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 100% coverage, but the description adds value by grouping tools by cost, which helps agents understand parameter relevance. Baseline 3, plus one for extra context.
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 runs a canvas edit tool on an image via an endpoint, lists tool categories by cost, and distinguishes from siblings like `estimate_edit_tool_cost` and `list_edit_tools`.
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 using `estimate_edit_tool_cost` first for paid tools and lists free vs charged tools, providing context for when to use. However, it does not explicitly state scenarios where the tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_inference_jobStart Async GenerationAInspectStart a generation as an async job (POST /v1/inferences with async=true) and return a task_id.
Recommended for advanced animations (rd_advanced_animation__*), other animation styles, and batches — they run for tens of seconds and can outlive a synchronous MCP call. Poll the returned task_id with get_inference_job roughly every 2-5 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Seed for reproducible results; reuse the same seed to iterate on one composition. | |
| width | Yes | Output width in pixels. Each style enforces its own limits; check list_available_styles or get_style_usage. | |
| height | Yes | Output height in pixels. Each style enforces its own limits; check list_available_styles or get_style_usage. | |
| prompt | Yes | Describe the SUBJECT only (e.g. 'a knight resting by a campfire'). Never write 'pixel art' — the selected style handles all rendering. | |
| tile_x | No | Make the result tile seamlessly on the horizontal axis. | |
| tile_y | No | Make the result tile seamlessly on the vertical axis. | |
| strength | No | How strongly to change input_image, 0-1 (default 0.75). Lower values keep more of the original. | |
| remove_bg | No | Remove the background for transparent output. | |
| num_images | No | How many images to generate in one batch. Style-specific maximums apply. | |
| rd_api_key | No | RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth. | |
| input_image | No | Base64 PNG used as the main source image for edits, variations, tilesets, animations, or styles that require a starting frame. Raw base64 or a data URL. | |
| extra_prompt | No | Secondary prompt for styles that use one (e.g. the transition texture in advanced tilesets). | |
| prompt_style | Yes | Style id from list_available_styles (e.g. 'rd_fast__default', 'rd_pro__isometric', or a custom 'user__...' style). | |
| input_palette | No | Base64 image of a color palette; output colors are constrained to it. | |
| upload_outputs | No | Host outputs and return URLs in output_urls (recommended for MCP clients) instead of only base64 payloads. | |
| frames_duration | No | Animation frame count for animation styles: 4, 6, 8, 10, 12, or 16. | |
| timeout_seconds | No | Read-timeout override in seconds for this call; increase for animations or large batches. | |
| reference_images | No | Extra per-inference guidance images (base64), only for styles where supports_reference_images is true. Not for defining custom styles. | |
| extra_input_image | No | Second base64 input image for styles that use one (e.g. the second texture in rd_tile__tileset_advanced). | |
| return_pre_palette | No | Also return the render from before palette constraints were applied. | |
| return_spritesheet | No | For animation styles: return a PNG sprite sheet instead of a GIF. | |
| return_non_bg_removed | No | Also return the render from before background removal was applied. | |
| upscale_output_factor | No | Integer upscale factor for the output image; 1 returns the native pixel size. | |
| bypass_prompt_expansion | No | Skip the automatic LLM prompt enrichment and use the prompt verbatim. | |
| include_downloadable_data | No | Include extra structured assets when available (e.g. tileset atlas JSON, animation frame data). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: async nature, estimated runtime (tens of seconds), and polling expectation. No contradiction with annotations.
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, front-loaded with core purpose followed by usage guidance. No redundant 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?
Given high schema coverage and output schema, description covers key behavioral aspects (async, polling) enough for tool selection and invocation. Could mention non-blocking behavior but still effective.
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 has 100% parameter description coverage; tool description adds no extra param meaning, so baseline 3 is appropriate.
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 it starts an async inference job, returns a task_id, and distinguishes from synchronous alternatives by specifying recommended use cases (animations, batches).
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 recommends for long-running tasks like advanced animations and batches, and advises polling with get_inference_job every 2-5 seconds. Lacks explicit when-not-to-use but implies sync tool for short tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_user_styleUpdate Custom StyleAUpdate a public RD Pro user style using /v1/styles/{style_id}.
Use style_reference_images and style_reference_caption for style-level references.
These are baked into the custom style and are not the same as per-inference reference_images.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | New display name for the custom style. | |
| style_id | Yes | Style id — the internal id or the prompt_style/public id (e.g. user__mystyle_ab12). | |
| min_width | No | Force a fixed width (96-256); must be provided together with min_height. | |
| min_height | No | Force a fixed height (96-256); must be provided together with min_width. | |
| rd_api_key | No | RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth. | |
| style_icon | No | Icon name for the style (e.g. 'sparkles'). | |
| description | No | Short description of the custom style. | |
| force_palette | No | Always apply palette constraining for this style. | |
| force_bg_removal | No | Always remove backgrounds for this style. | |
| llm_instructions | No | Instructions for the prompt-expansion LLM when this style is used. | |
| reference_images | No | Alias for style_reference_images on this tool; prefer style_reference_images and never provide both. | |
| reference_caption | No | Alias for style_reference_caption on this tool; prefer style_reference_caption and never provide both. | |
| apply_prompt_fixer | No | Let the API tidy prompts automatically for this style (default true). | |
| user_prompt_template | No | Prompt template for the style; must contain the {prompt} token. | |
| style_reference_images | No | Style-level reference image(s), base64, baked into the custom style (max 1 via the public API). | |
| reset_forced_dimensions | No | Clear previously forced dimensions; do not combine with min_width/min_height. | |
| style_reference_caption | No | Caption describing the style reference image(s). | |
| expanded_llm_instructions | No | Extended instructions for the prompt-expansion LLM. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by explaining that style references are baked into the style, that it uses a public API endpoint, and that max 1 image is allowed via the public API. Annotations already indicate non-readOnly and non-destructive, so consistency is maintained.
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 concise sentences cover purpose and key parameter guidance. The first sentence is front-loaded with action and resource. Could benefit from structuring, but it's 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 18 parameters, 100% schema coverage, and output schema exists, the description covers key behavioral aspects and parameter relationships. It does not explain prerequisites like ownership of the style, but it's largely complete for the tool's complexity.
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?
With 100% schema coverage, baseline is 3. The description adds value by explaining the relationship between style_reference_images and reference_images (aliases), the requirement for user_prompt_template to contain {prompt}, and the baking-in of style references.
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 'Update a public RD Pro user style' using the specific endpoint. The verb 'Update' and resource are explicit, and it distinguishes from siblings create_user_style and delete_user_style.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on using style_reference_images and style_reference_caption for style-level updates, differentiating them from per-inference reference_images. However, it does not explicitly contrast this tool with create/delete or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
