Skip to main content
Glama
davidharutyunyan

Archicad MCP Connector

Get property values

get_property_values
Read-onlyIdempotent

Read built-in and user-defined property values of many elements or element tool defaults at once, returned as one table.

Instructions

Reads property values (built-in and user-defined) of many elements — and/or of element TOOL DEFAULTS — as one table: {properties: [{guid, name, group, type}], results: [{guid | elementType, values: [cell per property, same order]} | {guid, error}]}. Each cell is {value, display?, isDefault?} (display = Archicad's formatted text incl. units, only when it differs from value; isDefault only for user-defined properties: true = the element has no own value and shows the default/expression) or {status: 'NotAvailable' (property not available for this element/classification) | 'NotEvaluated' | 'Undefined' (value set to Undefined) | 'Empty'}. Units: lengths m, areas m², volumes m³, angles DEGREES; option sets by display value. Without properties: every property available for the targets (scope UserDefined by default; BuiltIn/All can be hundreds). Address built-ins language-independently with {builtIn: 'General_ElementID'} etc.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNoUsed only without properties: which properties to return (default UserDefined)
elementsNoElements to read
propertiesNoProperties to read (columns). Omit = all available (see scope)
includeDisplayNoAdd Archicad's formatted display text (default true)
elementDefaultsNoRead the tool default settings of these element types

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive behavior, but the description adds substantial behavioral detail: the exact result table shape, per-cell value/display/isDefault semantics, status states like NotAvailable and Undefined, unit conventions, and default behavior when properties are omitted. This is rich transparency beyond the structured annotations.

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?

The description is dense but front-loaded, beginning with the core read operation and then compactly covering output shape, cell semantics, units, and parameter omission behavior. Every clause carries information needed to interpret or invoke the tool correctly, with no filler.

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?

There is no output schema, but the description fully compensates by defining the returned table, row shapes, cell value formats, statuses, and unit conventions. Combined with annotations covering safety and schema coverage at 100%, an agent has enough context to call and interpret this tool correctly.

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%, so the schema already defines each parameter well. The description still adds cross-parameter meaning: scope is used only when properties are omitted, omitting properties returns all available properties, built-in properties should be addressed language-independently, and display text is only added when it differs from the raw value.

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: reads property values of many elements and/or element tool defaults as one table. It also distinguishes built-in vs user-defined properties and scopes the operation clearly enough that an agent can separate it from get_property_definitions and set_property_values.

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?

Provides clear invocation context: omit properties to get all available properties, scope defaults to UserDefined, BuiltIn/All can be large, and names get_property_definitions as the way to find property names. It does not explicitly contrast this tool with sibling readers such as get_attribute_property_values or get_component_property_values, so it falls short of full when/when-not guidance.

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