Skip to main content
Glama

fill_area

Replace a contiguous region of matching color starting at (x, y) on a target layer with a new color, enabling flood-fill paint-bucket edits in pixel art.

Instructions

Flood fill (paint bucket): replace the contiguous region of matching colour starting at (x,y) on the target layer with color.

Coordinates: (0, 0) is the top-left pixel. x grows right, y grows DOWN. A span given as position plus size covers x .. x + width - 1, so width is a count of pixels, not an offset to the far edge.

Centring differs between primitives, so check this when aligning two shapes:

  • draw_rectangle(x, width) spans x .. x+width-1, centred on x + (width-1)/2. An even width therefore centres on a half pixel.

  • draw_ellipse(center, radius) spans center-radius .. center+radius, which is always an ODD 2*radius+1 pixels wide and always centred on a whole pixel.

  • draw_ellipse_in_box(x, y, width, height) takes the same bounding box as draw_rectangle and fills it exactly, so it is the one to use for an even diameter, a disc centred on an even canvas, or a circle that has to line up with a rectangle.

  • draw_symmetric_pixels mirrors about the canvas, not about either of the above.

Writes falling outside the canvas are dropped rather than raising. Every drawing tool reports pixels_written, and pixels_clipped when anything was dropped, so compare those against what you asked for rather than trusting ok.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xYes
yYes
colorYes
frameNoDefault: 1.
layerNo
filenameYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv0.10.0
    • removedInput schema / properties / color / title
      Removed value: -"Color"
    • removedInput schema / properties / filename / title
      Removed value: -"Filename"
    • addedInput schema / properties / frame / description
      Added value: +"Default: 1."
    • removedInput schema / properties / frame / title
      Removed value: -"Frame"
    • removedInput schema / properties / layer / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / layer / default
      Removed value: -null
    • removedInput schema / properties / layer / title
      Removed value: -"Layer"
    • addedInput schema / properties / layer / type
      Added value: +"string"
    • removedInput schema / properties / x / title
      Removed value: -"X"
    • removedInput schema / properties / y / title
      Removed value: -"Y"
    • removedInput schema / title
      Removed value: -"fill_areaArguments"
  2. First observedv0.7.0

TDQS

A3.7/5.0
Behavior4/5

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

Beyond the bare annotations (readOnlyHint false, openWorldHint false), it discloses that out-of-canvas writes are silently dropped and that results expose pixels_written/pixels_clipped, advising the agent to verify counts rather than trust 'ok'. That is meaningful behavioral context for a mutation tool with no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence is precise and front-loaded, but roughly two-thirds of the text is a digression into centring rules for draw_rectangle, draw_ellipse, draw_ellipse_in_box and draw_symmetric_pixels, which are largely irrelevant to a flood-fill start point and dilute the core instruction.

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 mutation tool with minimal annotations and no output schema, the description covers clipping behaviour and return fields well, but it omits the meaning of `frame`/`filename`, any failure modes beyond canvas clipping, and guidance on layer targeting versus the whole-canvas default.

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 only 17%, so the description must compensate, and it partially does: it defines the coordinate origin/direction for x and y and ties colour and 'target layer' to their roles. It says nothing about `frame` or `filename`, leaving two of six parameters undocumented in both places.

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 mechanism: 'Flood fill (paint bucket): replace the contiguous region of matching colour starting at (x,y) on the target layer with color.' It names the exact semantics (contiguous, colour-matching, start point, target layer), which cleanly separates it from whole-layer operations like fill_layer and from the draw_* primitives.

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 flood-fill semantics imply when it applies, but the description never states when to choose it over siblings such as fill_layer, select_by_color, or draw_brush. The centring guidance mentions conditions for aligning shapes but does not route the agent between competing tools.

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