How do I use recraft-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@recraft-mcp-server generate an image of a sunset over mountains" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

recraft-mcp-server

by BartWaardenburg

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Note: This is an unofficial, community-maintained project and is not affiliated with or endorsed by Recraft.

16 tools for image generation, processing, and style management — all accessible through the Model Context Protocol.

Generate — Text-to-image, image-to-image, inpainting, background replacement & generation
Process — Background removal, region erasing, vectorization (SVG), crisp & creative upscaling
Styles — Create custom styles from reference images, list/get/delete styles
Account — Check remaining credits and user info (included in styles toolset)
Configurable — Filter toolsets, adjust cache TTL, control retries

Prerequisites

Node.js 20+ (or Docker)
A Recraft API token

Related MCP server: Recraft AI MCP Server

Installation

Claude Desktop

Add to your config file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "recraft": {
      "command": "npx",
      "args": ["-y", "recraft-mcp"],
      "env": {
        "RECRAFT_API_TOKEN": "your-api-token"
      }
    }
  }
}

VS Code

Add to .vscode/mcp.json in your workspace (or use the one-click install buttons above):

{
  "servers": {
    "recraft": {
      "command": "npx",
      "args": ["-y", "recraft-mcp"],
      "env": {
        "RECRAFT_API_TOKEN": "your-api-token"
      }
    }
  }
}

Claude Code

claude mcp add recraft-mcp -e RECRAFT_API_TOKEN=your-api-token -- npx -y recraft-mcp

Cursor

Add to Cursor's MCP settings (~/.cursor/mcp.json):

{
  "mcpServers": {
    "recraft": {
      "command": "npx",
      "args": ["-y", "recraft-mcp"],
      "env": {
        "RECRAFT_API_TOKEN": "your-api-token"
      }
    }
  }
}

Windsurf

Add to Windsurf's MCP config (~/.codeium/windsurf/mcp_config.json):

{
  "mcpServers": {
    "recraft": {
      "command": "npx",
      "args": ["-y", "recraft-mcp"],
      "env": {
        "RECRAFT_API_TOKEN": "your-api-token"
      }
    }
  }
}

Docker

docker run --rm -i -e RECRAFT_API_TOKEN="your-api-token" ghcr.io/bartwaardenburg/recraft-mcp-server:latest

Use Docker in any MCP client by replacing the command:

{
  "mcpServers": {
    "recraft": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-e", "RECRAFT_API_TOKEN=your-api-token",
        "ghcr.io/bartwaardenburg/recraft-mcp-server:latest"
      ]
    }
  }
}

Smithery

npx -y @smithery/cli install recraft-mcp --client claude

Tools

Generation

Tool	Description
`generate_image`	Generate images from a text prompt with style, size, and artistic controls
`image_to_image`	Transform an existing image based on a text prompt with adjustable strength
`inpaint_image`	Fill in masked regions of an image based on a text prompt
`replace_background`	Replace the background while preserving the foreground subject
`generate_background`	Generate a background for masked areas of an image

Processing

Tool	Description
`remove_background`	Remove the background, leaving transparency
`erase_region`	Seamlessly erase a masked region from an image
`vectorize_image`	Convert raster images to scalable SVG vectors
`crisp_upscale`	Upscale with sharp detail preservation
`creative_upscale`	Upscale with creative enhancement and added detail

Styles & Account

Tool	Description
`create_style`	Create a custom style from 1-5 reference images
`get_style`	Get details of a custom style by ID
`list_styles`	List all custom styles
`list_basic_styles`	List available curated styles
`delete_style`	Delete a custom style
`get_current_user`	Get user info and remaining credits

Tool Annotations

All tools include MCP tool annotations to help clients understand their behavior:

Tool	Read-only	Open-world
`generate_image`		Yes
`image_to_image`		Yes
`inpaint_image`		Yes
`replace_background`		Yes
`generate_background`		Yes
`remove_background`		Yes
`erase_region`		Yes
`vectorize_image`		Yes
`crisp_upscale`		Yes
`creative_upscale`		Yes
`create_style`		Yes
`get_style`	Yes	Yes
`list_styles`	Yes	Yes
`list_basic_styles`	Yes	Yes
`delete_style`		Yes
`get_current_user`	Yes	Yes

`generate_image`

