Skip to main content
Glama
davidharutyunyan

Archicad MCP Connector

Count elements

get_element_counts
Read-onlyIdempotent

Count Archicad elements by type, story, layer, or renovation status using filters to get a quick project overview before detailed queries.

Instructions

Counts elements per type — optionally also per story, per layer and per renovation status — with the same filters as find_elements. Output: {total, byType: {Wall: 12, ...}, byStory?: [{storyIndex, storyName, total, byType}], byLayer?: [{layer, total, byType}] (largest first), byRenovationStatus?}. Good first call to get an overview of a project.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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
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
groupByNoExtra breakdowns; per-type counts are always returned
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)
renovationStatusNoOnly elements with one of these renovation statuses
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.2/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 safety is covered. The description adds real behavioral value: the exact return shape, the optional group breakdowns, and the 'largest first' ordering of byLayer. It stops short of noting limits on cost or result size for a 19-param query.

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?

Front-loads the core purpose, then the optional dimensions, then the output shape, then the usage hint. Every sentence carries information, and the output sketch earns its space because there is no output schema.

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?

With no output schema, the description usefully sketches the return object including optional grouped arrays, and defers filter detail to find_elements. It is largely complete, though it doesn't mention cost/performance or result-size caveats for such a broad counting query.

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?

Schema description coverage is 100%, so all 19 parameters are already documented in the schema. The description only adds that filters behave 'the same as find_elements' and which groupBy values produce which output keys; it adds little per-parameter meaning beyond the schema.

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+resource ('Counts elements per type') with optional breakdowns, and explicitly ties the filter semantics to the sibling find_elements, so an agent can distinguish counting from listing without opening either schema.

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 clear positive guidance ('Good first call to get an overview of a project') and points at find_elements as the filter reference, but never states when NOT to use it or when a full listing/counting alternative is preferred.

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