What can you do with this server?

The Replicate Flux MCP server enables AI assistants to generate high-quality images and vector graphics using advanced AI models via the Model Context Protocol. * Generate Images: Create single or multiple images from text prompts using Flux Schnell model * Create Image Variants: Produce multiple interpretations of a single prompt * Generate SVG Graphics: Create vector images using Recraft V3 SVG model * Customize Generation: Control parameters including seed, aspect ratio, resolution, quality, style, and inference steps * Manage Predictions: Retrieve details of specific predictions and browse history * Batch Processing: Generate multiple images or variants in a single request * Integration: Works with MCP clients like Cursor, Claude Desktop, Smithery, and Glama.ai

Which integrations are available for this server?

Enables image generation using Replicate's API with the Black Forest Labs' Flux Schnell model, allowing customization of aspect ratio, quality, and other parameters

How do I use replicate-flux-mcp?

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., "@replicate-flux-mcp generate a serene mountain landscape at sunset" 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.

de en es ja ko ru zh

replicate-flux-mcp

by awkoy

Overview Schema Related Servers Score Discussions(1)

TypeScript

Remote

Replicate Flux MCP

English | 中文

MCP Compatible License TypeScript Model Context Protocol

Trust Score NPM Downloads Stars

Replicate Flux MCP is an advanced Model Context Protocol (MCP) server that empowers AI assistants to generate high-quality images and vector graphics. By default it uses black-forest-labs/flux-schnell for raster images and recraft-ai/recraft-v3-svg for SVG output. You can override the curated image/SVG models through environment variables, and image tools also accept a per-call model_id override from the built-in allowlist.

📑 Table of Contents

Related MCP server: Flux Image MCP Server

🚀 Getting Started & Integration

Setup Process

Obtain a Replicate API Token
- Sign up at Replicate
- Create an API token in your account settings
Choose Your Integration Method
- Follow one of the integration options below based on your preferred MCP client
Ask Your AI Assistant to Generate an Image
- Simply ask naturally: "Can you generate an image of a serene mountain landscape at sunset?"
- Or be more specific: "Please create an image showing a peaceful mountain scene with a lake reflecting the sunset colors in the foreground"
Explore Advanced Features
- Try different parameter settings for customized results
- Experiment with SVG generation using generate_svg
- Use batch image generation or variant generation features

Cursor Integration

Method 1: Using mcp.json

Create or edit the .cursor/mcp.json file in your project directory:

{
  "mcpServers": {
    "replicate-flux-mcp": {
      "command": "env REPLICATE_API_TOKEN=YOUR_TOKEN npx",
      "args": ["-y", "replicate-flux-mcp"]
    }
  }
}

Replace YOUR_TOKEN with your actual Replicate API token
Restart Cursor to apply the changes

Method 2: Manual Mode

Open Cursor and go to Settings
Navigate to the "MCP" or "Model Context Protocol" section
Click "Add Server" or equivalent
Enter the following command in the appropriate field:

env REPLICATE_API_TOKEN=YOUR_TOKEN npx -y replicate-flux-mcp

Replace YOUR_TOKEN with your actual Replicate API token
Save the settings and restart Cursor if necessary

Claude Desktop Integration

Create or edit the mcp.json file in your configuration directory:

{
  "mcpServers": {
    "replicate-flux-mcp": {
      "command": "npx",
      "args": ["-y", "replicate-flux-mcp"],
      "env": {
        "REPLICATE_API_TOKEN": "YOUR TOKEN"
      }
    }
  }
}

Replace YOUR_TOKEN with your actual Replicate API token
Restart Claude Desktop to apply the changes

Smithery Integration

This MCP server is available as a hosted service on Smithery, allowing you to use it without setting up your own server.

Visit Smithery and create an account if you don't have one
Navigate to the Replicate Flux MCP server page
Click "Add to Workspace" to add the server to your Smithery workspace
Configure your MCP client (Cursor, Claude Desktop, etc.) to use your Smithery workspace URL

For more information on using Smithery with your MCP clients, visit the Smithery documentation.

Glama.ai Integration

This MCP server is also available as a hosted service on Glama.ai, providing another option to use it without local setup.

Visit Glama.ai and create an account if you don't have one
Go to the Replicate Flux MCP server page
Click "Install Server" to add the server to your workspace
Configure your MCP client to use your Glama.ai workspace

For more information, visit the Glama.ai MCP servers documentation.

Codex Integration

Add the server to ~/.codex/config.toml:

[mcp_servers.replicate]
command = "npx"
args = ["-y", "replicate-flux-mcp"]
env = { REPLICATE_API_TOKEN = "your-replicate-api-token", REPLICATE_IMAGE_MODEL_ID = "your-image-model-id", REPLICATE_SVG_MODEL_ID = "your-svg-model-id" }
startup_timeout_sec = 30_000

