Skip to main content
Glama
alesdev88

Archicad-MCP

by alesdev88

Record a learned library part

record_library_part

Store the head, height, hinge combos, or leaf states you judged from a learned library part's image, and return the fields still missing before it can be placed.

Instructions

Record what you judged from learn_library_part's image, in the part's stored record. Objects and lamps: head ('+x', '-x', '+y' or '-y', the part's own axis its head points along), one_sided (true or false) and height (metres). The head is the end that goes against the wall: a bed's pillow end, a chair's or sofa's back, not its front. A bed's head is the end with the pillows, or with the duvet's turned-back edge; when the image shows neither, ask. Doors and windows (learned with refSide false): combos, which maps a flag pair (reflected then oSide, t for true and f for false: 'ff', 'tf', 'ft' or 'tt') to [hinge, swing], hinge 'begin' or 'end' of the wall's own direction and swing 'left' or 'right' of it; leaves (a whole number, at least 1); and leaf_states, which maps a state name to GDL parameter values. The lines dividing a window give its sashes, the arcs give which sash or leaf opens and where it is hinged. combos and leaf_states merge by key: recording a key again replaces it, and removing one takes forget and a new learn; every other field replaces its value. One refused value saves nothing. Returns the record and 'missing', the fields still needed before the part can be placed from it. forget=true removes the part's record, which can be learned again, and takes no other field. The part must have been learned first. Writes only the MCP's own learned-parts file, never the model, and needs no Archicad.

Input Schema

NameRequiredDescriptionDefault
headNo
nameYes
combosNo
forgetNo
heightNo
leavesNo
one_sidedNo
leaf_statesNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.11.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that it writes only the MCP's own learned-parts file, never the model, needs no Archicad, is atomic on refusal ('One refused value saves nothing'), and that forget removes a record that can be re-learned. It also explains the merge semantics of combos/leaf_states versus replace-on-write for other fields.

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?

Front-loaded with the action and the two data families, and every clause carries real information. It is dense, semicolon-heavy prose that takes careful reading, which slightly hurts scannability.

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?

Even though an output schema exists, it still states the return value including 'missing', the list of fields still needed before placement. Combined with atomicity, merge rules, and the wall-facing head convention, 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.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description carries the full burden and mostly discharges it: allowed head values and axis meaning, height in metres, one_sided as boolean, the four combo flag-pair keys with [hinge, swing] semantics, leaves as an integer >= 1, and leaf_states as name-to-GDL-values. Only 'name' is left implicit, which is self-evident.

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?

Names a specific verb (record) and resource (the part's stored record) and explicitly frames the input as the judgement produced from learn_library_part's image, separating it from the sibling that produces that image. The two families of data it accepts (objects/lamps vs doors/windows) are spelled out.

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?

States the prerequisite ('The part must have been learned first'), the forget=true mode and that it 'takes no other field', and explicitly tells the agent to ask the user when the image is ambiguous. It does not contrast with list_library_part_records, but the usage context is otherwise unambiguous.

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