Skip to main content
Glama
Sign In
Archicad-MCP

Archicad-MCP

by alesdev88
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Read element data

get_element_data
Read-only

Read type, layer, and requested property values for specific Archicad elements, including classification, GDL, marker, and IFC data, and report any values that cannot be read.

Instructions

Read type, layer and requested values of the given elements. properties takes addresses: a property ('Group/Name', a built-in name or a property GUID, as search_definitions gives it); 'classification:' (the item ID); 'gdl:' (a GDL parameter of an object, lamp, door, window or other library part element); 'marker:' (a door's or window's marker parameter, Tapir 1.7.1); 'ifc:.' (an IFC property). Lengths in metres, angles in radians, attribute-typed GDL parameters as attribute indexes. 'gdl:', 'marker:', 'ifc:' and 'classification:' read every value, with display names in 'labels'; at most 20 elements per wildcard call. What could not be read for an element (a kind, a property or the layer) is named in its 'unreadable' with the reason; a property the official API refuses (on 2D elements and sub-elements, and definitions it does not support) is read through Tapir 2.0.0 or newer. include_classifications adds every system's item GUID.

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": {
      "guids": "<guids>"
    },
    "name": "get_element_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
portNo
guidsYes
propertiesNo
include_classificationsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior5/5

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

Beyond the readOnly/destructive annotations, the description discloses units (metres, radians), how attribute-typed GDL parameters are returned (attribute indexes), the wildcard semantics with 'labels' display names, a hard limit of 20 elements per wildcard call, how partial failures surface in 'unreadable' with reasons, and the Tapir 2.0.0 fallback used when the official API refuses a property. This is exactly the operational context annotations cannot carry.

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?

Purpose is front-loaded in the first clause and virtually every sentence carries non-redundant specification. The paragraph is a dense semicolon chain, however, and the parameter-address grammar would scan far better as a list than as one continuous block.

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?

An output schema exists, so return shapes need not be spelled out, yet the description still usefully names the 'labels' and 'unreadable' fields a caller will see. Combined with the unit and limit disclosures, the only real gap is the unexplained 'port' parameter on a tool that otherwise documents its surface in depth.

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 0%, so the description has to carry the load, and it does so thoroughly for 'properties' by enumerating all six address forms with concrete syntax and tying it to search_definitions; it also explains 'include_classifications' (adds every system's item GUID). 'port' is never explained, leaving one of four parameters undocumented in both schema and description.

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?

The opening sentence names a specific verb and resource ('Read type, layer and requested values of the given elements') and scopes it to values the caller explicitly requests, which separates it from a broad property search. It does not name a sibling alternative, so the distinction from tools like find_elements or search_definitions must be inferred from the property-address syntax discussion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied rather than stated: the caller learns that property addresses come 'as search_definitions gives it', which points at a companion tool for discovery. There is no explicit when-to-use/when-not-to-use statement, and no mention that GUIDs must be obtained elsewhere first (e.g. via find_elements), so a reader must assemble the workflow.

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