Parameter	Type	Required	Description
`prompt`	string	Yes	Text description (max 1000 chars V2/V3, 10000 V4)
`model`	enum		`recraftv3` (default), `recraftv4`, `recraftv4_vector`, `recraftv2`, `recraft20b`, `refm1`
`style`	enum		`realistic_image` (default), `digital_illustration`, `vector_illustration`, `icon`, `logo_raster`
`substyle`	string		Substyle refinement (e.g. `b_and_w`, `pixel_art`, `watercolor`)
`style_id`	uuid		Custom style ID (mutually exclusive with style/substyle)
`size`	enum		Image dimensions, e.g. `1024x1024` (default), `1365x1024`, `1536x1024`, etc.
`n`	integer		Number of images to generate (1-6, default 1)
`negative_prompt`	string		What to avoid in the image
`artistic_level`	integer		0 (simple) to 5 (dynamic)
`no_text`	boolean		Prevent text in the image
`image_format`	enum		`webp` or `png`
`random_seed`	integer		Seed for reproducible results

`image_to_image`

Parameter	Type	Required	Description
`image`	string	Yes	Source image (URL or base64). Max 5MB, <16MP, max 4096px per side
`prompt`	string	Yes	Description of desired changes
`strength`	number	Yes	Change magnitude: 0.0 (minimal) to 1.0 (maximum)
`model`	enum		Model to use
`style`	enum		Style category (not supported for V4)
`substyle`	string		Substyle refinement
`style_id`	uuid		Custom style ID
`n`	integer		Number of outputs (1-6)
`negative_prompt`	string		What to avoid
`image_format`	enum		`webp` or `png`
`random_seed`	integer		Seed for reproducibility

`inpaint_image`

Parameter	Type	Required	Description
`image`	string	Yes	Source image (URL or base64)
`mask`	string	Yes	Grayscale PNG mask (white = inpaint, black = preserve)
`prompt`	string	Yes	What to generate in the masked area
`model`, `style`, `substyle`, `style_id`, `n`, `negative_prompt`, `image_format`, `random_seed`			Same as generate_image

`replace_background`

Parameter	Type	Required	Description
`image`	string	Yes	Source image (URL or base64)
`prompt`	string	Yes	Description of the new background
`model`, `style`, `substyle`, `style_id`, `n`, `negative_prompt`, `image_format`, `random_seed`			Same as generate_image

`generate_background`

Parameter	Type	Required	Description
`image`	string	Yes	Source image (URL or base64)
`mask`	string	Yes	Mask defining the background area
`prompt`	string	Yes	Description of the background to generate
`model`, `style`, `substyle`, `style_id`, `n`, `negative_prompt`, `image_format`, `random_seed`			Same as generate_image

`remove_background`

Parameter	Type	Required	Description
`image`	string	Yes	Image (URL or base64)
`image_format`	enum		`webp` or `png`

`erase_region`

Parameter	Type	Required	Description
`image`	string	Yes	Source image (URL or base64)
`mask`	string	Yes	Grayscale mask (white = erase, black = preserve)
`image_format`	enum		`webp` or `png`

`vectorize_image`

Parameter	Type	Required	Description
`image`	string	Yes	Image to vectorize (URL or base64)

`crisp_upscale`

Parameter	Type	Required	Description
`image`	string	Yes	Image to upscale (URL or base64). Max 5MB, <4MP
`image_format`	enum		`webp` or `png`

`creative_upscale`

Parameter	Type	Required	Description
`image`	string	Yes	Image to upscale (URL or base64). Max 5MB, <16MP
`image_format`	enum		`webp` or `png`

`create_style`

Parameter	Type	Required	Description
`images`	string[]	Yes	1-5 reference images (URLs or base64)
`style`	enum	Yes	Base style category

`get_style`

Parameter	Type	Required	Description
`style_id`	uuid	Yes	Style ID to retrieve

`delete_style`

Parameter	Type	Required	Description
`style_id`	uuid	Yes	Style ID to delete

`list_styles`, `list_basic_styles`, `get_current_user`

No parameters required.

Configuration