Replace the env values as needed. If you omit REPLICATE_IMAGE_MODEL_ID / REPLICATE_SVG_MODEL_ID, the server uses black-forest-labs/flux-schnell for images and recraft-ai/recraft-v3-svg for SVGs.

Curated tools validate model overrides against built-in allowlists:

Image generation: black-forest-labs/flux-schnell, google/imagen-4, black-forest-labs/flux-kontext-pro, ideogram-ai/ideogram-v3-turbo, black-forest-labs/flux-1.1-pro, black-forest-labs/flux-dev
SVG generation: recraft-ai/recraft-v3-svg
Legacy run_model extras: minimax/video-01, luma/reframe-video, topazlabs/video-upscale, topazlabs/image-upscale, szcho/codeformer, tencentarc/gfpgan

🌟 Features

🖼️ High-Quality Image Generation — Flux Schnell raster images by default, with environment-variable and per-tool image model overrides.
🎨 Vector Graphics — Recraft V3 SVG for logos, icons, and diagrams.
📊 Batch + Variants — Generate N images from N prompts or N variants of one prompt (seed-based or prompt-modifier-based).
🧩 Arbitrary Replicate Models — run_replicate_model escape hatch accepts any owner/name[:version] reference, with get_model_schema introspection for the OpenAPI input schema. Optional allowlist via REPLICATE_MODEL_ALLOWLIST.
📦 Structured Output — Every generate_* tool returns machine-readable structuredContent alongside human-readable content, matching a per-tool outputSchema (URL, prompt, format, aspect ratio, per-variant seed, etc).
⏳ Progress Notifications — Batch and variant generation emit notifications/progress for clients that opt in via progressToken, so long runs aren't black-boxed.
💬 Curated Prompts — 5 ready-made prompt templates (logo, portrait, svg-icon, product-shot, isometric-diagram) surfaced in Claude Desktop's slash palette and Cursor's @-menu.
🏷️ Proper Tool Annotations — readOnlyHint / destructiveHint / openWorldHint / idempotentHint set correctly so clients can reason about safety and cost.
🪵 Structured Logging — Server-side errors travel over notifications/message instead of stderr.
🔌 Universal MCP Compatibility — MCP protocol 2025-11-25; works with Claude Desktop, Cursor, Cline, Zed, and any spec-compliant client.
🔍 Generation History — Browse past runs through imagelist, svglist, and predictionlist resources.

📚 Documentation

Available Tools

`generate_image`

Generates an image based on a text prompt using the configured image model (allowlist only).

{
  prompt: string;                // Required: Text description of the image to generate
  model_id?: string;             // Optional: Override image model (allowlist only)
  seed?: number;                 // Optional: Random seed for reproducible generation
  go_fast?: boolean;             // Optional: Run faster predictions with optimized model (default: true)
  megapixels?: "1" | "0.25";     // Optional: Image resolution (default: "1")
  num_outputs?: number;          // Optional: Number of images to generate (1-4) (default: 1)
  aspect_ratio?: string;         // Optional: Aspect ratio (e.g., "16:9", "4:3") (default: "1:1")
  output_format?: string;        // Optional: Output format ("webp", "jpg", "png") (default: "webp")
  output_quality?: number;       // Optional: Image quality (0-100) (default: 80)
  num_inference_steps?: number;  // Optional: Number of denoising steps (1-4) (default: 4)
  disable_safety_checker?: boolean; // Optional: Disable safety filter (default: false)
  support_image_mcp_response_type?: boolean; // Optional: Return embedded image content when supported (default: true)
}

`generate_multiple_images`

Generates multiple images based on an array of prompts using the configured image model (allowlist only).

{
  prompts: string[];             // Required: Array of text descriptions for images to generate (1-10 prompts)
  model_id?: string;             // Optional: Override image model (allowlist only)
  seed?: number;                 // Optional: Random seed for reproducible generation
  go_fast?: boolean;             // Optional: Run faster predictions with optimized model (default: true)
  megapixels?: "1" | "0.25";     // Optional: Image resolution (default: "1")
  aspect_ratio?: string;         // Optional: Aspect ratio (e.g., "16:9", "4:3") (default: "1:1")
  output_format?: string;        // Optional: Output format ("webp", "jpg", "png") (default: "webp")
  output_quality?: number;       // Optional: Image quality (0-100) (default: 80)
  num_inference_steps?: number;  // Optional: Number of denoising steps (1-4) (default: 4)
  disable_safety_checker?: boolean; // Optional: Disable safety filter (default: false)
  support_image_mcp_response_type?: boolean; // Optional: Return embedded image content when supported (default: true)
}

