Skip to main content
Glama
Archicad-MCP

Archicad-MCP

by alesdev88

Show elements in Archicad

show_elements

Displays specified Archicad elements by opening their story or view, then selecting, highlighting, and zooming to them; lists any elements that remain in other stories or views.

Instructions

Show elements to the user in Archicad: open the story or view that holds them (a section, elevation, detail, worksheet or layout when they are not on the floor plan), select them, highlight them and zoom to them. When they span several stories or views, the one holding the most is shown and the rest are listed (on_other_stories, in_other_views) for another call; with the 3D window in front, floor plan elements are shown there across every story. selected counts what Archicad really selected (not_selectable lists the rest). highlight=false removes any earlier highlight; guids=[] removes the highlight and, with select, the selection, and changes nothing else. in_3d=true (a Tapir newer than 1.8.0) opens the 3D window on just the floor plan's elements among them, as Show Selection in 3D does, so they always become the selection; there guids=[] shows everything, as Show All in 3D does. Changes only what is on screen, never the project.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "guids": "<guids>"
    },
    "name": "show_elements"
  }
}

Input Schema

NameRequiredDescriptionDefault
portNo
zoomNo
guidsYes
in_3dNo
selectNo
highlightNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.0
    • addedInput schema / properties / in_3d
      Added value: +{
      +  "default": false,
      +  "type": "boolean"
      +}
  2. Addedv0.10.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations only supply readOnlyHint=false and destructiveHint=false, so the description carries most of the burden and does so well: it discloses cross-story fallback behavior, that only screen state changes and never the project, and what selected/not_selectable report. It is consistent with the annotations, though the precise scope of what 'on screen' state persists is not spelled out.

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?

The purpose is front-loaded, but the remainder is a single sprawling sentence chain with nested parentheticals and semicolons that is hard to parse. The dense information is valuable, yet it would be far clearer as separate sentences or a short conditional list.

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 6-parameter tool with an output schema, the description covers nearly all behavior an agent needs: view resolution, selection/highlight effects, 3D-window mode, and the guarantee that the project is unmodified. Only the purpose of 'port' and the semantics of the 'zoom' toggle are missing.

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?

With 0% schema description coverage the description must compensate, and it does thoroughly for guids, select, highlight and in_3d, including non-obvious edge cases (guids=[] clears highlight/selection; in_3d=true makes them the selection). The 'port' parameter is never explained at all, and 'zoom' is only mentioned as an action in the opening sentence rather than as the toggle it actually is.

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 first clause names the exact action set (open story/view, select, highlight, zoom) on a specific resource (elements) in Archicad. It is clearly distinct from sibling operations like clear_selection, get_selection and find_elements, which read or change selection state without navigating to and revealing elements.

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

Usage Guidelines3/5

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

Usage is implied by 'Show elements to the user' and by the note that elements on other stories/views are listed 'for another call', which hints at a follow-up workflow. However, there is no explicit when-to-use versus clear_selection or find_elements, and no prerequisites (e.g. whether elements must be reserved or visible) are stated.

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