Skip to main content
Glama
fdciabdul

MCP Image Generator

by fdciabdul
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Providers supported (image models only):

  • OpenRouter (default) — Gemini Flash Image, FLUX 2, Sourceful Riverflow, GPT-5 Image

  • Together AI — FLUX.1 Schnell/Dev/Pro, Stable Diffusion XL

  • Replicate — FLUX Schnell, FLUX 1.1 Pro, SDXL, Ideogram

  • fal.ai — FLUX Dev/Schnell/2 Pro, Recraft V3

Quick Start

No install needed — just use npx:

OPENROUTER_API_KEY="sk-or-v1-..." npx -y mcpimg

Related MCP server: jgkme/kilo-image-gen-mcp

Tools

generate_image

Generate an image from a text prompt.

Parameter

Type

Description

prompt

string (required)

Text description of the image

model

string

Model ID (e.g. google/gemini-2.5-flash-image)

provider

string

openrouter (default), together, replicate, fal

aspect_ratio

string

1:1, 16:9, 9:16, 4:3, 3:4, 3:2, 2:3

image_size

string

1K (default), 2K, 4K

negative_prompt

string

What to exclude (not all providers support this)

seed

number

Random seed for reproducibility

save_to

string

Custom file path to save the image

list_providers

List all configured providers and their available image models.

Parameter

Type

Description

provider

string

Filter by provider name

Setup for AI Agents / IDEs

Claude Code

claude mcp add --scope user --transport stdio image-gen \
  --env OPENROUTER_API_KEY=sk-or-v1-xxx \
  -- npx -y mcpimg

Or create .mcp.json in your project root:

{
  "mcpServers": {
    "image-gen": {
      "command": "npx",
      "args": ["-y", "mcpimg"],
      "env": {
        "OPENROUTER_API_KEY": "sk-or-v1-..."
      }
    }
  }
}

Cursor

Edit ~/.cursor/mcp.json:

{
  "mcpServers": {
    "image-gen": {
      "command": "npx",
      "args": ["-y", "mcpimg"],
      "env": {
        "OPENROUTER_API_KEY": "sk-or-v1-..."
      }
    }
  }
}

Claude Desktop

Edit the config file:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

  • Linux: ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "image-gen": {
      "command": "npx",
      "args": ["-y", "mcpimg"],
      "env": {
        "OPENROUTER_API_KEY": "sk-or-v1-..."
      }
    }
  }
}

OpenCode (by SST)

Edit ~/.config/opencode/opencode.json or opencode.json in project root:

{
  "mcp": {
    "image-gen": {
      "type": "local",
      "command": ["npx", "-y", "mcpimg"],
      "environment": {
        "OPENROUTER_API_KEY": "sk-or-v1-..."
      },
      "enabled": true,
      "timeout": 120000
    }
  }
}

Charm Crush

Add to crush.json in your project root:

{
  "mcp": {
    "image-gen": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "mcpimg"],
      "env": {
        "OPENROUTER_API_KEY": "sk-or-v1-..."
      }
    }
  }
}

Charm Mods

Edit mods.yml (mods --settings):

mcp-servers:
  image-gen:
    command: [npx]
    args:
      - -y
      - mcpimg
    env:
      - OPENROUTER_API_KEY=sk-or-v1-...

Any MCP-compatible agent

This server uses stdio transport (JSON-RPC over stdin/stdout). Any agent that supports MCP stdio can use it:

npx -y mcpimg

# Required environment variables (at least one)
OPENROUTER_API_KEY=...    # OpenRouter (default)
TOGETHER_API_KEY=...      # Together AI
REPLICATE_API_TOKEN=...   # Replicate
FAL_KEY=...               # fal.ai

Using Multiple Providers

Set multiple API keys to use different providers:

export OPENROUTER_API_KEY="sk-or-v1-..."
export TOGETHER_API_KEY="..."
export FAL_KEY="..."

Then specify the provider when generating:

generate_image(prompt="a cat", provider="together", model="black-forest-labs/FLUX.1-schnell")

Environment Variables

Variable

Provider

Required

OPENROUTER_API_KEY

OpenRouter

At least one

TOGETHER_API_KEY

Together AI

provider key

REPLICATE_API_TOKEN

Replicate