`generate_image_variants`

Generates multiple variants of the same image from a single prompt using the configured image model (allowlist only).

{
  prompt: string;                // Required: Text description for the image to generate variants of
  model_id?: string;             // Optional: Override image model (allowlist only)
  num_variants: number;          // Required: Number of image variants to generate (2-10, default: 4)
  prompt_variations?: string[];  // Optional: List of prompt modifiers to apply to variants (e.g., ["in watercolor style", "in oil painting style"])
  variation_mode?: "append" | "replace"; // Optional: How to apply variations - 'append' adds to base prompt, 'replace' uses variations directly (default: "append")
  seed?: number;                 // Optional: Base random seed. Each variant will use seed+variant_index
  go_fast?: boolean;             // Optional: Run faster predictions with optimized model (default: true)
  megapixels?: "1" | "0.25";     // Optional: Image resolution (default: "1")
  aspect_ratio?: string;         // Optional: Aspect ratio (e.g., "16:9", "4:3") (default: "1:1")
  output_format?: string;        // Optional: Output format ("webp", "jpg", "png") (default: "webp")
  output_quality?: number;       // Optional: Image quality (0-100) (default: 80)
  num_inference_steps?: number;  // Optional: Number of denoising steps (1-4) (default: 4)
  disable_safety_checker?: boolean; // Optional: Disable safety filter (default: false)
  support_image_mcp_response_type?: boolean; // Optional: Return embedded image content when supported (default: true)
}

`generate_svg`

Generates SVG/vector output based on a text prompt using the configured SVG model (allowlist only).

{
  prompt: string;                // Required: Text description of the SVG to generate
  size?: string;                 // Optional: Size of the generated SVG (default: "1024x1024")
  style?: string;                // Optional: Style of the generated image (default: "any")
                                // Options: "any", "engraving", "line_art", "line_circuit", "linocut"
}

`prediction_list`

Retrieves a list of your recent predictions from Replicate.

{
  limit?: number;  // Optional: Maximum number of predictions to return (1-100) (default: 50)
}

`get_prediction`

Gets detailed information about a specific prediction.

{
  predictionId: string;  // Required: ID of the prediction to retrieve
}

`run_model`

Runs a whitelisted Replicate model with a raw input payload (useful for video or restoration models).

{
  model_id: string;                // Required: Replicate model id (allowlist only)
  input?: Record<string, unknown>; // Optional: Raw input payload for the model
}

`run_replicate_model`

Runs any model hosted on Replicate by its owner/name[:version] reference. Use this as an escape hatch when none of the curated tools fit. Call get_model_schema first if you don't know the input shape.

{
  model: string;                              // Required: 'owner/name' or 'owner/name:version'
  input: Record<string, unknown>;             // Required: Model input parameters
  prefer_wait?: number;                       // Optional: Seconds to block waiting for sync output (1-60, default 60)
  return_as?: "url" | "base64" | "both";      // Optional: How to return file outputs (default "url")
}

Set the REPLICATE_MODEL_ALLOWLIST env var (comma-separated owner/name entries) to restrict which models can be invoked. Unset = any model allowed. Set-but-empty = deny all (the server fails closed rather than silently allowing everything).

`get_model_schema`

Fetches the OpenAPI input schema and description for a Replicate model so you can pass the right parameters to run_replicate_model.

{
  model: string;  // Required: Replicate model reference in 'owner/name' form
}

Available Resources

`imagelist`

Browse your history of generated images created with the configured image model.

`svglist`

Browse your history of generated SVG outputs created with the configured SVG model.

`predictionlist`

Browse all your Replicate predictions history.

Available Prompts

Curated templates surfaced in Claude Desktop's slash menu and Cursor's @-palette. Each one fills in sensible defaults then delegates to the relevant generation tool.

Prompt	Description	Arguments
`logo`	Brand/product logo	`brand`, `style?`, `palette?`
`portrait`	Photoreal portrait	`subject`, `mood?`, `lens?`
`svg-icon`	Single-concept vector icon	`concept`, `style?`
`product-shot`	Studio product photography	`product`, `surface?`
`isometric-diagram`	Isometric technical illustration	`subject`, `emphasis?`

Structured Output

Every generate_* tool returns both human-readable content (text + image blocks) and machine-readable structuredContent that matches the tool's outputSchema.

