openrouter-image-gen-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENROUTER_API_KEY | Yes | Your OpenRouter API key for accessing image generation models. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| generate_imageA | Generate images using Google Gemini API. Control image style, aspect ratio, and composition through descriptive text in your prompt. |
| list_modelsB | Show information about the Gemini image generation model |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
generate_image and list_models serve clearly different purposes: one creates an image, the other retrieves model metadata. There is no overlap or ambiguity between the two tools.
Both tool names follow the same verb_noun pattern using snake_case, making the naming predictable and consistent across the set.
Two tools is on the thin side for an image generation server, but the pair covers the essential generation action and a supporting model lookup. It feels minimal yet not unreasonable.
The core image generation workflow is covered by generate_image, and list_models provides useful context for model selection. Minor gaps exist, such as no ability to inspect generation parameters or retrieve past generations, but these are not critical for a simple image generation API.