Skip to main content
Glama
davidharutyunyan

Archicad MCP Connector

Find elements

find_elements
Read-onlyIdempotent

Find project elements using combinable filters like type, story, layer, or region, and get a paginated list with GUIDs, IDs, and layer data. All filters AND-combine.

Instructions

Finds elements in the open project with combinable filters (type, story, layer, renovation status, visibility/editability, selection, Element ID pattern, library part name, group, hotlink, lock state, spatial region) and returns a paginated list [{guid, type, storyIndex, layer: {index, name}, elementId, boundingBox?, libraryPart?}] plus total/hasMore. All filters are optional and AND-combined; with no filter every main element is listed. Use the GUIDs with get_element_details, get_element_quantities, modify_elements, set_selection etc. For counts only use get_element_counts. Coordinates in meters.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoReturn at most this many matches. Default 500
typesNoOnly these element types. Default: every main type (sub-elements such as curtain wall panels, stair treads or railing posts are only included when listed here or with includeSubelements=true)
layersNoOnly elements on these layers (layer names are localized, e.g. Russian — take them from get_attributes or earlier results)
lockedNotrue = only locked elements, false = only unlocked ones
offsetNoSkip this many matches (pagination). Default 0
regionNoSpatial filter on the element's 3D bounding box (2D elements have a flat box at z=0). Give any subset of the limits; e.g. {xMin:0, yMin:0, xMax:10, yMax:8} for a plan rectangle
filtersNoArchicad visibility/editability filters; an element must pass ALL of them
groupedNotrue = only grouped elements, false = only ungrouped ones
storiesNoOnly elements whose home story is one of these
elementIdNoElement ID (the ID shown in the Info Box) wildcard pattern, case-insensitive: '*' = any characters, '?' = one character; without wildcards the ID must match exactly. Examples: 'W-*', '*01', 'D-0??'
groupGuidNoOnly members of this group (nested groups included); groupGuid comes from get_element_details
inHotlinkNotrue = only elements that come from a hotlinked module, false = only own elements
storyIndexNoOnly elements whose HOME story is this one (index or localized name, see get_stories)
hotlinkGuidNoOnly elements belonging to this hotlink instance
libraryPartNoLibrary part name contains this text (case-insensitive). Applies to objects, lamps, windows, doors, skylights and zone stamps; other types are excluded. Names are localized
excludeTypesNoSkip these element types
selectedOnlyNoOnly elements in the current selection
withinElementsNoRestrict the search to these elements (e.g. to refine an earlier result)
includeElementIdNoInclude the Element ID string. Default true
renovationStatusNoOnly elements with one of these renovation statuses
includeBoundingBoxNoAdd boundingBox {xMin,yMin,zMin,xMax,yMax,zMax} (m, z absolute) to each element. Default false
includeLibraryPartNoAdd the library part name of objects/lamps/doors/windows/skylights/zones. Default false
includeSubelementsNoAlso list sub-elements (curtain wall/stair/railing parts, beam/column segments) when 'types' is not given, and the hidden GDL part Objects/Lamps owned by curtain walls, railings and stairs (skipped otherwise, counted in stats.ownedPartObjectsSkipped). Default false

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavior beyond that: all filters are AND-combined, no-filter lists every main element, results are paginated with total/hasMore, and coordinates are absolute meters. It does not discuss result ordering or snapshot semantics, keeping it short of a 5.

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?

Front-loaded with the verb, scope, filter set and return shape, then routing guidance. The long parenthetical filter list is information-dense but does consume space; still, every clause maps to a real capability rather than padding.

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?

For a 23-parameter read tool with no output schema, the description covers the essentials: filter combinability, no-filter default, pagination fields, coordinate units, and downstream usage of GUIDs. Nothing an agent needs to call it correctly is missing.

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 100%, so the baseline is 3 and the schema carries the per-filter detail. The description still adds global semantics not obvious from individual fields: all filters are optional and AND-combined, and units are meters. It does not add syntax beyond what the schema already documents for specific params.

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 ('Finds elements in the open project'), enumerates the combinable filter categories, and describes the returned list shape. It also explicitly separates itself from get_element_counts, so an agent can pick it apart from siblings without reading the schema.

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?

Gives explicit routing: 'For counts only use get_element_counts' and 'Use the GUIDs with get_element_details, get_element_quantities, modify_elements, set_selection etc.' It also states the fallback behavior with no filters, so the agent knows when a bare call is appropriate.

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

Deploy Server

Other Tools