RunAPI Qwen Image MCP Server

Official

by runapi-ai

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation4/5
The three image generation tools (text_to_image, edit_image, remix_image) could be confused since they all create Qwen Image tasks returning similar payloads, but their action-prefix names do clearly distinguish the three modes. login, get_task, and check_pricing are distinct concerns. Only the generation trio has mild boundary ambiguity.
Naming Consistency5/5
All tools consistently follow a clear snake_case verb-first convention: login, edit_image, remix_image, text_to_image (verb or noun phrase prefix), get_task, check_pricing. There is a uniform action-oriented pattern with no mixed casing or style deviations.
Tool Count5/5
Six tools is a well-scoped surface for an image-generation API wrapper: auth, three generation modes, task status polling, and pricing lookup. Each tool earns its place and none feel redundant or unnecessary.
Completeness4/5
The surface covers the core lifecycle: authentication, generation in three modes, task polling, and pricing. Minor gaps exist—no explicit cancel/delete task or batch operations—but the primary workflows are fully supported and there are no dead ends.
Average 3.3/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on July 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It does mention it creates an asynchronous task and returns task id/status/output URLs, giving some sense of async behavior. However, it doesn't disclose rate limits, auth requirements, wait versus callback behavior, or what happens to the source image. Some context is added but not comprehensive.
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 a single efficient sentence conveying the core purpose and return shape. It's appropriately front-loaded and contains no filler. It could perhaps add a sentence on usage guidance, but as written it's compact and readable.
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?
This is a complex tool with 10 parameters and no output schema, but the description doesn't explain parameter interactions, async task semantics (wait/poll/callback options), or how results are retrieved. It mentions returning output URLs but doesn't connect to the async task model or the get_task sibling. Given the complexity and lack of output schema, more explanation is warranted.
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 80%, so the schema already documents most parameters. The description adds the overall behavioral context (returns task id/status) but doesn't elaborate on parameters beyond what the schema describes. With high schema coverage, baseline 3 is appropriate — description adds modest value but doesn't compensate for the 20% uncovered.
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 (Create a Qwen Image task), the resource (RunAPI edit image), and the return payload (task id, status, output URLs). It distinguishes from siblings like text_to_image and remix_image which cover generation/remix rather than editing. However, it doesn't explicitly contrast with the sibling edit-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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. It doesn't clarify how it differs from remix_image (which may also modify existing images), nor does it state prerequisites like needing an existing image URL. Usage context is only implied through the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The description implies a read-only lookup ('look up') but doesn't explicitly state it makes no changes, doesn't disclose any side effects, authentication needs, or response characteristics. It's a low-risk read operation, so the minimal disclosure is moderately acceptable, but richer behavioral context would help.
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 a single clear sentence that is appropriately sized for a simple lookup tool. No wasted words. It could add slightly more context, but for the tool's apparent simplicity, this length is appropriate.
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 2-param tool with full schema coverage and no output schema, the description is reasonably complete. However, no output schema exists, so the description could have disclosed what the pricing response looks like (per-unit costs, tiers, currency), which would help the agent interpret results. This is a moderate gap for a pricing lookup 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?
Both parameters have 100% schema description coverage with enums and helpful descriptions. The description adds no additional parameter detail beyond what the schema provides, so the baseline of 3 applies. With no params that require extra explanation and schema coverage at 100%, the description adequately distributes responsibility.
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 tool looks up RunAPI pricing for the qwen-image model line. Verb (look up) + resource (RunAPI pricing) + scope (qwen-image) is specific. However, it doesn't distinguish itself from sibling tools, though the siblings are mostly functional endpoint tools (edit_image, remix_image, text_to_image) that are clearly different in nature.
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. It doesn't explain that it's complementary to the sibling endpoint tools (e.g., check pricing before calling edit_image). No explicit alternatives or when-not-to-use scenarios are given. The timing/value of checking pricing before invoking an operation is implied but never stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. It clearly states this is a read operation ('Fetch') and specifies what it returns: current status and latest result payload. For a read tool, this is reasonably transparent about its purpose, though it doesn't mention whether it blocks until completion, whether it can be polled repeatedly, error behavior for invalid task IDs, or how 'status' values correspond to states. It's adequate but not rich in behavioral detail.
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?
A single, efficient sentence that covers what is fetched and for what resource type. No wasted words, no redundancy. Appropriate length for a simple read tool.
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?
This is a read/retrieval tool with no output schema and no annotations. Given that context, the description explains it returns 'status' and 'latest result payload', which is the essential expected return. However, without an output schema or annotations, it would benefit from clarifying the relationship to sibling tools (it's the async counterpart to edit_image/remix_image/text_to_image) and whether the result payload structure varies by action. It's mostly complete for a simple polling-style tool but lacks some useful context about the task lifecycle.
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 both task_id and action are already documented in the schema. The description adds the context that this relates to a 'qwen-image task' and that the result is 'latest', but it doesn't add meaning beyond the schema for the parameters themselves. Since schema coverage is complete, baseline 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') plus a clear resource ('status and latest result payload for a qwen-image task'). It's clear what the tool does. However, it doesn't explicitly distinguish from siblings — though the read-only nature versus the create/edit siblings is fairly evident from the name and phrasing. It's clear and specific, just not explicitly differentiated from siblings.
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?
There is no explicit guidance on when to use this tool versus alternatives. It's implied that this is the retrieval/polling counterpart to the creation tools (edit_image, remix_image, text_to_image) given the action enum, but the description never states 'use this after creating a task to check progress' or mentions polling semantics. The context must be inferred from sibling names rather than stated directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a task id, status, and output URLs, and mentions 'task' semantics (implying async operation), but does not disclose the wait/polling behavior, rate limits, cost implications, or reversibility. For a task-based image generation tool with zero annotations, more behavioral context is expected.
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 a single clear sentence that establishes purpose and return value in under 30 words. It is front-loaded with the key information (what it does, what it returns). While it could add usage guidance, for conciseness and structure this is appropriately sized and efficiently worded with zero waste.
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?
The tool has 9 parameters, no output schema, and no annotations, making it fairly complex. The description explains the task-based async model and return payload shape (task id, status, URLs), which is helpful context. However, it doesn't clarify the relationship between wait/poll_interval_ms/timeout_ms/callback_url parameters or when async vs sync operation is preferred. For a tool with this many configurable async behaviors, more contextual guidance would be valuable.
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 78%, which is above the 80% baseline... actually at 78%. The description adds 'Returns a task id, status, and output URLs' framing but does not explain individual parameters beyond what the schema already provides. Parameters like timeout_ms, poll_interval_ms, and callback_url are self-explanatory in schema but the description's task-based framing adds marginal context about how they relate to each other. The description compensates slightly but doesn't deeply enrich parameter semantics.
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 states a specific verb+resource: 'Create a Qwen Image task on RunAPI (text to image)'. It clearly indicates the tool generates an image from text and returns a task id, status, and output URLs. It differentiates from siblings (edit_image, remix_image) by specifying 'text to image' generation, though it could be more explicit about distinguishing itself from the editing/remix siblings.
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 indicates this tool creates a text-to-image task with optional wait behavior, but does not explicitly say when to use this vs edit_image or remix_image, nor when to use the wait parameter vs callback_url. The schema implies polling capabilities but the description doesn't provide clear guidance on selecting this tool over siblings or choosing among the async patterns (wait, callback_url).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It usefully discloses that it opens a browser window (a side effect agents should know about) and writes to a config file (~/.config/runapi/config.json), which is genuinely helpful. However, it doesn't mention whether login is idempotent, whether the browser flow is blocking/headless, or any network considerations.
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?
A single sentence conveys the purpose and the side-effect file path efficiently. Zero waste, though it could slightly expand on behavioral implications without becoming verbose.
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?
This is a stateful side-effecting tool (writes config, opens browser) with no annotations and no output schema, which raises the completeness bar. The description covers the mechanism and file destination but omits return value expectations, whether the flow is interactive or automated, and how the agent verifies successful login. For such a consequential action, slightly more detail is warranted.
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% for the single 'force' parameter, which has a clear schema description ('Re-run browser login when the current credential comes from the local config file'). The description's mention of saving to config.json complements the force parameter's meaning but doesn't add much beyond what the 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?
The description clearly states the verb (Authenticate), resource (RunAPI), and mechanism (browser PKCE login flow), and notes it saves the API key to a config file path. It clearly distinguishes from sibling tools (edit_image, remix_image, etc.) which are all image-related operations, so no confusion about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when this is needed (when authentication is required for RunAPI), but doesn't explicitly state when-not-to-use or alternatives. No mention of whether there's an existing credential or how an agent knows authentication is already complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It mentions that the tool returns a task id and is asynchronous by nature (implying task-based workflow), referencing polling via wait/poll params. However, it does not disclose rate limits, auth requirements, cost implications, or the asynchronous execution model explicitly. It adds modest context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that packs the core purpose (create task, API provider, operation) and the return signature without any waste. Front-loaded with the primary action verb. Every word 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?
Given no output schema and 2 undocumented params, the description could do marginally more to explain the task lifecycle and how the returned task id relates to get_task. However, with 10 parameters at 80% schema coverage, the schema does most of the documentational work, and the description correctly anchors the async task model. The sibling get_task exists to fill the task-tracking gap.
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?
Schema coverage is 80% with 10 parameters, so most parameters are already documented in the schema. The description's mention of return values (task id, status, output URLs) complements the undocumented params like wait, timeout_ms, and poll_interval_ms by situating them in a task lifecycle. For 2 undocumented params (timeout_ms, poll_interval_ms), the description's task-frame reference provides useful context. The description doesn't need to repeat schema details.
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 states a specific verb ('Create'), resource ('a Qwen Image task on RunAPI'), and operation ('remix image'), clearly distinguishing it as the remix variant among siblings like text_to_image and edit_image. It also notes the return signature (task id, status, output URLs). It could be slightly stronger by explaining the distinction from edit_image explicitly, but the purpose is clear.
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 remix operation (requires source_image_url, mentions 'remix image' in the name), but does not explicitly state when to use this vs edit_image or text_to_image. It does not describe when not to use it or any prerequisites (like needing a public HTTPS URL — though that is in the schema). No explicit alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![qwen-image-mcp MCP server](https://glama.ai/mcp/servers/runapi-ai/qwen-image-mcp/badges/card.svg)](https://glama.ai/mcp/servers/runapi-ai/qwen-image-mcp)

Score Badge

Copy to your README.md:

[![qwen-image-mcp MCP server](https://glama.ai/mcp/servers/runapi-ai/qwen-image-mcp/badges/score.svg)](https://glama.ai/mcp/servers/runapi-ai/qwen-image-mcp)

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/runapi-ai/qwen-image-mcp'

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