What can you do with this server?

The Flux MCP Server gives AI agents focused access to RunAPI's Flux image-generation models through a set of MCP tools. Here's what you can do: * login — Authenticate via a browser-based PKCE flow, saving the API key to ~/.config/runapi/config.json. Supports a force flag to re-run login. Auth also resolves from the RUNAPI_API_KEY env var for headless/CI use. * text_to_image — Create a Flux text-to-image task using flux-2-klein, flux-dev, or flux-pro. Configure wait, timeout_ms, poll_interval_ms, aspect_ratio, output_count, and callback_url. Returns task ID, status, and output URLs. * remix_image — Create a Flux remix-image task from a source image URL + prompt using flux-dev or flux-pro, with the same configurable options as text-to-image. * get_task — Fetch the current status and latest result payload for an existing task by providing the task ID and endpoint/action type. * check_pricing — Look up current pricing for any Flux model and endpoint — works without authentication. The server works with Claude Code, Codex, Cursor, Windsurf, VS Code, Roo Code, and any MCP-compatible host via stdio.

Which integrations are available for this server?

Provides tools for generating images via RunAPI's Flux model line, including text-to-image and remix image operations, task status polling, and pricing lookup.

How do I use Flux 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., "@Flux MCP Server Generate a photorealistic image of a cat in a spacesuit using flux-pro" 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.

Flux MCP Server

by runapi-ai

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Why This Package?

@runapi.ai/flux-mcp is a focused Model Context Protocol server for the Flux model line on RunAPI. It gives MCP-compatible assistants direct access to 2 endpoints and 3 model variants without loading the full RunAPI catalog.

Use this per-model server when an agent should stay scoped to Flux. Use @runapi.ai/mcp when one assistant should discover every RunAPI model line.

Related MCP server: NIMGEN

Install

Add it to Claude Code:

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

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

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

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

