Skip to main content
Glama

aseprite_fill_regions

Paint individual pixels with unique colors on a chosen Aseprite layer, avoiding a rectangular block. Use it to touch up scattered details, add highlights, or fix stray pixels.

Instructions

Paint a set of individual pixels, each with its own colour, on one layer. Unlike aseprite_pixels this does not need a rectangular block, so it suits touching up scattered details, adding a highlight, or fixing stray pixels.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNoX offset added to every cell (default 0).
yNoY offset added to every cell (default 0).
cellsYesPixels to paint.
layerNoTarget layer.
documentNoDocument to act on: a short name inside the art folder ("hero"), a relative path, or an absolute .aseprite path. Omit to use the active document.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4/5.0
Behavior3/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 the single-layer scope and per-pixel semantics, but says nothing about whether existing pixels are overwritten, undo behavior, or permission/document requirements for a clearly mutating operation. Useful scoping context, but the mutation contract is underspecified.

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?

Two sentences, front-loaded with the core action, then the differentiation. Every clause earns its place with no redundancy.

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?

No output schema and no annotations, but for a per-pixel paint tool the description plus rich schema cover the essentials. The main remaining gap is behavioral: overwrite/undo semantics and document-state requirements are unstated, which a mutation tool of this kind ideally would address.

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?

Schema description coverage is 100%, so the schema already documents x/y offsets, cells structure, layer, document, and color formats. The description only loosely maps to the parameters ('each with its own colour, on one layer') and adds no format or default details beyond what the schema supplies. Baseline 3 applies.

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 ('Paint') and resource ('set of individual pixels, each with its own colour, on one layer'), and explicitly names the sibling it differs from (`aseprite_pixels`). An agent can distinguish this from the rectangular-block variant without opening either schema.

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?

Explicitly contrasts with the alternative ('Unlike `aseprite_pixels` this does not need a rectangular block') and lists concrete scenarios: touching up scattered details, adding a highlight, fixing stray pixels. It lacks an explicit 'when not to use this' caveat, but the context is clear.

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