What can you do with this server?

This server provides AI agents with access to Qwen 2 image generation and editing capabilities via the MCP protocol. Here's what you can do: * Generate images from text (text_to_image): Create a new image from a text prompt, with options for aspect ratio and output format. * Edit an image (edit_image): Submit an image editing task by providing a source image URL and a prompt, with aspect ratio and output format options. * Remix an image (remix_image): Create a remix of an existing image using a source URL and prompt, with support for acceleration levels (none, regular, high) and output format. * Check task status (get_task): Poll or retrieve the current status and result (including output URLs) of any previously created task by its ID. * Check pricing (check_pricing): Look up current pricing for Qwen 2 models and endpoints without requiring an API key. All task creation tools support an optional waiting/polling mode. The server is compatible with MCP-enabled hosts such as Claude Code, Codex, and Cursor.

How do I use Qwen 2 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., "@Qwen 2 MCP Server generate a sunset over the ocean" 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.

Qwen 2 MCP Server

by runapi-ai

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

Why This Package?

@runapi.ai/qwen-2-mcp is a focused Model Context Protocol server for the Qwen 2 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 Qwen 2. Use @runapi.ai/mcp when one assistant should discover every RunAPI model line.

Related MCP server: grok-imagine-mcp

Install

Add it to Claude Code:

claude mcp add qwen-2 -s user -- npx -y @runapi.ai/qwen-2-mcp

Use project scope when the server should be shared with a repository:

claude mcp add qwen-2 -s project -- npx -y @runapi.ai/qwen-2-mcp

Codex, Cursor, Windsurf, VS Code, Roo Code, and other MCP hosts can use the same stdio command:

