Skip to main content
Glama

Find elements

find_elements
Read-onlyIdempotent

Find elements - occurrences, and type objects by their class (IfcDoorType) - by filter: rows, count, coverage, and a set id. To change what you found, pass that set to a write tool - it writes exactly these elements. Every answer echoes the filter in IFC terms (target.filter), the count per class and, per where-condition, how many elements carry a value at all: "0 found" and "property missing everywhere" differ. fields adds IFC paths per row (fields, group_by, sum and order_by together: at most 8 property or quantity paths); group_by and sum aggregate FILE values (for measured bodies use compute_quantities). A hull cell with body_gap is no value to order_by, group_by or sum (partial_body: a minimum, not the extent; no hull where no body item was read); fields_coverage counts partial and missing hulls apart. Occurrence, type, spatial-node or opening classes, IfcGrid, IfcAnnotation, IfcAlignment, ports, groups, IfcStructuralItem, IfcStructuralActivity, IfcStructuralLoadGroup and IfcStructuralAnalysisModel go in separate calls. Pages: n is the whole set, rows a page; cursor continues. Read-only. Example: {"filter":{"class":["IfcDoor"],"storey":"EG","where":{"Pset_DoorCommon.FireRating":null}}}

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": "find_elements"
  }
}

Input Schema

NameRequiredDescriptionDefault
sumNoSum these numeric paths (file values, e.g. "Qto_WallBaseQuantities.NetSideArea"); n_shadowed counts elements whose summed value is the first of several under that name
limitNoRows per page, default 20
cursorNoContinue a previous answer; bound to its revision
fieldsNoIFC paths to add to each row; the value comes with where it sits (from: type|occurrence). A type-object row lists what it types as "Types.RelatedObjects.GlobalId" (where null: types nothing)
filterNoWhich elements (IDS applicability). Omitted: the whole model. All fields AND-combined
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
group_byNoGroup rows by this path, or by "class" (each row's own IFC class); each group has n, its own sum, a set of all its members and the first 20 GlobalIds (GlobalIds_capped when cut); on AssignedToGroups an element counts in each of its groups (groups_overlap)
order_byNoOrder the whole set before paging; default: file order. The northernmost element has the largest hull.center_y: walls meeting at a corner share the max

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description explains response echoing, per-class counts, per-where-condition value coverage, pagination semantics, and cursor behavior. It also discloses aggregation behavior, hull limitations, partial and missing hull handling, and class restrictions that affect invocation.

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?

The description is front-loaded with purpose and key usage, and most clauses add substantive information for a complex eight-parameter query tool. It is dense and somewhat run-on, with heavy parenthetical detail, but little is pure repetition.

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 query tool with no output schema, the description is complete enough to explain response shape, filtering behavior, aggregation, pagination, alternative tools, and important class restrictions. It also includes a concrete example that anchors the filter syntax.

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 already 100%, so the schema provides strong baseline semantics. The description nevertheless adds material constraints, such as the limit of eight property or quantity paths across fields/group_by/sum/order_by, the distinction between file-value aggregation and measured-body compute_quantities, and hull-cell behavior for grouping and ordering.

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?

The description states a specific verb and resource: find elements, occurrences, and type objects by class and filter. It names the class-based query and distinguishes the tool from write tools and compute_quantities, so an agent can identify its role without opening the 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?

The description gives clear usage context: use it for filtered element queries, pass the resulting set to a write tool for changes, and use compute_quantities for measured body values. It also states that occurrence, type, spatial-node, opening, and several structural classes require separate calls. It does not explicitly compare against all relevant siblings such as get_element or get_selection, so it falls short of exhaustive when-to-use guidance.

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