The Recraft MCP Server provides AI agents with access to Recraft image processing tools via the RunAPI platform, enabling the following capabilities:
Remove Background (remove_background): Submit an image URL to create a background removal task using the recraft-remove-background model. Supports optional polling until completion, with configurable timeout and poll interval settings.
Upscale Image (upscale_image): Submit an image URL to create an image upscaling task using the recraft-crisp-upscale model. Also supports optional polling until the task reaches a terminal status.
Check Task Status (get_task): Fetch the current status and result payload for a previously created task by providing its task ID and action type (remove_background or upscale_image).
Control Task Waiting: Tasks can either poll until completion (wait: true) or return immediately for later status checks (wait: false).
Check Pricing (check_pricing): Look up current pricing for Recraft model endpoints (e.g., recraft-remove-background, recraft-crisp-upscale) without requiring authentication.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Recraft MCP Server remove background from https://example.com/photo.png"
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.
@runapi.ai/recraft-mcp is a focused Model Context Protocol server for the Recraft model line on RunAPI.
It gives MCP-compatible assistants direct access to 2 endpoints and 2 model variants without loading the full RunAPI catalog.
Use this per-model server when an agent should stay scoped to Recraft. Use @runapi.ai/mcp when one assistant should discover every RunAPI model line.
Related MCP server: Runware MCP Server
Add it to Claude Code:
claude mcp add recraft -s user -- npx -y @runapi.ai/recraft-mcpUse project scope when the server should be shared with a repository:
claude mcp add recraft -s project -- npx -y @runapi.ai/recraft-mcpCodex, Cursor, Windsurf, VS Code, Roo Code, and other MCP hosts can use the same stdio command:
{
"mcpServers": {
"recraft": {
"command": "npx",
"args": ["-y", "@runapi.ai/recraft-mcp"]
}
}
}check_pricing works before sign-in. For task creation and status polling, ask your assistant to call the login tool. It opens a browser login and saves credentials to ~/.config/runapi/config.json, the same file used by runapi login.
Headless and CI hosts can still set RUNAPI_API_KEY before starting the MCP host.
Ready-made examples are in examples/ for Claude, Cursor, Windsurf, VS Code, and Roo Code.
Tool | Auth | Purpose |
| Yes | Create a Recraft remove background task and optionally wait for a terminal status. Returns the task id, status, and output URLs. |
| Yes | Create a Recraft upscale image task and optionally wait for a terminal status. Returns the task id, status, and output URLs. |
| Yes | Fetch the current status and latest payload for an existing task. |
| No | Look up current pricing for a Recraft model and endpoint. |
Recraft covers 2 model variants across 2 endpoints. Each tool accepts the models listed for it:
Tool | Models |
|
|
|
|
Model availability can change between releases. Use check_pricing or the Recraft model page for the current catalog view.
Ask your assistant in natural language; it can inspect pricing, create the task, and return the task id plus output URLs.
Run a Recraft remove background task with RunAPI.The assistant can call check_pricing, then remove_background, and return the task id, status, and output URLs.
Create the task but don't wait for it to finish.The assistant calls the create tool with wait: false and returns the task id. Check on it later with get_task.
Check current Recraft pricing, then create the task if it matches my request.The assistant calls check_pricing and can link to the Recraft model page for the canonical catalog entry.
The server resolves auth in this order:
RUNAPI_API_KEY environment variable, useful for headless and CI hosts
~/.config/runapi/config.json, created by the MCP login tool or runapi login
No key, which still allows check_pricing
The config file is normally managed by login. A pre-provisioned headless config can use:
{
"apiKey": "your_runapi_key"
}Do not commit real API keys.
Resource | URL |
Recraft model page | |
npm package | |
GitHub repository | |
RunAPI MCP overview | |
RunAPI docs |
Licensed under the Apache License, Version 2.0.
Look up RunAPI pricing for the recraft model line.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model slug. Defaults to the line's primary model. | |
| action | No | Endpoint name. Defaults to the endpoint that offers the model. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full behavioral burden and falls short: it doesn't state that this is a read-only, non-billing lookup, whether authentication or credits are required, or what the pricing response represents (units, currency, tiers). 'Look up' implies a safe read, but that is inference, not disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with the key information front-loaded and no filler. It is efficient, though so terse that the scope clause ('recraft model line') is the only detail it offers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must fill more gaps than it does: return value shape, whether the lookup is free/safe, and how the two optional parameters steer the result are all unaddressed. For a pricing-query tool with zero structured behavioral coverage, this is too thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (model slug and action enum) are already documented with their defaults; baseline 3 applies. The description adds no parameter-level meaning beyond the schema and never mentions that the model defaults to the line's primary model or that action defaults to the endpoint offering the model.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('look up RunAPI pricing') and scopes it to a model line, which is enough to distinguish it from operational siblings like remove_background, upscale_image, and get_task. However, 'for the recraft model line' sits awkwardly beside a schema that accepts an arbitrary model slug and an action enum, leaving the exact scope slightly ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No indication of when to call this versus the sibling tools. It never says whether this is a pre-flight cost check before invoking remove_background/upscale_image, or whether it is required before those calls, and no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the current status and latest result payload for a recraft task.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Asynchronous endpoint the task was created on. | |
| task_id | Yes | Task id returned when the task was created. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the operation is a read that returns status and the latest result payload, which is useful context, but it omits permissions, error behavior, or whether results may be null while a task is pending.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to describing the operation and the data returned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple polling tool with a fully documented schema, the description is nearly complete: it names the resource and the returned data. It is slightly lacking because no output schema exists and the description does not explain the shape or lifecycle of the result payload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are fully documented in the schema. The description adds no additional parameter meaning beyond what the schema already provides, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Fetch') and resource ('current status and latest result payload for a recraft task'), making the purpose immediately clear. It does not explicitly differentiate itself from sibling tools like remove_background or upscale_image, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no when-to-use guidance, no alternatives, and no prerequisites. It does not explain that this tool should be used after creating an asynchronous task or how to poll with it, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Authenticate RunAPI by opening a browser PKCE login flow and saving the API key to ~/.config/runapi/config.json.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Re-run browser login when the current credential comes from the local config file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the interactive browser flow and the file write side effect (config.json). However, it does not mention that it may overwrite existing credentials or that it could block waiting for user input, though these are implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action ('Authenticate RunAPI') and provides necessary details without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple login tool with one optional parameter and no output schema, the description covers the core purpose and side effect. It lacks an explicit statement that this is a prerequisite for other tools, but that is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the only parameter 'force' has a description). The tool description adds no additional meaning about parameters beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Authenticate'), target resource ('RunAPI'), method ('browser PKCE login flow'), and side effect (saving to config.json). It is distinct from sibling tools, none of which relate to authentication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (to authenticate RunAPI) but does not explicitly say when to run it (e.g., before other RunAPI tools) or when to use the 'force' parameter. Since there are no alternative auth tools among siblings, 'vs alternatives' is not applicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Recraft task on RunAPI (remove background). Returns a task id, status, and output URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Poll until the task reaches a terminal status. | |
| model | No | RunAPI model slug for this model line. | |
| timeout_ms | No | ||
| callback_url | No | Declared type: string. | |
| poll_interval_ms | No | ||
| source_image_url | Yes | Declared type: string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that a task is created and what the response generally contains (task id, status, output URLs), which is useful. However, it omits behavioral traits like async polling behavior, whether the operation is idempotent, what happens on failure, or any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise clauses, front-loaded with the action and the backend target. No waste, and the response contents are noted tersely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 1 required, no annotations, and no output schema, the description provides basic context about the return shape but leaves gaps: it doesn't explain async behavior, timeout handling, or how wait and poll_interval_ms interact. It is adequate but incomplete for a task-based asynchronous tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, above the baseline threshold. The description adds no parameter-level meaning beyond what the schema provides. With 6 parameters and only 1 required, an agent could benefit from knowing more about wait, model, and callback_url, but the schema covers several of these.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb+resource ('remove background') and states the backend operation ('Create a Recraft task on RunAPI'). It distinguishes itself from siblings like upscale_image and get_task, though it doesn't explicitly reference them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, no pointer to alternatives. The presence of sibling tools like upscale_image and get_task makes routing ambiguous, yet the description offers no selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Recraft task on RunAPI (upscale image). Returns a task id, status, and output URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Poll until the task reaches a terminal status. | |
| model | No | RunAPI model slug for this model line. | |
| timeout_ms | No | ||
| callback_url | No | Declared type: string. | |
| poll_interval_ms | No | ||
| source_image_url | Yes | Declared type: string. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden. It discloses the return payload (task id, status, output URLs), which is genuinely useful with no output schema, but says nothing about the async lifecycle, that wait=true blocks and polls, timeout behavior, cost, or any required credentials.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the purpose front-loaded and the return contract second. No filler, though it is arguably too terse for a 6-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a task-submission tool with no annotations and no output schema, the description should explain the async model, polling semantics, and the wait flag. It covers only the return shape, leaving the core invocation behavior undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters at all. With only 67% schema coverage and source_image_url's schema description being a vacuous 'Declared type: string.', the description adds no meaning about what to pass or how wait/timeout_ms/poll_interval_ms/callback_url interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Create a Recraft task') and resource ('upscale image'), and even previews the return shape. It does not explicitly differentiate itself from siblings like get_task or remove_background, but the operation described is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance. For an async task-submission tool it never says how it relates to get_task for polling, or when wait=true vs wait=false is appropriate. The agent must infer the workflow entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0check_pricing2 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / model / enumRemoved value: -[
- "recraft-remove-background",
- "recraft-crisp-upscale"
-]get_task2 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / action / descriptionPrevious value: -"Endpoint the task was created on."New value: +"Asynchronous endpoint the task was created on."remove_background8 fields changedInput schema / additionalPropertiesPrevious value: -falseNew value: +{}Input schema / properties / callback_urlAdded value: +{
+ "description": "Declared type: string.",
+ "type": "string"
+}Input schema / properties / model / enumRemoved value: -[
- "recraft-remove-background"
-]Input schema / properties / poll_interval_ms / maximumAdded value: +9007199254740991Input schema / properties / source_image_url / descriptionAdded value: +"Declared type: string."Input schema / properties / source_image_url / typeAdded value: +"string"Input schema / properties / timeout_ms / maximumAdded value: +9007199254740991Input schema / requiredAdded value: +[
+ "source_image_url"
+]upscale_image8 fields changedInput schema / additionalPropertiesPrevious value: -falseNew value: +{}Input schema / properties / callback_urlAdded value: +{
+ "description": "Declared type: string.",
+ "type": "string"
+}Input schema / properties / model / enumRemoved value: -[
- "recraft-crisp-upscale"
-]Input schema / properties / poll_interval_ms / maximumAdded value: +9007199254740991Input schema / properties / source_image_url / descriptionAdded value: +"Declared type: string."Input schema / properties / source_image_url / typeAdded value: +"string"Input schema / properties / timeout_ms / maximumAdded value: +9007199254740991Input schema / requiredAdded value: +[
+ "source_image_url"
+]v0.1.6loginv0.1.0check_pricingget_taskremove_backgroundupscale_imageScored across 5 tools
Each tool has a clearly distinct purpose: remove_background and upscale_image are non-overlapping image operations, while get_task, check_pricing, and login serve separate functions. No two tools could be confused.
Four of five tools follow a clean verb_noun snake_case pattern (remove_background, upscale_image, get_task, check_pricing). The only deviation is 'login', which is a single word acting as both noun and verb, but overall consistency is strong.
Five tools is a well-scoped number, each earning its place for task creation, status checking, pricing, and authentication. It is slightly thin for a full Recraft platform integration, but reasonable for a focused RunAPI wrapper.
Despite being named 'Recraft MCP Server', the surface exposes only two image operations (background removal and upscaling) out of Recraft's broader capabilities, and lacks task listing, cancellation, or core generation features like image creation and vectorization. These are significant gaps for the apparent domain.
AI-powered image processing via GPU. Remove backgrounds and upscale images (2x/4x) directly from any MCP client. OAuth 2.1 authenticated, returns processed images inline with download links. Free credits on signup at maskr.io.
LLM chat, text tools, image generation, editing, batch image jobs, and asynchronous video generation
Video, audio, and image processing for AI agents: convert, transcribe, upscale - 150+ operations.
Generate and edit images, create videos, quote credit costs, and retrieve private results.
