SpriteForge Editor

Open the full SpriteForge editor

open_full_editor

Opens a sprite in SpriteForge's full pixel editor - layers, selection and move, line/rectangle/ellipse, mirror painting, brush sizes, animation frames with onion skin and playback, palette tools - as an interactive card where the app shows them, and returns an edit link that opens the same editor in a browser. One source at most: session_id (an edit session that's already open, or an edit link), png_base64 (an existing PNG), art (palette + index grid), or none for a blank width x height canvas. Max 128x128 pixels and 256 colours. The user's edits save to the edit session.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "open_full_editor"
  }
}

Input Schema

Name	Required	Description
`art`	No	Pixel art in SpriteForge's format: palette = hex colours, grid = rows of palette indexes (-1 = transparent). Optional frames for an animation, each { grid } on the same palette.
`name`	No	Sprite name, used as the download filename (letters, digits, _ and -).
`width`	No	Blank canvas width in pixels (default 32).
`height`	No	Blank canvas height in pixels (default 32).
`palette`	No	Starting palette for a blank canvas, as hex colours.
`png_base64`	No	A PNG file, base64-encoded (a data: URL prefix is fine). Pixels under 50% alpha become transparent.
`session_id`	No	An edit session that's already open, or an edit link containing ?s=<id>.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations declare the safety profile (not read-only, not destructive, not idempotent) and the description adds genuinely new behavior: it renders as an interactive card, returns a browser edit link, persists edits to the edit session, and enforces 128x128 / 256-colour limits. It does not say what happens on repeated calls (a new session per call, given idempotentHint=false), which is the one notable gap.

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 core action and its output are front-loaded, then input modes, then limits — a sensible ordering. The long parenthetical feature catalogue (layers, mirror painting, onion skin, etc.) is descriptive but is the least load-bearing part of the text and inflates an otherwise tight definition.

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?

With no output schema, the description steps in to say it returns an edit link and an interactive card, which is what an agent needs. Combined with the source-mode rules and hard limits, an agent can call this correctly; only the multi-session/repeat-call behavior is left unstated.

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 already 100%, so the baseline is 3, and the description earns an extra point by explaining the mutual exclusivity of the four source parameters and the blank-canvas default behavior — semantics the schema cannot express. The 50% alpha transparency rule for png_base64 and size limits are reinforced at the top level rather than being buried in property docs.

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?

Opens with a specific verb+resource ("Opens a sprite in SpriteForge's full pixel editor") and enumerates the editing capabilities, so the agent knows exactly what this tool produces. The word "full" implicitly contrasts with the sibling open_editor, but the distinction between open_full_editor, open_editor and open_tileset_editor is never made explicit.

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

Usage Guidelines4/5

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

The 'one source at most' rule with four enumerated input modes (session_id, png_base64, art, or none for a blank canvas) gives clear guidance on how to call it and what the defaults are. It never states when to pick this over the sibling open_editor or open_tileset_editor, so routing between siblings is left to inference.

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

All SpriteForge Editor tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?