is required

FAL_KEY

fal.ai

IMAGE_OUTPUT_DIR

—

Optional. Default: ~/generated-images/

License

MIT

Available Tools

2 tools
generate_imageGenerate ImageC

Generate an image from a text prompt. Uses OpenRouter by default. Supports multiple providers: openrouter, together, replicate, fal.

ParametersJSON Schema
NameRequiredDescriptionDefault
seedNoRandom seed for reproducibility
modelNoModel ID (e.g. 'google/gemini-2.5-flash-image', 'black-forest-labs/flux-schnell')
promptYesText description of the image to generate
save_toNoCustom file path to save the image. Defaults to ~/generated-images/
providerNoProvider to use: openrouter (default), together, replicate, fal
image_sizeNoImage resolution: 1K (default), 2K, 4K
aspect_ratioNoAspect ratio: 1:1, 16:9, 9:16, 4:3, 3:4, 3:2, 2:3
negative_promptNoWhat to exclude from the image (not supported by all providers)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the default provider (OpenRouter) and that negative_prompt support varies by provider, but says nothing about API key/auth requirements, cost, generation latency, or side effects such as writing a file to disk.

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?

Two short, front-loaded sentences with no filler; the core action leads and provider info follows. The trailing provider list is slightly listy but not wasteful.

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 8 parameters, no annotations and no output schema, the description omits key operational context: what the call returns (path/URL), auth setup, cost, and failure modes for unsupported options. The provider string in the description partially covers schema territory rather than filling the real gaps.

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 8 parameters, including defaults and the provider list. The description largely repeats that structured information (default provider, provider names) without adding format or behavioral detail, so 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?

States a specific verb+resource (generate an image from a text prompt) and identifies the default provider and supported provider set. It is distinguishable from the sibling list_providers, though it does not explicitly mention that sibling.

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, nor when to pick a given provider (e.g. cost, quality, speed tradeoffs). The provider list is presented without any selection criteria, leaving the agent to guess.

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

list_providersList Image ProvidersB

List all configured image generation providers and their available models

ParametersJSON Schema
NameRequiredDescriptionDefault
providerNoFilter by provider name: openrouter, together, replicate, fal

TDQS

B3.4/5.0
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. It implies a read-only enumeration of current configuration ('configured providers', 'available models'), which is helpful, but it says nothing about authentication requirements, whether credentials or keys are exposed in the output, or how large the result can be.

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 front-loaded sentence with no filler; the resource and scope are stated immediately and nothing is wasted.

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, parameterized list tool with one fully documented optional parameter and no output schema, the description covers the essential purpose. The remaining gap is minor: it does not describe the shape of the returned provider/model list or indicate whether filtering is exact-match.

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% and the single optional 'provider' parameter already enumerates the accepted values (openrouter, together, replicate, fal) plus its filter semantics, so the description adds nothing beyond the schema. Baseline 3 applies 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 gives a specific verb and resource ('List all configured image generation providers and their available models'), and it is easy to tell apart from the sibling generate_image, which performs a mutation rather than discovery. It stops short of naming the sibling or contrasting behavior explicitly, so it is clear but not maximally differentiated.

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 statement of when to use this tool versus alternatives, nor any workflow context (e.g., 'use before generate_image to discover valid providers'). The optional provider filter is never mentioned in the description, so its usage is left entirely to the schema.

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.

  1. 2 tool updatesv1.0.2
    • First observedgenerate_image
    • First observedlist_providers
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored across 2 tools

Disambiguation5/5

The two tools are clearly distinct: list_providers is a read-only discovery call, while generate_image performs the actual generation action. An agent can trivially tell which one to invoke for a given need.

Naming Consistency5/5

Both tools follow a consistent verb_noun snake_case pattern (list_providers, generate_image), matching the conventions used in the descriptions' provider references. No stylistic deviations.

Tool Count3/5

Two tools is on the thin side for the stated scope: listing providers and generating images leaves no room for variations, edits, or batch operations. It is defensible for a narrow text-to-image wrapper but borderline per the rubric.

Completeness4/5

The core lifecycle of discovering providers and generating an image is covered, with sensible multi-provider support. Gaps like image editing/variations, batch generation, or generation status are absent but not fatal to the primary use case.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers