Skip to main content
Glama
davidharutyunyan

Archicad MCP Connector

by davidharutyunyan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Find property definitions

get_property_ids_by_name
Read-onlyIdempotent

Resolve Archicad property names to GUIDs and definitions, or search the property catalog by name, group, type, or elements.

Instructions

Resolves property names to GUIDs and definitions, or searches the property catalog. Built-in properties have stable non-localized names (e.g. 'General_ElementID', 'General_Width', 'Zone_CalculatedArea', 'Component_Thickness'); user-defined ones are 'Group/Name' with localized names (e.g. 'ИНФОРМАЦИЯ О ПРОДУКТЕ/Модель'). Pass properties to resolve specific names, or browse with search (case-insensitive substring of built-in name, group or name, any language), group, propertyType and/or elements (only the properties those elements have — e.g. which user-defined properties their classification makes available). Returns [{guid, builtInName?, kind: 'BuiltIn'|'UserDefined', group, name, type, editable, description?, enumValues?, defaultValue?}]. The GUIDs work in every tool taking property references. Works without the Claude Connector add-on.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
groupNoOnly properties of this (localized) group, e.g. 'ИНФОРМАЦИЯ О ПРОДУКТЕ' or 'Компоненты'
limitNoReturn at most this many results (default 500)
offsetNoSkip this many results
searchNoSubstring to search in built-in names, group names and property names (e.g. 'Area', 'Площадь', 'Thickness')
elementsNoBrowse only properties available for these elements (see elementMatch)
propertiesNoNames/GUIDs to resolve (output in input order, with {input, error} for misses)
elementMatchNoWith elements: 'any' (default) = available for at least one of them, 'all' = available for every one of them
propertyTypeNoBrowse only built-in or only user-defined properties
includeDetailsNoInclude description, enum values and default value (default: true for `properties`, false for browsing)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial extra context: exact return shape, output ordering with {input, error} for misses, the fact GUIDs are usable in every property-referencing tool, and that it works without the Connector add-on.

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?

Dense but front-loaded, with the resolve-vs-browse decision stated before the naming details and return shape. Long, though every clause (naming conventions, return fields, connector note) carries information.

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 no output schema, the description documents the return array structure and error entries, and covers naming, mode selection, and scope. Nothing essential for correct invocation 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 coverage is 100% (baseline 3), but the description genuinely adds semantics: built-in vs localized 'Group/Name' naming, case-insensitive multi-language substring behavior for `search`, and the 'only the properties those elements have' meaning of `elements`. This exceeds what the schema alone conveys.

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 (resolves/searches) and resource (property names to GUIDs/definitions), and distinguishes itself from sibling property tools like get_property_definitions by framing itself as the name-resolution/catalog-search entry point.

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?

Explicitly splits usage into two modes: 'Pass `properties` to resolve specific names, or browse with `search`...'. The schema even routes users back to this tool to find names. It lacks an explicit contrast with the sibling get_property_definitions, which keeps it from a 5.

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