recraft-mcp-server
Server Quality Checklist
Latest release: v1.2.0
- Disambiguation3/5
Most tools fall into clearly distinguishable categories such as generation, background editing, upscaling, and vectorization, but several close-purpose tools overlap, including inpaint/erase_region/texture_swap and image_to_image/variate_image/explore_similar. The descriptions help, but an agent would need to read carefully to avoid selecting the wrong editing tool.
Naming Consistency3/5All tools share the recraft_ prefix and use snake_case, which keeps things readable, but the underlying pattern is mixed: many are verb_noun (generate_image, remove_background), while others are single verbs (inpaint, vectorize), reversed noun_verb (texture_swap), or adverb/adjective_verb (batch_generate, creative_upscale). This is not chaotic, but it lacks a single predictable convention.
Tool Count3/524 tools is at the heavy end of a reasonable range and approaches the threshold where the surface becomes hard to navigate. The breadth is somewhat justified by the wide scope of image generation, editing, background replacement, upscaling, asset pipelines, and style exploration, but several tools could potentially be consolidated.
Completeness4/5The server covers the core lifecycle of image creation and manipulation: generating, editing, inpainting/outpainting, background changes, upscaling, vectorizing, style creation, comparison, and batch asset generation. Minor gaps exist, such as no listing or deletion of custom styles and no image metadata retrieval, but these do not block typical agent workflows.
Average 3.9/5 across 24 of 24 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral disclosure burden. It only says the results are 'similar but different versions,' and omits details such as whether the original image is preserved, how many results may be returned, output/response behavior, or any cost or randomness implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler and the action front-loaded. The second sentence adds a useful clarification that the outputs are similar but distinct, so every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no annotations, no output schema, and a 23-tool sibling suite, this description is too thin to support reliable selection and invocation. It lacks guidance on response contents, output count behavior, and how it differs from recraft_image_to_image or recraft_batch_generate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies. The description adds no meaningful parameter-level detail beyond 'existing image' mapping to file_path; the size, n, image_format, and response_format semantics are already covered by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Generate variations of an existing image') and clarifies the output as 'similar but different versions.' It is clear about the resource and result, but it does not explicitly distinguish this tool from nearby siblings such as recraft_image_to_image or recraft_explore_similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives like batch_generate, image_to_image, or explore_similar. The description only restates the operation, leaving selection among sibling tools to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It usefully explains that white mask areas are removed and content-aware filled, but it does not state whether the source file is mutated, what kind of output is returned, or any side effects or limitations beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core operation front-loaded and a clarifying behavioral detail in the second sentence. There is no filler or redundant structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core mask behavior is covered, and the schema handles parameter documentation, but with no annotations and no output schema, the description does not disclose output format behavior, source-file mutation, or how this tool differs from overlapping siblings. It is minimally complete but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all three parameters at 100% coverage, so the baseline is 3. The description adds 'White mask areas are erased and filled naturally,' which reinforces mask_path semantics, but it does not add meaningful parameter-level information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('erase'), a resource ('region in an image'), and a mechanism ('using a mask'), and clarifies that white mask areas are removed and filled naturally. It is clear on its own, but it does not explicitly distinguish this tool from the sibling recraft_inpaint or from the other removal/editing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use erase_region versus recraft_inpaint, recraft_remove_background, or recraft_outpaint. The mask semantics imply a use case, but no when/when-not criteria or alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses that strength controls preservation of the original and that only V3/V3 Vector models are supported. However, it does not disclose output behavior, whether the original file is modified, side effects, or any operational limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core action is front-loaded, and the strength behavior and model restriction are stated efficiently. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 11 parameters, nested objects, no output schema, and no annotations. The description covers only the basic purpose, strength, and model restriction. It lacks output expectations, sibling differentiation, and usage context, leaving too much for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds some framing for strength and model constraints, but mostly restates information already present in the schema rather than adding new parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: transform an existing image with a text prompt. This clearly distinguishes it from text-to-image generation. However, it does not explicitly differentiate it from closely related siblings like recraft_variate_image or recraft_inpaint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for editing existing images via prompt, and it adds a model restriction ('V3/V3 Vector models only'). But it gives no explicit guidance on when to choose this tool over alternatives, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does add useful behavior context: it declares support for all Recraft model families and reveals that V4 Vector models produce SVG output, which is a genuine behavioral trait not obvious from the schema. However, it omits operational behaviors that matter when calling a paid generation API, such as credit consumption, rate limits, or how output is delivered beyond the schema's response_format enum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences totaling roughly 45 words, with the core purpose front-loaded in the first sentence. Each subsequent sentence adds non-redundant capability context (model coverage, style/control options, SVG behavior), so no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully documents all ten parameters, so the parameter surface is well covered and the description does not need to repeat it. For a tool with this complexity, the description gives a solid high-level orientation but leaves gaps: no differentiation from overlapping generation siblings, no credit or cost disclosure, and no mention of prompt-length or other constraints that only appear buried in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even without parameter detail in the description. The description's references to models, styles, color palette, text layout, and sizes largely mirror existing schema properties, but the note that V4 Vector models produce SVG adds a selection-relevant meaning not present in the model enum descriptions, keeping it at baseline rather than below.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Generate images from text prompt' states a specific verb, resource, and input source, leaving no ambiguity about the core function. The supporting sentences enumerate capabilities (all model families, 70+ styles, palette, text layout, sizes, SVG output) that clearly distinguish it from specialized siblings like recraft_erase_region, recraft_variate_image, or recraft_image_to_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus any of its 23 siblings. Overlapping tools such as recraft_batch_generate, recraft_generate_sized, recraft_generate_asset, and recraft_variate_image are never mentioned, and there is no when-to-use or when-not-to-use statement. The only routing signal is the tool's name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose the source-image prerequisite and gives concrete meaning to the similarity parameter, but it does not mention output behavior, failure modes, or side effects. For a non-destructive generation tool, this is a moderate but acceptable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with no filler. The core action and source constraint are front-loaded, and the similarity explanation is concise and directly useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter tool, the description combined with the fully-described schema covers required inputs, source provenance, and similarity semantics. The absence of an output schema is partially mitigated by the response_format enum, although the description does not explicitly describe return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning by labeling similarity endpoints ('1=slightly, 5=extremely similar') and emphasizing that the source image must originate from recraft_explore, which goes slightly beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation ('Generate images visually similar') and identifies the source resource ('a source image previously created with recraft_explore'). It is clear enough to distinguish from recraft_explore itself, though it does not explicitly differentiate from similar sibling tools like recraft_variate_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used after a recraft_explore call and explains the similarity scale. However, it does not explicitly state when not to use this tool or name alternatives such as recraft_variate_image, leaving usage selection partially to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does disclose the main output behavior — creating individual images and an optional comparison grid — but it omits other behavioral details like writing files to output_dir, consuming credits, or what happens when grid=false. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The core operation is front-loaded, the optional grid behavior is stated second, and the use case is a short, useful closing note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is thorough, so the description only needs to supply selection-level context. It does that well by clarifying the same-prompt-across-styles behavior, the individual images plus grid output, and the intended decision-making use case. A small gap is that it does not explicitly state the number of images or that files are saved to output_dir, though the schema covers the latter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 and the schema already documents every parameter. The description only adds high-level semantic alignment ('same prompt' maps to prompt, 'multiple styles' maps to styles, 'comparison grid' maps to grid) without adding details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Generate') and resource ('the same prompt in multiple styles'), clearly establishing the tool's role as a style comparison generator. It further distinguishes itself from sibling tools like recraft_generate_image or recraft_batch_generate by highlighting 'side-by-side comparison' and the optional comparison grid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Great for choosing the best style for your project' implies a use case, but the description does not explicitly state when to prefer this tool over alternatives such as recraft_generate_image or recraft_explore. There are no exclusions or 'use X instead' guidance, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses the key behavioral effect: white mask areas are regenerated while black areas are preserved, which effectively indicates what gets replaced. The model restriction is also transparent, though other behavioral details like output format or number of variations are left to the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the operation and immediately follows with the most important behavioral constraint (mask semantics) and model restriction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich 100%-covered schema, the description is reasonably complete for a tool of this complexity. It provides the core semantics and model constraint, and the schema fills in the parameter details. It could go further by guiding selection versus sibling tools, but nothing essential is missing for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description does not add much beyond what the schema provides, though it restates the mask_path behavior in plain language, which is mildly helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool edits specific image regions using a mask, and it usefully explains the mask color semantics (white regenerated, black preserved). It does not explicitly name the closest sibling such as recraft_erase_region, but the operation is specific and understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended use case: region-specific editing via a mask, with model restriction to V3/V3 Vector only. It does not explicitly state when to prefer this tool over siblings like recraft_erase_region or recraft_outpaint, nor does it give exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the core behavioral effect ('Replace the background... Keeps the subject, changes the scene') and calls out a model restriction. However, it does not disclose whether the original file is modified or a new image is returned, the output format, or any side effects, which is a notable gap for an image-generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The core function is front-loaded, and the additional semantic clarification ('Keeps the subject, changes the scene') earns its place. The model limitation is stated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 10 parameters, nested objects, no annotations, and no output schema, the description offers only a brief purpose statement and model note. It omits usage scenarios, sibling-tool differentiation, and return-value behavior, which an agent would need for this complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning about parameters beyond implying that the prompt describes the new background, which is minimal but acceptable given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description has a specific verb ('Replace'), a clear resource ('the background of an image'), and the key outcome ('Keeps the subject, changes the scene'). This distinguishes it from sibling tools like recraft_remove_background and recraft_generate_background without needing to open their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use this tool: when the intent is to preserve the subject while generating a new scene. It also states an explicit model constraint ('V3/V3 Vector only'), which helps the agent avoid invalid calls, though it does not explicitly name alternative tools or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does disclose that the upscale is creative, includes AI-generated detail, and refines faces, which is useful beyond the tool name. However, it does not describe output behavior, potential image modifications, or any side effects, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core action is front-loaded, followed by a precise use-case qualifier. Every word contributes to understanding the tool's purpose and appropriate context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple two-parameter tool: it states what the tool does and when it is best used. However, there is no output schema and no mention of return format or how the output is delivered, so an agent is not fully informed about the call's result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented in the schema. The tool description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Upscale an image') and a resource, then clarifies its creative nature with 'AI-generated detail enhancement and face refinement.' This clearly differentiates it from sibling recraft_crisp_upscale, which implies a more straightforward, non-creative upscale.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Best for photos and realistic images' gives a clear context for when to use this tool. It does not explicitly mention alternatives or when not to use it, but the use-case guidance is specific enough to route an agent appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions the output effect and model compatibility, but does not disclose side effects, whether the original file is modified, output handling, credit costs, or failure modes. For a generation tool with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first states the operation, the second differentiates from the sibling, and the third lists the key control parameters. The content is front-loaded and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is rich (16 params, nested controls), but with no output schema and no annotations, the description should provide more invocation context, such as the required file_path/prompt and how results are returned. The differentiator addresses only one of many image-editing siblings, and no guidance is given for other alternatives like inpaint or erase_region. It is adequate for selection but not fully complete for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter is already documented. The description's summary of 'target size, per-side expand amounts, and/or a zoom-out percentage' restates the parameter groups without adding new semantic detail beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Extend'), a resource ('an image beyond its original boundaries'), and a clear mechanism ('AI-generated content (canvas expansion)'). It explicitly contrasts with recraft_generate_background, which 'only fills masked areas within the existing canvas', making the tool's unique scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names the closest alternative (recraft_generate_background) and explains the difference, telling an agent when not to use this tool. It also adds a compatibility precondition ('V3/V3 Vector only') and hints at the three control modes (size, expand amounts, zoom-out percentage), which helps the agent select between parameter groups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses the return value and model compatibility, but it does not mention persistence, credit consumption, or other side effects of creating a style.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each carrying distinct information: input, output, and compatibility. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers the inputs, the output, and the compatibility constraint. Since there is no output schema, the explicit style_id mention is valuable; a note about persistence or side effects would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description's mention of 1-5 reference images mirrors the file_paths schema, and it adds no additional semantics about style_base.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: create a custom style from 1-5 reference images, and clearly identifies the key output (style_id). This distinguishes it from the sibling generation and editing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear workflow context: the style_id is for use in generation tools, and the V3/V3 Vector-only restriction helps an agent decide applicability. It does not explicitly name alternatives or exclusions, but the operation is distinct enough that the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It communicates the enhancement style ('sharp, clean') and intended subjects, but does not disclose limitations such as upscale factor, aspect ratio behavior, or whether photographic images are unsupported. It is not contradictory, but it could be more transparent about side effects and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that front-loads the core action and then adds the most useful usage context. Every word earns its place with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with a fully documented schema, the description is nearly complete. It could strengthen selection by explicitly pointing to recraft_creative_upscale for non-crisp or photographic upscaling, but its 'best for graphics, icons, illustrations' guidance substantially covers the decision context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with 100% coverage, including file_path constraints and response_format enum/default. The description adds no new parameter-level detail, but none is needed since the schema fully covers parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Upscale an image with sharp, clean enhancement.' It clearly distinguishes this tool from the sibling recraft_creative_upscale by emphasizing crisp, clean output, making the tool's purpose immediately identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Best for graphics, icons, illustrations' gives clear context about when to use this tool. It does not explicitly name alternatives or exclusions, but the placement of this tool alongside recraft_creative_upscale makes the intended use case reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden; it does state the main side effect (writing to a local file). However, it does not disclose whether existing files are overwritten, whether directories need to exist, or how download failures are surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler; the core action and the practical use case are both front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter utility with fully described schema, the description covers what the tool does and when it is useful. It could be more complete by mentioning overwrite behavior or return value, but nothing essential is missing for selection and basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already explains both parameters ('URL to download' and 'local file path to save the image'). The description does not add extra parameter-level meaning beyond restating these roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (download) and resource (image from URL) plus the concrete outcome (saving to a local file). Among siblings, which are all generation/editing tools, this is clearly the only download-and-save utility, so it distinguishes itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
'Useful for saving generated images' provides a clear context for when to call this tool. It does not name alternatives or exclusions, but no sibling performs the same function, so the absence of explicit when-not guidance is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It openly discloses the pipeline: a hero asset is created, a custom style is built from it, and all remaining symbols are generated with visual consistency. It also calls out optional background generation and a Pixi.js-compatible manifest, providing meaningful insight beyond the raw schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose, followed by a clear sequence of behavioral details. Every sentence contributes useful information, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of an output schema, the description does a solid job of conveying the overall workflow and key outputs. It could be more complete by explicitly stating where files are written or what the tool returns to the caller, but the rich parameter schema compensates for most gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds conceptual context about the pipeline but does not meaningfully elaborate on individual parameters beyond what the schema already documents. It references hero assets and style consistency without mapping them explicitly to specific parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Generate a complete themed asset set for game design.' It further explains the unique multi-step workflow (hero asset, custom style, consistent symbols, optional background, manifest), which clearly distinguishes it from sibling tools like recraft_generate_asset or recraft_generate_background.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the phrase 'complete themed asset set for game design,' which suggests it is for full sets rather than single assets. However, it does not explicitly state when to prefer this over alternatives such as recraft_generate_asset or recraft_batch_generate, nor does it mention any exclusions or fallback conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does disclose the key behavior and output format ('producing a transparent PNG'), but it does not mention whether the original file is modified, how the result is returned, or other side-effect/timing details. Adequate for a simple image transform but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and output. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema coverage, the description plus schema is largely complete. It clearly states the operation and the output, though it does not elaborate on return envelope behavior or explicitly route away from sibling tools; these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents file_path and response_format. The description adds no parameter-level meaning beyond what the schema provides, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('background from an image') and names the exact output ('transparent PNG'). This clearly distinguishes it from siblings like recraft_replace_background and recraft_generate_background by the transparent-result outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool when you need the background removed from an image and a transparent PNG produced. It does not explicitly compare against sibling tools or provide exclusions, so it stops short of a 5, but the usage is not merely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It transparently identifies the operation as a conversion and names accepted input formats, but it does not disclose side effects, file-size limits, or delivery details beyond what the schema already documents. This is adequate for a simple transformation but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler. The core action and resource are front-loaded, making it easy to scan and interpret.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter conversion tool with no output schema, the description plus the fully documented input schema provide enough information to call it correctly. It does not explicitly explain return behavior, but the response_format enum covers the main delivery options, so the remaining gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already defined. The description adds value by specifying the accepted raster formats (PNG/JPG/WEBP) and the SVG output target, which helps an agent validate the file_path and understand the overall transformation beyond the schema's generic 'raster image' phrasing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Convert') with a clear resource ('raster image') and target result ('SVG vector format'), and lists accepted input types. This makes it easy to distinguish from generation and editing siblings like recraft_generate_image or recraft_image_to_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent should use this when a user wants a raster PNG/JPG/WEBP converted to SVG. However, it does not explicitly mention when not to use it or name an alternative among the many recraft_* siblings, so routing relies on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden, and it does disclose an informative behavioral workflow: generate new content, match aspect ratio, resize, and composite onto the original. It does not address credit consumption, original-file preservation, or failure modes, but the core nondestructive-ish output-to-output_path behavior is reasonably conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two focused sentences with no filler. The first sentence states the core action, and the second adds behavioral detail plus a concrete use case, all front-loaded and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, a nested region object, no annotations, and no output schema, the description explains the main workflow and target use case but omits return behavior, prerequisite conditions, and how options like style or negative_prompt interact. It is adequate for selection but not fully complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters in detail, including region, feather, model, and output_path. The description adds only high-level context about region compositing, not parameter-level semantics beyond the schema, matching the baseline for fully covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: replacing a specific image region with AI-generated content for texture swaps. It also clarifies the distinctive behavior—matching region aspect ratio, resizing, and compositing—which separates it from sibling tools like recraft_inpaint or recraft_erase_region.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly frames the tool as 'Perfect for Spine atlas texture swaps and spritesheet updates,' giving a clear use context. It does not name alternatives or exclusions, so it stops short of full routing guidance, but the intended scenario is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does well by revealing that generation is sequential, that failure is isolated per asset, and that there is a built-in 300ms rate limit delay. It could mention output/return behavior, but the disclosed pipeline and failure semantics are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The core purpose is front-loaded, and the failure-isolation and rate-limit details are presented efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch tool with nested parameters but no output schema, the description covers the essential behavioral context: sequencing, background removal, saving, failure isolation, and rate limiting. It is complete enough for correct invocation; only a more explicit return/status description would round it out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all asset properties such as name, prompt, output_dir, remove_bg, and negative_prompt. The description adds high-level pipeline context but not deeper parameter-level meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Generate multiple assets in sequence') and identifies the full pipeline (generate → bg remove → save). This distinguishes it from singular generation sibling tools like recraft_generate_asset and recraft_generate_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the primary usage context explicit: use this tool when generating multiple assets in a single batch. It does not explicitly name alternatives or give exclusion criteria, but the 'multiple assets' framing provides clear context without being vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. The word 'Check' implies a read-only operation and the scope is clear, but the description does not disclose response format, whether the call consumes credits, or any authentication requirements. For a simple status tool this is acceptable but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the resource and the action in minimal words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter account/credit status tool, the description covers the essential context: what resource is checked and what kind of information will be returned. It could optionally mention the output shape, but the absence is not a significant gap given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to add beyond what the input schema provides. The description appropriately focuses on the action and result rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Check') and resource ('Recraft account info and remaining API credits'). This unambiguously distinguishes it from all sibling tools, which are image generation or editing operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's purpose clear enough that an agent can infer when to use it: whenever account status or remaining credits are needed. It does not explicitly discuss when not to use it, but given that every sibling is an image-related operation, confusion is unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It transparently explains the transformation: the prompt is expanded with visual context, style cues, and composition details, and the result is meant for downstream generation. It stops short of stating the exact return format, but the description's 'use the result' phrasing makes the delivered value clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The core transformation is front-loaded, followed by actionable downstream guidance. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, non-destructive prompt-enhancement tool, the description is largely complete: it states inputs, transformation, and intended use of the output. It does not explicitly define the output format or include an example, but the tool's simplicity and the clear 'use the result' guidance keep the gap minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the only parameter ('prompt', 'original prompt to enhance', max 2000 chars), so schema coverage is 100%. The description adds only the qualifier 'short', which is a minor clarification. This is the appropriate baseline for a fully documented single-parameter schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('expand') and resource ('a short prompt'), and describes the outcome as a richer, more detailed description with visual context, style cues, and composition details. This distinguishes it from all sibling image-generation/manipulation tools, which operate on images rather than prompts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: use it when you have a short prompt and want a more vivid prompt for any generation tool. It also tells the agent that the result should be fed into a generation tool rather than consumed directly. It does not explicitly discuss when not to use it or mention alternatives, but this is less critical since no sibling tool performs the same prompt-enhancement function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses several behavioral traits: outputs are diverse, style/color control is coarse, and the result includes image IDs intended for recraft_explore_similar. It could go further on side effects such as count of generated images or cost/rate behavior, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. The purpose, behavioral boundary, and output hook are each conveyed in a compact, scannable way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description usefully provides the key return-value semantic (image IDs for recraft_explore_similar), and the input schema documents all parameters. It does not spell out how many images are produced, but 'set of images' plus 'diverse results' is sufficient for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters. The description adds conceptual context about coarse style/color control but no parameter-level detail beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action ('Generate a set of images') and a clear purpose ('visual exploration and discovery'), with a behavior signature ('diverse results from a prompt') that separates it from focused-generation siblings. It also names the follow-up tool recraft_explore_similar, making the tool's role distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'no fine-grained style/color control' provides an explicit boundary for when this tool is not appropriate, and 'visual exploration and discovery' gives a clear use-case context. It does not explicitly name which sibling to use when fine-grained control is needed, so the guidance stops just short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does reveal the key behavior: it does not just generate, it downloads, may remove the background, and writes to a file. It is transparent about the side effect of saving to output_path, though it doesn't mention overwrite behavior, return value, or credit/cost implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence front-loads the operation sequence and then gives concrete use cases. There is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 23 siblings, the description covers the core selection and invocation context: what the pipeline does, the final save destination, and representative use cases. It does not specify return values or behavior when the output file already exists, but these are secondary for selecting and calling the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all seven parameters are already documented in the schema. The description adds only the 'remove background' toggle context, which is already reflected in remove_bg's schema default; no substantial new parameter meaning is provided, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete multi-step operation (generate → download → optionally remove background → save to file) and the target domain (game assets, icons, UI elements). This clearly distinguishes it from siblings like recraft_generate_image (generation only) and recraft_download_image (download only), so an agent can select it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Full asset pipeline' plus 'Perfect for game assets, icons, and UI elements' gives clear context for choosing this tool over single-step siblings. It does not explicitly say when not to use it or name alternatives, so it's one notch below the most explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden; it discloses a non-obvious processing pipeline ('generates at API-compatible size, then resizes with Lanczos3 downsampling'). It does not discuss upscaling behavior, output format, or credential/credit effects, but the core behavioral trait is usefully exposed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no wasted words; the differentiator (any target size) is front-loaded, the mechanism follows in the second sentence, and the ideal use cases close it out. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with fully documented schema properties, the description covers purpose, appropriate use, and the key resizing behavior. The main missing piece is explicit guidance on when to choose this over recraft_generate_image and what the final saved output/return looks like, which is a minor gap given output_path is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 and the schema already documents width, height, prompt, fit, etc. The description adds usage-oriented context for width/height (small sizes) but does not add new semantic detail to individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Generate') and resource ('image') with a unique scope ('any target size, including small sizes like 64x64') that distinguishes it from generic generation siblings. The phrase 'Perfect for game sprites, icons, and UI elements' reinforces the intended output category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear use context (game sprites, icons, UI elements, small sizes), so an agent can infer when this tool is appropriate. It does not explicitly name excluded cases or alternative tools, so it stops short of full when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It reveals important non-obvious behavior: output stays within original bounds, white mask means fill, black means preserve, and only V3/V3 Vector is supported. It does not discuss output format or side effects, but the core behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense, front-loaded sentences cover the core function, mask semantics, an explicit alternative, and model restriction without any filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 11 parameters and no output schema, the description gives enough context to call it correctly: required inputs are clear via schema, and the key differentiator from recraft_outpaint is stated. It could more thoroughly distinguish itself from other background tools like recraft_replace_background or recraft_inpaint, but the essential invocation context is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all 11 parameters in detail. The description adds the same-size constraint and reinforces mask semantics, but it does not materially explain parameters beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (fill masked background areas), the exact resource (existing canvas), and a hard constraint (same size in, same size out). It also clarifies mask semantics, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use this tool (within existing canvas) and when not to (expanding canvas), naming the alternative recraft_outpaint directly. The V3/V3 Vector model restriction also provides clear eligibility guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/muhammetali/recraft-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server