brickbuilder-mcp

Overview Schema Source Related Servers Discussions Admin

fill_layers

Turn colour maps into packed LEGO layers: create stacked brick/plate/tile volumes or upright wall mosaics, skipping occupied cells with staggered seams.

Instructions

Build volume from colour maps, automatically packed into bricks/plates/tiles.

layers: bottom-to-top list of layers; each layer is a list of equal-length rows seen from ABOVE, first row = back, last row = front. Each character is a cell of 1 stud; '.' = empty. legend maps characters to colours, e.g. {"R": "Red", "W": 15}. Each layer is one brick (3 plates) or one plate tall depending on kind; layer i sits at y + i*height. (x, z) is the front-left corner of the map.

upright=True: each layer is instead a front-facing wall picture (first row = top, last row = bottom), one course per row, at depth z + layer index. Handy for mosaics and facades.

Cells already occupied are skipped. Seams are staggered between courses.

Input Schema

TableJSON Schema

Name	Required	Default
`x`	No
`y`	No
`z`	No
`kind`	No	brick
`layers`	Yes
`legend`	Yes
`upright`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 30, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does well: it discloses auto-packing, skipping already occupied cells, staggered seams, per-layer height depending on kind, and coordinate placement. It still omits mutation/reversibility details, permission needs, and failure behavior.

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?

The description is front-loaded with the core action and then structured into compact paragraphs covering layers, legend, placement, and upright mode. Despite its length, the detail is necessary for a nested map-based tool and every sentence contributes.

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?

For a complex 7-parameter tool with nested arrays/objects, no annotations, and no schema descriptions, the description is strong and covers the essential map format and placement behavior. It misses some parameter edge semantics and explicit model-context behavior, but the output schema covers return-value details.

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 description coverage is 0%, so the description must compensate. It explains the layers matrix orientation, legend mapping with examples, x/z as front-left corner, y as layer offset, kind height behavior, and upright mode. Gaps remain for 'tile' in kind and integer legend values.

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?

The first sentence states a specific verb and resource: 'Build volume from colour maps, automatically packed into bricks/plates/tiles.' This distinguishes the tool from generic part addition or mosaic conversion. It does not name siblings, but the resource and packing behavior make the purpose unambiguous.

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 description gives use context only for the upright mode ('Handy for mosaics and facades'), implying when that variant is useful. It never states when to use fill_layers over alternatives such as build_mosaic, image_to_grid, or add_parts, so routing guidance is incomplete.

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

Deploy Server