Skip to main content
Glama

Get element

get_element
Read-onlyIdempotent

One object by GlobalId - element, storey, space, opening, type object, IfcGrid (axes), IfcAnnotation (annotation), IfcStructuralItem (representation: its topology). Sections by include, named as in IFC: attributes, psets (effective values with from: type|occurrence; a predefined Set.Prop another class or set shares: Set[Class].Prop, several of one class Set[Class#n].Prop in entity id order), qtos, relations (inverse attributes: IsTypedBy, ContainedInStructure, Decomposes, HasOpenings, FillsVoids ...), material (hatching as fill_styles; dash pattern, line width, PatternStart not read), representation (RepresentationType; body_gap there: a body not stored, not no body; a type object: RepresentationMaps with mapped_by, a Body map is what like places; prism at a tessellated segment, beam, column: length, axis, sections measured, diameter only an assumption), placement; and frame (own axes s/t/h), faces, snap_points; mesh (points + faces as create_elements.mesh takes them, face_colours from a colour map; move_points true: each point is a from of edit_mesh move_points; n_faces_not_polygonal > 0: curved faces left out; capped: no lists; defects of a file mesh (closed, kinds, examples; world m) - a boundary_edge point is an at for edit_mesh close_hole; measured bodies: defects_not_read); appearance (an element: colour, style with transparency 0..1, layers); terrain (an IfcGeographicElement moddl derives: its entries with ids, current or stale). The range values in frame and faces (s_range, range) are metres from the origin of their block along its axis (s/t/h or dir), not world coordinates. IfcProject reads attributes, psets, relations; site, building, storey and space those and qtos, placement (space also outline); a group or other root attributes, psets, qtos, relations; opening, port, system and zone fewer: the rest answers not_read or is refused; analysis model loads and supports in SI, results counted only. Read-only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_element"
  }
}

Input Schema

NameRequiredDescriptionDefault
guidNoGlobalId of the object; in a catalog also the entry by GlobalId
nameNoWith library only: the entry by Name, e.g. HEA 200
classNoWith library and name only: just the type for this class (IfcColumn or IfcColumnType)
pointsNoIfcAlignment only: world points [x,y,z] in m; a row each with station_m, offset_m, offset_vertical_m, height_above_axis_m, source, or the reason (never clamped)
columnsNoIfcGeomodel, its strata or a layered terrain: plan points [x,y] or [x,y,z] in world m; per point each layer top/bottom with source and rule, groundwater, nearest borehole; with z the layer it lies in
includeNoSections; default attributes, psets, relations, at an IfcGrid also axes (each axis: tag, from/to in world m and grid m, curve; origin, ref_direction), at an IfcAnnotation also annotation (curves as points, arcs as chords; texts with anchor, text_height_m from its IfcTextStyle or the reason none, direction, extent; AssignedToProduct); outline at an IfcSpace: its footprint; alignment at an IfcAlignment (IFC4X3): horizontal and vertical segments with world ends, start station, station_equations, referents, length, warnings where layout and curve disagree
libraryNoRead in this catalog instead of the model (names from get_model_summary): a row per Name with its section in m and its type objects by class (types); target.n counts types. Catalog or model per call
stationsNoIfcAlignment only: stations in m; a row each with world point, direction_deg, gradient, radius_m (+ left, null straight), cant (rail heads, roll_deg about the axis point, lift_m; null: no cant layout) and source, or the reason there is none; in an overlap a row per run, in a gap station_in_gap

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

Beyond the read-only annotations, the description discloses substantial behavior: default sections, per-class section support (IfcProject, site, building, storey, space, groups, openings), fallbacks such as not_read or refused, unit conventions for range values, and catalog-vs-model behavior. This is far more context than the annotations provide and is consistent with readOnlyHint=true.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body is a dense, semicolon-heavy run-on with nested parentheticals that is difficult to parse. Much of the content is useful, but it could be structured more cleanly and shortened without losing essential meaning.

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 complex eight-parameter retrieval tool with no output schema, the description is unusually complete: it covers supported object types, section behavior, per-class limitations, units, default sections, and catalog mode. An agent has enough information to call it correctly and interpret common failure responses.

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 baseline is 3, but the description adds real meaning beyond the schema: it explains include sections in domain terms, states default sections, describes effective pset values and relation naming, and clarifies library catalog semantics. Some parameter detail remains in the schema rather than the description, so it is not a full 5.

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 phrase 'One object by GlobalId' states a specific retrieval action and enumerates the object kinds it can return, so an agent can tell this is a targeted single-object fetch. It does not explicitly differentiate itself from sibling tools such as find_elements, which keeps it from a 5.

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 is implied: use it when you have a GlobalId, or with library/name/class for catalog entries. However, there is no explicit when-to-use versus find_elements or get_model_summary guidance, and no stated exclusions or alternatives.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources