Archicad-MCP

by alesdev88

Overview Schema Source Related Servers Discussions Admin

Python

Local

Apply favorites

apply_favorites

Destructive

Instructions

Make existing elements match a favourite (Tapir), the office standard in one step. Without favorite it changes nothing and lists the favourites that fit the given elements' types (all types when no guids either). DRY-RUN BY DEFAULT: lists the elements it would change, skips with the reason those of another type than the favourite's or that Archicad would refuse (another view's, hidden or locked layer, not reserved in Teamwork, inside a hotlinked module, locked), and warns what the favourite takes over besides materials and pens: a wall's height, top link, reference line and structure, a column's height and top link, a door's or window's library part, size and sill, and every element's layer; for other types it says what was not checked live. Plan positions stay. Stairs, railings and curtain walls get only their own settings, not their parts'. keep (default ["id"]) writes each element's own Element ID back after the favourite, and "layer" its own layer; use modify_elements for heights and sizes. settings, classifications, categories and properties choose what the favourite applies; classifications are added per system and property values overwrite. Pass dry_run=false to apply: returns applied, changed (per element current and new of every field the favourite changed, read back), unchanged, failed grouped by reason, and restored for keep. Classifications, categories and properties are not read back. to_defaults=true with no guids sets the favourite's tool defaults instead.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`keep`	No
`port`	No
`guids`	No
`dry_run`	No
`favorite`	No
`settings`	No
`categories`	No
`properties`	No
`to_defaults`	No
`classifications`	No

Output Schema

TableJSON 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?

Beyond the destructiveHint annotation, the description discloses dry-run-by-default behavior, what gets skipped and why, which fields the favorite takes over, and that classifications/categories/properties are not read back. It also explains keep behavior and restored results.

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?

The purpose and dry-run warning are front-loaded and nearly every sentence adds operational value for a complex destructive tool. The description is still a dense single paragraph with long semicolon-heavy sentences, making it harder to scan than it could be.

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?

Despite having an output schema, the description explains the important return groups (applied, changed, unchanged, failed, restored) and what is not read back. For a 10-parameter destructive tool, the behavioral and contextual coverage is strong.

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 description coverage, the description carries most parameter meaning: dry_run, favorite, guids, keep, settings, classifications, categories, properties, and to_defaults are all explained. However, the port parameter is never mentioned, and the stated keep default ['id'] differs from the schema default null.

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 states a specific verb and resource: 'Make existing elements match a favourite (Tapir), the office standard in one step.' It also distinguishes this tool from the sibling modify_elements by explicitly routing height and size changes there.

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?

It explains key usage modes directly: without a favorite the tool lists matching favorites, dry-run is the default, and dry_run=false applies changes. It also names modify_elements as the alternative for heights and sizes and explains the to_defaults mode.

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

Deploy Server