{
  "mcpServers": {
    "flux": {
      "command": "npx",
      "args": ["-y", "@runapi.ai/flux-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
`remix_image`	Yes	Create a Flux remix image task and optionally wait for a terminal status. Returns the task id, status, and output URLs.
`text_to_image`	Yes	Create a Flux 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 Flux model and endpoint.

Models

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

Tool	Models
`remix_image`	`flux-dev`, `flux-pro`
`text_to_image`	`flux-2-klein`, `flux-dev`, `flux-pro`

Model availability can change between releases. Use check_pricing or the Flux 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 Flux remix image task with RunAPI.

The assistant can call check_pricing, then remix_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 Flux pricing, then create the task if it matches my request.

The assistant calls check_pricing and can link to the Flux 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
Flux model page	https://runapi.ai/models/flux
npm package	@runapi.ai/flux-mcp
GitHub repository	runapi-ai/flux-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 flux 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.5/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 behavioral burden. It fails to disclose whether the tool is read-only, requires authentication, or has other traits, offering only a minimal 'look up' statement.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with no wasted words, making it highly concise and efficient.

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

Completeness3/5

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

With two optional parameters, no output schema, and no annotations, the description lacks details on defaults, return format, or how to interpret results, leaving some gaps despite adequate schema coverage.

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

Parameters3/5

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

Schema coverage is 100%, so parameters already have clear descriptions. The description adds 'for the flux model line' but does not significantly enhance parameter semantics beyond the schema defaults.

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

Purpose5/5

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

The description clearly states the verb 'look up', the resource 'pricing', and the scope 'flux model line', effectively distinguishing it from sibling tools like text_to_image or login.

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 use for pricing lookups but does not explicitly state when to use vs alternatives or provide exclusions. Sibling tools are different, but no direct guidance is given.

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

get_taskA

Fetch the current status and latest result payload for a flux 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

A3.8/5.0

Behavior3/5

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

No annotations provided. Description indicates a read operation ('Fetch') but does not disclose any side effects or behavioral traits beyond that. Minimal additional context.

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

Conciseness5/5

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

Single sentence, no wasted words. Front-loaded with the action and resource.

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 fetch tool with two parameters and no output schema, the description is adequate. It mentions both status and payload, covering the return value sufficiently.

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%, fully documenting the two parameters and their enums. 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.

Purpose5/5

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

Description clearly states the verb 'Fetch' and resource 'current status and latest result payload for a flux task'. It distinguishes from sibling tools that create tasks 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.

Usage Guidelines3/5

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

No explicit guidance on when to use this tool vs alternatives. It is implied that it should be used after task creation via text_to_image or remix_image, but no direct statement.

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.4/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses key behaviors: opening a browser, using PKCE flow, saving to a config file. It lacks details on whether it overwrites existing credentials or if it blocks, but is otherwise transparent for a login action.

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?

A single, well-structured sentence with no superfluous words. Every part adds value, front-loading the action and its result.

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

Completeness5/5

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

Given the tool's simplicity (one optional parameter, no output schema, no nested objects), the description is complete. It explains the core functionality and the parameter adequately.

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

Parameters5/5

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

The sole parameter 'force' is well-described in the schema, and the tool description adds context by explaining when it is used ('when the current credential comes from the local config file'). Schema coverage is 100%, and the description enriches understanding.

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

Purpose5/5

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

The description clearly states the verb 'Authenticate', the resource 'RunAPI', and the method 'PKCE login flow', specifying the output saved to a config file. It effectively distinguishes from sibling tools like text_to_image and get_task.

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 authentication before using other tools, but it does not provide explicit guidance on when to use it versus alternatives, nor does it mention prerequisites like browser availability or when a re-login is needed beyond the 'force' parameter.

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

remix_imageC

Create a Flux task on RunAPI (remix image). Returns a task id, status, and output URLs.

ParametersJSON Schema

Name	Required	Description
`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_count`	No
`poll_interval_ms`	No
`source_image_url`	Yes

TDQS

C2.9/5.0

Behavior3/5

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

The description discloses that the tool returns a task id, status, and output URLs, giving some insight into expected outputs. However, it does not explain the synchronous/asynchronous behavior, the effect of the wait parameter (default true), or any side effects such as image modification. With no annotations provided, 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.

Conciseness4/5

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

The description is a single sentence, efficiently stating the main purpose and return values. It is front-loaded with the action. However, some brevity is sacrificed at the expense of completeness, as key details are omitted.

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 the tool has 9 parameters, no output schema, and no annotations, the description is insufficiently complete. It lacks workflow context (e.g., pairing with get_task for async polling) and does not explain the purpose of most parameters. An 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.

Parameters2/5

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

The input schema has 9 parameters with only 22% description coverage. The tool description adds no parameter-level information beyond the high-level action. An agent cannot understand the meaning of parameters like prompt, source_image_url, or aspect_ratio from the description alone.

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 'Create a Flux task on RunAPI (remix image)', which clearly indicates the action and resource. However, it does not distinguish from the sibling 'text_to_image', which likely creates from text rather than remixing an existing image. The parenthetical 'remix image' helps but lacks explicit differentiation.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like text_to_image or get_task. There is no mention of prerequisites, when not to use, or recommended context, leaving the agent to infer from the tool name alone.

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 Flux task on RunAPI (text to image). Returns a task id, status, and output URLs.

ParametersJSON Schema

Name	Required	Description
`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_count`	No
`poll_interval_ms`	No

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states the basic action and return type. It does not disclose whether the tool blocks, requires authentication, is idempotent, or how the 'wait' parameter affects behavior. Agents must infer from parameter names.

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 conveying the core purpose and return value without any unnecessary words.

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 the complexity of 8 parameters and no output schema, the description is too brief. It omits the asynchronous workflow, polling behavior, output format details, and parameter constraints, leaving significant gaps for an agent.

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 25%, and the description adds no parameter details. The critical 'prompt' parameter is not explained, nor are 'model', 'aspect_ratio', or 'callback_url'. The single sentence does not compensate for the low schema 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 clearly states the verb 'Create', the resource 'Flux task', the platform 'RunAPI', and the modality 'text to image'. It also mentions the return value (task id, status, output URLs). This distinguishes it from sibling tools like get_task and remix_image.

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 is provided on when to use this tool versus alternatives like remix_image or get_task. There is no mention of prerequisites, when not to use, or context for polling versus async.

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

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct action: text-to-image creation, image remix, task retrieval, pricing lookup, and authentication. No overlap or ambiguity.

Naming Consistency4/5

Most tools follow a verb_noun pattern (text_to_image, get_task, check_pricing, remix_image), with 'login' as a single-word exception. The pattern is largely consistent.

Tool Count5/5

Five tools are appropriate for an image generation service, covering creation, status checking, pricing, and authentication without being excessive or insufficient.

Completeness4/5

Core operations (create, retrieve, pricing, auth) are covered. Missing potential features like task cancellation or listing are minor gaps for typical usage.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

mcp-flux-pro
io.github.AceDataCloud
MCP server for Flux AI image generation
Image & Video Processing Multimedia Processing
23
FLUX
io.github.black-forest-labs
Official FLUX MCP server. Generate, edit, vary, and browse images from Black Forest Labs.
Image & Video Processing AI & Machine Learning
2
Claude Imagine AOAuth
com.claudeimagine
Generate AI images and videos from any compatible MCP client.
AI & Machine Learning Image & Video Processing
42
Frenchie A
io.github.Lab94
OCR, transcription, file extraction, and image generation for AI agents via MCP.
AI & Machine Learning Image & Video Processing Speech Processing
72

Related MCP Servers

mcp-server-bfl
AI & Machine Learning Image & Video Processing
fernforestgames
A
license
Not graded
quality
F
maintenance
An MCP server that enables AI assistants to generate images using Black Forest Labs API and FLUX models, with automatic polling and image URL retrieval.
Updated 6 months ago (2026-02-24 10:11 UTC)
19
1
MIT
NIMGEN
Image & Video Processing AI & Machine Learning
gabriel-ferraresi
A
license
A
quality
B
maintenance
First MCP server for NVIDIA NIM FLUX. Generate and edit images using FLUX.1 models with your existing NVIDIA API key.
Updated 3 months ago (2026-06-18 03:16 UTC)
3
41
Apache 2.0
@runapi.ai/flux-kontext-mcp
AI & Machine Learning Image & Video Processing
runapi-ai
A
license
A
quality
A
maintenance
MCP server for the Flux Kontext model line that enables text-to-image generation, task status polling, and pricing lookup via RunAPI.
Updated a month ago (2026-07-31 10:13 UTC)
4
73
Apache 2.0
@runapi.ai/flux-2-mcpofficial
AI & Machine Learning Image & Video Processing
runapi-ai
A
license
A
quality
A
maintenance
RunAPI MCP server for the Flux 2 model line. Create tasks, poll their status, and check pricing through a single RunAPI API key.
Updated a month ago (2026-07-31 09:32 UTC)
5
70
Apache 2.0

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/flux-mcp'

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

Why This Package?

Install

Tools

Models

Agent Prompts

Create a task

Submit without waiting

Check pricing before creating

Configuration

Links

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

@runapi.ai/flux-2-mcpofficial

Latest Blog Posts

MCP directory API