Tool	`structuredContent` shape
`generate_image`	`{ url, prompt, format, aspect_ratio, seed? }`
`generate_svg`	`{ url, prompt, size, style, svg? }`
`generate_multiple_images`	`{ images: [{ url, prompt }], format, aspect_ratio }`
`generate_image_variants`	`{ base_prompt, variation_mode, variants: [{ variant_index, url, prompt_used, seed? }], format, aspect_ratio }`

Clients that understand MCP structured output can consume URLs and metadata directly without parsing prose.

Environment Variables

Variable	Required	Purpose
`REPLICATE_API_TOKEN`	yes	API token for Replicate. The server exits immediately if it's missing.
`REPLICATE_IMAGE_MODEL_ID`	no	Overrides the default curated image model used by `generate_image`, `generate_multiple_images`, `generate_image_variants`, and `create_prediction`. The value must be in the built-in image allowlist.
`REPLICATE_SVG_MODEL_ID`	no	Overrides the default SVG model used by `generate_svg`. The value must be in the built-in SVG allowlist.
`REPLICATE_MODEL_ALLOWLIST`	no	Comma-separated `owner/name` entries that gate `run_replicate_model`. Unset = any model allowed. Set-but-empty = deny all (fail-closed). Evaluated once at process start, so set it in your MCP client's `env` block (not via a dotenv loaded later).

💻 Development

Clone the repository:

git clone https://github.com/awkoy/replicate-flux-mcp.git
cd replicate-flux-mcp

Install dependencies:

npm install

Start the TypeScript watcher:

npm run watch

Build the project:

npm run build

Smoke-test the server with the MCP Inspector:

npm run inspector

Connect to Client:

{
  "mcpServers": {
    "image-generation-mcp": {
      "command": "npx",
      "args": [
        "/Users/{USERNAME}/{PATH_TO}/replicate-flux-mcp/build/index.js"
      ],
      "env": {
        "REPLICATE_API_TOKEN": "YOUR REPLICATE API TOKEN"
      }
    }
  }
}

Testing

This project currently has no automated test suite. Verification is done via:

npm run build — TypeScript type-checking catches most regressions.
npm run inspector — drives the built binary through the official MCP Inspector for end-to-end smoke testing of tools, resources, and prompts.

Contributions adding a proper test framework (e.g. Vitest + an MCP stdio client harness) are welcome.

⚙️ Technical Details

Stack

Model Context Protocol SDK - Core MCP functionality for tool and resource management
Replicate API - Provides access to state-of-the-art AI image generation models
TypeScript - Ensures type safety and leverages modern JavaScript features
Zod - Implements runtime type validation for robust API interactions

Configuration

The server can be configured by modifying the CONFIG object in src/config/index.ts or by setting the REPLICATE_IMAGE_MODEL_ID / REPLICATE_SVG_MODEL_ID environment variables to override the defaults:

export const CONFIG = {
  serverName: "replicate-flux-mcp",
  serverVersion: "0.4.0",
  imageModelId: process.env.REPLICATE_IMAGE_MODEL_ID ?? "black-forest-labs/flux-schnell",
  svgModelId: process.env.REPLICATE_SVG_MODEL_ID ?? "recraft-ai/recraft-v3-svg",
  pollingAttempts: 25,
  pollingInterval: 2000, // ms
  modelAllowlistConfigured: process.env.REPLICATE_MODEL_ALLOWLIST !== undefined,
  modelAllowlist: (process.env.REPLICATE_MODEL_ALLOWLIST ?? "")
    .split(",")
    .map((s) => s.trim())
    .filter(Boolean),
};

Switching models (no code changes)

Use env vars when launching the server (works with npx, Cursor, Claude Desktop, etc.). Curated image/SVG tool overrides must be in the built-in allowlists:

# Stay on defaults:
REPLICATE_API_TOKEN=YOUR_TOKEN npx -y replicate-flux-mcp

# Switch to other allowlisted models
REPLICATE_IMAGE_MODEL_ID="google/imagen-4" \
REPLICATE_SVG_MODEL_ID="recraft-ai/recraft-v3-svg" \
REPLICATE_API_TOKEN=YOUR_TOKEN \
npx -y replicate-flux-mcp

modelAllowlist is evaluated once at process start from REPLICATE_MODEL_ALLOWLIST. Restart the server after changing it.

🔍 Troubleshooting

Common Issues

Authentication Error

Ensure your REPLICATE_API_TOKEN is correctly set in the environment
Verify your token is valid by testing it with the Replicate API directly

Safety Filter Triggered

The model has a built-in safety filter that may block certain prompts
Try modifying your prompt to avoid potentially problematic content

Timeout Error

For larger images or busy servers, you might need to increase pollingAttempts or pollingInterval in the configuration
Default settings should work for most use cases

🤝 Contributing

Contributions are welcome! Please follow these steps to contribute:

Fork the repository
Create your feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add some amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

For feature requests or bug reports, please create a GitHub issue. If you like this project, consider starring the repository!

📄 License

This project is licensed under the MIT License - see the LICENSE file for details.

🔗 Resources

🎨 Examples

Demo

Multiple Prompts	Prompt Variants

Here are some examples of how to use the tools:

Batch Image Generation with `generate_multiple_images`

Create multiple distinct images at once with different prompts:

{
  "prompts": [
    "A red sports car on a mountain road", 
    "A blue sports car on a beach", 
    "A vintage sports car in a city street"
  ]
}

Image Variants with `generate_image_variants`

Create different interpretations of the same concept using seeds:

{
  "prompt": "A futuristic city skyline at night",
  "num_variants": 4,
  "seed": 42
}

Or explore style variations with prompt modifiers:

{
  "prompt": "A character portrait",
  "prompt_variations": [
    "in anime style", 
    "in watercolor style", 
    "in oil painting style", 
    "as a 3D render"
  ]
}

Made with ❤️ by Yaroslav Boiko

Available Tools

7 tools

create_predictionC

Generate an prediction from a text prompt using Flux Schnell model

ParametersJSON Schema

Name	Required	Description	Default
`aspect_ratio`	No	Aspect ratio for the generated image	1:1
`disable_safety_checker`	No	Disable safety checker for generated images.
`go_fast`	No	Run faster predictions with model optimized for speed (currently fp8 quantized); disable to run in original bf16
`megapixels`	No	Approximate number of megapixels for generated image	1
`num_inference_steps`	No	Number of denoising steps. 4 is recommended, and lower number of steps produce lower quality outputs, faster.
`num_outputs`	No	Number of outputs to generate
`output_format`	No	Format of the output images	webp
`output_quality`	No	Quality when saving the output images, from 0 to 100. 100 is best quality, 0 is lowest quality. Not relevant for .png outputs
`prompt`	Yes	Prompt for generated image
`seed`	No	Random seed. Set for reproducible generation

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the model ('Flux Schnell') but doesn't describe what 'prediction' means in this context (likely image generation), expected outputs, rate limits, authentication needs, or potential costs. For a tool with 10 parameters and no annotations, this is a significant gap.

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: 'Generate an prediction from a text prompt using Flux Schnell model.' It's front-loaded with the core purpose and has zero wasted words. The minor grammatical error ('an prediction') doesn't impact clarity.

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 (10 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain what a 'prediction' is in this context (likely an image), the output format (though hinted by parameters like 'output_format'), or behavioral aspects like generation time or error handling. For an image generation tool with many parameters, more context is needed.

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 description coverage is 100%, so all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions 'text prompt' which aligns with the 'prompt' parameter, but this is already covered. Baseline 3 is appropriate when the schema does the heavy lifting.

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's purpose: 'Generate an prediction from a text prompt using Flux Schnell model.' It specifies the verb ('Generate'), resource ('prediction'), and model ('Flux Schnell'), but doesn't explicitly differentiate from sibling tools like 'generate_image' or 'get_prediction'. The description is clear but lacks sibling 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 'generate_image' or 'generate_image_variants'. It doesn't mention prerequisites, constraints, or comparative use cases. The agent must infer usage from the tool name and parameters alone.

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

generate_imageC

Generate an image from a text prompt using Flux Schnell model

ParametersJSON Schema

Name	Required	Description	Default
`aspect_ratio`	No	Aspect ratio for the generated image	1:1
`disable_safety_checker`	No	Disable safety checker for generated images.
`go_fast`	No	Run faster predictions with model optimized for speed (currently fp8 quantized); disable to run in original bf16
`megapixels`	No	Approximate number of megapixels for generated image	1
`num_inference_steps`	No	Number of denoising steps. 4 is recommended, and lower number of steps produce lower quality outputs, faster.
`num_outputs`	No	Number of outputs to generate
`output_format`	No	Format of the output images	webp
`output_quality`	No	Quality when saving the output images, from 0 to 100. 100 is best quality, 0 is lowest quality. Not relevant for .png outputs
`prompt`	Yes	Prompt for generated image
`seed`	No	Random seed. Set for reproducible generation
`support_image_mcp_response_type`	No	Disable if the image type is not supported in the response, if it's Cursor app for example

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the model ('Flux Schnell') but doesn't describe rate limits, authentication needs, cost implications, or what happens when generation fails. For a complex image generation tool with 11 parameters, 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, efficient sentence that states the core functionality without unnecessary elaboration. Every word earns its place, and the information is front-loaded with the essential action and method.

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?

For a complex image generation tool with 11 parameters and no annotations or output schema, the description is inadequate. It doesn't explain what the output looks like (e.g., image URLs, binary data), error conditions, or practical limitations. The agent lacks sufficient context to use this tool effectively beyond basic invocation.

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 description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description doesn't add any parameter-specific context beyond what's in the schema, such as guidance on prompt engineering or trade-offs between parameters. Baseline 3 is appropriate when schema does the heavy lifting.

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 ('generate') and resource ('image') with the specific method ('from a text prompt using Flux Schnell model'). It distinguishes from siblings like 'generate_svg' by specifying image generation, but doesn't explicitly differentiate from 'generate_image_variants' or 'generate_multiple_images' which are closely related.

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 'generate_image_variants' or 'generate_multiple_images'. There's no mention of prerequisites, constraints, or comparative use cases with sibling tools, leaving the agent to infer usage context.

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

generate_image_variantsC

Generate multiple variants of the same image from a single prompt

ParametersJSON Schema

Name	Required	Description	Default
`aspect_ratio`	No	Aspect ratio for the generated image	1:1
`disable_safety_checker`	No	Disable safety checker for generated images.
`go_fast`	No	Run faster predictions with model optimized for speed (currently fp8 quantized); disable to run in original bf16
`megapixels`	No	Approximate number of megapixels for generated image	1
`num_inference_steps`	No	Number of denoising steps. 4 is recommended, and lower number of steps produce lower quality outputs, faster.
`num_variants`	No	Number of image variants to generate (2-10)
`output_format`	No	Format of the output images	webp
`output_quality`	No	Quality when saving the output images, from 0 to 100. 100 is best quality, 0 is lowest quality. Not relevant for .png outputs
`prompt`	Yes	Text description for the image to generate variants of
`prompt_variations`	No	Optional list of prompt modifiers to apply to variants (e.g., ['in watercolor style', 'in oil painting style']). If provided, these will be used instead of random seeds.
`seed`	No	Base random seed. Each variant will use seed+variant_index for reproducibility
`support_image_mcp_response_type`	No	Support image MCP response type on client side
`variation_mode`	No	How to apply prompt variations: 'append' adds to the base prompt, 'replace' uses variations as standalone prompts	append

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core action (generating image variants) but lacks critical behavioral details: it doesn't mention whether this is a read-only or mutating operation, what permissions might be required, rate limits, cost implications, or what the output looks like (e.g., file format, size, or how variants are returned). For a complex tool with 13 parameters, this is a significant gap.

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 directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, with every word earning its place. No structural issues or unnecessary elaboration are present.

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's complexity (13 parameters, no annotations, no output schema), the description is incomplete. It adequately states what the tool does but fails to address behavioral aspects (e.g., whether it's a costly operation, what the output contains), usage guidelines relative to siblings, or any higher-level context. For a generative AI tool with many configuration options, more guidance would be helpful.

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 description coverage is 100%, meaning all parameters are well-documented in the schema itself. The description adds no additional parameter information beyond what's in the schema (e.g., it doesn't explain parameter interactions or provide usage examples). According to the rules, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.

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's purpose: 'Generate multiple variants of the same image from a single prompt.' It specifies the verb ('generate'), resource ('image variants'), and scope ('multiple variants from a single prompt'). However, it doesn't explicitly distinguish this from sibling tools like 'generate_image' or 'generate_multiple_images', which likely have different functionality.

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. There are several sibling tools (e.g., 'generate_image', 'generate_multiple_images') that appear related, but the description doesn't explain how this tool differs from them or when it's the appropriate choice. No usage context, prerequisites, or exclusions are mentioned.

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

