Which integrations are available for this server?

Enables using Hugging Face's free tier text-to-image models as a backend for generating pixel art, configurable via HF_TOKEN and HF_MODEL environment variables.

How do I use Pixel Art MCP?

1. Click on "Deploy 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., "@Pixel Art MCP generate a cozy cabin in the woods, 160x90, 32 colors" 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.

Pixel Art MCP

by uncagedspirit

Overview Schema Source Related Servers Discussions Admin

Python

Local

🎨 Pixel Art MCP

An MCP server that turns text prompts into cozy pixel-art PNGs — using a free, no-API-key image backend — and saves them straight into your project.

Point Claude (or any MCP client) at this server and ask for "a cozy library interior, side view, warm afternoon light"; it generates the image, crushes it down into authentic, palette-limited pixel art, and writes the PNG to disk. Built originally to make scene art for a pixel study-game, but useful for any game/app that needs quick, consistent pixel assets.

✨ Features

Text → pixel art in one call, saved as a ready-to-use PNG.
Free by default — uses Pollinations (no API key, no signup).
Real pixel-art post-processing — the model output is downscaled to a true pixel grid (nearest-neighbor) and palette-quantized, so it looks like pixel art, not just a blurry "pixel-ish" render.
Pluggable backends — swap to Hugging Face (free token) or a local Stable Diffusion endpoint by changing one function / env var.
Project-agnostic output — relative paths resolve against PIXEL_OUT_DIR, so the same server serves any project.
Two tools: generate from a prompt, or pixelate an image you already have.
Tiny & hackable — one server.py, ~200 lines, easy to extend.

Related MCP server: pixel-mcp

🧠 How it works

MCP servers expose tools to an LLM. This one talks to the client (e.g. Claude Code) over stdio using JSON-RPC; the client launches it, lists its tools, and calls them when the model decides to.

prompt ──▶ style preamble ──▶ free image backend (HTTPS)
                                     │  raw image bytes
                                     ▼
                            Pillow: resize to WxH (NEAREST)
                                     │
                            quantize to N colors (median cut)
                                     ▼
                            save PNG ──▶ PIXEL_OUT_DIR/<out_path>

The "make it look like real pixel art" step is the downscale + palette quantize, not the model — that's the part worth keeping no matter which backend you use.

📦 Requirements

Python 3.10+
Outbound HTTPS at generation time (to the chosen backend)
An MCP client (e.g. Claude Code)

🚀 Install

git clone https://github.com/uncagedspirit/pixel-art-mcp.git
cd pixel-art-mcp

python -m venv .venv
# Windows:
.venv/Scripts/python.exe -m pip install -r requirements.txt
# macOS / Linux:
# .venv/bin/python -m pip install -r requirements.txt

Optionally install it as a package (gives you a pixel-art-mcp command):

.venv/Scripts/python.exe -m pip install .

🔌 Register with Claude Code

Add an entry to your project's .mcp.json (or your global Claude config).

Windows

{
  "mcpServers": {
    "pixel-art": {
      "command": "C:/path/to/pixel-art-mcp/.venv/Scripts/python.exe",
      "args": ["C:/path/to/pixel-art-mcp/server.py"],
      "env": { "PIXEL_OUT_DIR": "C:/path/to/your/project" }
    }
  }
}

macOS / Linux

{
  "mcpServers": {
    "pixel-art": {
      "command": "/path/to/pixel-art-mcp/.venv/bin/python",
      "args": ["/path/to/pixel-art-mcp/server.py"],
      "env": { "PIXEL_OUT_DIR": "/path/to/your/project" }
    }
  }
}

Then restart Claude Code and approve the pixel-art server. The CLI alternative: claude mcp add pixel-art -- <python> <server.py>.

PIXEL_OUT_DIR sets where generated files land (defaults to the working directory). Set it to the project you want assets written into.

🛠️ Tools

`generate_pixel_art(prompt, out_path, width=160, height=90, colors=32, seed=None)`

Generate a pixel-art PNG from a prompt.

Arg	Meaning
`prompt`	What to draw
`out_path`	Where to save (relative → under `PIXEL_OUT_DIR`)
`width`,`height`	Pixel-grid size. `160x90` for 16:9 scenes; `32`–`64` for sprites
`colors`	Palette size; `16`–`32` reads as retro
`seed`	Optional, for reproducible results

`pixelate_image(in_path, out_path, width=160, height=90, colors=32)`

Pixelate an image you already have into a matching style.

🎚️ Backends

Set PIXEL_BACKEND:

Value	Free?	Setup
`pollinations` (default)	✅	nothing — no key
`huggingface`	free tier	set `HF_TOKEN` (and optionally `HF_MODEL`)

To use a local Stable Diffusion (best quality/control, needs a GPU), add a backend function that POSTs to your local endpoint (e.g. AUTOMATIC1111 / ComfyUI / SD.Next) and wire it into _generate_raw. The post-processing stays the same.

🧪 Quick test (without an MCP client)

.venv/Scripts/python.exe -c "import server; print(server.make_pixel_art('cozy cafe interior, side view, warm lamps', 'out/cafe.png', 160, 90, 32, 1))"

🗺️ Roadmap / ideas

chroma_key tool — generate sprites on a solid background and key it out for transparent characters/props.
Sprite-sheet / animation frames (e.g. N-frame idle loops, packed into a strip).
Palette locking — pass a fixed palette so a whole asset set shares colors.
Tileset / tilemap export (Tiled-friendly) for maps.
Batch generation from a manifest (one call → a whole scene set).
Upscaled preview output alongside the true-resolution PNG.
More backends (Replicate, local ComfyUI workflow, Retro Diffusion).
Optional background removal / auto-trim for props.
Deterministic, seed-pinned regeneration + a small results gallery.

Contributions welcome — open an issue or PR.

🤝 Contributing

Fork & branch.
Keep server.py small; put new capabilities behind new @mcp.tool() functions.
Prefer pure helper functions (like make_pixel_art) so logic is testable without the MCP transport.
Update this README's tool list + roadmap.

⚠️ Notes

Pollinations is a free community service: it can be slow/rate-limited and you should review its terms for your intended (especially commercial) use.
This is a generation/dev tool. It makes network calls when generating; the output is plain local PNGs you commit into your project.

📄 License

MIT — do whatever, just keep the notice.

Available Tools

2 tools

generate_pixel_artA

Generate a pixel-art PNG from a text prompt and save it.

Args: prompt: What to draw, e.g. "cozy library interior, side view, tall arched windows, warm lamps". out_path: Save location (relative paths resolve against PIXEL_OUT_DIR), e.g. "assets/pixel/library/background.png". width: Pixel-grid width (smaller = chunkier). 160x90 suits 16:9 scenes; use 32-64 for sprites/props. height: Pixel-grid height. colors: Palette size (16-48 reads as retro). seed: Optional seed for reproducible output.

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	Yes
`out_path`	Yes
`width`	No
`height`	No
`colors`	No
`seed`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/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. It discloses behavioral traits such as saving to a file, path resolution against PIXEL_OUT_DIR, default dimensions and their recommended use cases, and a seed parameter for reproducibility. It does not mention overwrite behavior or error handling, but overall adds significant context.

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 a clear summary line followed by parameter details. It is mostly concise, though the parameter examples add length. Every sentence adds value, and the structure is easy to parse.

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 6 parameters, 0% schema coverage, and an existing output schema, the description covers all parameters with good context. It does not detail return values, but that is acceptable since an output schema exists. The description is sufficient for an agent to understand and use the tool correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must compensate. It provides detailed explanations for all 6 parameters: prompt (example), out_path (path hints), width/height (recommended sizes for different uses), colors (palette hint), and seed (optional for reproducibility). Each parameter gains meaningful semantics beyond the schema fields.

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 generates a pixel-art PNG from a text prompt and saves it. It specifies the verb ('generate', 'save') and resource ('pixel-art PNG'), and implicitly distinguishes from the sibling 'pixelate_image' which operates on existing images.

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

Usage Guidelines3/5

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

The description implies usage for creating pixel art from scratch but does not explicitly state when to use this tool versus the sibling 'pixelate_image'. No when-not-to-use or alternative guidance is provided, only implied context.

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

pixelate_imageC

Pixelate an existing image into matching pixel art (downscale + quantize).

ParametersJSON Schema

Name	Required	Description	Default
`in_path`	Yes
`out_path`	Yes
`width`	No
`height`	No
`colors`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided. Description mentions downscale+quantize but omits important behaviors: whether original image is modified, file format handling, permission requirements, or error conditions.

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?

Single sentence, efficient. Could be improved with structured format (e.g., bullet points for parameters) but is not verbose.

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?

With 5 parameters and 0% schema coverage, description is too sparse. No details on output format, error handling, or usage examples; output schema exists but is not reflected.

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

Parameters2/5

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

Schema description coverage is 0%; description adds no parameter-specific meaning. It loosely refers to 'downscale+quantize' but does not connect width/height/colors to those operations.

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?

Description clearly states it pixelates an existing image via downscale and quantize, distinguishing from sibling generate_pixel_art which generates from scratch. However, it could be more explicit about the distinction.

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 vs. generate_pixel_art or other alternatives. No mention of prerequisites or context.

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.

2 tool updatesv0.1.0Jun 21, 2026
- First observedgenerate_pixel_art
- First observedpixelate_image

Deploy Server

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

TDQS

B3.4/5.0

Scored 2026-06-21 07:55 across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: generating pixel art from a text prompt and pixelating an existing image. There is no overlap or ambiguity.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern in snake_case: 'generate_pixel_art' and 'pixelate_image'. The naming is predictable and easy to understand.

Tool Count3/5

The server has only two tools, which is on the low side. While they cover basic generation and pixelation, the small number may limit the server's usefulness for complex workflows.

Completeness2/5

The tool set lacks common operations like listing, deleting, or editing pixel art. The completeness is minimal, covering only creation and transformation without supporting lifecycle management.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mcp-flux-proOAuth
io.github.AceDataCloud
MCP server for Flux AI image generation
Image & Video Processing Multimedia Processing
23
mcp-nanobanana-proOAuth
io.github.AceDataCloud
MCP server for NanoBanana AI image generation and editing
Image & Video Processing Multimedia Processing
27
mcp A
com.budgetpixel
Generate AI images, video, music, and sound effects, and upscale them, from any MCP client.
AI & Machine Learning Image & Video Processing Audio Processing
1312
Gessa: game asset generation for AI agentsOAuth
ai.gessa
Generate game-ready 3D models, textures, and audio from natural language, over MCP.
AI & Machine Learning Image & Video Processing Audio Processing
1

Related MCP Servers

Image Generator MCP Server
Image & Video Processing File Systems
rmcendarfer2017
A
license
B
quality
D
maintenance
An MCP server that allows users to generate images using Replicate's Stable Diffusion model and save them to the local filesystem.
Updated 2 years ago (2025-03-08 16:13 UTC)
3
MIT
pixel-mcp
Image & Video Processing Design Tools
adrianoamaral
F
license
A
quality
D
maintenance
An MCP server that enables AI coding agents to create pixel art programmatically by providing canvas manipulation tools and PNG export.
Updated 5 months ago (2026-04-16 23:12 UTC)
10
30
2
-
Imagen
AI & Machine Learning Image & Video Processing Games & Gamification
emil28092005
A
license
Not graded
quality
B
maintenance
MCP server for generating pixel-art sprites with transparent backgrounds using any diffusers-compatible text-to-image model.
Updated a month ago (2026-07-29 10:56 UTC)
MIT
2DPIXELMCP
Image & Video Processing Design Tools
alikayalll43-sudo
A
license
Not graded
quality
B
maintenance
An MCP server that bridges Antigravity AI with LibreSprite, enabling real-time pixel art drawing, animation, and manipulation through natural language commands.
Updated 2 months ago (2026-07-08 17:59 UTC)
MIT

🎨 Pixel Art MCP

✨ Features

🧠 How it works

📦 Requirements

🚀 Install

🔌 Register with Claude Code

🛠️ Tools

generate_pixel_art(prompt, out_path, width=160, height=90, colors=32, seed=None)

pixelate_image(in_path, out_path, width=160, height=90, colors=32)

🎚️ Backends

🧪 Quick test (without an MCP client)

🗺️ Roadmap / ideas

🤝 Contributing

⚠️ Notes

📄 License

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Image Generator MCP Server

pixel-mcp

Imagen

2DPIXELMCP

`generate_pixel_art(prompt, out_path, width=160, height=90, colors=32, seed=None)`

`pixelate_image(in_path, out_path, width=160, height=90, colors=32)`