Pixael

Watch your animation
Edit your frames
Manage your assets
Edit your sprites
Pixael!!
Connect your AI

Inspiration

I've spent more hours redrawing walk cycles pixel-by-pixel than actually building the games they were for. Sprite work is one of those things everyone assumes is quick, it isn't. At the same time, AI has gotten genuinely good at generating pixel art, but every tool treats it as a one-shot image: no memory of your last frame, no shared palette, no way to nudge a single pixel afterward. It generates around your project, not inside it. WebMCP looked like a real answer to that gap, a way to let an agent work inside the same live tool a human uses, instead of handing back a disconnected PNG. Pixael is what that looks like for pixel-art sprites specifically.

What it does

Pixael is a pixel-art sprite studio for creating, animating, and exporting 2D game assets — and every meaningful action in it is also a WebMCP tool, so a human and an AI agent can work on the same live canvas.

Full pixel editor: pencil, eraser, bucket fill, eyedropper, lines, rectangles, undo/redo, zoom, onion skinning
Multi-state animation system (Idle, Walk, Attack, Hurt, etc.) with per-state frame timelines and adjustable-FPS playback
Multi-asset project management with categories, palettes, and PNG/sprite-sheet export
Zero login, zero backend everything saves locally via IndexedDB, works the moment you open it
37 WebMCP tools spanning asset management, animation states, frame editing, three tiers of pixel manipulation, palette control, and export registered through document.modelContext.registerTool

An agent can create a character, add an animation, edit specific pixels, fix a visual bug, or export a sprite sheet using the exact same operations the UI calls, nothing simulated or faked.

How we built it

React + TypeScript on Vite, with a strict layered architecture: UI components never touch state directly, they call a pure, deterministic domain layer (assetOperations, animationOperations, frameOperations, pixelOperations, paletteOperations, exportOperations), which sits on top of an authoritative project store with full undo/redo, plus isolated stores for playback and editor tool state so a 60fps animation preview doesn't re-render the whole app. Persistence is IndexedDB with debounced autosave and a graceful in-memory fallback if it's unavailable.

The WebMCP layer was built as a thin registration module wrapping that same domain layer. Two design decisions mattered most: pixel data is transmitted as palette-index + run-length encoding rather than raw pixel arrays or images, keeping a typical frame read to roughly 100–300 tokens instead of 600+; and pixel editing is split into three tiers (full-frame rewrite, targeted coordinate patches, and shape/transform operations like flood fill and line draw) so an agent picks the cheapest tool for the job instead of rewriting an entire canvas for a one-pixel fix.

Challenges we ran into

WebMCP is genuinely new. The flag needed for testing (chrome://flags/#enable-webmcp-testing) only works on recent Chrome builds, and even the correct API surface shifted under us mid-build (navigator.modelContext vs. document.modelContext across different docs and spec drafts). Chrome's native tool-result contract also turned out to be string-only no structured image content blocks like backend MCP supports which meant redesigning how the agent gets visual feedback, leaning on the compact RLE pixel format as the primary channel instead of images. And with a hard four-day runway from architecture decision to submission, we had to be disciplined about which tools were "genuinely useful agent capability" versus "nice to have" to hit both breadth and reliability in time.

Accomplishments that we're proud of

The full 36-tool surface actually works end-to-end, verified through both the Model Context Tool Inspector extension and ChatGPT's in-app browser not a demo of one tool, a real one covering asset creation, animation, pixel editing, and export. It's held up across different model sizes too, including smaller/cheaper models, which we take as a sign the tool schemas carry enough signal on their own rather than relying on a large model to compensate for ambiguity. And in testing, agents completed genuinely non-trivial multi-step tasks in a single instruction resizing a sprite and adding a held item consistently across four animation frames, or diagnosing and correcting a specific pixel-level bug in an existing sprite without us hand-holding the request.

What we learned

Schema clarity matters more than model size the clearest signal came from watching a smaller model succeed at multi-step tasks because the tool contracts left little room for ambiguity, not because it was a bigger model doing more inference work. We also learned the token economics of data representation are a real design constraint for agent-facing tools, not an afterthought RLE vs. raw pixel arrays was a multi-hundred-token difference per call, which adds up fast across an editing session. And architecting the domain layer for automation from day one before WebMCP was even in the picture made the actual integration almost mechanical; retrofitting agent tools onto UI-coupled logic would have been a much harder rebuild.

What's next for Pixael

Batch and multi-select operations so an agent can act across several frames or assets in one call instead of one-at-a-time. Undo-aware agent tools that can reason about and revert their own multi-step changes. Broader testing across WebMCP-capable surfaces as the standard matures beyond Chrome and ChatGPT's in-app browser. And of course improving the quality and performance.