Skip to main content
Glama
skulitom

pixelbolt

by skulitom
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

pixel_scene

Render pixel-art scenes or rooms from sprites, tilemaps, and lighting, returning the image, placements, lights, and warnings for review or export.

Instructions

Compose a pixel art scene or room from sprites, tilemaps and lighting. Renders a pixelforge-scene manifest (placements, autotiled tilemaps, cues, motion, ground sorting, camera and parallax, haze, lights and shadows; pixel_help topic scenes) at a time in milliseconds and returns the image, placements, lights and warnings. Assets may be inline recipes, files under the server root or {"revision": id}. view: depth shows who covers whom; export: true writes a replayable scene bundle.

Input Schema

NameRequiredDescriptionDefault
litNo
timeNo
viewNo
scaleNo
sceneYes
exportNo
guidesNoPerspective guides: {horizon: row, vanish: [[x, y], …up to 3], iso: {tile: [32, 16], at: [x, y]}}.
densityNo
sequenceNoAlso write numbered PNG frames for a video editor: pixel_render's sequence options, without animation and step.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.9.2
    • addedInput schema / properties / guides
      Added value: +{
+  "description": "Perspective guides: {horizon: row, vanish: [[x, y], …up to 3], iso: {tile: [32, 16], at: [x, y]}}.",
+  "type": "object"
+}
    • removedInput schema / properties / sequence / additionalProperties
      Removed value: -false
    • changedInput schema / properties / sequence / description
      Previous value: -"Also write a numbered PNG sequence for a video editor into sequence/: one PNG per video frame with alpha, plus sequence.json and a README with the ffmpeg command for a .mov. The result reports timing changes and whether a loop closes on the frame grid."New value: +"Also write numbered PNG frames for a video editor: pixel_render's sequence options, without animation and step."
    • removedInput schema / properties / sequence / properties
      Removed value: -{
-  "align": {
-    "enum": [
-      "top-left",
-      "top",
-      "top-right",
-      "left",
-      "center",
-      "right",
-      "bottom-left",
-      "bottom",
-      "bottom-right"
-    ]
-  },
-  "background": {
-    "description": "Palette name or opaque hex colour. Default: transparent.",
-    "type": "string"
-  },
-  "fit": {
-    "description": "contain (default): the whole sprite fits the canvas. cover: the smallest scale that covers the canvas; the overhang is cropped.",
-    "enum": [
-      "contain",
-      "cover"
-    ]
-  },
-  "fps": {
-    "description": "Frame rate: 24, 25, 30, 60, or \"23.976\", \"29.97\", \"59.94\" (exact n000/1001), or a fraction such as \"30000/1001\".",
-    "type": [
-      "number",
-      "string"
-    ]
-  },
-  "loops": {
-    "maximum": 1000,
-    "minimum": 1,
-    "type": "integer"
-  },
-  "offset": {
-    "description": "[x, y] canvas pixels added to the aligned position.",
-    "items": {
-      "type": "integer"
-    },
-    "maxItems": 2,
-    "minItems": 2,
-    "type": "array"
-  },
-  "scale": {
-    "description": "Whole-number enlargement. Default: the largest that fits the canvas, or 1 without a size.",
-    "maximum": 256,
-    "minimum": 1,
-    "type": "integer"
-  },
-  "seconds": {
-    "description": "Length of the clip instead of loops.",
-    "exclusiveMinimum": 0,
-    "maximum": 3600,
-    "type": "number"
-  },
-  "size": {
-    "description": "Canvas: 720p, 1080p, 1440p, 4k, vertical, square or WIDTHxHEIGHT. Default: the sprite at scale.",
-    "type": "string"
-  }
-}
    • changedInput schema / properties / view / enum
      Previous value: -[
-  "color",
-  "grayscale"
-]New value: +[
+  "color",
+  "grayscale",
+  "depth"
+]
  2. First observedv0.9.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations declare destructiveHint=false and idempotentHint=false, so the safety bar is partly covered; the description earns credit beyond that by disclosing side effects annotations don't capture — export:true writes a replayable scene bundle, sequence writes numbered PNG frames, timing is reported in milliseconds, and warnings are returned alongside the image. It stops short of saying where bundles/frames are written or what failures look like.

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?

Two sentences, front-loaded with the verb and resource, with the parenthetical enumerating exactly what a manifest may contain. It is dense but nearly every clause carries signal; the 'pixel_help topic scenes' aside is the one item that could be trimmed or moved.

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

Completeness3/5

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

For a high-complexity tool with nested objects, no output schema and low schema coverage, the description does well on the scene manifest and outputs (image, placements, lights, warnings) but leaves three parameters and the practical workflow (how a revision-based asset resolves, what a scene bundle contains) undocumented.

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

Parameters3/5

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

With 9 parameters and only 22% schema description coverage, the description must compensate — and it does for scene (enumerating placements, autotiling, cues, motion, sorting, parallax, lights), view: depth ('shows who covers whom'), export, and time units. But lit, scale and density get no explanation anywhere, leaving a real gap.

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?

States a specific verb and resource — 'Compose a pixel art scene or room from sprites, tilemaps and lighting' — and then names the actual artifact produced (a pixelforge-scene manifest with placements, tilemaps, camera, haze, lights). It also implicitly separates itself from pixel_render by referencing 'pixel_render's sequence options', so an agent can place it in the sibling set without opening the schema.

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?

Usage is implied rather than stated: the description tells you what inputs are acceptable (inline recipes, files under the server root, or {"revision": id}) and points to pixel_help topic scenes, but never says when to choose this over pixel_render, pixel_compile or pixel_validate, nor any precondition or exclusion.

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

Deploy Server

Other Tools