Skip to main content
Glama
Archicad-MCP

Archicad-MCP

by alesdev88

Reserve Teamwork elements and sets

reserve_elements

Reserve elements or non-element object sets in a Teamwork project to gain edit access. Dry-run first to see who holds them, then confirm to avoid blocked edits.

Instructions

Reserve elements, and non-element object sets, in a Teamwork project so you can edit them (Tapir). CONFIRM-GATED: without confirm=true it only reports what it can learn without touching the server: not_found, already_mine, and would_attempt. On Tapir 1.7.3 it also reads who holds an element (held_by_others, with the user's name); on older Tapir that is only learned by attempting, because Archicad exposes no read for it. With confirm=true returns reserved, reserved_by_others (with the user's name), already_mine, not_found, and indirectly_reserved: elements Archicad pulled into your workspace that you did not ask for, such as a door's wall. object_sets reserves what attribute, property and classification edits need: an attribute type (Layers, Composites, Fills, Lines, PenTables, Profiles, BuildingMaterials, Surfaces, ZoneCategories), Properties or Classifications, or any Archicad set name (Favorites, ProjectInfo, ...); needs Tapir 1.7.1. Each set's entry says status, held_by and outcome (would_reserve, already_mine, held_by_others, reserved, failed); for sets the dry run does know who holds them. A reservation is visible to every teammate and blocks their edits until released.

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": "reserve_elements"
  }
}

Input Schema

NameRequiredDescriptionDefault
portNo
guidsNo
confirmNo
object_setsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.10.0
    • addedInput schema / properties / guids / anyOf
      Added value: +[
      +  {
      +    "items": {
      +      "type": "string"
      +    },
      +    "type": "array"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • addedInput schema / properties / guids / default
      Added value: +null
    • removedInput schema / properties / guids / items
      Removed value: -{
      -  "type": "string"
      -}
    • removedInput schema / properties / guids / type
      Removed value: -"array"
    • addedInput schema / properties / object_sets
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null
      +}
    • removedInput schema / required
      Removed value: -[
      -  "guids"
      -]
  2. Addedv0.5.1

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses the confirm-gate contract, the exact outcome keys per mode, version-dependent behaviour (held_by_others readable on Tapir 1.7.3, attempt-only on older), Tapir 1.7.1 requirement for sets, and the real-world effect that a reservation is visible to teammates and blocks their edits until released.

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 core action and the CONFIRM-GATED contract are front-loaded in the first two clauses, and the long middle sentence is dense but information-bearing. It is wordy (multiple semicolon-chained asides about Tapir versions) and could be tightened without losing meaning.

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?

An output schema exists, yet the description still enumerates return keys usefully, and it covers the version and set-entry semantics an agent needs to interpret results. The only meaningful gap given the tool's complexity is the unmentioned port parameter and the lack of any note about Teamwork/server connectivity requirements.

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 0%, so the description carries the burden and mostly does: confirm is explained in detail, object_sets is explained with accepted value families and per-entry fields, and guids is implied by 'elements'. The port parameter is never mentioned, leaving one of four parameters undocumented anywhere.

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 and resource ('Reserve elements, and non-element object sets, in a Teamwork project') and explains the intent ('so you can edit them'). The reservation semantics make it clearly distinct from create_elements, modify_elements and release_elements among the siblings.

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 explicit when-to-use guidance for its two modes: without confirm=true it is a safe dry run, with confirm=true it actually reserves. It does not name the natural alternative (release_elements) or state prerequisites such as needing an active Teamwork connection, so it stops short of full routing guidance.

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