Skip to main content
Glama

Derive structural model

derive_structural_model

Derives a structural analysis model from the elements named by guids or a set: every IfcColumn, IfcBeam and IfcMember becomes IfcStructuralCurveMember on its own straight axis, every IfcSlab and IfcWall IfcStructuralSurfaceMember on its mid-plane with its thickness and its openings as holes, all in one new IfcStructuralAnalysisModel at the building and coupled to its element. The named elements stay as they are (n_changed 0). A node (tolerance_m) sits on the axis of the column, else the beam, else the member; the others join with an eccentricity, never moved onto it. Nodes never chain beyond tolerance_m: ends kept apart within it stand in warnings. A bar is split where another axis meets it inside. A bar end at a surface is a point of it; a beam or a wall edge lying against a slab face (bodies in contact) is a line in the slab mid-plane, the offset an eccentricity. Curved, unread or non-flat bodies are rejected with their reason. With model the same set brings that model up to date in place. No supports, no loads: the model is not ready for analysis. New revision, effect report. A call that succeeds is not a job that's done. The report's structural_derived: members, surfaces with net area and holes, nodes with the largest snap distance, connections with their offset in m, each assumption with its rule and measured deviation. Double-check before handover: the nodes and lines against the joints you expect - a tolerance too small splits one joint into two nodes, one too large joins what is apart.

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

Input Schema

NameRequiredDescriptionDefault
setNoA set id from find_elements or get_selection: writes exactly the elements seen there, nothing that matches later. An element changed since reading is rejected alone; the others are written
guidNoOne element (GlobalId)
noteNoYour note, stored with the new revision
guidsNoThese elements (GlobalIds)
modelNoAn IfcStructuralAnalysisModel to bring up to date: its members and nodes keep their GlobalIds and psets, orphaned ones are named, never deleted; a node moved off its Lage stays held
dry_runNoPreview: the planned effect and its checks, nothing written
request_idNoYour id for this call: a repeat answers the first result and writes nothing
tolerance_mNoSnap distance in m, required: axis ends and closest points of two axes within it are one node; never assumed
expect_countNoWith set: how many elements the set holds - guards against a mixed-up set id
surface_typeNoThe surface member type of every slab and wall; left out SHELL (assumption)
opening_min_area_m2NoRequired once IfcSlab or IfcWall is named: openings from this area in m2 become holes, smaller ones are dropped and counted

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (non-read-only, non-destructive, non-idempotent, closed-world) it discloses a great deal: source elements are left untouched (n_changed 0), a new revision is created, curved/unread/non-flat bodies are rejected with reasons, nodes never chain beyond tolerance_m, and the closing warning 'A call that succeeds is not a job that's done' sets expectations about verification. It also explains request_id repeat semantics and that model updates preserve GlobalIds and psets without deleting orphans — all context the 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.

Conciseness3/5

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

The core action is front-loaded, but the body is a dense ~230-word block of run-on sentences with dropped verbs ('every IfcSlab and IfcWall IfcStructuralSurfaceMember on its mid-plane'), which makes it slow to parse. Most sentences do carry unique information, but the packing is heavier than necessary and would benefit from splitting into purpose / behavior / caveats.

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 an 11-parameter geometry tool with no output schema, the description compensates well: it enumerates the effect report's contents (structural_derived: members, net area and holes, nodes with largest snap distance, connections with offsets, assumptions with measured deviation) and covers rejection, revision, idempotency and tolerance pitfalls. An agent has enough to call it correctly and to interpret the result.

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 documents all 11 parameters; the description nevertheless adds real meaning for the hardest one, tolerance_m, by spelling out the snap/eccentricity/no-chaining rules and the node-placement priority (column, else beam, else member). It also gives default and assumption behavior for surface_type and the required-when-slabs rule for opening_min_area_m2, though a few parameters (note, expect_count, dry_run) are left to the schema alone.

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 ('Derives a structural analysis model') plus the exact input forms (guids or a set) and the resulting IFC types (IfcStructuralCurveMember, IfcStructuralSurfaceMember, IfcStructuralAnalysisModel). It is unmistakably distinct from siblings such as check_model, find_supports or compute_quantities.

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?

It clearly frames the context: deriving an analysis model from physical elements, with the 'model' parameter for in-place update, the dry_run preview, and the explicit limitation 'No supports, no loads: the model is not ready for analysis.' What is missing is any explicit routing against alternatives (e.g., when to check the model first or use find_supports instead), so it stops 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources