Skip to main content
Glama
Archicad-MCP

Archicad-MCP

by alesdev88

Create elements

create_elements
Destructive

Creates Archicad elements such as walls, doors, windows, MEP routes, annotations, and drawings from validated item data; dry-run validation checks schemas and hosts before committing.

Instructions

Create elements of any type Tapir can create. element_type: model wall, beam, column, slab, roof, shell, morph, mesh, stair, railing, railing_polyline, zone, curtain_wall, grid_element, object, lamp; hosted door, window (in a wall), skylight (in a roof or shell), opening; MEP mep_route, mep_element, mep_flexible_segment, mep_take_off (Archicad 28+), electrical_panel, electrical_device, electrical_circuit (Archicad 30); markers section, elevation, interior_elevation, detail_marker, worksheet_marker; hotlink_instance; 2D line, arc, circle, polyline, spline, hatch, hotspot, text, label, keynote_label; dimension, level_dimension, wall_thickness_dimension, section_dimension; drawing (on a layout). Plurals and Tapir command names work too. Items use Tapir's field names and units (metres, radians): call with items=[] to get the item schema for a type, with notes on what the schema leaves out (which heights are absolute, which side a wall's body, a door's swing and a stair's flight lie on). DRY-RUN BY DEFAULT: every item is validated against the schema (any problem: nothing is sent, problems listed by item index and field), a favoriteName and a libraryPartName must exist (closest names suggested), and hosts (a door's wall, the elements a dimension measures, a label's parent) must exist, be the right type and be editable; items failing those are skipped with the reason and the rest go ahead. Most types take the Element ID as 'id' from Tapir 1.7.3 (doors, windows, openings, roofs and morphs do not); on an older Tapir such an item is skipped. Warns when the active window is wrong for the type, when an object or lamp has no dimensions (it would take the tool's current size, not the library part's), when it sends offset or useFixedAngle (Archicad discards them), when a door or window has no sillHeight (it would take the tool's sill), when one placed by libraryPartName leaves the Door or Window tool holding that part, when an absolute height lies off the story floorIndex names, when a stair's flights overlap, and, after the create, when a stair runs past its baseline. Learn a part once with learn_library_part before placing it by placement; a learned part is then placed with no samples. An object, lamp, door or window of such a part may give placement instead: an object's footprint centre, size (length along the head, width across it) and head direction (the head is the end that goes against the wall: a bed's pillow end, a chair's or sofa's back), for coordinates, angle, reflected and dimensions; a door's or window's hinge_near and opens_toward points, for reflected and oSide, and leaves (a recorded leaf state, written right after the create). On a part learned with a Tapir newer than 1.8.0, an object's size may be left out, as may a door's or window's width and height, which then take the part's own. items=[] shows its placement_schema; 'placements' lists what each one derived, and for a door or window the hinge and swing it read. Reading a sketch: choose the part from what it draws, the lines dividing a window give its sashes and the arcs give which sash or leaf opens and where it is hinged; prefer the plain generic part ("Window", "Door", "Double Window") when the sketch says no more. Width is a check: a window about 1.2 m wide is a single or a double window, never a multi-sash one; when the count and the width disagree, ask. A bed's head is the end with the pillows, or with the duvet's turned-back edge; when the sketch shows neither, ask. After placing, look (capture_window) and correct with modify_elements before reporting done. Pass dry_run=false to create: returns created GUIDs, plus Tapir's per-item errors grouped with item indices and by_index (item index -> GUID) when not every item was created, and 'placed_not_set' for an element placed whose leaves Archicad refused. On a Tapir newer than 1.8.0, database ({"guid": ...}, from GetDatabaseIdFromNavigatorItemId) puts lines, arcs, circles, polylines, splines, hatches, hotspots, texts or labels into that layout's, section's or other view's database instead of the active window's.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "element_type": "<element_type>",
      "items": "<items>"
    },
    "name": "create_elements"
  }
}

Input Schema

NameRequiredDescriptionDefault
portNo
itemsYes
dry_runNo
databaseNo
element_typeYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.0
    • addedInput schema / properties / database
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": true,
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null
      +}
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only say readOnly=false and destructive=true; the description goes far beyond by disclosing dry-run-by-default, per-item validation, skip-on-failure with reasons, the full warning catalogue (wrong active window, discarded offset/useFixedAngle, stair overlap, wrong sill), and the exact return shape including by_index and placed_not_set. Nothing here contradicts the destructive hint; it clarifies that writes only occur with dry_run=false.

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?

Content is front-loaded with purpose and alternatives, and nearly every sentence carries procedural value, but the body is a dense wall of run-on sentences mixing validation, warnings, placement semantics and sketching heuristics. Paragraph or list structure would make the same content far easier to scan and act on.

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 high-complexity, destructive, 5-parameter tool with an output schema, the description covers creation semantics, dry-run behavior, error handling, placements and the database override, so an agent can call it correctly. The only meaningful gap is the undocumented 'port' parameter; return values are already covered by the output schema.

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 0%, so the description must carry the load: it thoroughly explains element_type (with plurals and Tapir command names accepted), items (Tapir field names and units in metres/radians, items=[] to get the schema), dry_run, database, and the placement/placement_schema conventions. The 'port' parameter is never mentioned, leaving one of five parameters undocumented.

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?

Opens with a specific verb and resource ("Create elements of any type Tapir can create") and then enumerates every supported element_type family (model, hosted, MEP, markers, 2D, dimensions), so an agent can immediately tell what the tool covers versus siblings like modify_elements or find_elements. The taxonomy is concrete enough to select a type without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing: learn a part once with learn_library_part before placing by placement; call items=[] to fetch the schema; look with capture_window and correct with modify_elements before reporting done; pass dry_run=false to actually create. It also states exclusions and preconditions (hosts must exist and be editable, libraryPartName must exist, items failing checks are skipped).

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