Skip to main content
Glama
davidharutyunyan

Archicad MCP Connector

Duplicate attributes

duplicate_attributes

Copies existing Archicad attributes of any type except Pen/Font to a new name, optionally changing fields, with collision handling and one undo step.

Instructions

Copies existing attributes of any type except Pen/Font (e.g. a pen set, a symbol fill, an MEP system, a model view option, a dimension standard, an operation profile, a composite) under a new name, optionally changing fields on the copy: each item is {source, name, folder?, ...fields of that type as in the create_* tools / modify_attributes}. 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
typeYesAttribute type to copy (every type except Pen and Font)
ifExistsNoName collision handling for all items: 'error' (default), 'skip' (reuse the existing attribute), 'update' (apply the fields to it)
attributesYes

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 declare write/non-destructive/non-idempotent; the description adds substantial behavior beyond them: atomic undo grouping, per-item failure isolation ('one failing item does not stop the others'), the three-way created/existed/error result shape, input-order preservation, and the localization caveat for Russian Archicad names. This is exactly the extra context annotations cannot carry.

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?

Dense but front-loaded: purpose first, then item shape, then return contract and the localization caveat. Every clause carries information, though the single long opening sentence with four parenthetical examples is heavier than necessary.

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 batch copy tool with no output schema, the description supplies the return contract, failure semantics, undo behavior, and a lookup prerequisite, so nothing an agent needs to call 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?

Schema coverage is 67% and the description compensates meaningfully: it explains the item shape ({source, name, folder?, ...type-specific fields}) and that extra fields follow the create_*/modify_attributes conventions. IfExists and the source name/index/guid union are left to the schema, so it does not fully close the gap, but it adds real semantics.

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?

States a specific verb (copies) plus the exact resource (existing attributes of any type) and explicitly excludes Pen/Font. It enumerates concrete examples of copyable types and names the related siblings (create_*/modify_attributes) that supply the field semantics, so an agent can separate it from create_* and modify_attributes without opening a 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?

Gives actionable context: look existing attributes up with get_attributes first, and use create_*/modify_attributes field conventions for the extra fields. It does not explicitly state when to prefer create_* over this tool, so it stops short of full when/when-not routing, but the prerequisites and referenced alternatives are clear.

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