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.
Scored across 20 tools
Most tools target clearly distinct resource-action pairs, and the sync/async generation and edit workflow tools are well explained. The main ambiguities are create_inference vs. start_inference_job and list_available_models vs. list_available_styles, though their descriptions help resolve the differences.
Tool names consistently follow a snake_case verb_noun pattern: create_, get_, list_, estimate_, run_, start_, delete_, update_. The only exceptions are authenticate and logout, which still fit the overall verb-first style and are unambiguous.
Twenty tools is on the higher end, but each one maps to a real API operation or workflow across auth, inference, style management, estimation, jobs, and edit tools. It feels slightly heavy rather than bloated, and no tool is purely redundant.
The core generation lifecycle is well covered: create/start/get/list jobs, result retrieval, cost estimation, and edit tools. Minor gaps include no dedicated list/get for user styles and no async job cancellation, but agents can work around these with saved style_ids and polling.
Authenticate 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.
Generate images using the public /v2/inferences endpoint.
For the highest quality prefer RD Pro styles (rd_pro__*); they support reference_images for character/style consistency, and most go as small as 12x12 px (check list_available_styles for each style's limits) — a small target size is never a reason to switch to a cheaper model family. Style ids are opaque strings with no uniform format (some RD Fast styles appear as "default:rd_flux"); take them verbatim from the catalog and never infer capabilities from an id's prefix. For animation styles prefer start_inference_job + get_inference_job instead — animations are long-running, and a failed animation is worth one retry with identical parameters (failures auto-refund).
Field-tested workflow rules: N distinct items = N individually usable images (separate calls or num_images=N), never one sheet/grid image unless a sheet IS the deliverable. Variants of ONE image (seasons, day/night, palettes) = generate the base once, then derive each variant with the image_edit tool ("... keep the exact same composition") — independent generations of the "same" scene come out unrelated. Converting an existing image INTO pixel art is rd_pro__pixelate with input_image (16-256 px output, batch<=16); reference_images-based generation re-imagines rather than converts. To animate an image you already have, use rd_advanced_animation__* with input_image (fixed-format rd_animation__* styles generate their own subject from the prompt instead).
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. Genre-native sizes per item: Minecraft 16; items/icons/props 32-64; character sprites 16-48 retro or 96-128 showcase; tiles 16-32; portraits 96-128; full scenes 256 (RD Pro's max; 16:9 scenes = 256x144 — pixel art integer-upscales losslessly). | |
| 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, richly and concretely ('a squat round flask of glowing crimson liquid, cork stopper, bright highlight on the upper-left rim' beats 'a potion'). Never write 'pixel art' — the selected style handles all rendering. For standalone assets, state a flat background color that contrasts the subject (default 'on a plain white background') and pair with remove_bg=true; never write 'transparent background' (that is remove_bg's job), and never leave the background unstated (it drifts to drab dark gray). Scenes instead describe their real environment. | |
| 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. Use true for standalone assets and pair it with a stated contrasting background in the prompt ('on a plain white background') — removal works best on flat contrasting backdrops. Animations inherit the start frame's transparency automatically. | |
| num_images | No | How many images to generate in one batch; a batch produces varied takes of one prompt (the right way to get N distinct items as individually usable images — never pack N items into a single sheet/grid image unless a sheet IS the deliverable). 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. Send the NATIVE-resolution image: an upscaled display copy (e.g. a 96px sprite exported at 4x = 384px) exceeds style ranges and gets rejected — downscale to the true pixel grid first. For advanced animations the frame's dimensions must equal width/height, and sprites whose opaque pixels touch the canvas edge animate badly (pad onto a larger transparent canvas first, e.g. 48x48 content onto 64x64). | |
| 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. Pick deliberately: 8 is the sweet spot for loops (walking, idle), 6 for a snappy single action, 10-12 for flowing ambient motion. | |
| 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?
The description discloses critical behavioral traits beyond annotations: 'failures auto-refund', 'The response excludes raw base64 image payloads to keep MCP outputs compact', and 'Style ids are opaque strings... never infer capabilities from an id's prefix'. These are not present in the annotations (readOnlyHint=false, openWorldHint=true) and significantly inform agent behavior.
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 long but well-structured, front-loading the core purpose and then providing actionable workflow rules. Every sentence adds value (quality guidance, animation alternatives, workflow rules, parameter usage, response note). It is not redundant, though it could arguably be trimmed; the thoroughness is justified by the tool's complexity (25 parameters).
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 25-parameter tool with an output schema, the description is exceptionally complete. It covers the endpoint, style selection, animations, pixelation, workflow patterns, parameter roles, and response format. With the output schema already present, the description need not explain return values, and it does not omit any crucial operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, so baseline is 3, but the description adds valuable parameter-use context: it clarifies the roles of input_image vs reference_images ('Use input_image for the main source image, reference_images for extra per-inference guidance') and emphasizes num_images vs single sheet generation. This goes beyond raw parameter definitions, elevating the score to 4.
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 opens with a specific verb and resource: 'Generate images using the public /v2/inferences endpoint.' It clearly distinguishes itself from sibling start_inference_job by stating animations should use that tool instead, and it gives concrete distinctions for pixelating via rd_pro__pixelate. The purpose is unmistakable.
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 explicit when-to-use guidance: 'For animation styles prefer start_inference_job + get_inference_job instead' and 'Converting an existing image INTO pixel art is rd_pro__pixelate with input_image'. It also gives workflow rules for N items vs variants, directing when to use num_images versus image_edit. There is no ambiguity about when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a user style from the public RD Pro template using /v2/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 already flag this as a mutating (non-read-only) operation, so the descrioption does not need to restate that. It adds value by explaining that style_reference_images are baked into the custom style and are not the same as per-inference reference images, which is a non-obvious persistence behavior an agent should know before calling.
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 short, front-loaded, and every sentence earns its keep: it states the endpoint and resource, then highlights the key styling nuance. No fluff or redundant repetition of schema 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 16 parameters, 100% schema coverage, an output schema, and annotations marking this as a mutating operation, the description provides enough orienting context. It is slightly light on how this relates to update_user_style or deletion, but those are inferable from the create verb and sibling names.
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% parameter coverage, so the baseline is solid. The description supplements this by making the crucial distinction between style-level reference images and per-inference reference images, clarifying that the former are baked in. This adds semantic meaning beyond the schema fields, especially around the reference_image alias warnings.
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 a specific action and resource: it creates a user/custom style via /v2/tyles from the RD Pro template. It also highlights style-level reference semantics, which helps distinguish style creation from ordinary inference. It does not explicitly name a sibling alternative, but the core purpose is unmistakable.
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 concrete usage guidance by directing agents to use style_reference_images and style_reference_caption for style-level references and warning that these differ from per-inference reference_images. This effectively communicates when to use the style-reference parameters during creation. It does not list exclusions or alternative sibling tools, but the guidance is relevant and operational.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a user style using /v2/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?
The description says 'Delete a user style,' which is a destructive mutation, while the annotations declare readOnlyHint: true. This directly contradicts the operation's semantics, so the score must be 1 per the rubric. The description adds no mitigating context about irreversibility or side effects.
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 short, front-loaded sentences with no filler: the first states the action and endpoint, the second clarifies the accepted id forms. This is appropriately sized 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?
Although an output schema exists and the operation is simple, the readOnlyHint contradiction leaves the behavior ambiguous. The description also does not address ownership/permissions, irreversibility of deletion, or behavior when style_id is not found, so it is not complete enough for a destructive tool carrying conflicting annotations.
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 both style_id and rd_api_key are already documented. The description repeats the fact that style_id can be an internal id or prompt_style/public id, matching the schema description without adding new information. It meets the baseline but does not go beyond it.
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 opens with a specific verb and resource: 'Delete a user style' and identifies the exact endpoint /v2/styles/{style_id}. This clearly distinguishes the tool from siblings such as create_user_style and update_user_style without being a tautology.
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 intended use is plainly stated: use this when a user style should be removed. It gives clear context, but it does not explicitly name alternatives or exclusions, such as using update_user_style when only a modification is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate 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, 0-10 (0 disables, default 5). | |
| 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 mark readOnlyHint, idempotentHint, destructiveHint as false. The description adds 'Always free' and 'without running it,' which goes beyond annotations and provides useful cost 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 concise sentences that pack key info: purpose, cost, and behavior. 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?
Given 25 parameters with 100% schema coverage and annotations, the description captures the core function well. The 'Always free' note is valuable. Could mention when to use over run_edit_tool explicitly.
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 descriptions for each parameter. The description adds 'Always free' but no extra parameter info. 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 'validate an edit-tool request and estimate its cost and duration' and notes 'Always free,' distinguishing it from 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?
Explicitly says this is for validation and estimation without running, implying use before executing. No direct sibling alternative named, but context with run_edit_tool is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate generation cost using the public /v2/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. Genre-native sizes per item: Minecraft 16; items/icons/props 32-64; character sprites 16-48 retro or 96-128 showcase; tiles 16-32; portraits 96-128; full scenes 256 (RD Pro's max; 16:9 scenes = 256x144 — pixel art integer-upscales losslessly). | |
| 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, richly and concretely ('a squat round flask of glowing crimson liquid, cork stopper, bright highlight on the upper-left rim' beats 'a potion'). Never write 'pixel art' — the selected style handles all rendering. For standalone assets, state a flat background color that contrasts the subject (default 'on a plain white background') and pair with remove_bg=true; never write 'transparent background' (that is remove_bg's job), and never leave the background unstated (it drifts to drab dark gray). Scenes instead describe their real environment. | |
| 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; a batch produces varied takes of one prompt (the right way to get N distinct items as individually usable images — never pack N items into a single sheet/grid image unless a sheet IS the deliverable). 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. Send the NATIVE-resolution image: an upscaled display copy (e.g. a 96px sprite exported at 4x = 384px) exceeds style ranges and gets rejected — downscale to the true pixel grid first. For advanced animations the frame's dimensions must equal width/height, and sprites whose opaque pixels touch the canvas edge animate badly (pad onto a larger transparent canvas first, e.g. 48x48 content onto 64x64). | |
| 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. Pick deliberately: 8 is the sweet spot for loops (walking, idle), 6 for a snappy single action, 10-12 for flowing ambient motion. | |
| 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 declare readOnly, idempotent, and non-destructive behavior, so the description does not need to repeat that. It adds useful context by naming the public endpoint and check_cost=true, signaling that no actual charged inference occurs. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the purpose and endpoint appear in the first sentence, followed by only the most essential parameter-use guidance. Every sentence earns its place with no repetition of schema 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's safety profile is fully covered by annotations, the input schema is rich, and an output schema exists, the description supplies exactly the missing contextual framing: endpoint, cost-estimation semantics, and image-parameter roles. Nothing essential is left unexplained.
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%, so the detailed parameter descriptions already bear most of the burden. The description adds meaningful cross-parameter guidance, especially distinguishing input_image vs reference_images and telling users that style_reference_images belongs only to create_user_style/update_user_style, which prevents a likely misuse.
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 estimates generation cost via the public /v2/inferences endpoint with check_cost=true. This distinguishes it from create_inference/start_inference_job (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 context is clear: this is a free/public cost-estimation call, and the description gives specific guidance on which image parameters to use. It does not explicitly state 'use this instead of create_inference when you only need a cost quote,' but the endpoint and check_cost=true make the intended use readily inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recover 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 credits/balance using the public /v2/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 declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds only that the endpoint is 'public', which is a mild behavioral trait. It does not describe rate limits, response behavior, or auth interactions beyond that, but the annotations carry most of the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence contains the action, the resource, and the endpoint. There is zero filler, and the most important distinguishing detail (the exact endpoint) is included without extra 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?
The tool is simple: one optional parameter, no required inputs, an output schema exists, and annotations cover the safety profile. The description's mention of the public endpoint combined with the schema and annotations is sufficient for an agent to call it correctly.
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%, and the rd_api_key parameter is already fully described in the schema as optional and overriding session/header auth. The description adds no parameter-level information, so the baseline score of 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?
The description names a specific verb ('Get') and resource ('credits/balance') and pins it to the exact endpoint '/v2/inferences/credits'. This is unambiguous and, by naming the endpoint, effectively distinguishes it from other tools without needing to list siblings.
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 state when to use this tool versus alternatives or when not to use it. The word 'public' hints that it may not need authentication, but there is no explicit usage context or exclusion. An agent is left to infer that this is simply the balance-checking tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check 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.
Retrieve retained outputs for a synchronous generation.
Use the request_id returned by create_inference to recover or refresh signed output URLs. This lookup is read-only; never repeat a paid create_inference call just because delivery URLs are temporarily missing.
| Name | Required | Description | Default |
|---|---|---|---|
| rd_api_key | No | RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth. | |
| request_id | Yes | Inference request id returned by create_inference. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description reinforces this with 'This lookup is read-only.' It adds valuable context beyond annotations: the tool returns signed output URLs and warns against unnecessary paid calls, which is a meaningful economic/behavioral nuance. 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?
The description is three short, purposeful paragraphs: purpose, usage, and warning. Every sentence earns its place, with no filler. The front-loaded purpose makes it immediately clear what the tool does.
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?
This is a simple lookup tool with an output schema and strong annotations. The description covers the synchronous generation context, how to obtain the request_id, and the read-only nature. There are no significant gaps for an agent to invoke it correctly.
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% (both request_id and rd_api_key are documented). The description adds contextual meaning by linking request_id to create_inference's return value, clarifying the parameter's origin. This goes beyond the schema description, justifying a score above the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve retained outputs for a synchronous generation.' It uses a specific verb ('retrieve') and resource ('retained outputs'), and distinguishes itself from siblings like get_inference_job and create_inference by focusing on output retrieval via request_id.
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 explicit usage context: use the request_id from create_inference to recover/refresh signed URLs. It also cautions against repeating a paid create_inference call, which is a clear anti-pattern. It doesn't explicitly contrast with alternative tools like get_inference_job, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check RetroDiffusion subsystem health (/v2/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?
Annotations already indicate read-only and idempotent behavior, and the description adds the no-auth detail and the health-check scope. No contradiction with annotations; the additional context around intended use complements them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence conveys purpose, endpoint, auth status, and usage context with zero waste. Front-loaded with the action and resource before the context.
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 no parameters and an output schema present, the description covers the essential call-time context (auth, health-check purpose). Could mention what status values are returned, but the output schema likely 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?
The tool has zero parameters, and schema coverage is 100% (trivially). The description doesn't need to document parameters; the no-auth note and health-check context provide all needed semantics.
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 states a specific verb ('Check'), resource ('RetroDiffusion subsystem health'), path ('/v2/status'), and no-auth requirement. It clearly distinguishes this health-check tool from sibling inference/job/balance 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?
Provides usage context ('before bulk generation runs') without naming alternatives. No explicit when-not-to-use, but the context is enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain 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.
Return unique public model identifiers available in /v2/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 declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior. The description adds the endpoint path and the uniqueness/public qualifiers, but provides no further behavioral context such as authentication behavior, ordering, or open-world implications.
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?
A single front-loaded sentence conveys the core purpose with no filler. Every word contributes meaning, and the most important information appears immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has full parameter documentation, a complete output schema, and annotations covering safety and idempotency. The description covers what is returned and where, though it does not help an agent disambiguate between this and sibling list tools.
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%: the only parameter, rd_api_key, is fully documented in the input schema. The description adds no parameter-level detail, so the baseline of 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?
The description uses a specific verb 'Return' and identifies the resource as 'unique public model identifiers available in /v2/styles/selector'. This clearly distinguishes it from sibling tools like list_available_styles 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?
The description gives no guidance on when to use this tool versus alternative list tools, and does not mention any exclusion criteria or contexts where a sibling would be more appropriate. Usage must be inferred entirely from the tool's name and endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List publicly available styles from /v2/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 declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so no safety contradiction exists. The description adds useful behavioral context by naming the exact endpoint and the metadata fields returned, which goes beyond the annotations. It does not go into details like pagination or response envelope, but the output schema likely covers that.
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 with no filler. The primary action and endpoint are front-loaded, followed immediately by the practical purpose and example metadata fields. Every sentence 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 no required parameters, a complete input schema, an output schema, and annotations that clearly establish it as a safe read-only operation. The description adds endpoint and purpose context, making the tool fully understandable for an agent without any apparent missing information.
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 explains tab, model, and rd_api_key with their filtering values and defaults. The description adds overall purpose but does not enrich the meaning of individual parameters beyond what the schema provides. Therefore, the 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 uses a specific verb and resource: 'List publicly available styles from /v2/styles/selector.' It also clearly states the tool's purpose: discovering valid prompt_style values and style metadata such as require_input_image and supports_reference_images. This clearly differentiates it from sibling tools like list_available_models or style-management 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?
The description gives clear usage context: 'Use this to discover valid prompt_style values plus style metadata.' This implies the right time to call it when an agent needs style options before creating or running an inference. It does not explicitly mention alternatives or exclusions, such as not using it for user-defined styles, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the enabled canvas edit tools from /v2/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 already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds the endpoint and the fact that it lists only enabled tools with their fields, costs, and limits, which is useful but not extensive. 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, both purposeful. The first sentence states the core action and endpoint, and the second adds useful context about why edit tools matter. There is no wasted text or repetition of schema 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?
For a simple, read-only listing tool with a single optional parameter, an output schema, and strong annotations, the description is complete enough. It names the endpoint, the data returned, and the domain context, leaving no significant gaps for an agent to call it correctly.
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 only parameter, rd_api_key, has full schema description coverage. The description does not need to explain the parameter, and the schema already provides its type, default, and purpose. 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 uses specific language: 'List the enabled canvas edit tools from /v2/edit/tools with their fields, costs, and limits.' This clearly identifies the verb, resource, endpoint, and what is returned, distinguishing it from sibling tools like run_edit_tool and estimate_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 helpful context by positioning edit tools as the recommended post-processing approach, but it does not explicitly state when to use this listing tool versus alternatives such as run_edit_tool or estimate_edit_tool_cost. Usage context is implied rather than directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your most recent async jobs, newest first (GET /v2/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?
Beyond the annotations, it discloses non-obvious durability behavior: a job may be accepted even if the response was lost, and listing it here is the safe way to recover it without re-submitting. This adds real value beyond readOnly/idempotent hints and has 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 concise, purpose-driven sentences followed by a useful recovery note. Every sentence contributes: the first defines the operation, the second explains why an agent might need this tool, and the sibling pointer adds actional guidance.
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 operation with an output schema and complete annotations, the description covers purpose, ordering, recovery behavior, and the next-step sibling. Nothing needed for correct invocation is missing.
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 coverage is 100%, with clear descriptions for limit, status, and rd_api_key. The description itself adds little parameter-specific meaning besides confirming the list is reverse-chronological, so the baseline of 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?
The description clearly states a specific verb and resource: 'List your most recent async jobs, newest first', and includes the exact endpoint. It also distinguishes itself from the sibling get_inference_job by positioning it as the polling tool to use after this 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?
It provides an explicit recovery path: when a submission response is lost before task_id arrives, use this tool instead of re-submitting to avoid double charges. It also names get_inference_job as the next step, but doesn't explicitly state when not to use this tool for single-job lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear 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 a canvas edit tool on an image via /v2/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, 0-10 (0 disables, default 5). | |
| 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?
The description adds useful operational behavior beyond the annotations: per-tool pricing, the endpoint pattern, and the base64_images return format. Annotations already cover read-only/idempotent/destructive hints, so the description isn't burdened with those, and there is 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?
Every sentence earns its place: endpoint, tool list with costs, free estimation caveat, and output format. It is compact, scannable, and front-loaded with the primary 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?
For a 26-parameter tool with 100% schema coverage and an output schema, the description does not need to enumerate parameters. It covers the critical workflow (estimate before paid calls), cost, and output representation, making the definition complete enough for safe 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?
With 100% schema coverage, the schema already documents most parameters, but the description adds cost categories attached to specific tool_id values, which helps an agent select the right tool parameter. It also notes that the edited image returns in base64, which is relevant to handling the output but not a schema parameter.
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 opens with a specific action and resource—'Run a canvas edit tool on an image via /v2/edit/tools/{tool_id}'—and enumerates the valid tool IDs, making the tool's job unmistakable and separating it from cost-estimation and listing siblings. The name alone is generic, but the description removes 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?
It gives an explicit workflow rule: call estimate_edit_tool_cost first for any paid tool, and flags which tools are free versus paid. It does not explicitly say 'use list_edit_tools instead when you only need metadata' or list exclusions, but the pricing guidance is concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a generation as an async job (POST /v2/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. Genre-native sizes per item: Minecraft 16; items/icons/props 32-64; character sprites 16-48 retro or 96-128 showcase; tiles 16-32; portraits 96-128; full scenes 256 (RD Pro's max; 16:9 scenes = 256x144 — pixel art integer-upscales losslessly). | |
| 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, richly and concretely ('a squat round flask of glowing crimson liquid, cork stopper, bright highlight on the upper-left rim' beats 'a potion'). Never write 'pixel art' — the selected style handles all rendering. For standalone assets, state a flat background color that contrasts the subject (default 'on a plain white background') and pair with remove_bg=true; never write 'transparent background' (that is remove_bg's job), and never leave the background unstated (it drifts to drab dark gray). Scenes instead describe their real environment. | |
| 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. Use true for standalone assets and pair it with a stated contrasting background in the prompt ('on a plain white background') — removal works best on flat contrasting backdrops. Animations inherit the start frame's transparency automatically. | |
| num_images | No | How many images to generate in one batch; a batch produces varied takes of one prompt (the right way to get N distinct items as individually usable images — never pack N items into a single sheet/grid image unless a sheet IS the deliverable). 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. Send the NATIVE-resolution image: an upscaled display copy (e.g. a 96px sprite exported at 4x = 384px) exceeds style ranges and gets rejected — downscale to the true pixel grid first. For advanced animations the frame's dimensions must equal width/height, and sprites whose opaque pixels touch the canvas edge animate badly (pad onto a larger transparent canvas first, e.g. 48x48 content onto 64x64). | |
| 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. Pick deliberately: 8 is the sweet spot for loops (walking, idle), 6 for a snappy single action, 10-12 for flowing ambient motion. | |
| 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 frame this as a non-read-only, non-idempotent write; the description adds real behavioral detail beyond that — the call returns immediately with task_id, the job runs asynchronously for tens of seconds, and the agent must poll rather than expect a synchronous result. It does not mention cost or failure-mode behavior, but nothing contradits 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?
Three sentences, each earning its place: the core action and return value, the when-to-use recommendation, and the polling cadence. The most important fact (async=true returns task_id) is front-loaded before the use-case context. No filler or repeated schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 25-param tool with an output schema and 100% param coverage, the description covers the two decisions that matter: whether to route here (animations, batches, long-running jobs) and what to do next (poll task_id). It could have named create_inference explicitly as the sync alternative and pointed at estimate_inference_cost for pre-flight cost checks, but nothing critical to correct invocation is missing.
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 each of the 25 parameters already carries rich documentation (prompt style constraints, base64 image notes, animation frame counts, upscaling, palette flags). The description adds no per-param semantics, but with coverage above 80% the rubric baselines this at 3; no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (start), resource (a generation/inference job), mechanism (POST /v2/inferences with async=true), and return (task_id). The phrase 'async job' differentiates it from the synchronous sibling create_inference, and it names its poll companion get_inference_job. No ambiguity as to what operation this performs.
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 the tool for advanced animations (rd_advanced_animation__*), other animation styles, and batch, with the concrete rationale that they run for tens of seconds and can outlive a synchronous MCP call. It also gives an actionable follow-through: poll the returned task_id with get_inference_job every 2-5 seconds. It stops short of naming create_inference as the explicit alternative for short simple request, but the sync/async contrast is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a public RD Pro user style using /v2/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 one meaningful behavioral detail: style-level references are 'baked into the custom style' and are distinct from per-inference reference_images. It does not disclose whether unspecified fields are preserved or reset, what side effects updating a style has, or any auth-related behavior. The annotations are also internally inconsistent because destructiveHint appears twice with conflicting values.
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 three short sentences with no filler. The core operation is front-loaded, and the important caveat about style-level references is stated clearly and compactly.
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 18 parameters, an output schema, and several mutual-exclusion constraints, the description is somewhat thin. It covers the endpoint and the reference distinction, and the schema compensates for parameter-level details, but it omits update semantics such as whether omitted fields are preserved and does not guide the agent on when to update versus create or delete a style.
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%, and the schema already documents parameter meanings, defaults, and constraints such as min_width being required together with min_height. The description adds only the style-level versus per-inference reference distinction, which is useful but only partially extends beyond the schema text.
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 opens with 'Update a public RD Pro user style using /v2/styles/{style_id}', which names a specific verb, resource, and endpoint. This clearly identifies the operation as an update rather than a read or list operation, though it does not explicitly contrast with create_user_style or 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 gives useful guidance for choosing style_reference_images/style_reference_caption over per-inference reference_images, which helps with parameter selection. However, it does not explain when to prefer update_user_style over create_user_style or delete_user_style, nor does it mention preconditions or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_inference6 fields changedInput schema / properties / frames_duration / descriptionPrevious value: -"Animation frame count for animation styles: 4, 6, 8, 10, 12, or 16."New value: +"Animation frame count for animation styles: 4, 6, 8, 10, 12, or 16. Pick deliberately: 8 is the sweet spot for loops (walking, idle), 6 for a snappy single action, 10-12 for flowing ambient motion."Input schema / properties / input_image / descriptionPrevious value: -"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."New value: +"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. Send the NATIVE-resolution image: an upscaled display copy (e.g. a 96px sprite exported at 4x = 384px) exceeds style ranges and gets rejected — downscale to the true pixel grid first. For advanced animations the frame's dimensions must equal width/height, and sprites whose opaque pixels touch the canvas edge animate badly (pad onto a larger transparent canvas first, e.g. 48x48 content onto 64x64)."Input schema / properties / num_images / descriptionPrevious value: -"How many images to generate in one batch. Style-specific maximums apply."New value: +"How many images to generate in one batch; a batch produces varied takes of one prompt (the right way to get N distinct items as individually usable images — never pack N items into a single sheet/grid image unless a sheet IS the deliverable). Style-specific maximums apply."Input schema / properties / prompt / descriptionPrevious value: -"Describe the SUBJECT only (e.g. 'a knight resting by a campfire'). Never write 'pixel art' — the selected style handles all rendering."New value: +"Describe the SUBJECT only, richly and concretely ('a squat round flask of glowing crimson liquid, cork stopper, bright highlight on the upper-left rim' beats 'a potion'). Never write 'pixel art' — the selected style handles all rendering. For standalone assets, state a flat background color that contrasts the subject (default 'on a plain white background') and pair with remove_bg=true; never write 'transparent background' (that is remove_bg's job), and never leave the background unstated (it drifts to drab dark gray). Scenes instead describe their real environment."Input schema / properties / remove_bg / descriptionPrevious value: -"Remove the background for transparent output."New value: +"Remove the background for transparent output. Use true for standalone assets and pair it with a stated contrasting background in the prompt ('on a plain white background') — removal works best on flat contrasting backdrops. Animations inherit the start frame's transparency automatically."Input schema / properties / width / descriptionPrevious value: -"Output width in pixels. Each style enforces its own limits; check list_available_styles or get_style_usage."New value: +"Output width in pixels. Each style enforces its own limits; check list_available_styles or get_style_usage. Genre-native sizes per item: Minecraft 16; items/icons/props 32-64; character sprites 16-48 retro or 96-128 showcase; tiles 16-32; portraits 96-128; full scenes 256 (RD Pro's max; 16:9 scenes = 256x144 — pixel art integer-upscales losslessly)."estimate_inference_cost5 fields changedInput schema / properties / frames_duration / descriptionPrevious value: -"Animation frame count for animation styles: 4, 6, 8, 10, 12, or 16."New value: +"Animation frame count for animation styles: 4, 6, 8, 10, 12, or 16. Pick deliberately: 8 is the sweet spot for loops (walking, idle), 6 for a snappy single action, 10-12 for flowing ambient motion."Input schema / properties / input_image / descriptionPrevious value: -"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."New value: +"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. Send the NATIVE-resolution image: an upscaled display copy (e.g. a 96px sprite exported at 4x = 384px) exceeds style ranges and gets rejected — downscale to the true pixel grid first. For advanced animations the frame's dimensions must equal width/height, and sprites whose opaque pixels touch the canvas edge animate badly (pad onto a larger transparent canvas first, e.g. 48x48 content onto 64x64)."Input schema / properties / num_images / descriptionPrevious value: -"How many images to generate in one batch. Style-specific maximums apply."New value: +"How many images to generate in one batch; a batch produces varied takes of one prompt (the right way to get N distinct items as individually usable images — never pack N items into a single sheet/grid image unless a sheet IS the deliverable). Style-specific maximums apply."Input schema / properties / prompt / descriptionPrevious value: -"Describe the SUBJECT only (e.g. 'a knight resting by a campfire'). Never write 'pixel art' — the selected style handles all rendering."New value: +"Describe the SUBJECT only, richly and concretely ('a squat round flask of glowing crimson liquid, cork stopper, bright highlight on the upper-left rim' beats 'a potion'). Never write 'pixel art' — the selected style handles all rendering. For standalone assets, state a flat background color that contrasts the subject (default 'on a plain white background') and pair with remove_bg=true; never write 'transparent background' (that is remove_bg's job), and never leave the background unstated (it drifts to drab dark gray). Scenes instead describe their real environment."Input schema / properties / width / descriptionPrevious value: -"Output width in pixels. Each style enforces its own limits; check list_available_styles or get_style_usage."New value: +"Output width in pixels. Each style enforces its own limits; check list_available_styles or get_style_usage. Genre-native sizes per item: Minecraft 16; items/icons/props 32-64; character sprites 16-48 retro or 96-128 showcase; tiles 16-32; portraits 96-128; full scenes 256 (RD Pro's max; 16:9 scenes = 256x144 — pixel art integer-upscales losslessly)."start_inference_job6 fields changedInput schema / properties / frames_duration / descriptionPrevious value: -"Animation frame count for animation styles: 4, 6, 8, 10, 12, or 16."New value: +"Animation frame count for animation styles: 4, 6, 8, 10, 12, or 16. Pick deliberately: 8 is the sweet spot for loops (walking, idle), 6 for a snappy single action, 10-12 for flowing ambient motion."Input schema / properties / input_image / descriptionPrevious value: -"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."New value: +"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. Send the NATIVE-resolution image: an upscaled display copy (e.g. a 96px sprite exported at 4x = 384px) exceeds style ranges and gets rejected — downscale to the true pixel grid first. For advanced animations the frame's dimensions must equal width/height, and sprites whose opaque pixels touch the canvas edge animate badly (pad onto a larger transparent canvas first, e.g. 48x48 content onto 64x64)."Input schema / properties / num_images / descriptionPrevious value: -"How many images to generate in one batch. Style-specific maximums apply."New value: +"How many images to generate in one batch; a batch produces varied takes of one prompt (the right way to get N distinct items as individually usable images — never pack N items into a single sheet/grid image unless a sheet IS the deliverable). Style-specific maximums apply."Input schema / properties / prompt / descriptionPrevious value: -"Describe the SUBJECT only (e.g. 'a knight resting by a campfire'). Never write 'pixel art' — the selected style handles all rendering."New value: +"Describe the SUBJECT only, richly and concretely ('a squat round flask of glowing crimson liquid, cork stopper, bright highlight on the upper-left rim' beats 'a potion'). Never write 'pixel art' — the selected style handles all rendering. For standalone assets, state a flat background color that contrasts the subject (default 'on a plain white background') and pair with remove_bg=true; never write 'transparent background' (that is remove_bg's job), and never leave the background unstated (it drifts to drab dark gray). Scenes instead describe their real environment."Input schema / properties / remove_bg / descriptionPrevious value: -"Remove the background for transparent output."New value: +"Remove the background for transparent output. Use true for standalone assets and pair it with a stated contrasting background in the prompt ('on a plain white background') — removal works best on flat contrasting backdrops. Animations inherit the start frame's transparency automatically."Input schema / properties / width / descriptionPrevious value: -"Output width in pixels. Each style enforces its own limits; check list_available_styles or get_style_usage."New value: +"Output width in pixels. Each style enforces its own limits; check list_available_styles or get_style_usage. Genre-native sizes per item: Minecraft 16; items/icons/props 32-64; character sprites 16-48 retro or 96-128 showcase; tiles 16-32; portraits 96-128; full scenes 256 (RD Pro's max; 16:9 scenes = 256x144 — pixel art integer-upscales losslessly)."estimate_edit_tool_cost1 field changedInput schema / properties / dither_strength / descriptionPrevious value: -"color_reducer/palette_converter: dithering strength."New value: +"color_reducer/palette_converter: dithering strength, 0-10 (0 disables, default 5)."run_edit_tool1 field changedInput schema / properties / dither_strength / descriptionPrevious value: -"color_reducer/palette_converter: dithering strength."New value: +"color_reducer/palette_converter: dithering strength, 0-10 (0 disables, default 5)."get_inference_resultlist_inference_jobsfix_pixel_art6 fields changedInput schema / properties / image_urlAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "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."
+}Input schema / properties / input_image / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / input_image / defaultAdded value: +nullInput schema / properties / input_image / descriptionPrevious value: -"Base64 PNG or JPEG to reconstruct at its native pixel grid. Raw base64 or a data URL; minimum 16x16, maximum 4 megapixels, and the complete request JSON must stay within 900,000 bytes."New value: +"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."Input schema / properties / input_image / typeRemoved value: -"string"Input schema / requiredRemoved value: -[
- "input_image"
-]fix_pixel_artauthenticate1 field changedInput schema / properties / api_key / descriptionAdded value: +"RetroDiffusion API key (rdpk-...), created free at https://retrodiffusion.ai/app/devtools."create_inference25 fields changedInput schema / properties / bypass_prompt_expansion / descriptionAdded value: +"Skip the automatic LLM prompt enrichment and use the prompt verbatim."Input schema / properties / extra_input_image / descriptionAdded value: +"Second base64 input image for styles that use one (e.g. the second texture in rd_tile__tileset_advanced)."Input schema / properties / extra_prompt / descriptionAdded value: +"Secondary prompt for styles that use one (e.g. the transition texture in advanced tilesets)."Input schema / properties / frames_duration / descriptionAdded value: +"Animation frame count for animation styles: 4, 6, 8, 10, 12, or 16."Input schema / properties / height / descriptionAdded value: +"Output height in pixels. Each style enforces its own limits; check list_available_styles or get_style_usage."Input schema / properties / include_downloadable_data / descriptionAdded value: +"Include extra structured assets when available (e.g. tileset atlas JSON, animation frame data)."Input schema / properties / input_image / descriptionAdded value: +"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."Input schema / properties / input_palette / descriptionAdded value: +"Base64 image of a color palette; output colors are constrained to it."Input schema / properties / num_images / descriptionAdded value: +"How many images to generate in one batch. Style-specific maximums apply."Input schema / properties / prompt / descriptionAdded value: +"Describe the SUBJECT only (e.g. 'a knight resting by a campfire'). Never write 'pixel art' — the selected style handles all rendering."Input schema / properties / prompt_style / descriptionAdded value: +"Style id from list_available_styles (e.g. 'rd_fast__default', 'rd_pro__isometric', or a custom 'user__...' style)."Input schema / properties / rd_api_key / descriptionAdded value: +"RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth."Input schema / properties / reference_images / descriptionAdded value: +"Extra per-inference guidance images (base64), only for styles where supports_reference_images is true. Not for defining custom styles."Input schema / properties / remove_bg / descriptionAdded value: +"Remove the background for transparent output."Input schema / properties / return_non_bg_removed / descriptionAdded value: +"Also return the render from before background removal was applied."Input schema / properties / return_pre_palette / descriptionAdded value: +"Also return the render from before palette constraints were applied."Input schema / properties / return_spritesheet / descriptionAdded value: +"For animation styles: return a PNG sprite sheet instead of a GIF."Input schema / properties / seed / descriptionAdded value: +"Seed for reproducible results; reuse the same seed to iterate on one composition."Input schema / properties / strength / descriptionAdded value: +"How strongly to change input_image, 0-1 (default 0.75). Lower values keep more of the original."Input schema / properties / tile_x / descriptionAdded value: +"Make the result tile seamlessly on the horizontal axis."Input schema / properties / tile_y / descriptionAdded value: +"Make the result tile seamlessly on the vertical axis."Input schema / properties / timeout_seconds / descriptionAdded value: +"Read-timeout override in seconds for this call; increase for animations or large batches."Input schema / properties / upload_outputs / descriptionAdded value: +"Host outputs and return URLs in output_urls (recommended for MCP clients) instead of only base64 payloads."Input schema / properties / upscale_output_factor / descriptionAdded value: +"Integer upscale factor for the output image; 1 returns the native pixel size."Input schema / properties / width / descriptionAdded value: +"Output width in pixels. Each style enforces its own limits; check list_available_styles or get_style_usage."create_user_style16 fields changedInput schema / properties / apply_prompt_fixer / descriptionAdded value: +"Let the API tidy prompts automatically for this style (default true)."Input schema / properties / description / descriptionAdded value: +"Short description of the custom style."Input schema / properties / expanded_llm_instructions / descriptionAdded value: +"Extended instructions for the prompt-expansion LLM."Input schema / properties / force_bg_removal / descriptionAdded value: +"Always remove backgrounds for this style."Input schema / properties / force_palette / descriptionAdded value: +"Always apply palette constraining for this style."Input schema / properties / llm_instructions / descriptionAdded value: +"Instructions for the prompt-expansion LLM when this style is used."Input schema / properties / min_height / descriptionAdded value: +"Force a fixed height (96-256); must be provided together with min_width."Input schema / properties / min_width / descriptionAdded value: +"Force a fixed width (96-256); must be provided together with min_height."Input schema / properties / name / descriptionAdded value: +"Display name for the custom style."Input schema / properties / rd_api_key / descriptionAdded value: +"RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth."Input schema / properties / reference_caption / descriptionAdded value: +"Alias for style_reference_caption on this tool; prefer style_reference_caption and never provide both."Input schema / properties / reference_images / descriptionAdded value: +"Alias for style_reference_images on this tool; prefer style_reference_images and never provide both."Input schema / properties / style_icon / descriptionAdded value: +"Icon name for the style (e.g. 'sparkles')."Input schema / properties / style_reference_caption / descriptionAdded value: +"Caption describing the style reference image(s)."Input schema / properties / style_reference_images / descriptionAdded value: +"Style-level reference image(s), base64, baked into the custom style (max 1 via the public API)."Input schema / properties / user_prompt_template / descriptionAdded value: +"Prompt template for the style; must contain the {prompt} token."delete_user_style2 fields changedInput schema / properties / rd_api_key / descriptionAdded value: +"RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth."Input schema / properties / style_id / descriptionAdded value: +"Style id — the internal id or the prompt_style/public id (e.g. user__mystyle_ab12)."estimate_edit_tool_costestimate_inference_cost20 fields changedInput schema / properties / bypass_prompt_expansion / descriptionAdded value: +"Skip the automatic LLM prompt enrichment and use the prompt verbatim."Input schema / properties / extra_input_image / descriptionAdded value: +"Second base64 input image for styles that use one (e.g. the second texture in rd_tile__tileset_advanced)."Input schema / properties / extra_prompt / descriptionAdded value: +"Secondary prompt for styles that use one (e.g. the transition texture in advanced tilesets)."Input schema / properties / frames_duration / descriptionAdded value: +"Animation frame count for animation styles: 4, 6, 8, 10, 12, or 16."Input schema / properties / height / descriptionAdded value: +"Output height in pixels. Each style enforces its own limits; check list_available_styles or get_style_usage."Input schema / properties / include_downloadable_data / descriptionAdded value: +"Include extra structured assets when available (e.g. tileset atlas JSON, animation frame data)."Input schema / properties / input_image / descriptionAdded value: +"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."Input schema / properties / input_palette / descriptionAdded value: +"Base64 image of a color palette; output colors are constrained to it."Input schema / properties / num_images / descriptionAdded value: +"How many images to generate in one batch. Style-specific maximums apply."Input schema / properties / prompt / descriptionAdded value: +"Describe the SUBJECT only (e.g. 'a knight resting by a campfire'). Never write 'pixel art' — the selected style handles all rendering."Input schema / properties / prompt_style / descriptionAdded value: +"Style id from list_available_styles (e.g. 'rd_fast__default', 'rd_pro__isometric', or a custom 'user__...' style)."Input schema / properties / rd_api_key / descriptionAdded value: +"RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth."Input schema / properties / reference_images / descriptionAdded value: +"Extra per-inference guidance images (base64), only for styles where supports_reference_images is true. Not for defining custom styles."Input schema / properties / return_non_bg_removed / descriptionAdded value: +"Also return the render from before background removal was applied."Input schema / properties / return_pre_palette / descriptionAdded value: +"Also return the render from before palette constraints were applied."Input schema / properties / return_spritesheet / descriptionAdded value: +"For animation styles: return a PNG sprite sheet instead of a GIF."Input schema / properties / strength / descriptionAdded value: +"How strongly to change input_image, 0-1 (default 0.75). Lower values keep more of the original."Input schema / properties / timeout_seconds / descriptionAdded value: +"Read-timeout override in seconds for this call; increase for animations or large batches."Input schema / properties / upscale_output_factor / descriptionAdded value: +"Integer upscale factor for the output image; 1 returns the native pixel size."Input schema / properties / width / descriptionAdded value: +"Output width in pixels. Each style enforces its own limits; check list_available_styles or get_style_usage."get_balance1 field changedInput schema / properties / rd_api_key / descriptionAdded value: +"RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth."get_inference_jobget_service_statusget_style_usage2 fields changedInput schema / properties / prompt_style / descriptionAdded value: +"Style id from list_available_styles (e.g. 'rd_fast__default', 'rd_pro__isometric', or a custom 'user__...' style)."Input schema / properties / rd_api_key / descriptionAdded value: +"RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth."list_available_models1 field changedInput schema / properties / rd_api_key / descriptionAdded value: +"RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth."list_available_styles3 fields changedInput schema / properties / model / descriptionAdded value: +"Filter styles by model: rd_fast, rd_plus, rd_pro, or rd_mini."Input schema / properties / rd_api_key / descriptionAdded value: +"RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth."Input schema / properties / tab / descriptionAdded value: +"Filter styles by tab: tab:image, tab:animation, tab:advanced-animation, or tab:tileset."list_edit_toolsrun_edit_toolstart_inference_jobupdate_user_style18 fields changedInput schema / properties / apply_prompt_fixer / descriptionAdded value: +"Let the API tidy prompts automatically for this style (default true)."Input schema / properties / description / descriptionAdded value: +"Short description of the custom style."Input schema / properties / expanded_llm_instructions / descriptionAdded value: +"Extended instructions for the prompt-expansion LLM."Input schema / properties / force_bg_removal / descriptionAdded value: +"Always remove backgrounds for this style."Input schema / properties / force_palette / descriptionAdded value: +"Always apply palette constraining for this style."Input schema / properties / llm_instructions / descriptionAdded value: +"Instructions for the prompt-expansion LLM when this style is used."Input schema / properties / min_height / descriptionAdded value: +"Force a fixed height (96-256); must be provided together with min_width."Input schema / properties / min_width / descriptionAdded value: +"Force a fixed width (96-256); must be provided together with min_height."Input schema / properties / name / descriptionAdded value: +"New display name for the custom style."Input schema / properties / rd_api_key / descriptionAdded value: +"RetroDiffusion API key (rdpk-...) for this call only; overrides session or header auth."Input schema / properties / reference_caption / descriptionAdded value: +"Alias for style_reference_caption on this tool; prefer style_reference_caption and never provide both."Input schema / properties / reference_images / descriptionAdded value: +"Alias for style_reference_images on this tool; prefer style_reference_images and never provide both."Input schema / properties / reset_forced_dimensions / descriptionAdded value: +"Clear previously forced dimensions; do not combine with min_width/min_height."Input schema / properties / style_icon / descriptionAdded value: +"Icon name for the style (e.g. 'sparkles')."Input schema / properties / style_id / descriptionAdded value: +"Style id — the internal id or the prompt_style/public id (e.g. user__mystyle_ab12)."Input schema / properties / style_reference_caption / descriptionAdded value: +"Caption describing the style reference image(s)."Input schema / properties / style_reference_images / descriptionAdded value: +"Style-level reference image(s), base64, baked into the custom style (max 1 via the public API)."Input schema / properties / user_prompt_template / descriptionAdded value: +"Prompt template for the style; must contain the {prompt} token."authenticatecreate_inferencecreate_user_styledelete_user_styleestimate_inference_costget_balanceget_style_usagelist_available_modelslist_available_styleslogoutupdate_user_style
