Archicad-MCP

Overview Schema Source Related Servers Discussions Admin

Edit attributes

edit_attributes

Destructive

Create, modify, delete or replace Archicad attributes such as layers, fills and building materials, or set their property values, with a dry run by default so changes are previewed before committing.

Instructions

Create, modify, delete and replace attributes (layers, layer combinations, lines, fills, zone categories, pen tables, profiles, building materials, composites, surfaces) and set attribute property values (Tapir). DRY-RUN BY DEFAULT; pass dry_run=false to commit. Each change has one action key whose value is the type: {"create": "Layer", "name": "X", } makes a new one and NEVER overwrites (an existing name is skipped, with what would change and the modify to send instead); {"modify": "Composite", "attribute": "", } changes an existing one (name renames; fields not given keep their value, including what Tapir's own overwrite would drop: a composite's useWith, a building material's texts); {"modify": ..., "properties": {"Group/Name": "value"}} sets property values; {"delete": "Fill", "attribute": ...} deletes; {"replace": "Fill", "attribute": ..., "with": ...} (fills, lines, surfaces, building materials, a Tapir newer than 1.8.0, Archicad 27) rewrites every reference across the project and deletes it, and its dry run lists what uses it (uses). Fields use Tapir's names and units (metres, radians, pen numbers); a field holding another attribute (buildingMaterialId, lineTypeId, fillId, cutFillIndex, a layer combination's layers[].attributeId) takes its name. changes=[] lists every type's fields; list_attributes(details=true) shows current values in the same form. The dry run shows current -> new and skips with the reason anything Archicad or Tapir would refuse or silently get wrong: misspelt enums, unknown references, Archicad's own index 1 attributes, a layer delete while elements are on the layer (it would delete them) or without the floor plan active. In Teamwork the attribute type's set must be reserved (reserve_elements object_sets). Attribute writes cannot be undone, except a replace, which is one undo step per type. A commit returns applied (read back), not_applied, failed (grouped) and stopped.

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

Input Schema

Name	Required	Description	Default
`port`	No
`changes`	Yes
`dry_run`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.10.0Oct 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the destructiveHint=true annotation: create never overwrites and reports what it would have changed, modify preserves unspecified fields including ones Tapir's own overwrite would drop, replace rewrites every project reference then deletes and its dry run lists uses, delete of a layer with elements on it would delete those elements, and attribute writes are irreversible except replace (one undo step per type). It also names the classes of the dry run's refusals (misspelt enums, unknown references, Archicad index 1 attributes, inactive floor plan).

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 dry-run default and heavily information-dense with no filler sentences. The single long paragraph and the nested brace-quoted payload examples make it dense on first read, though every clause carries behavioral content.

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?

For a generic changes-array mutation tool this is thorough: payload grammar, invariant semantics per action, refusal handling, Teamwork preconditions, undo behavior, and the commit result buckets (applied/not_applied/failed/stopped) are all covered even though an output schema exists. Nothing needed to invoke it correctly is missing apart from port.

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?

With 0% schema coverage the description must carry the load, and it does for two of three parameters: dry_run's default and commit meaning, and the discriminator-shaped changes payload with its action keys (create/modify/delete/replace), attribute/name/with/properties fields, Tapir naming and unit conventions, and the rule that attribute-reference fields take a name rather than an id. The port parameter is never mentioned, leaving one documented gap.

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 plus an enumerated resource set (layers, composites, fills, surfaces, pen tables, profiles, building materials) and distinguishes itself from list_attributes by being the mutation counterpart. An agent can tell exactly what object family this tool operates on 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 operating defaults (DRY-RUN BY DEFAULT; pass dry_run=false to commit), a discovery path for the payload format (changes=[] lists every type's fields), the read-side alternative for current values (list_attributes(details=true) in the same form), and the Teamwork precondition (reserve the type's set via reserve_elements). When-to-use and the alternatives are both named rather than inferred.

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

Deploy Server