What can you do with this server?

Pixara is an MCP server that gives LLMs direct access to OpenRouter's Image API for generating, editing, and exploring AI image models through 4 tools: * Generate images (pixara_generate_image): Create images from text prompts using any OpenRouter image model (e.g., FLUX, GPT Image, Stable Diffusion), with control over resolution, aspect ratio, quality, output format, background, compression, and seed. Results are saved to disk and file paths are returned. * Edit/transform images (pixara_edit_image): Perform image-to-image edits by providing one or more reference images (local file path, remote URL, or raw base64) alongside a text prompt. File reading and encoding are handled automatically. * List available models (pixara_list_image_models): Browse OpenRouter's image model catalog with filtering by provider, name, and capability flags (img2img, streaming, transparent background support). Supports pagination and returns results in Markdown or JSON. * Inspect model details (pixara_get_model_details): Retrieve per-provider pricing, supported parameters (with allowed values/ranges), and passthrough options for a specific model — useful for confirming compatibility before making a generation call. All image operations are billed through OpenRouter; listing and model details are free.

Pixara

by pinkpixel-dev

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Pixara MCP Server

pixara-mcp MCP server

An MCP server that gives LLMs direct access to OpenRouter's Image API to generate images, edit/transform existing ones, and browse the model catalog, all through 4 tools.

I built this because I saw that OpenRouter announced a unified Image API that gives you one endpoint to use image generation and image editing models like GPT Image, Nano Banana, Flux, etc. Use the pixara_list_image_models tool to see the full, current models list from OpenRouter.

Features

Generate images from a text prompt against any OpenRouter image model
Edit/transform images (img2img) using a local file, a URL, or raw base64 as the reference, and the tool reads and encodes local files for you
List models with filtering by provider, name, and capability (img2img, streaming, transparent background), plus pagination
Inspect a model's endpoint details: per-provider pricing, supported parameters, and allowed passthrough options — before you spend a call on something it doesn't support
Generated images are decoded and saved to disk, so responses stay small and a file path is returned
Clear error messages for common failure modes: bad/conflicting params, invalid key, insufficient credits, rate limits, provider unavailable

Related MCP server: openrouter-image-gen-mcp

Quick start (recommended)

Pixara is published on npm as @pinkpixel/pixara-mcp. The easiest way to use it is via npx — no install, no cloning, no build step.

Add this to your MCP config (claude_desktop_config.json) for Claude Desktop, or your MCP client's .json config file:

{
  "mcpServers": {
    "pixara": {
      "command": "npx",
      "args": ["-y", "@pinkpixel/pixara-mcp"],
      "env": {
        "OPENROUTER_API_KEY": "sk-or-v1-your-key-here",
        "OPENROUTER_IMAGE_OUTPUT_DIR": "/absolute/path/to/wherever/you/want/images"
      }
    }
  }
}

Restart the client and you should see the four pixara_* tools available. npx -y fetches and caches the package on first run, so there's nothing to update manually. New versions get picked up automatically.

Configuration

Variable	Required	Description
`OPENROUTER_API_KEY`	Yes	Get one at openrouter.ai/keys
`OPENROUTER_IMAGE_OUTPUT_DIR`	No	Where generated images are saved. Defaults to `./pixara-images`

The server just reads these from process.env — there's no .env file loading built in. Whether you're running via npx or from source, set these in the env block of your MCP config, as shown above. OPENROUTER_IMAGE_OUTPUT_DIR is optional — leave it out and images save to ./pixara-images relative to wherever the server process runs; set it to an absolute path if you want a predictable location regardless of the client's working directory.

Installing from source

For local development, or if you'd rather not rely on npx:

Requires Node.js 18+.

git clone https://github.com/sizzlebop/pixara-mcp.git
cd pixara-mcp
npm install
npm run build

Then point your MCP config at the built file instead of npx:

{
  "mcpServers": {
    "pixara": {
      "command": "node",
      "args": ["/absolute/path/to/openrouter-image-mcp/dist/index.js"],
      "env": {
        "OPENROUTER_API_KEY": "sk-or-v1-your-key-here",
        "OPENROUTER_IMAGE_OUTPUT_DIR": "/absolute/path/to/wherever/you/want/images"
      }
    }
  }
}

Tools

`pixara_generate_image`

Text-to-image. Required: model, prompt. Optional: n, resolution, aspect_ratio, size, quality, output_format, background, output_compression, seed, provider_options, output_dir, filename_prefix.

Don't combine size with resolution/aspect_ratio — pick one or the other, the tool will reject the call with a clear message if you mix them.

`pixara_edit_image`

Same params as generate_image, plus a required input_references array. Each entry is one of:

{ "source": "file", "path": "/path/to/photo.png" }
{ "source": "url", "url": "https://example.com/photo.jpg" }
{ "source": "base64", "data": "<base64>", "media_type": "image/png" }

`pixara_list_image_models`

Read-only, free (no image billing). Filter by filter (substring), provider, or capability booleans (supports_img2img, supports_streaming, supports_transparent_background). Paginated with limit/offset.

`pixara_get_model_details`

Read-only, free. Pass a model slug, get back per-provider pricing and exactly which parameters/passthrough options that provider supports. Worth calling before you use provider_options, since unsupported params get silently dropped or rejected by the API.

How it decides where to save images

Every generate/edit call decodes the base64 image(s) OpenRouter returns and writes them to OPENROUTER_IMAGE_OUTPUT_DIR (or a per-call output_dir override), named {prefix}-{timestamp}-{index}.{ext}. The extension follows output_format, except for vector output (Recraft's SVG models), which is detected via the response's media_type and written as .svg regardless of what output_format was requested.

Limitations

No SSE streaming support yet (see Roadmap)
Model capabilities vary a lot by provider, and OpenRouter's catalog moves fast — always trust pixara_list_image_models/pixara_get_model_details over any hardcoded list
This is new — OpenRouter's Image API has only been out a couple of weeks, so expect model IDs and params to shift over time

License

Apache 2.0 — see LICENSE.

Made with 💖 by Pink Pixel

Available Tools

4 tools

pixara_edit_imageEdit Image (OpenRouter)A

Edit or transform an existing image using a text prompt and one or more reference images, via any image-to-image-capable model on OpenRouter.

This calls OpenRouter's Image API with input_references and saves the resulting image(s) to disk. Reference images can be a local file path, a remote URL, or raw base64 — this tool handles reading/encoding local files itself, so you never need to pre-encode anything.

Args:

model (string): Must support image-to-image, e.g. 'openai/gpt-image-1' or 'bytedance-seed/seedream-4.5'. Check with pixara_get_model_details first if unsure.
prompt (string): Instruction describing the desired edit/transformation.
input_references (array, required, 1+): Each entry is one of: { source: "file", path: "/abs/or/relative/path.png" } { source: "url", url: "https://example.com/photo.jpg" } { source: "base64", data: "", media_type: "image/png" }
n, resolution, aspect_ratio, size, quality, output_format, background, output_compression, seed, provider_options, output_dir, filename_prefix: same meaning as in pixara_generate_image.

Returns: Markdown summary listing each saved file's path, media type, size in bytes, and the total cost charged by OpenRouter for the request.

Examples:

Use when: "Make this photo look like a watercolor painting" with a local file path
Use when: "Remove the background from this product photo" with a URL reference
Don't use when: there's no reference image at all (use pixara_generate_image)

Error Handling:

"Could not read reference image" -> check the file path is correct and readable
"Bad request" -> the chosen model may not support img2img; verify with pixara_get_model_details
"Insufficient OpenRouter credits" -> add credits at https://openrouter.ai/credits

ParametersJSON Schema

Name	Required	Description	Default
`n`	No	Number of images to generate (1-10). Not all models support n > 1.
`seed`	No	Seed for deterministic generation, where supported.
`size`	No	Convenience shorthand for either a tier ('2K') or explicit dimensions ('2048x2048'). Don't combine with 'resolution' or 'aspect_ratio'.
`model`	Yes	OpenRouter model slug, e.g. 'black-forest-labs/flux-1.1-pro' or 'openai/gpt-image-1'. Use pixara_list_image_models to discover available models.
`prompt`	Yes	Text description of the desired image.
`quality`	No	Quality tier: 'auto', 'low', 'medium', or 'high'.
`background`	No	Background handling: 'auto', 'transparent', or 'opaque'. 'transparent' requires output_format 'png' or 'webp'.
`output_dir`	No	Directory to save generated images into. Defaults to OPENROUTER_IMAGE_OUTPUT_DIR.
`resolution`	No	Resolution tier: '512', '1K', '2K', or '4K'. Don't combine with 'size'.
`aspect_ratio`	No	Aspect ratio, e.g. '16:9' or '1:1'. Don't combine with 'size'.
`output_format`	No	Output image format: 'png', 'jpeg', or 'webp'.	png
`filename_prefix`	No	Prefix for saved image filenames (default: 'openrouter-image').
`input_references`	Yes	Reference image(s) to edit/transform. Each entry is a local file path, a remote URL, or raw base64 data — the tool handles reading/encoding for you.
`provider_options`	No	Provider-specific passthrough params, keyed by provider slug, e.g. { 'black-forest-labs': { steps: 40, guidance: 3 } }. Check pixara_get_model_details for each provider's allowed_passthrough_parameters before using this.
`output_compression`	No	Compression level 0-100, only applies to 'webp'/'jpeg' output_format.

TDQS

A4.8/5.0

Behavior5/5

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

Annotations (readOnlyHint=false, destructiveHint=false) are supplemented by the description's disclosure that the tool saves images to disk, handles encoding of local files, and returns a Markdown summary. It also includes error handling details. No contradictions.

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 well-structured with sections (general, Args, Returns, Examples, Error Handling). It is comprehensive but not excessively long. Could be slightly more concise, but it earns its place.

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 complexity (15 params, nested objects, no output schema), the description covers purpose, usage, all parameter categories, return format, and error scenarios. It is sufficiently complete for an AI agent to invoke correctly.

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

Parameters4/5

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

Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the three input_reference source types (file, url, base64) and automating local file reading. It groups some parameters by referencing pixara_generate_image, which is efficient but assumes knowledge of that tool.

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 it edits/transforms an existing image using a text prompt and reference images. It specifies the action (edit/transform), resource (image), and method (via OpenRouter). It distinguishes from sibling pixara_generate_image by noting when not to use it (no reference image).

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

Usage Guidelines5/5

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

The description provides explicit examples ('Use when: ...', 'Don't use when: ...') and advises checking model capabilities with pixara_get_model_details before selecting a model. This gives clear guidance on when to invoke this tool vs alternatives.

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

pixara_generate_imageGenerate Image (OpenRouter)A

Generate an image from a text prompt using any image model available on OpenRouter.

This calls OpenRouter's dedicated Image API (not chat completions) and saves the resulting image(s) to disk, returning the file path(s), model used, and cost. It does NOT edit or use reference images — for image-to-image/editing, use pixara_edit_image instead.

Args:

model (string): OpenRouter model slug, e.g. 'black-forest-labs/flux-1.1-pro' or 'openai/gpt-image-1'. Use pixara_list_image_models to discover options.
prompt (string): Text description of the desired image.
n (number, 1-10, default 1): Number of images to generate. Not all models support n > 1.
resolution ('512'|'1K'|'2K'|'4K', optional): Resolution tier.
aspect_ratio (string, optional): e.g. '16:9', '1:1'. Don't combine with 'size'.
size (string, optional): Convenience tier or explicit dimensions. Don't combine with resolution/aspect_ratio.
quality ('auto'|'low'|'medium'|'high', optional)
output_format ('png'|'jpeg'|'webp', default 'png')
background ('auto'|'transparent'|'opaque', optional): 'transparent' requires png/webp.
output_compression (0-100, optional): webp/jpeg only.
seed (number, optional): For deterministic generation where supported.
provider_options (object, optional): Provider-specific passthrough params. Check pixara_get_model_details first for allowed keys.
output_dir (string, optional): Where to save images (default: OPENROUTER_IMAGE_OUTPUT_DIR).
filename_prefix (string, optional): Prefix for saved filenames.

Returns: Markdown summary listing each saved file's path, media type, size in bytes, and the total cost charged by OpenRouter for the request.

Examples:

Use when: "Generate a picture of a red panda astronaut" -> model + prompt only
Use when: "Make a transparent-background product shot" -> background='transparent', output_format='png'
Don't use when: you have a reference image to transform (use pixara_edit_image)

Error Handling:

"Insufficient OpenRouter credits" -> add credits at https://openrouter.ai/credits
"Bad request" / conflicting params -> re-check with pixara_get_model_details
"Rate limited" -> wait and retry

ParametersJSON Schema

Name	Required	Description	Default
`n`	No	Number of images to generate (1-10). Not all models support n > 1.
`seed`	No	Seed for deterministic generation, where supported.
`size`	No	Convenience shorthand for either a tier ('2K') or explicit dimensions ('2048x2048'). Don't combine with 'resolution' or 'aspect_ratio'.
`model`	Yes	OpenRouter model slug, e.g. 'black-forest-labs/flux-1.1-pro' or 'openai/gpt-image-1'. Use pixara_list_image_models to discover available models.
`prompt`	Yes	Text description of the desired image.
`quality`	No	Quality tier: 'auto', 'low', 'medium', or 'high'.
`background`	No	Background handling: 'auto', 'transparent', or 'opaque'. 'transparent' requires output_format 'png' or 'webp'.
`output_dir`	No	Directory to save generated images into. Defaults to OPENROUTER_IMAGE_OUTPUT_DIR.
`resolution`	No	Resolution tier: '512', '1K', '2K', or '4K'. Don't combine with 'size'.
`aspect_ratio`	No	Aspect ratio, e.g. '16:9' or '1:1'. Don't combine with 'size'.
`output_format`	No	Output image format: 'png', 'jpeg', or 'webp'.	png
`filename_prefix`	No	Prefix for saved image filenames (default: 'openrouter-image').
`provider_options`	No	Provider-specific passthrough params, keyed by provider slug, e.g. { 'black-forest-labs': { steps: 40, guidance: 3 } }. Check pixara_get_model_details for each provider's allowed_passthrough_parameters before using this.
`output_compression`	No	Compression level 0-100, only applies to 'webp'/'jpeg' output_format.

TDQS

A4.8/5.0

Behavior5/5

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

Discloses that the tool saves images to disk, calls OpenRouter's Image API (not chat), and returns file paths and cost. No annotation contradictions; adds context beyond annotations such as error handling and environment variable usage.

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?

Well-structured with sections: summary, args, returns, examples, error handling. Slightly lengthy but justified by the tool's complexity (14 params); no unnecessary sentences.

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?

No output schema but describes return format adequately. Covers error scenarios, environment variable defaults, and sibling tool references. Thorough for a complex tool.

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

Parameters4/5

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

Schema coverage is 100%, baseline 3. Description adds significant value by explaining parameter constraints (e.g., n>1 not universal), mutual exclusivity rules, and defaults, surpassing basic schema descriptions.

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?

Clearly states the tool generates images from text prompts using OpenRouter models. Distinguishes itself from sibling pixara_edit_image by explicitly noting it does not edit or use reference images.

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

Usage Guidelines5/5

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

Provides explicit when-to-use and when-not-to-use examples, plus alternatives like pixara_edit_image for editing. Also references pixara_list_image_models for model discovery and error handling guidance.

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

pixara_get_model_detailsGet Model Details (OpenRouter)A

Read-onlyIdempotent

Get per-provider pricing, supported parameters, and passthrough options for one OpenRouter image model.

This is a read-only, no-cost call. Use it before pixara_generate_image / pixara_edit_image to confirm exactly which parameters a model/provider supports and what it costs — unsupported parameters are silently ignored or rejected by the API, so checking first avoids wasted/failed calls.

Args:

model (string, required): OpenRouter model slug, e.g. 'black-forest-labs/flux.2-pro'.
response_format ('markdown'|'json', default 'markdown').

Returns: Per-provider breakdown: pricing (billable type, unit, price, tier/variant), supported parameter descriptors (enum values, numeric ranges, or plain booleans), and any allowed_passthrough_parameters for use with the generate/edit tools' provider_options field.

Examples:

Use when: "How much does flux.2-pro cost and what steps/guidance params does it take?"
Use when: "Does gpt-image-1 support transparent backgrounds on this provider?"
Don't use when: browsing across many models (use pixara_list_image_models instead)

Error Handling:

"Resource not found" / empty endpoints -> the model id may be wrong; verify with pixara_list_image_models

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes	OpenRouter model slug to inspect, e.g. 'openai/gpt-image-1'.
`response_format`	No	Output format: 'markdown' for humans or 'json' for machine processing.	markdown

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds that the call is 'no-cost' and explains that unsupported parameters are silently ignored or rejected, justifying why checking first is important. No contradictions.

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 well-structured with clear sections (main description, args, returns, examples, error handling). It is front-loaded with the primary purpose and every sentence adds meaningful information without redundancy.

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?

Even without an output schema, the description details the return structure (per-provider pricing, parameter descriptors, passthrough options). It also covers error scenarios. All aspects of the tool's usage are covered comprehensively.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds example model slugs and clarifies the response_format options with practical examples ('markdown' for humans, 'json' for machines), adding value 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?

The description clearly states the tool retrieves per-provider pricing, supported parameters, and passthrough options for a single OpenRouter model. It uses specific verbs ('Get', 'confirm') and distinguishes itself from sibling tools like pixara_generate_image, pixara_edit_image, and pixara_list_image_models.

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

Usage Guidelines5/5

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

Explicit guidance: use before generate/edit to avoid wasted calls, and avoid when browsing many models (suggesting pixara_list_image_models). Provides example use cases and error handling instructions.

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

pixara_list_image_modelsList Image Models (OpenRouter)A

Read-onlyIdempotent

List image-generation models available on OpenRouter, with filtering and pagination.

This is a read-only, no-cost call (no image is generated). Use it to discover model IDs before calling pixara_generate_image or pixara_edit_image, or to find models with a specific capability.

Args:

filter (string, optional): Case-insensitive substring match against model id or name.
provider (string, optional): Restrict to models whose id starts with this prefix, e.g. 'openai', 'black-forest-labs'.
supports_img2img (boolean, optional): Only models that accept input_references.
supports_streaming (boolean, optional): Only models that support SSE streaming.
supports_transparent_background (boolean, optional): Only models supporting transparent backgrounds.
limit (number, 1-100, default 30), offset (number, default 0): Pagination.
response_format ('markdown'|'json', default 'markdown').

Returns: For JSON: { total, count, offset, models: [...], has_more, next_offset? } For Markdown: a heading per model with id, description, and supported parameter names.

Examples:

Use when: "What image models can do transparent backgrounds?" -> supports_transparent_background=true
Use when: "Show me FLUX models" -> filter='flux'
Don't use when: you already know the exact model id (skip straight to generate_image)

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of models to return (1-100).
`filter`	No	Case-insensitive substring match against model id or name.
`offset`	No	Number of models to skip, for pagination.
`provider`	No	Filter to models whose id starts with this provider prefix, e.g. 'openai'.
`response_format`	No	Output format: 'markdown' for humans or 'json' for machine processing.	markdown
`supports_img2img`	No	Only include models that support image-to-image via input_references.
`supports_streaming`	No	Only include models that support SSE streaming.
`supports_transparent_background`	No	Only include models that support transparent backgrounds.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that it is a no-cost call (no image generated), providing useful behavioral context beyond the annotations.

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 well-structured with clear sections (Args, Returns, Examples) and front-loaded key points. Though somewhat long, every sentence earns its place.

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

Completeness4/5

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

Given 8 parameters and no output schema, the description adequately covers return formats for both JSON and Markdown. It provides sufficient context for a discovery tool, though more detail on pagination behavior could be added.

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

Parameters4/5

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

Schema coverage is 100%, giving a baseline of 3. The description adds semantic meaning by explaining each filter's purpose (e.g., case-insensitive substring match) and output format behavior, enhancing 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 tool lists image-generation models with filtering and pagination. It distinguishes itself from siblings by specifying it is a read-only discovery call before using pixara_generate_image or pixara_edit_image.

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

Usage Guidelines5/5

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

Explicit when-to-use and when-not-to-use examples are provided, such as 'Use when: What image models can do transparent backgrounds?' and 'Don't use when you already know the exact model ID.' It also references sibling 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.

4 tool updatesv1.0.1Jul 11, 2026
- First observedpixara_edit_image
- First observedpixara_generate_image
- First observedpixara_get_model_details
- First observedpixara_list_image_models

Install Server

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

TDQS

A4.8/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: generation, editing, model details, and model listing. There is no overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent 'pixara_verb_noun' snake_case pattern, making them predictable and easy to navigate.

Tool Count5/5

With 4 tools, the server is well-scoped, covering the essential image generation, editing, and model exploration without unnecessary or missing tools.

Completeness5/5

The tool set covers the full lifecycle: discovery (list and get details), generation (text-to-image), and editing (image-to-image). No obvious gaps for the stated purpose.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

mcp-qwen-imageOAuth
io.github.AceDataCloud
MCP server for Qwen Image 3 AI image generation
AI & Machine Learning Image & Video Processing
1
OpenAI Tools MCP Server B
ai.com.mcp
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
Image & Video Processing Audio Processing Multimedia Processing
927
Claude Imagine AOAuth
com.claudeimagine
Generate AI images and videos from any compatible MCP client.
AI & Machine Learning Image & Video Processing
82
mcp-flux-proOAuth
io.github.AceDataCloud
MCP server for Flux AI image generation
Image & Video Processing Multimedia Processing
23

Related MCP Servers

imagegen-mcp
AI & Machine Learning Image & Video Processing
spartanz51
A
license
Not graded
quality
D
maintenance
MCP server that wraps OpenAI's image generation and editing APIs, enabling text-to-image and image-to-image operations via tools.
Updated a year ago (2025-05-02 08:47 UTC)
204
37
ISC
openrouter-image-gen-mcp
Image & Video Processing AI & Machine Learning
dev66613
A
license
A
quality
D
maintenance
MCP server for generating images using OpenRouter API, supporting models like Gemini 2.5 Flash. Enables image generation with flexible options like saving to local files.
Updated 7 months ago (2026-01-27 19:36 UTC)
2
Do What The F*ck You Want To Public
mcp_photo
afr13nd77
A
license
Not graded
quality
B
maintenance
MCP server for generating and editing images using OpenRouter API, with support for multiple models and dynamic model discovery. Runs in Docker and integrates with Claude Desktop via stdio transport.
Updated 2 months ago (2026-07-20 06:59 UTC)
MIT
HiggsHole
AI & Machine Learning Image & Video Processing
szk1234
A
license
A
quality
B
maintenance
An MCP server that enables local AI agents to generate images and videos through the OpenRouter API, manage a browsable media library, and track generation costs.
Updated 2 months ago (2026-07-21 22:38 UTC)
11
MIT

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/pinkpixel-dev/pixara-mcp'

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