{
  "mcpServers": {
    "qwen-2": {
      "command": "npx",
      "args": ["-y", "@runapi.ai/qwen-2-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.

Tools

Tool	Auth	Purpose
`edit_image`	Yes	Create a Qwen 2 edit image task and optionally wait for a terminal status. Returns the task id, status, and output URLs.
`text_to_image`	Yes	Create a Qwen 2 text to image task and optionally wait for a terminal status. Returns the task id, status, and output URLs.
`get_task`	Yes	Fetch the current status and latest payload for an existing task.
`check_pricing`	No	Look up current pricing for a Qwen 2 model and endpoint.

Models

Qwen 2 covers 2 model variants across 2 endpoints. Each tool accepts the models listed for it:

Tool	Models
`edit_image`	`qwen-2-edit-image`
`text_to_image`	`qwen-2-text-to-image`

Model availability can change between releases. Use check_pricing or the Qwen 2 model page for the current catalog view.

Agent Prompts

Ask your assistant in natural language; it can inspect pricing, create the task, and return the task id plus output URLs.

Create a task

Run a Qwen 2 edit image task with RunAPI.

The assistant can call check_pricing, then edit_image, and return the task id, status, and output URLs.

Submit without waiting

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 pricing before creating

Check current Qwen 2 pricing, then create the task if it matches my request.

The assistant calls check_pricing and can link to the Qwen 2 model page for the canonical catalog entry.

Configuration

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.

Links

Resource	URL
Qwen 2 model page	https://runapi.ai/models/qwen-2
npm package	@runapi.ai/qwen-2-mcp
GitHub repository	runapi-ai/qwen-2-mcp
RunAPI MCP overview	runapi.ai/mcp
RunAPI docs	runapi.ai/docs

License

Licensed under the Apache License, Version 2.0.

Available Tools

5 tools

check_pricingA

Look up RunAPI pricing for the qwen-2 model line.

ParametersJSON Schema

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.

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. 'Look up' indicates a read-only operation, which is a useful behavioral signal, but it does not disclose the return format, error handling, or any other implications. It is minimally sufficient but leaves room for improvement.

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, concise sentence that directly states the purpose. It contains no redundancy or irrelevant information, and it is front-loaded with the action and subject.

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 lookup tool with optional parameters and no output schema, the description adequately conveys the core function. However, it could be more complete by indicating what kind of pricing information is returned (e.g., per-call cost, rate limits) or noting that it is read-only.

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 schema provides 100% coverage of parameters with descriptions and enums, so this dimension is at baseline. The description adds no extra meaning beyond what is already in the schema, nor does it clarify the relationship between 'model line' and the specific model values.

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 function with a specific verb ('Look up') and resource ('RunAPI pricing for the qwen-2 model line'). It is easily distinguishable from sibling tools like login, edit_image, and get_task, which serve entirely different purposes.

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 for looking up pricing but provides no explicit guidance on when to use it vs. alternatives. It lacks any mention of prerequisites, exclusions, or helpful context about the model line or parameters.

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

edit_imageB

Create a Qwen 2 task on RunAPI (edit image). Returns a task id, status, and output URLs.

ParametersJSON Schema

Name	Required	Description
`seed`	No
`wait`	No	Poll until the task reaches a terminal status.
`model`	No	RunAPI model slug for this model line.
`prompt`	Yes
`timeout_ms`	No
`aspect_ratio`	No
`callback_url`	No
`output_format`	No
`poll_interval_ms`	No
`source_image_url`	Yes
`enable_safety_checker`	No

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden of disclosure. It mentions returning a task id, status, and output URLs, which hints at asynchronous processing, but it does not explain that output URLs may only be available after task completion, how to poll, or whether the operation has side effects (e.g., creating a new image). The safety checker, callback, and polling parameters are not explained.

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?

The description is two sentences long and front-loaded with the verb and resource. It contains no unnecessary words, but it sacrifices critical detail for brevity. Every sentence contributes, but the overall structure could be more informative.

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?

Given 11 parameters, no annotations, and no output schema, the description is severely insufficient. It lacks guidance on async workflows, parameter values, and edge cases. The existence of sibling tools like get_task suggests a workflow that is not described here.

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

Parameters2/5

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

Schema description coverage is only 18% (model and wait only). The description provides no parameter-specific meaning. The phrase 'edit image' implies the existence of a source image and prompt, but it does not name or explain the required parameters (prompt, source_image_url) or optional behaviors. The description does not compensate for the low coverage.

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 states a specific verb ('Create') and resource ('Qwen 2 task on RunAPI') with the parenthetical '(edit image)' distinguishing it from the sibling text_to_image tool. It also specifies the return value structure, so the agent knows what to expect.

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?

There is no explicit guidance on when to use this tool versus alternatives like text_to_image. The name and '(edit image)' imply it is for image-editing tasks, but the description does not state that this tool should be used for editing and text_to_image for generation. No exclusions or preferences are given.

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

get_taskB

Fetch the current status and latest result payload for a qwen-2 task.

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes	Asynchronous endpoint the task was created on.
`task_id`	Yes	Task id returned when the task was created.

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description must carry the full burden of disclosing side effects and behavior. It states the read-only action ('Fetch'), but does not mention whether the call is safe to repeat, what happens if the task is incomplete, auth requirements, or error semantics. This leaves significant behavioral gaps.

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 redundant information. Every word contributes to defining the tool's purpose and scope.

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?

The absence of an output schema and annotations means the description must explain return behavior and contextual details. It mentions 'status and latest result payload' but does not describe how status is represented, when the payload becomes available, pagination (if any), or error conditions. For a tool with only 2 parameters and no rich schema, this is a notable gap.

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 provides complete descriptions for both parameters (task_id and action), covering 100% of the query parameters. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.

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

Purpose4/5

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

The description uses a specific verb ('Fetch') and names the resource ('qwen-2 task') and the data returned ('current status and latest result payload'). It clearly differentiates from sibling tools like login, edit_image, and text_to_image, though without explicitly naming them as alternatives.

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 the tool is used to check on an existing asynchronous task created via siblings, but it does not explicitly state when to use it, what prerequisites exist (e.g., task_id from a prior call), or which alternatives to consider. The wording 'current status' hints at polling, but no direct guidance is provided.

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

loginA

Authenticate RunAPI by opening a browser PKCE login flow and saving the API key to ~/.config/runapi/config.json.

ParametersJSON Schema

Name	Required	Description	Default
`force`	No	Re-run browser login when the current credential comes from the local config file.

TDQS

A4/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

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 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.

Usage Guidelines3/5

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.

text_to_imageB

Create a Qwen 2 task on RunAPI (text to image). Returns a task id, status, and output URLs.

ParametersJSON Schema

Name	Required	Description
`seed`	No
`wait`	No	Poll until the task reaches a terminal status.
`model`	No	RunAPI model slug for this model line.
`prompt`	Yes
`timeout_ms`	No
`aspect_ratio`	No
`callback_url`	No
`output_format`	No
`poll_interval_ms`	No
`enable_safety_checker`	No

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It discloses the return shape (task id, status, output URLs) and the creating action, but does not explain the asynchronous nature, wait/polling behavior, callback mechanism, or safety checker. Behavior beyond the obvious create action is under-specified.

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 exactly two sentences, with the main action front-loaded and the return info added second. Every sentence earns its place; no fluff.

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?

Given 10 parameters, no annotations, and no output schema, this description is far too sparse. It lacks guidance on configuration (aspect ratio, output format), async behavior, and error cases. The return statement is helpful but insufficient for a complex task creation tool.

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

Parameters2/5

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

Schema description coverage is only 20% (2 of 10 params have descriptions). The tool description adds no parameter-level explanations – it only mentions the overall 'text to image' function. It does not clarify prompt, seed, aspect_ratio, output_format, or other meaningful parameters, which the low schema coverage does not compensate for.

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 begins with 'Create a Qwen 2 task on RunAPI (text to image)' – a specific verb and resource. It clearly differentiates from sibling tools like edit_image and get_task by specifying the text-to-image generation use case and the RunAPI platform.

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 this tool is for generating images from text ('text to image') but provides no explicit guidance on when to choose it over alternatives like edit_image. No exclusions or alternative tool references are given; usage context is inferred rather than stated.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.7Aug 5, 2026

Changedcheck_pricing2 fields changed

changedInput schema / properties / action / enum

Previous value: -[
-  "edit_image",
-  "remix_image",
-  "text_to_image"
-]New value: +[
+  "edit_image",
+  "text_to_image"
+]

changedInput schema / properties / model / enum

Previous value: -[
-  "qwen-2-edit-image",
-  "qwen-2-remix-image",
-  "qwen-2-text-to-image"
-]New value: +[
+  "qwen-2-edit-image",
+  "qwen-2-text-to-image"
+]

Changededit_image6 fields changed
- addedInput schema / properties / callback_url
```
Added value: +{
+  "type": "string"
+}
```
- addedInput schema / properties / enable_safety_checker
```
Added value: +{
+  "type": "boolean"
+}
```
- addedInput schema / properties / prompt / type
```
Added value: +"string"
```
- addedInput schema / properties / seed
```
Added value: +{
+  "type": "number"
+}
```
- addedInput schema / properties / source_image_url / type
```
Added value: +"string"
```
- addedInput schema / required
```
Added value: +[
+  "prompt",
+  "source_image_url"
+]
```

Changedget_task2 fields changed

changedInput schema / properties / action / description

Previous value: -"Endpoint the task was created on."New value: +"Asynchronous endpoint the task was created on."

changedInput schema / properties / action / enum

Previous value: -[
-  "edit_image",
-  "remix_image",
-  "text_to_image"
-]New value: +[
+  "edit_image",
+  "text_to_image"
+]

Removedremix_image
Changedtext_to_image5 fields changed
- addedInput schema / properties / callback_url
```
Added value: +{
+  "type": "string"
+}
```
- addedInput schema / properties / enable_safety_checker
```
Added value: +{
+  "type": "boolean"
+}
```
- addedInput schema / properties / prompt / type
```
Added value: +"string"
```
- addedInput schema / properties / seed
```
Added value: +{
+  "type": "number"
+}
```
- addedInput schema / required
```
Added value: +[
+  "prompt"
+]
```

1 tool updatev0.1.6Jul 11, 2026
- Addedlogin
5 tool updatesv0.1.0Jun 24, 2026
- First observedcheck_pricing
- First observededit_image
- First observedget_task
- First observedremix_image
- First observedtext_to_image

Install Server

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

TDQS

A3.7/5.0

Scored 2026-08-05 00:35 across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: login (auth), edit_image and text_to_image (different task creation modes), get_task (retrieval), and check_pricing (billing). No overlap or ambiguity between tools.

Naming Consistency4/5

Most tools follow a verb_noun pattern (edit_image, get_task, check_pricing), but login is a bare verb and text_to_image is a noun phrase rather than a clear verb_noun. Slight inconsistency but still readable and predictable.

Tool Count5/5

Five tools cover the essential workflows for a Qwen 2 image server: authentication, two generation modes, result retrieval, and pricing. The count is well-scoped and each tool earns its place.

Completeness5/5

The tool set covers the full lifecycle: authenticate, create a task (edit or generate), check results, and even check pricing. There are no obvious dead ends or critical missing operations for the stated domain.

Maintenance

ActivitySlowing

ResponsivenessNo issues

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

fengyinxia-jimeng-mcp
ai.smithery
Create images and videos from prompts, with options for image mixing, reference images, and start/…
Image & Video Processing Multimedia Processing
2
APICK AI A
app.apick
LLM chat, text tools, image generation, editing and batch image jobs
AI & Machine Learning Image & Video Processing
911
FOTOhub Creative AI
app.fotohub
Generate images, video, music, voice and 3D through one API. 30 tools, 200+ models.
Image & Video Processing Audio Processing AI & Machine Learning
2
MorphedOAuth
app.morphed
Create AI images and videos, manage projects and credits, and use workspace campaign context.
AI & Machine Learning Image & Video Processing
1

Related MCP Servers

GPT Image MCP Server
Image & Video Processing AI & Machine Learning
runapi-ai
A
license
B
quality
A
maintenance
Enables creating and managing GPT Image tasks (edit and text-to-image) via RunAPI, with options to poll status and check pricing.
Updated a month ago (2026-07-31 09:32 UTC)
5
107
Apache 2.0
grok-imagine-mcp
AI & Machine Learning Image & Video Processing
runapi-ai
A
license
B
quality
A
maintenance
Enables AI image and video generation tasks (text-to-image, image-to-video, edit, upscale, etc.) via RunAPI, with support for polling and pricing lookups.
Updated 6 days ago (2026-09-04 10:59 UTC)
10
280
Apache 2.0
Recraft MCP Server
Image & Video Processing AI & Machine Learning
runapi-ai
A
license
A
quality
A
maintenance
Enables background removal and upscaling of images using Recraft models via RunAPI, with task polling and pricing lookup.
Updated a month ago (2026-07-31 09:38 UTC)
5
68
Apache 2.0
z-image-mcp
AI & Machine Learning Image & Video Processing
runapi-ai
A
license
B
quality
A
maintenance
Enables text-to-image generation using Z Image models via RunAPI, with task management and pricing lookup.
Updated a month ago (2026-07-31 09:40 UTC)
3
72
Apache 2.0