Skip to main content
Glama
Archicad-MCP

Archicad-MCP

by alesdev88

Write element data

set_element_data
Destructive

Preview or commit Archicad element data across properties, classifications, GDL, markers, and IFC, returning applied, failed, and skipped changes.

Instructions

Write element data. DRY-RUN BY DEFAULT: returns planned changes (current -> new) without touching the model; pass dry_run=false to commit. A change is {guid, property, value}; property takes the addresses get_element_data reads (a property, 'classification:', 'gdl:', 'marker:', 'ifc:.'), so one call can mix kinds. Classification values are an item ID or GUID, null unclassifies. GDL and marker values in metres and radians, an array as the whole list in its own shape (rows for two dimensions; array writes need Tapir 1.7.2), an attribute parameter by index or name. IFC values are text, a number or true/false, with an optional ifc_type (IfcLabel for text by default); Tapir writes IFC properties only in Archicad 27 and older. A commit sends classifications first and reads every change back: 'applied' counts what reads as sent; 'not_applied', changes Archicad answered success for but kept or replaced (a GDL Parameter Script can); 'failed', Archicad's refusals grouped by code and message with a count and sample GUIDs; 'skipped', changes not sent, with the reason (value type, enum, unknown parameter, a property the official API cannot read, or an element Archicad would refuse: in another view's database than the active window's, on a hidden or locked layer, inside a hotlinked module, locked with Edit > Locking, or not reserved in Teamwork); 'not_sent' and 'stopped' if a batch was refused outright after earlier batches landed; 'unconfirmed' if the read after the write failed. run_parameter_script=true (Tapir 1.7.3) runs the Parameter Script of every element whose GDL write went through, before the read back, so parameters that depend on the written ones update as they would after an edit in the settings dialog; 'parameter_script' reports the run. Off by default: a part's script can reset what was just written.

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": "set_element_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
portNo
changesYes
dry_runNo
run_parameter_scriptNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.12.0
    • addedInput schema / properties / run_parameter_script
      Added value: +{
      +  "default": false,
      +  "type": "boolean"
      +}
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare this non-read-only and destructive, but the description adds substantial behavior beyond them: dry-run semantics, commit ordering, status meanings, skip reasons, Tapir/Archicad version constraints, and the parameter-script side effect. There is no contradiction with the annotations.

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?

The definition front-loads purpose and dry-run behavior, but the body is a dense single block with long semicolon-separated enumerations. Much of the status taxonomy may already be covered by the output schema, and the run-on structure makes it harder to scan than necessary.

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 complex destructive write tool, it covers the important execution behavior, dry-run/commit flow, property value rules, and failure handling. The main gaps are the undocumented port parameter and lack of explicit sibling-tool routing, though the output schema reduces the need to explain return values.

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 parameter meaning, and it defines the changes object as {guid, property, value}, explains property address syntax, specifies value typing for classifications/GDL/markers/IFC, and describes dry_run and run_parameter_script. It never explains port, leaving one of four 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?

The description opens with a specific verb and resource and immediately defines the change shape and the property address forms it accepts. It also distinguishes itself from get_element_data by tying its property addresses to what that read tool consumes.

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 clearly explains the dry-run default, how to commit with dry_run=false, and when to enable run_parameter_script. It does not explicitly route the agent among write siblings such as execute_write_api_command or edit_classifications, so alternative-selection guidance is incomplete.

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