Skip to main content
Glama

Set dimension

set_dimension
Idempotent

Sets one parametric dimension (thickness, length, height, width, depth, radius). New revision, effect report (n_changed, rejected, cloned, carried). A call that succeeds is not a job that's done. Target: guid, guids or a set from find_elements/get_selection, never a filter. Beyond the named: PLAN_REQUIRED, run its plan_id with expect_beyond. Openings follow the thickness; base quantities are recomputed or removed, never left stale. A door or window in an opening takes width or height with that opening (width about its centre, height from the sill); OverallWidth/OverallHeight follow, GlobalIds stay. A layer set restating the thickness follows in one layer (layer) or is replaced whole (layers). An IfcOpeningElement without fill named by guid takes width (along its host), height or depth about its centre, refused where it would leave the host or cut another opening; a filled one: set_dimension at its fill. A free profile extrusion (polygon, arcs, holes) takes length as its depth and thickness at its offset pair (concentric arcs or parallel sides): keep start (default) holds the inner arc or the side nearer the profile origin, end the outer or farther one, center both by half; at equal distance its layer set decides: start holds its first layer's face, end its last's. Openings through parallel sides follow. Refused where the body has no such parameter.

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

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)
keepNoWhat stays in place: start, end or center along the measured axis, top or bottom where it is vertical. Default: in the profile its centre (a wall's length and thickness), along the extrusion its foot (a wall's height, a slab's thickness), a level beam's or member's height its top. With several elements each keeps its own
noteNoYour note, stored with the new revision
pairNothickness at a free profile with several offset pairs: the one meant, index as the refusal lists them (0 first). Without it several pairs are refused
guidsNoThese elements (GlobalIds)
layerNothickness with a layer set: the layer taking the change, index in the set (0 first), its material name or its Name; refused where layers and body already differ. Default the only layer, else the one with Category LoadBearing, else none
valueNoNew value: metres, or a text with unit: 300 mm
layersNothickness: the whole layer set replaced by this list, the first layer at the face the old first lay at; at an element without one (no material or one IfcMaterial of its own) a new set and usage across the body, the first layer at its low face along the object axis (read_as names it). Sums to value, else refused. Adding, removing, swapping or reordering a layer is the whole new list; the set name stays behind. Not beside layer
sourceNoWhere the values you write come from: assumption (default, your own estimate, stamped in the file) or user (only what the person named word for word; it then reads as the file does)
dry_runNoPreview: the planned effect and a plan_id, nothing written
operandNoOperand of a boolean body; 2 = the second (a cutter, a joined part); default 1
plan_idNoExecute exactly the plan a dry_run returned, all or nothing; the plan holds target and fields. Plans that clone the same shared object (type, material) run one after the other: plan the second after the first ran, else PLAN_CHANGED
dimensionNoWhich dimension; a bar section by its lie: up to 45 degrees width (the level axis)/height, steeper width (along its x)/depth, height its length; an IfcSpace takes height (its floor stays)
request_idNoYour id for this call: a repeat answers the first result and writes nothing
expect_countNoWith set: how many elements the set holds - guards against a mixed-up set id
expect_beyondNoWith plan_id: how many elements the plan reaches beyond those named (n_beyond of PLAN_REQUIRED or the dry_run)
expect_contactsNoIntended contacts: checks.contacts splits into as_expected, missing, surprises; an omitted kind is not judged

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the annotations, the description discloses substantial behavior: a new revision is created, effect fields are reported, PLAN_REQUIRED and plan execution are explained, layer-set replacement is described, and refusal conditions are given. This is rich context for a mutation tool and is consistent with the declared non-read-only, idempotent, non-destructive profile.

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 description is front-loaded with the core operation, but it is dense and uses long semicolon-separated clauses that are hard to parse. Most details are relevant for a complex tool, yet the structure could be clearer and some terse phrases such as 'A call that succeeds is not a job that's done' are opaque.

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?

For an 18-parameter mutation tool with no output schema, the description covers purpose, targeting, revision behavior, planning, refusals, and many domain-specific cases well. It leaves some return-value detail implicit, but the effect report summary and plan workflow provide enough completeness for correct invocation.

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 carries the parameter documentation. The description still adds useful cross-parameter meaning, especially how layer versus layers behaves, how keep interacts with profile and extrusion axes, and which dimension to select for openings, bars, and free profiles.

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 first sentence states a specific verb and resource: it sets one parametric dimension and enumerates the supported dimension types. It also names the effect report fields, making the core operation and outcome clear enough to distinguish it from general property editing or scaling.

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?

The description gives operational targeting rules such as using guid, guids, or a set from find_elements/get_selection, and it routes opening fills to their fill element. However, it does not explicitly compare this tool with siblings like scale_elements or set_properties, so an agent must infer when this is preferable.

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