Skip to main content
Glama
Archicad-MCP

Archicad-MCP

by alesdev88

Modify elements

modify_elements
Destructive

Update existing Archicad elements by GUID—preview current and new field values, skipped elements, and warnings before committing with dry_run=false.

Instructions

Change existing elements. DRY-RUN BY DEFAULT: returns per element the current and new value of every field, plus skipped elements with the reason and warnings; pass dry_run=false to commit. Each change is {"guid", ...fields}. Any element: story (index, ground floor 0, or a story name; the element keeps its height above the story and moves with it unless keep_elevation=true), layer (name), draw_order (1 to 14, 0 = the type's default), id (the Element ID; Tapir 1.7.3 and newer, otherwise set_element_data General_ElementID). Walls, beams, slabs, columns, windows, doors, morphs, multi-plane roofs, meshes, objects, lamps, texts and labels also take the fields of Tapir's Modify command by its own names (describe_api_command ModifyWalls lists them), e.g. height, thickness, sillHeight, lightIsOn. On a Tapir newer than 1.8.0 so do stairs (ModifyStairs), railings (ModifyRailings), sections and elevations (ModifySections) and detail and worksheet markers (ModifyDetailMarkers); on those last two the reference ID shown in the marker is reference_id, as id stays the Element ID. Attribute fields (buildingMaterialId, compositeId, profileId, surfaceId, lineTypeId, sectionFillId, ...) take a name. Lengths in metres, angles in radians, text sizes in mm. Partial coordinates, dimensions and visibility are completed from the current values. Elements Archicad would refuse (another view's, hidden or locked layer, not reserved in Teamwork, inside a hotlinked module, locked) are skipped with the reason, never unlocked. A placed object, lamp, door or window of a part learned with learn_library_part may take placement, as create_elements does (its items=[] shows the placement_schema), in place of the fields it works out: an object or lamp keeps its story and elevation (center takes x and y only), a door or window its wall and centerOffset; leaves are written after the commit, and 'placed_not_set' names an element whose leaves were not set. A placement that cannot be worked out makes the whole call an error naming the change. After a placement, look (capture_window) and correct with this tool before reporting done; create_elements has the rules for reading a sketch. A commit reads the elements back: 'modified' counts what landed, 'failed' groups Archicad's refusals, 'not_applied' lists fields Archicad answered success for but did not change.

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": {
      "changes": "<changes>"
    },
    "name": "modify_elements"
  }
}

Input Schema

NameRequiredDescriptionDefault
portNo
changesYes
dry_runNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false and destructiveHint=true; the description goes far beyond them, disclosing that refused elements (other view's, hidden/locked layer, unreserved in Teamwork, hotlinked, locked) are skipped with a reason and never unlocked, and that a commit reads back 'modified', 'failed' and 'not_applied'. That is exactly the mutation-risk context an agent needs before committing.

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?

The dry-run default and the change-object shape are front-loaded, which is the right ordering for a destructive mutation. The prose is dense with parentheticals and version qualifiers (Tapir 1.7.3, 1.8.0), so scanning is harder than it needs to be, but nearly every clause conveys operational detail rather than filler.

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?

With an output schema, destructive annotations and a nested free-form 'changes' array, the description supplies the missing pieces: field semantics, skip behavior, placement fallbacks and the meaning of the commit read-back counters. Nothing essential for a correct call is left implicit.

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?

Schema coverage is 0%, so the description must carry the burden and it does: each change is {guid, ...fields}, with per-field meaning for story (index/name, keep_elevation), layer, draw_order (0 = type default), id, attribute fields (which take a name), and units (metres, radians, mm). Only the 'port' parameter is left unexplained, which is a minor omission against a very dense compensation.

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?

"Change existing elements" gives a specific verb and resource, and the description immediately separates this tool from create_elements (placement rules, placement_schema) and set_element_data (older-Tapir Element ID fallback). An agent can tell what this tool owns without inspecting 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 Guidelines4/5

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

It is explicit that dry_run defaults to true and that dry_run=false commits, and it routes the agent to describe_api_command for the list of modifiable fields and to capture_window to verify after a placement. What is missing is an explicit exclusion against siblings such as move_elements or get_element_data; alternatives are mentioned incidentally rather than as a decision rule.

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