Skip to main content
Glama
davidharutyunyan

Archicad MCP Connector

Delete attribute folders

delete_attribute_folders
Destructive

Deletes attribute folders and all deletable attributes within them, preserving in-use or built-in attributes. Irreversible; inspect first.

Instructions

Deletes attribute folders AND every deletable attribute inside them (attributes in use or built-in ones are kept). Irreversible through this connector — inspect with get_attribute_folders first, and move attributes you want to keep out with move_attributes_to_folder. Output: {results: [{folder, ok: true} | {folder, error}]}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
foldersYesFolders: path ['A','B'] / 'A/B', {guid}, or {attributeType, path}
attributeTypeNoAttribute type of all folders (or per folder)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare destructive, non-idempotent, non-read-only behavior. The description adds the concrete blast radius (deletable attributes inside folders are also removed), the safety carve-out (in-use/built-in attributes are kept), and irreversibility — behavior an agent cannot infer from the flags alone.

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?

Three tightly-packed sentences, front-loaded with the verb and cascade scope, then the safety warning, then the output shape. Dense but nothing wasted; the em-dashes and parentheticals are slightly compressed but readable.

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?

No output schema exists, and the description supplies the return shape ({results: [{folder, ok}|{folder, error}]}), the cascade semantics, the preservation rule, and the pre-flight workflow. An agent has everything needed to call this destructive tool safely.

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 100% and the folders parameter has rich nested descriptions (path array, 'A/B' string, {guid}, {attributeType, path}). The description adds nothing about parameter syntax or formats, so the baseline of 3 is appropriate given the schema does the heavy lifting.

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 (Deletes) and resource (attribute folders) plus the crucial cascade scope: every deletable attribute inside them. This distinguishes it cleanly from delete_attributes, which deletes individual attributes, and from delete_project_info_fields.

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?

Explicitly prescribes the safe workflow: inspect with get_attribute_folders first, and move attributes you want to keep out with move_attributes_to_folder. Both an alternative tool and a when-to-use condition are named.

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