Skip to main content
Glama
davidharutyunyan

Archicad MCP Connector

Create layers

create_layers

Creates visible, unlocked Archicad layers in one undo step and returns their GUIDs, so elements can then be placed on them via the layer field of create or modify tools.

Instructions

Creates layers (visible and unlocked unless stated; intersection group 1). Then place elements on them with the 'layer' field of any create_*/modify_elements tool. Runs in one undo step. Returns {results: [{index, name, guid, created: true} | {..., existed: true} | {error}]} in input order; one failing item does not stop the others. Names are localized (Russian Archicad): look existing attributes up with get_attributes first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
layersYes
ifExistsNoName collision handling for all items: 'error' (default), 'skip' (reuse the existing attribute), 'update' (apply the fields to it)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only cover the safety profile; the description goes well beyond by disclosing defaults (visible/unlocked, intersection group 1), the single-undo-step behavior, partial-failure semantics ('one failing item does not stop the others'), and the localization caveat for Russian Archicad. The full return shape is spelled out, which is essential since no output schema exists.

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?

Sentences are dense but front-loaded: the core action and defaults come first, then workflow, then return/failure behavior, then the localization note. Every sentence carries information, though the return-shape sentence is unusually long.

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 creation tool with no output schema and only 2 top-level parameters, the description covers purpose, defaults, cross-tool usage, partial-failure handling, and return structure. Nothing an agent needs to invoke it correctly is missing.

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 ~50% schema description coverage, the description compensates by surfacing defaults not stated in the schema (intersection group 1, visible/unlocked) and the ifExists/existed:true semantics. It does not explain basedOn, wireframe, or folder, but the schema documents those inline, so the description adds meaningful value above the schema.

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+resource ('Creates layers') and immediately qualifies scope with defaults (visible/unlocked, intersection group 1). It distinguishes this attribute-creation tool from siblings like create_layer_combinations and create_attributes by naming the exact follow-up tools (create_*/modify_elements).

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 states the workflow context ('Then place elements on them with the layer field of any create_*/modify_elements tool') and a prerequisite ('look existing attributes up with get_attributes first'). It lacks an explicit when-not-to-use or a named alternative for attribute creation, so it falls short of a 5.

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

Deploy Server

Other Tools