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 "Install 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?
Without annotations, the description carries the full burden of behavioral disclosure, but it only states 'look up pricing'. It does not indicate that this is a read-only operation, whether authentication is required, or what the output format is. For a simple lookup, the lack of side effects is implicit, but more context would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose, but could be slightly expanded to include usage or behavioral details without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more context about what the tool returns and when to use it. It only covers the basic purpose, leaving gaps in understanding the tool's full behavior and relationship to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameter definitions, including enum values and descriptions. The description adds no additional meaning beyond 'recraft model line', which is already evident from the enum values. Baseline score of 3 is appropriate since the schema is self-sufficient.
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 function: look up RunAPI pricing for the recraft model line. The verb 'look up' and the specific resource 'pricing for recraft model line' distinguish it from sibling tools like remove_background and upscale_image, which perform image operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or situations where this tool is or isn't appropriate. The agent receives no help in deciding between this and sibling tools.
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 | 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?
Description only implies a read operation but lacks details on side effects, auth requirements, or behavior on missing tasks, especially given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately describes purpose but lacks details on return format or error scenarios, which would be helpful given no output schema.
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 covers both parameters with descriptions; tool description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches current status and latest result payload for a recraft task, distinguishing it from sibling tools like remove_background or upscale_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, or prerequisites like having created a task first.
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?
No annotations provided, so description carries full burden. It discloses the login flow and file save path, but does not mention potential side effects (e.g., overwriting existing config), failure modes, or the need for user interaction. Adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded and efficiently conveys the core purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one optional param, no output schema), the description covers the main behavior. However, it misses any mention of return values or prerequisites like browser availability, which would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the only param 'force'. The tool description adds no additional parameter meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool authenticates RunAPI using a PKCE flow and saves the API key to a specific file path. It is a specific verb ('Authenticate') and resource ('RunAPI'), and it is clearly distinct from siblings like check_pricing or get_task.
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 usage is implied: use this tool to authenticate. However, no explicit guidance on when not to use it or alternatives. Given siblings are unrelated, it's still clear, but a note about requiring a browser would improve it.
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 | ||
| poll_interval_ms | No | ||
| source_image_url | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions returning a task id, status, and output URLs, but fails to disclose the asynchronous nature (with polling via wait parameter) and any rate limits, authentication, or potential costs. With no annotations, the description should cover more behavioral traits.
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 concise sentence with no waste, but it lacks structure such as sections or bullet points that could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description is too brief. It does not explain how to use the returned task id or the behavior of the wait parameter, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40%; parameters like source_image_url, timeout_ms, and poll_interval_ms lack descriptions in both schema and tool description. The description does not add meaning beyond the schema's documented parameters (wait and 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?
The description clearly states it creates a Recraft task to remove background, which distinguishes it from sibling tools like upscale_image. However, it does not explicitly mention that the task is asynchronous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like check_pricing or get_task. Usage is only implied through the tool name and sibling context.
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 | ||
| poll_interval_ms | No | ||
| source_image_url | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool creates a task and returns IDs status and URLs but does not disclose that the task is asynchronous, that polling occurs via the wait parameter, or any potential costs or side effects. Important behavioral traits are missing.
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 very brief (one sentence) but misses essential details. It is not well-structured; it front-loads the purpose but omits necessary context about the async workflow and parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, no annotations, async behavior), the description is grossly inadequate. It does not explain the task lifecycle, how to obtain the upscaled image, or the meaning of any parameters. The agent would struggle to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40% (2 out of 5 parameters have descriptions). The description adds no parameter information, failing to compensate for undocumented parameters like source_image_url. It does not clarify the role of timeout_ms or poll_interval_ms.
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 verb 'Create', the resource 'Recraft task', and the specific action 'upscale image'. It also mentions the return values. This distinguishes it from sibling tools like remove_background or check_pricing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance on when to use this tool. It doesn't compare with alternatives or specify prerequisites. For example, it doesn't mention that this is for upscaling images while remove_background is for background removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: pricing lookup, task status, authentication, background removal, and upscaling. No overlap.
All tool names follow a verb_noun pattern in snake_case (e.g., check_pricing, remove_background). Even 'login' is a single verb but consistent with the verb-first style.
With 5 tools covering authentication, pricing, status checking, and two core image operations, the count feels well-scoped for a focused API wrapper.
The surface covers the key actions (login, pricing, task creation for two operations, and status polling). Missing cancel or list tasks, but the main workflows are supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
Video, audio, and image processing for AI agents: convert, transcribe, upscale - 150+ operations.
Run 100+ AI models — image, video, audio, 3D — through one API with pay-per-use billing.
130+ AI models for image, video, music, and audio — 18 model families, one RunAPI account.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/runapi-ai/recraft-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