Environment Variable	Description	Default
`RECRAFT_API_TOKEN`	Required. Your Recraft API token	—
`RECRAFT_TOOLSETS`	Comma-separated toolsets to enable: `generation`, `processing`, `styles`	All
`RECRAFT_CACHE_TTL`	Cache TTL in seconds (`0` to disable)	`120`
`RECRAFT_MAX_RETRIES`	Max retry attempts on rate limit (429)	`3`

Toolset Filtering

Reduce the number of tools exposed to the LLM by enabling only what you need:

# Only image generation
RECRAFT_TOOLSETS=generation

# Generation + processing, no style management
RECRAFT_TOOLSETS=generation,processing

Supported Models

Model	Description
`recraftv3`	Recraft V3 (default)
`recraftv4`	Recraft V4 (latest raster)
`recraftv4_vector`	Recraft V4 Vector (SVG output)
`recraftv2`	Recraft V2
`recraft20b`	Recraft 20B (legacy)
`refm1`	RefM1

Note: V4 models do not support the style parameter — use the prompt to control style.

Supported Styles

Style	Substyles
`realistic_image` (default)	`b_and_w`, `enterprise`, `hard_flash`, `hdr`, `motion_blur`, `natural_light`, `studio_portrait`
`digital_illustration`	`pixel_art`, `hand_drawn`, `grain`, `infantile_sketch`, `2d_art_poster`, `handmade_3d`, `engraving`, `comic_book`
`vector_illustration`	`bold_stroke`, `chemistry`, `colored_stencil`, `contour_pop_art`, `flat_2`, `line_art`, `line_circuit`
`icon`	`broken_line`, `colored_outline`, `colored_shapes`, `doodle_fill`, `doodle_offset_fill`, `offset_fill`, `outline`
`logo_raster`	—

Image Input

Tools that accept images (image_to_image, inpaint_image, remove_background, etc.) support:

URL — Any publicly accessible HTTP(S) URL
Base64 — Raw base64-encoded image data

Security

