Skip to main content
Glama
davidharutyunyan

Archicad MCP Connector

Modify classification items

modify_classification_items
DestructiveIdempotent

Update the ID, name, or description of multiple Archicad classification items in one undoable step, with per-item results for each change.

Instructions

Changes the ID, name and/or description of classification items in one undo step. Returns {results: [{guid, id, name?, description?} | {error}]}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYes
systemNoSystem in which item IDs are looked up (needed when an ID exists in several systems)
undoNameNoName of the undo step shown in Archicad

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the baseline is covered. The description adds meaningful behavior beyond annotations by stating the operation is grouped into one undo step and returns per-item success or error objects, which hints at bulk partial-failure behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two compact sentences with no wasted wording. The core behavior is front-loaded, followed by the return shape, which is efficient and directly useful.

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?

There is no output schema, but the description explicitly states the return structure with results, guid, id, optional name/description, and error objects. Combined with annotations covering safety and undo behavior, this is close to complete, though it does not cover prerequisites such as ensuring the target classification items already exist.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is moderate at 67%, and the schema already documents the target fields id, name, and description. The description restates those fields but does not explain the top-level system parameter, the undoName parameter, or the accepted item identifier forms, so it adds only limited semantic value.

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 uses a specific verb and resource: it changes the ID, name, and/or description of classification items. This clearly separates it from create/delete classification item siblings and states the exact editable fields.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description says what the tool changes but gives no explicit guidance on when to use it instead of related siblings like create_classification_items, delete_classification_items, or modify_classification_system. The only contextual cue is 'one undo step', which is behavioral rather than usage guidance.

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