Skip to main content
Glama
U-C4N
by U-C4N

Architecture: Wall

arch_wall

Add walls to an existing plan network and resolve junctions (L, T, X) automatically. Redraws affected walls with openings.

Instructions

Add walls to the plan network already on the drawing and resolve every junction.

Two ends at one point mitre into a clean L; an end inside another wall is a T (the stem stops on the crossing wall's near face, which is cut there); two axes crossing are an X (all four faces cut). A drawn wall whose outline the new walls change is taken back out and redrawn with its openings - the result lists it under redrawn - and a wall they do not touch is left alone. Every wall carries an ACADMCP_ARCH record, so later calls find it by id.

Refused before anything is drawn or erased, by path: a wall id already on the drawing or used twice, an axis of fewer than two points or with a zero-length segment, a non-positive thickness, an unknown justification or material (the list is named), two walls meeting at less than 5° (the mitre would run away), a wall corner lying inside another wall off its axis, an end inside a wall whose axis only meets it past that wall's end, and a new wall that would leave a drawn opening uncuttable. A curved wall is not supported: an axis is straight segments only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pocheNoHatch the cut wall faces in their material (ISO 128-50)
wallsYesWalls to add: [{id, axis:[[x,y],...] (2+ points, straight segments, WCS mm), thickness, justification:'center'|'left'|'right' (side of the axis looking along it), material:'brick'|'aac'|'concrete'|'reinforced_concrete'|'gypsum_board'|'stone'|'timber'|'generic', closed:bool}]

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

A4.6/5.0
Behavior5/5

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

With only destructiveHint=false given, the description carries the burden and delivers: junction resolution semantics (L/T/X), redraw-and-listing of affected walls under `redrawn`, the ACADMCP_ARCH record for later id lookup, and a thorough enumeration of pre-draw refusal conditions. This is unusually rich behavioral disclosure.

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?

Dense but front-loaded: the core action comes first, then junction behavior, then mutations, then refusals. Every sentence encodes a rule, though the prose is heavy enough that it could be tightened without losing meaning.

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?

An output schema exists, so return-shape explanation is unnecessary, and the description still covers the one return detail that matters (`redrawn`). For a junction-resolving wall tool, an agent has everything needed to call it correctly.

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 coverage is 100%, so the schema already documents `walls` and `poche`. The description still adds meaning beyond it: thickness must be positive, axes need 2+ points with no zero-length segment, justification/material values are validated against named lists, and ids persist via the ACADMCP_ARCH record.

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 opening sentence states a specific verb (add) and resource (walls) plus the scope (the plan network already on the drawing) and the side effect (resolve every junction). It is clearly distinguishable from siblings like arch_opening, arch_stair, and entity_create_line.

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?

Usage is well-framed as an operation on an existing plan network, and the long refusal list effectively communicates when the tool will not act (duplicate ids, degenerate axes, sub-5° mitres, curved walls). It does not explicitly name competing sibling tools, so it stops short of a 5.

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