API token — Your RECRAFT_API_TOKEN is sent only to the Recraft API (https://external.api.recraft.ai). It is never logged or stored beyond the process lifetime.
Image data — Images are sent to Recraft's servers for processing. No image data is cached on disk.
Network access — This server makes outbound HTTPS requests to external.api.recraft.ai and registry.npmjs.org (for update checks).

See SECURITY.md for reporting vulnerabilities.

Development

pnpm install         # Install dependencies
pnpm dev             # Run with tsx (hot reload)
pnpm build           # Compile TypeScript
pnpm test            # Run tests
pnpm typecheck       # Type check

See CONTRIBUTING.md for guidelines.

License

MIT

Available Tools

16 tools

create_styleCreate Custom StyleA

Create a custom style from 1-5 reference images. The style can be used in subsequent image generation by passing the returned style_id. Reference images define the visual style that will be applied.

ParametersJSON Schema

Name	Required	Description	Default
`style`	Yes	Base style category for the custom style.
`images`	Yes	1-5 reference images as URLs or base64-encoded strings.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations show readOnlyHint=false (write operation) and openWorldHint=true. The description adds that it returns a style_id, but does not disclose side effects, authentication needs, or failure modes. It adds minimal behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences, each adding value. Front-loaded with the core action, then explains usage and returned value. No redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers creation, input constraints (1-5 images), and use of the returned style_id. No output schema exists, but the description adequately explains the outcome. Could mention error conditions or required permissions, but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, explaining both parameters (images, style). The description restates '1-5 reference images' and mentions the returned style_id, but adds no new parameter details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a custom style from 1-5 reference images and returns a style_id for later use. It distinguishes itself from sibling tools like generate_image or list_styles by focusing on style creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage in a workflow (create then use style in generation), but does not explicitly state when to use this tool versus alternatives like list_styles or delete_style. No exclusions or when-not-to-use guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

creative_upscaleCreative UpscaleA

Upscale an image with creative enhancement — adds detail and improves quality beyond simple scaling. Best for artistic images where added creative detail is desirable. Input image must be max 5MB and <16MP.

ParametersJSON Schema

Name	Required	Description	Default
`image`	Yes	Image to upscale as a URL or base64-encoded string. Max 5MB, <16MP.
`image_format`	No	Output format.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are minimal (readOnlyHint=false, openWorldHint=true). The description discloses input constraints (max 5MB, <16MP) and that the tool adds detail and improves quality. However, it does not describe behavioral traits like irreversibility, cost, or effect on original image. Adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with main action, then usage guidance and constraint. No filler words; every sentence adds value. Extremely concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with 2 parameters and no output schema, the description covers core behavior, input constraints, and usage context. It could mention output format possibilities, but the schema covers that. Contextually sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both parameters. The description repeats the input constraint from the schema but adds no significant new meaning about parameters, such as defaults or behavior of image_format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Upscale an image with creative enhancement.' It distinguishes from simple scaling and implies differentiation from sibling 'crisp_upscale' by specifying 'added creative detail.' The verb and resource are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides guidance on when to use: 'Best for artistic images where added creative detail is desirable.' It implies when not to use (non-artistic images) but does not explicitly name alternatives. This is clear but lacks explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

crisp_upscaleCrisp UpscaleA

Upscale an image with crisp, sharp detail preservation. Best for images where sharpness is important. Input image must be max 5MB and <4MP.

ParametersJSON Schema

Name	Required	Description	Default
`image`	Yes	Image to upscale as a URL or base64-encoded string. Max 5MB, <4MP.
`image_format`	No	Output format.

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=false and openWorldHint=true. Description repeats file size constraints from schema but adds no new behavioral context beyond that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words, essential information front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Sufficient for a tool with complete schema descriptions and no output schema. Provides file constraints and output format option, though return value type is implied.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the description adds no new meaning for parameters beyond what's already in the input schema. 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/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Upscale an image with crisp, sharp detail preservation' and notes it's best for images where sharpness is important, distinguishing it from siblings like 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/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Best for images where sharpness is important', giving clear context for when to use this tool over alternatives, though it lacks explicit '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.

delete_styleDelete Custom StyleA

Delete a custom style by its ID. This action is irreversible.

ParametersJSON Schema

Name	Required	Description	Default
`style_id`	Yes	The style ID to delete.

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the action is irreversible, which is a key behavioral trait not covered by annotations (which only indicate mutation and open world). This adds value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. The action and consequence are front-loaded, making it easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple single-parameter tool with no output schema, the description adequately covers the action, resource, and key consequence (irreversibility). No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with one parameter. The description adds 'by its ID' but does not provide additional semantics beyond the schema's format and pattern.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Delete' and resource 'custom style', distinguishing it from siblings like create_style, get_style, and list_styles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when wanting to remove a custom style. It does not specify exclusions like built-in styles, but the title 'Delete Custom Style' provides clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

erase_regionErase RegionA

Erase a region from an image defined by a mask. The erased area is filled seamlessly. Provide the image and a grayscale mask (white = erase, black = preserve).

ParametersJSON Schema

Name	Required	Description
`mask`	Yes	Grayscale mask as a URL or base64-encoded string. White = erase, black = preserve.
`image`	Yes	Source image as a URL or base64-encoded string.
`image_format`	No	Output format.

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false, and description confirms modification (erase). Adds that filling is seamless and mask interpretation. With openWorldHint=true, description does not address potential side effects or limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the main action. No wasted words, every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, description explains the tool's behavior and input requirements sufficiently, but does not mention the return value (likely an image) or error conditions. Sibling tools exist, but the description is largely self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description reinforces mask meaning but does not add new information beyond schema for `image_format` or clarify formats for `image` and `mask` beyond what schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states that the tool erases a region from an image using a mask, with seamless filling. It differentiates from siblings like `inpaint_image` only implicitly through the mask specification, but not explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description tells how to provide image and mask but does not specify when to use this tool over alternatives such as `inpaint_image` or `remove_background`. No exclusions or alternative tool names given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_backgroundGenerate BackgroundB

Generate a background for an image using a mask to define the background area. The mask indicates which areas should be filled with the generated background.

ParametersJSON Schema

Name	Required	Description
`n`	No	Number of output images (1-6).
`mask`	Yes	Mask defining the background area as a URL or base64-encoded string.
`image`	Yes	Source image as a URL or base64-encoded string.
`model`	No	Model to use.
`style`	No	Style category.
`prompt`	Yes	Description of the background to generate.
`style_id`	No	Custom style ID.
`substyle`	No	Substyle.
`random_seed`	No	Seed for reproducibility.
`image_format`	No	Output format.
`negative_prompt`	No	What to avoid.

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false, confirming mutation, but the description adds no further behavioral context (e.g., auth requirements, rate limits, what happens to original image). It merely restates functionality.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with action, no wasted words. Every sentence contributes to defining the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite high parameter count (11) and no output schema, the description does not clarify mask color conventions, output format, or return behavior. It minimally defines the task but leaves gaps for a complex generation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description only mentions mask and prompt briefly, adding marginal value beyond the schema's existing parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'generate', the resource 'background for an image', and the method 'using a mask'. It distinguishes itself from sibling tools like remove_background by specifying generation rather than removal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as replace_background or image_to_image. It does not mention any prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_imageGenerate ImageA

Generate images from a text prompt using Recraft AI. Supports multiple styles (realistic, illustration, vector, icon, logo), various sizes, and fine-tuning controls like color palette and artistic level. V4 models do not support style parameters — use the prompt to control style instead.

ParametersJSON Schema

Name	Required	Description
`n`	No	Number of images to generate (1-6). Default: 1.
`size`	No	Image dimensions as WxH. Default: 1024x1024.
`model`	No	Model to use. Default: recraftv3.
`style`	No	Style category. Not supported for V4 models. Default: realistic_image.
`prompt`	Yes	Text description of the image to generate. Max 1000 chars for V2/V3, 10000 for V4.
`no_text`	No	Prevent text from appearing in the image.
`style_id`	No	Custom style ID. Cannot be used together with style/substyle.
`substyle`	No	Substyle to refine the style (e.g. 'b_and_w', 'pixel_art', 'watercolor').
`random_seed`	No	Seed for reproducible results.
`image_format`	No	Output format: webp or png.
`artistic_level`	No	Artistic level from 0 (simple) to 5 (dynamic).
`negative_prompt`	No	What to avoid in the generated image.

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate this is a generative, open-world tool. The description adds context about model-specific behavior (V4 style restriction) and mentions style/size controls, but lacks details on rate limits or output handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences. The first sentence captures the main purpose and capabilities, the second adds a critical caveat. No unnecessary words, effectively front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (12 parameters, no output schema), the description covers the core functionality and a key limitation. However, it omits details about the output format (e.g., image URL or base64) and potential variability due to openWorldHint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed descriptions. The description adds value by clarifying the interaction between model and style for V4, but does not significantly expand on parameter meanings beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it generates images from text prompts using Recraft AI, listing supported styles and controls. It distinguishes from sibling tools like image_to_image by focusing on text-to-image generation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides conditional guidance: V4 models do not support style parameters. However, it does not explicitly discuss when to use this tool versus siblings like image_to_image or generate_background.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_current_userGet Current UserA

Read-only

Retrieve information about the authenticated user, including remaining credits.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds value beyond annotations by specifying that the result includes 'remaining credits'. The readOnlyHint annotation is already present, but the description provides a concrete detail about what kind of information is returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. Every part earns its place: it specifies the action, the resource, and a key return element.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and no output schema, the description is mostly complete. It explains what the tool returns (user info + credits). However, it could be slightly more explicit about the need for authentication, though 'authenticated user' implies it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so schema coverage is 100%. The description adds meaning by indicating the output includes user information and credits. With 0 parameters, the baseline is 4, and the description meets that.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'retrieve' and the resource 'information about the authenticated user', with a specific detail about including remaining credits. This distinguishes it from all sibling tools which deal with images, styles, or other operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool versus alternatives, but the tool's purpose is unique among siblings. It implicitly tells the agent to use it to get user info, but lacks explicit 'when not to use' or mention of alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_styleGet Style DetailsB

Read-only

Retrieve details of a custom style by its ID.

ParametersJSON Schema

Name	Required	Description	Default
`style_id`	Yes	The style ID to retrieve.

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, so the tool is known to be safe and non-destructive. The description adds no extra behavioral context beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no wasted words. Front-loaded with verb and resource. Could be slightly expanded to include return value without harming conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a single parameter and readOnly annotations, the description is adequate but lacks detail on what details are returned. No output schema increases need for more description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 1 parameter with full description. The tool description does not add meaning beyond the schema, which already documents the parameter's purpose. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('retrieve details') and resource ('custom style by its ID'). It is specific and implies a singular lookup, distinguishing from list or create tools, but does not explicitly differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like list_styles or when a style does not exist. Does not mention prerequisites or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

image_to_imageImage to ImageB

Transform an existing image based on a text prompt. The strength parameter controls how much the image changes (0.0 = minimal change, 1.0 = maximum change). Provide the image as a URL or base64-encoded string.

ParametersJSON Schema

Name	Required	Description
`n`	No	Number of output images (1-6).
`image`	Yes	Source image as a URL or base64-encoded string. Max 5MB, <16MP, max 4096px per side.
`model`	No	Model to use.
`style`	No	Style category. Not supported for V4 models.
`prompt`	Yes	Description of desired changes to the image.
`strength`	Yes	Change magnitude from 0.0 (minimal) to 1.0 (maximum).
`style_id`	No	Custom style ID.
`substyle`	No	Substyle to refine the style.
`random_seed`	No	Seed for reproducibility.
`image_format`	No	Output format.
`negative_prompt`	No	What to avoid.

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare mutation (readOnlyHint=false) and open world. The description adds only minor input format hints already present in schema. No additional behavioral traits (e.g., side effects, limits) 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/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundancy. Front-loaded purpose, then parameter hint. Every word serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 11 parameters and no output schema, the description is too minimal. It doesn't explain optional parameters (model, style) or output behavior, leaving gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description echoes some parameter info (strength, image format) but adds no new semantics beyond what's in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Transform an existing image based on a text prompt,' which is a specific verb and resource. It distinguishes from siblings like generate_image (creates new) and other 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance. The purpose implies use for modifying existing images, but no comparison with alternatives like generate_image or inpaint_image.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

inpaint_imageInpaint ImageA

Inpaint (fill in) a masked region of an image based on a text prompt. Requires the original image and a grayscale mask (white = inpaint, black = preserve).

ParametersJSON Schema

Name	Required	Description
`n`	No	Number of output images (1-6).
`mask`	Yes	Grayscale PNG mask as a URL or base64-encoded string. White = areas to inpaint, black = areas to preserve.
`image`	Yes	Source image as a URL or base64-encoded string.
`model`	No	Model to use.
`style`	No	Style category.
`prompt`	Yes	Description of what to generate in the masked area.
`style_id`	No	Custom style ID.
`substyle`	No	Substyle.
`random_seed`	No	Seed for reproducibility.
`image_format`	No	Output format.
`negative_prompt`	No	What to avoid.

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool modifies the image (not read-only) and details the mask semantics. It does not mention potential rate limits, size constraints, or that the original image may be transformed, but annotations already indicate it is a mutation. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, front-loaded with the operation and key inputs. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 11 optional params and no output schema, the description covers the core functionality well. It could mention optional controls (style, seed) but they are documented in the schema. Overall adequate for an agent to understand the main purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents each parameter. The description adds minor emphasis on the mask's color meaning, which is already in the schema. No additional value beyond that.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the operation ('inpaint'), the required inputs (image, mask, prompt), and the mask color semantics. It distinguishes from sibling tools like erase_region (which removes without filling) and replace_background (which targets the 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/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use (inpainting a masked region with a prompt) and the required inputs, but it does not explicitly state when not to use or mention alternative tools for similar tasks (e.g., erase_region for removal without filling).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_basic_stylesList Basic StylesA

Read-only

List all available curated/basic styles provided by Recraft. These can be used as the style parameter in generation tools.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint and openWorldHint, indicating a safe read operation with possibly dynamic data. The description reinforces this by mentioning 'available' styles, but doesn't add new behavioral constraints or details about the returned data format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loading the purpose and then clarifying usage. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema), the description is adequate. It explains what the function returns and how to use it. While it doesn't describe the output format, the context of 'list' implies a collection, and the openWorldHint suggests completeness is not guaranteed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so the description doesn't need to explain them. The baseline for 0 parameters is 4, and the description provides sufficient context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists all curated/basic styles from Recraft, specifying the resource (curated/basic styles) and the action (list). It distinguishes from siblings like list_styles (which likely includes other style types) by specifying 'basic' styles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the tool's purpose and how the output can be used (as style parameter in generation tools). While it doesn't explicitly exclude alternatives, the context is clear enough for an agent to decide when 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.

list_stylesList Custom StylesA

Read-only

List all custom styles created by the authenticated user.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint. Description adds user scope context but no additional behavioral traits beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded, no extraneous words. Every word serves the purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple zero-parameter tool with readOnlyHint and openWorldHint annotations, the description fully covers the purpose and scope. Output schema not needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so description cannot add param info beyond schema. Baseline 4 for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the verb 'List', resource 'custom styles', and scope 'by the authenticated user'. It clearly distinguishes from sibling tools like list_basic_styles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context (listing user's custom styles) but does not provide explicit guidance on when to use this tool versus alternatives like list_basic_styles.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

remove_backgroundRemove BackgroundA

Remove the background from an image, leaving a transparent background. Provide the image as a URL or base64-encoded string.

ParametersJSON Schema

Name	Required	Description	Default
`image`	Yes	Image as a URL or base64-encoded string.
`image_format`	No	Output format: webp or png.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate mutation (readOnlyHint=false) and variability (openWorldHint=true). The description adds that the output has a transparent background, but does not discuss side effects, auth needs, or error states. The behavioral disclosure is minimal beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the purpose, and contains no fluff. Every sentence is relevant and earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with two parameters and no output schema, the description covers the main behavior (removing background, transparent output, input options). However, it omits mention of output format or any limitations (e.g., image requirements). Slightly incomplete but adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description adds no new information about parameters beyond already-stated input formats and enum. It does not explain the image_format parameter or provide additional context not in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'remove' and resource 'background from an image', leaving a transparent background. This specifically distinguishes it from siblings like 'replace_background' and '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/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides input format (URL or base64) but lacks explicit guidance on when to use this tool versus alternatives like 'replace_background'. The decision is implied by the name, but no when-not or if-then reasoning is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

replace_backgroundReplace BackgroundA

Replace the background of an image while preserving the foreground subject. Provide a text prompt describing the new background.

ParametersJSON Schema

Name	Required	Description
`n`	No	Number of output images (1-6).
`image`	Yes	Source image as a URL or base64-encoded string.
`model`	No	Model to use.
`style`	No	Style category.
`prompt`	Yes	Description of the new background.
`style_id`	No	Custom style ID.
`substyle`	No	Substyle.
`random_seed`	No	Seed for reproducibility.
`image_format`	No	Output format.
`negative_prompt`	No	What to avoid.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=false (modification) and openWorldHint=true (unpredictable). The description adds that the foreground is preserved, but does not disclose other behavioral traits like potential failures, destructive effects, or rate limits. It provides some additional context but not extensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with no wasted words. It front-loads the core action and immediately follows with the key guidance about the prompt.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (10 parameters, no output schema), the description covers the essential behavior and required input. It lacks return value details (e.g., output images), but annotations and schema partially fill gaps. Almost complete for an AI to select and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents parameters well. The description mentions the 'prompt' parameter's purpose ('Provide a text prompt describing the new background'), but adds no significant meaning beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Replace the background of an image while preserving the foreground subject', which specifies the verb 'replace' and the resource 'background of an image'. This distinguishes it from siblings like 'remove_background' and '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/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use (when you want to replace the background with a text-described scene), but does not explicitly state when not to use or compare to alternatives. Sibling tools like 'remove_background' and 'generate_background' are not mentioned, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

vectorize_imageVectorize ImageA

Convert a raster image (PNG/JPG/WEBP) to a scalable vector SVG format. Useful for converting logos, icons, and illustrations to resolution-independent vectors.

ParametersJSON Schema

Name	Required	Description	Default
`image`	Yes	Image to vectorize as a URL or base64-encoded string.

TDQS

A3.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and openWorldHint=true, but the description only says 'convert' without disclosing side effects, permission needs, or output specifics like SVG quality or color handling. Fails to add behavioral depth beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. Front-loaded with the core action and supported by an example of usefulness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a simple 1-param tool with no output schema, the description covers input format and use cases. However, it does not describe the output (e.g., SVG string or file), leaving the agent guessing about the return type.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'image' has a clear description in the schema (URL or base64), which is already covered. The description adds no further detail but schema coverage is 100%, so baseline is 3; the description's mention of 'URL or base64-encoded string' adds marginal value, justifying a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool converts raster images (PNG/JPG/WEBP) to SVG format, specifying use cases like logos and icons. It is distinct from all listed sibling 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/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides usage context (converting logos, icons, illustrations) and mentions the benefit (resolution-independent vectors). However, it does not explicitly state when not to use it or compare to alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation4/5

Most tools have distinct purposes with clear descriptions. However, pairs like erase_region and inpaint_image (both fill regions) or generate_background and replace_background (both background-related) could cause confusion if descriptions are not carefully read.

Naming Consistency4/5

Names follow a mostly consistent verb_noun pattern in snake_case. The lone exception is 'image_to_image', which is a noun phrase rather than a verb action. The modifiers in 'creative_upscale' and 'crisp_upscale' are acceptable but break the simple verb_noun scheme.

Tool Count4/5

Sixteen tools is slightly above the ideal range for a focused server, but the number is justified by the breadth of image generation and editing operations. Each tool serves a distinct operation, and no tool appears redundant.

Completeness4/5

The tool set covers core image generation, style management, and common editing tasks. Missing operations include updating a style or batch processing, but these are not essential for the primary use case. The surface is generally well-rounded.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp A
com.budgetpixel
Generate AI images, video, music, and sound effects, and upscale them, from any MCP client.
AI & Machine Learning Image & Video Processing Audio Processing
1211
mcp-nanobanana-pro
io.github.AceDataCloud
MCP server for NanoBanana AI image generation and editing
Image & Video Processing Multimedia Processing
27
mcp-flux-pro
io.github.AceDataCloud
MCP server for Flux AI image generation
Image & Video Processing Multimedia Processing
23
mcp-qwen-image
io.github.AceDataCloud
MCP server for Qwen Image 3 AI image generation
AI & Machine Learning Image & Video Processing
1

Related MCP Servers

Stability AI MCP Server
Image & Video Processing RAG Systems
tadasant
A
license
Not graded
quality
D
maintenance
An MCP Server that integrates with Stability AI's API to provide high-quality image generation, editing, and manipulation capabilities including background removal, outpainting, search-and-replace, and upscaling.
Updated a year ago (2025-06-24 22:16 UTC)
82
84
MIT
Recraft AI MCP Serverofficial
Image & Video Processing Developer Tools
recraft-ai
A
license
A
quality
F
maintenance
An MCP server that integrates with Recraft AI to enable generation and manipulation of high-quality raster and vector images through tools like image generation, editing, vectorization, background removal, and upscaling.
Updated 2 months ago (2026-07-13 10:45 UTC)
9
139
60
MIT
Image MCP Server
Image & Video Processing Multimedia Processing
iplanwebsites
A
license
C
quality
C
maintenance
An MCP server that provides AI image generation capabilities using OpenAI and Replicate APIs with support for customizable prompts and dimensions. It features specialized tools for generating square, landscape, and portrait images through simple natural language commands.
Updated a year ago (2025-06-16 19:51 UTC)
5
43
MIT
Nano-Banana MCP Server
AI & Machine Learning Image & Video Processing
bongartzdiaz
A
license
A
quality
D
maintenance
An MCP server that provides AI image generation and editing capabilities using Google's Gemini 2.5 Flash Image API. It allows users to create new images from text, modify existing files, and perform iterative edits through natural language prompts.
Updated 5 months ago (2026-03-28 12:32 UTC)
6
758
MIT

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BartWaardenburg/recraft-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Prerequisites

Installation

Claude Desktop

VS Code

Claude Code

Cursor

Windsurf

Docker

Smithery

Tools

Generation

Processing

Styles & Account

Tool Annotations

generate_image

image_to_image

inpaint_image

replace_background

generate_background

remove_background

erase_region

vectorize_image

crisp_upscale

creative_upscale

create_style

get_style

delete_style

list_styles, list_basic_styles, get_current_user

Configuration

Toolset Filtering

Supported Models

Supported Styles

Image Input

Security

Development

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Recraft AI MCP Serverofficial

Latest Blog Posts

MCP directory API

`generate_image`

`image_to_image`

`inpaint_image`

`replace_background`

`generate_background`

`remove_background`

`erase_region`

`vectorize_image`

`crisp_upscale`

`creative_upscale`

`create_style`

`get_style`

`delete_style`

`list_styles`, `list_basic_styles`, `get_current_user`