generate_multiple_imagesC

Generate multiple images from an array of prompts using Flux Schnell model

ParametersJSON Schema

Name	Required	Description	Default
`aspect_ratio`	No	Aspect ratio for the generated image	1:1
`disable_safety_checker`	No	Disable safety checker for generated images.
`go_fast`	No	Run faster predictions with model optimized for speed (currently fp8 quantized); disable to run in original bf16
`megapixels`	No	Approximate number of megapixels for generated image	1
`num_inference_steps`	No	Number of denoising steps. 4 is recommended, and lower number of steps produce lower quality outputs, faster.
`output_format`	No	Format of the output images	webp
`output_quality`	No	Quality when saving the output images, from 0 to 100. 100 is best quality, 0 is lowest quality. Not relevant for .png outputs
`prompts`	Yes	Array of text descriptions for the images to generate
`seed`	No	Random seed. Set for reproducible generation
`support_image_mcp_response_type`	No	Disable if the image type is not supported in the response, if it's Cursor app for example

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions the model ('Flux Schnell') but doesn't disclose performance characteristics (e.g., speed, cost), error handling, rate limits, or what happens when prompts fail. For a generative AI tool with 10 parameters, this leaves significant gaps in understanding its operational behavior.

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 front-loads the core functionality. Every word earns its place, with no redundant or vague phrasing. It's appropriately sized for the tool's complexity.

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?

