Skip to main content
Glama

Repair furniture placement

repair
Read-onlyIdempotent

Corrects furniture placement in an ArchLang plan, resolving wall, doorway, overlap, room, and floating-piece issues, then returns the updated .arch source with a change log.

Instructions

Correct furniture placement and return the corrected .arch source with a change log. It pushes furniture out of walls, doorways and door swings, separates overlapping pieces, moves fixtures that sit in the wrong room, and snaps floating pieces to walls. A piece it may not rewrite is listed in unresolved with the reason. It never adds doors or windows (that is a design choice); use suggest for those.

Input Schema

NameRequiredDescriptionDefault
sourceYesArchLang source to correct.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

With annotations covering read-only, idempotent, non-destructive behavior, the description adds substantial context: it describes the specific corrections, reports unresolved pieces with reasons, returns a change log, and clarifies it never adds doors or windows. This goes well beyond what the annotations convey.

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 four focused sentences, front-loaded with the core action and return value. Each sentence adds useful detail without redundancy, and the exclusion is placed at the end where it naturally follows.

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

Completeness5/5

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

For a tool with one well-documented parameter and no output schema, the description covers what the tool does, what it returns ('corrected .arch source with a change log'), how unresolved pieces are handled, and what it does not do. This is sufficient for an agent to invoke it correctly.

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?

The input schema has full description coverage for the single 'source' parameter, so the schema carries the burden of parameter meaning. The description does not add any extra semantics about the parameter format or constraints, which is acceptable given the high coverage.

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 description uses a specific verb ('Correct furniture placement') and explains the exact transformations performed, such as pushing furniture out of walls and snapping floating pieces. It explicitly distinguishes itself from the sibling tool 'suggest' for adding doors or windows.

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?

It gives a clear exclusion ('never adds doors or windows') and names the alternative ('use suggest for those'). However, it does not differentiate itself from other likely siblings like 'fix' or 'lint', leaving some ambiguity about when to choose repair over those tools.

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