Archicad-MCP

Overview Schema Source Related Servers Discussions Admin

Apply favorites

apply_favorites

Destructive

Applies an Archicad favorite (Tapir) to selected elements, with a dry-run listing changes and skipped elements before you confirm.

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. From Tapir 1.7.3 Tapir keeps them itself, and keep also takes "width", "height" and "sillHeight" (doors, windows), "referenceLineLocation" (walls) and "height", "topOffset" and "relativeTopStory" (walls, columns; keep the three together), so e.g. only the library part or the wall type changes; on older Tapir use modify_elements for heights and sizes. On Tapir 1.7.3 the dry run also names the favourite's library part, marker and folder (favorite_settings), and on a Tapir newer than 1.8.0 and Archicad 29 its layer and Element ID as well. 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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "apply_favorites"
  }
}

Input 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

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.10.0Oct 22, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only say readOnlyHint=false and destructiveHint=true; the description adds substantial context beyond them: dry-run-by-default, which elements are skipped and why (other view, hidden/locked layer, unreserved in Teamwork, hotlinked module, locked), exactly what gets overwritten (wall height/top link/reference line/structure, door/window library part/size/sill, layer), that plan positions stay, and version-dependent differences up to Tapir 1.8.0 / Archicad 29. This is far richer than the annotations and consistently aligns with them (mutating, destructive).

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

Conciseness3/5

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

Nearly every clause carries information, but it is delivered as one long run-on block with no paragraph or bullet structure, so the critical dry-run-by-default and apply instructions compete with version minutiae. Front-loading is decent (the purpose and the no-favourite branch come first), but the scanability cost is real for a 10-parameter tool.

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?

For a complex, version-sensitive mutation tool this covers dry-run vs apply, skip reasons, overwrite warnings, version gates, keep semantics, what the apply result contains, and the limitations of read-back (classifications/categories/properties not read back). The only meaningful hole is the undocumented `port` parameter; return values are partly described even though an output schema exists.

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 description coverage is 0%, so the description must carry the load, and it does for keep (enumerating "layer", "width", "height", "sillHeight", "referenceLineLocation", "topOffset", "relativeTopStory" with version constraints), dry_run, favorite, guids, to_defaults, settings, classifications, categories and properties. Gaps: the `port` parameter is never mentioned, and the description's stated keep default (["id"]) differs from the schema default of 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 opening states a specific verb and resource: making existing elements match a favourite (Tapir), the office standard, in one step. It is immediately distinguishable from create_elements, modify_elements and edit_attributes, and it names the scope (element types, favourite settings).

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 explicitly covers the no-favourite case (lists matching favourites instead of changing anything), states the dry-run default, and says to pass dry_run=false to apply — i.e. the conditions that select each mode. It also routes older-Tapir users to modify_elements for heights and sizes, a real alternative. No explicit 'do not use this when...' exclusion is given, so it is a strong 4 rather than 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