For a complex image generation tool with 10 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns (e.g., image URLs, metadata), error conditions, or practical limitations. The absence of output schema means the description should compensate by describing outputs, but it doesn't.

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 all parameters are documented in the schema. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain how 'prompts' array relates to output, or provide context for parameter interactions. Baseline 3 is appropriate when schema does the heavy lifting.

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 ('Generate multiple images') and the resource ('from an array of prompts'), specifying the model used ('Flux Schnell model'). It distinguishes from sibling 'generate_image' by indicating multiple images from multiple prompts, but doesn't explicitly contrast with other siblings like 'generate_image_variants' or 'generate_svg'.

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 'generate_image' (single image) or 'generate_image_variants' (variations of one image). There's no mention of prerequisites, constraints, or typical use cases beyond the basic functionality.

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

generate_svgC

Generate an SVG from a text prompt using Recraft model

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	Yes	Prompt for generated SVG
`size`	No	Size of the generated SVG	1024x1024
`style`	No	Style of the generated image.	any

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't mention rate limits, authentication requirements, whether it's a read-only or mutation operation, what happens on failure, or what the output format looks like. For a generative tool with zero annotation coverage, 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, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a straightforward generation tool and front-loads the essential information.

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?

For a generative tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (SVG data, URL, file path?), error conditions, rate limits, or authentication requirements. The schema handles parameters well, but the overall context for proper tool invocation is incomplete.

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 the schema already documents all three parameters thoroughly with descriptions, enums, and defaults. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.

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 'generate' and resource 'SVG', specifying it uses the Recraft model from a text prompt. It distinguishes from sibling tools like 'generate_image' by specifying SVG format rather than general images. However, it doesn't explicitly differentiate from other SVG-related tools (none exist among siblings), so it's not a perfect 5.

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 'generate_image' or 'generate_multiple_images'. It doesn't mention use cases, prerequisites, or exclusions. The only contextual clue is 'using Recraft model', which doesn't help with sibling tool selection.

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

get_predictionC

Get details of a specific prediction by ID

ParametersJSON Schema

Name	Required	Description	Default
`predictionId`	Yes	ID of the prediction to retrieve

TDQS

C2.9/5.0

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 retrieves details but doesn't describe what 'details' include (e.g., status, output, metadata), whether it's a read-only operation, error handling, or performance characteristics. This leaves significant gaps for an agent to understand the tool's behavior.

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 with zero waste. It's front-loaded with the core purpose and uses clear language. Every word earns its place, making it easy for an agent to parse quickly.

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's complexity (retrieving a specific resource) and lack of annotations and output schema, the description is incomplete. It doesn't explain what 'details' are returned, error conditions, or how this fits into broader workflows with siblings. For a tool with no structured output information, more context is needed.

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 description coverage is 100%, with the parameter 'predictionId' clearly documented in the schema. The description adds minimal value beyond the schema by implying the parameter is required ('by ID') but doesn't provide additional context like format examples or constraints. Baseline 3 is appropriate since the schema does the heavy lifting.

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's purpose with a specific verb ('Get') and resource ('prediction'), and identifies the key input ('by ID'). It distinguishes from siblings like 'prediction_list' (which retrieves multiple predictions) by focusing on a single prediction. However, it doesn't specify what 'details' include, leaving some ambiguity.

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. It doesn't mention when to choose 'get_prediction' over 'prediction_list' (for listing multiple predictions) or other siblings like 'create_prediction'. There's no context about prerequisites, such as needing an existing prediction ID.

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

prediction_listC

Get a list of recent predictions from Replicate

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of predictions to return

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'recent predictions' but doesn't specify timeframes, ordering, pagination, authentication requirements, rate limits, or what constitutes 'recent'. This leaves significant gaps in understanding the tool's behavior.

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 directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand immediately.

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?

