Skip to main content
Glama
Archicad-MCP

Archicad-MCP

by alesdev88

Find elements by criteria

find_elements
Read-only

Find Archicad elements by element type and property comparisons in OR-combined groups; returns GUIDs and counts with coverage warnings so you can verify query completeness.

Instructions

Find elements matching criteria groups. Groups combine with OR; inside a group the comparisons combine with logical_operator 'and' (default) or 'or'. Each group may restrict element types (is / is_not) and lists comparisons of {property, operator, value}; the schema enumerates the element types and the 22 operators, and each field documents its values and units. Call search_definitions to find a property's exact address. An element with no usable value matches no binary operator. Returns GUIDs, counts, how many elements had properties read, and 'coverage' ('whole-plan' with Tapir, 'model-elements-only' without: then 2D elements are invisible and 0 is not proof of absence). 'not_read' lists the properties nothing could read on some elements, with the reason (the official API refuses them, and Tapir 2.0.0 or newer was not there or did not answer); such a pair matches no operator, so check it before trusting a count. Property comparisons read values in the server (no API filters by property); a read spanning more than the element ceiling is refused, so narrow with element_types, story or classification first.

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": {
      "groups": "<groups>"
    },
    "name": "find_elements"
  }
}

Input Schema

NameRequiredDescriptionDefault
portNo
groupsYes
selection_onlyNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.1
    • changedInput schema / properties / groups / items / properties / element_types / description
      Previous value: -"Archicad element type names to restrict this group to. Omit for every type; 'all' says so explicitly."New value: +"Archicad element type names to restrict this group to. Omit for every type; 'all' says so explicitly. 'Unknown' is an element that exists but has no type in either API, such as a native MEP route, segment or node; it is matched over the whole plan, so it is slower."
  2. Addedv0.5.1

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint/destructiveHint annotations: it discloses that property filtering happens server-side in the server (no API-side filter), that over-ceiling reads are refused, and that coverage degrades to 'model-elements-only' without Tapir so 2D elements are invisible and a 0 count is not proof of absence. The 'not_read' explanation with failure reasons is exactly the sort of behavioral caveat an agent needs before trusting a result.

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

Conciseness5/5

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

Dense but front-loaded: matching semantics come first, then prerequisites, then result interpretation and failure modes. Every sentence carries information an agent needs, and the long parentheticals are the only minor cost.

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 a rich nested schema and an output schema, the description still adds the semantics that matter: server-side evaluation, element ceiling, coverage modes, and the not_read trap for trusting counts. Only the unexplained 'port' and 'selection_only' parameters keep it from being airtight, and that is a small gap for a read-only query tool.

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?

Top-level parameters have no schema descriptions (reported 0% coverage), so the description has to compensate: it explains group-level OR vs. the group's logical_operator, is/is_not element-type restriction, and points to the schema for the 22 operators and field units. It never mentions the 'port' or 'selection_only' parameters, leaving those undocumented in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Find elements matching criteria groups,' and then explains the group/comparison structure so the agent knows exactly what query shape it accepts. It does not explicitly distinguish itself from siblings like get_element_data or find_collisions, so it falls short of full sibling differentiation.

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 concrete operational guidance: call search_definitions first to resolve a property address, and narrow with element_types, story or classification when a read would exceed the element ceiling. It provides conditions for use but no explicit statement of when another tool is the better choice.

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