For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the returned predictions contain, their format, or how 'recent' is defined. Given the lack of structured data, more descriptive context is needed for the agent to use this tool effectively.

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 description coverage is 100%, with the single parameter 'limit' well-documented in the schema. The description doesn't add any parameter-specific information beyond what the schema already provides, so it meets the baseline for high schema coverage.

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 ('Get a list') and resource ('recent predictions from Replicate'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_prediction' which might retrieve a single prediction, leaving room for ambiguity.

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 'get_prediction' or 'create_prediction'. The description only states what it does, not when it's appropriate or what distinguishes it from similar tools.

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. Dates show when Glama detected each change.

7 tool updatesv1.0.0Mar 18, 2025
- First observedcreate_prediction
- First observedgenerate_image
- First observedgenerate_image_variants
- First observedgenerate_multiple_images
- First observedgenerate_svg
- First observedget_prediction
- First observedprediction_list

Install Server

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

TDQS

B3.2/5.0

Disambiguation3/5

The tools have some clear distinctions, such as between image generation and prediction management, but there is significant overlap and ambiguity among the image generation tools. For example, 'generate_image' and 'create_prediction' both seem to create images from prompts, and 'generate_image_variants' and 'generate_multiple_images' could be confused for handling multiple outputs in similar ways.

Naming Consistency4/5

The naming is mostly consistent with a verb_noun pattern, such as 'create_prediction' and 'generate_image', but there are minor deviations like 'prediction_list' (noun_verb) and inconsistent use of 'generate' vs. 'create'. Overall, the pattern is readable and predictable with only slight variations.

Tool Count5/5

With 7 tools, the count is well-scoped for an image generation server, covering core operations like creating, retrieving, and listing predictions, as well as various image generation methods. Each tool appears to serve a distinct purpose within this domain, making the set appropriately sized.

Completeness4/5

The tool set provides good coverage for image generation and prediction management, including creation, retrieval, and listing. However, there is a minor gap in update or delete operations for predictions or images, which might limit full lifecycle management but is not critical for basic usage.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Reddit Discussion

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-proOAuth
io.github.AceDataCloud
MCP server for Flux AI image generation
Image & Video Processing Multimedia Processing
23
FLUXOAuth
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
mcp-qwen-image
io.github.AceDataCloud
MCP server for Qwen Image 3 AI image generation
AI & Machine Learning Image & Video Processing
1
NinjaChat MCP
ai.ninjachat
Create images & video from any MCP agent — 17 models, spend limits, one URL.
Image & Video Processing AI & Machine Learning
1

Related MCP Servers

Image Generation MCP Server
Image & Video Processing App Automation
mikeyny
F
license
B
quality
D
maintenance
Enables users to generate images from text prompts using Replicate's model, with configurable parameters and full MCP protocol compliance.
Updated 2 years ago (2025-02-03 22:10 UTC)
1
123
-
Flux Image MCP Server
Image & Video Processing Multimedia Processing
ckz
A
license
Not graded
quality
D
maintenance
Provides image generation capabilities using the Flux Schnell model on Replicate, allowing users to create images from text prompts.
Updated 2 years ago (2025-03-02 06:39 UTC)
2
MIT
Flux Schnell MCP Server
Image & Video Processing Autonomous Agents
ckz
A
license
Not graded
quality
D
maintenance
A server that enables generating images through the Replicate API by calling the Flux Schnell model via the Model Context Protocol (MCP).
Updated a year ago (2025-03-10 19:24 UTC)
3
MIT
Replicate Designer MCP
Image & Video Processing Multimedia Processing
noeltg77
A
license
B
quality
D
maintenance
An MCP server that enables image generation using Replicate's Flux 1.1 Pro model. It provides a tool for creating visuals from text prompts with customizable settings for aspect ratio, output format, and quality.
Updated a year ago (2025-03-31 20:06 UTC)
1
MIT

Appeared in Searches

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

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

Replicate Flux MCP

📑 Table of Contents

🚀 Getting Started & Integration

Setup Process

Cursor Integration

Method 1: Using mcp.json

Method 2: Manual Mode

Claude Desktop Integration

Smithery Integration

Glama.ai Integration

Codex Integration

🌟 Features

📚 Documentation

Available Tools

generate_image

generate_multiple_images

generate_image_variants

generate_svg

prediction_list

get_prediction

run_model

run_replicate_model

get_model_schema

Available Resources

imagelist

svglist

predictionlist

Available Prompts

Structured Output

Environment Variables

💻 Development

Testing

⚙️ Technical Details

Stack

Configuration

Switching models (no code changes)

🔍 Troubleshooting

Common Issues

Authentication Error

Safety Filter Triggered

Timeout Error

🤝 Contributing

📄 License

🔗 Resources

🎨 Examples

Batch Image Generation with generate_multiple_images

Image Variants with generate_image_variants

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

`generate_image`

`generate_multiple_images`

`generate_image_variants`

`generate_svg`

`prediction_list`

`get_prediction`

`run_model`

`run_replicate_model`

`get_model_schema`

`imagelist`

`svglist`

`predictionlist`

Batch Image Generation with `generate_multiple_images`

Image Variants with `generate_image_variants`