Skip to main content
Glama

Set properties

set_properties
DestructiveIdempotent

Sets values by IFC path: attributes, properties, material, style, classification. 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. Paths: "Name", "Pset_WallCommon.FireRating", "Material.Name" (beside it "Material.Category", written only to a new material; IFC4X3 recommends concrete, steel, aluminium, block, brick, stone, wood, glass, gypsum, plastic, earth; any text), "Material.MassDensity" (kg/m3 or a text with unit; one held beyond the named is cloned), "SurfaceColour", "SurfaceTransparency" (0..1), "SurfaceReflectanceMethod" (GLASS ...) - a style others read is cloned. level occurrence (default) writes at the elements and overrides a type value; level type at the type object, reaching every occurrence; level material in place at the one IfcMaterial, reaching every holder (paths: level). A named type object (its GlobalId) also takes attributes, Material.Name and style paths (its occurrences take them); its PredefinedType reaches occurrences stating none, USERDEFINED with ElementType in the same values. Spatial nodes take style and classification paths. "Classification.<IfcClassification.Name>" takes the Identification of a reference: the element joins it and leaves its other one in that system (a missing reference is created; "Classification" alone: references without a system). remove deletes a value; null is not a removal. The value type comes from the PSD template or the existing property; a property with neither goes in a pset named "Moddl_..." (exactly this case), typed from the value, or names its type in measure_type. A group, zone, system or other non-element object by guid takes attributes and property values. Example: {"set":"s_7f3","values":{"Pset_WallCommon.FireRating":"F90"}}

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_properties"
  }
}

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)
levelNoWhere the value is written. material: Material.Name, .Description, .Category, .MassDensity, its own sets ("Pset_MaterialThermal.ThermalConductivity", file unit), SurfaceColour and SurfaceTransparency at its surface style (built where it has none; material_colour counts the holders showing a colour of their own)
removeNoPaths whose value is removed; "Pset_X.*" a whole set (also level type), "Qto_X.Q" or "Qto_X.*" quantities at elements (a quantity is never set); a set losing its last property falls, at level type too. No rename: the value under the new path in values, the old path here (different values per element: run_script)
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)
valuesNoPath -> value; paths as list_properties and find_elements show them. Lengths in metres, angles in degrees, temperatures in degC, times in s. At an IfcSite "SiteAddress.<IfcPostalAddress attribute>" (Town, PostalCode, AddressLines: a line break per line ...), at an IfcBuilding "BuildingAddress.<...>"; at an IfcAnnotation "Text" its one IfcTextLiteral, in a call of its own
dry_runNoPreview: the planned effect and a plan_id, nothing written
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
request_idNoYour id for this call: a repeat answers the first result and writes nothing
new_systemsNoSystems (IfcClassification.Name) to create for "Classification.<name>" values
expect_countNoWith set: how many elements the set holds - guards against a mixed-up set id
measure_typeNoPath -> IFC value type (IfcLabel, IfcReal, IfcLengthMeasure, IfcDate ...) for a new property neither the file, the PSD nor a Moddl_ set types; refused where one does; elements, type objects, structural items and analysis models only, never a spatial node, other group or zone
expect_beyondNoWith plan_id: how many elements the plan reaches beyond those named (n_beyond of PLAN_REQUIRED or the dry_run)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only say this is a destructive, idempotent, non-readOnly mutation; the description adds the material facts an agent needs: a new revision is created, an effect report with n_changed/rejected/cloned/carried comes back, an element modified since the set was read is rejected alone without failing the rest, shared type/material/style objects are cloned rather than edited in place, and request_id makes a repeat a no-op. That is well beyond the annotation surface.

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 first sentence is well front-loaded, but the body is one dense block of fragment sentences with nested parentheses, mixing high-value rules (PLAN_REQUIRED, remove vs null) with low-value asides such as the IFC4X3 list of recommended material categories. No wasted breadth, but parsing cost is high and structure is poor.

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 a 15-parameter mutation tool with no output schema, the description covers the mutation model, escalation path, cloning side effects, and error/guard codes. The return payload is only sketched as 'effect report (n_changed, rejected, cloned, carried)' with no field detail, and the cryptic line 'A call that succeeds is not a job that's done' is never unpacked.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, yet the description still adds semantics the schema does not: the snapshot-not-filter meaning of 'set', the write sites behind the level enum, unit conventions in 'values' (metres, degrees, degC, seconds), address and annotation path shapes, the refusal rule for measure_type, and the rule that plans cloning the same shared object must be sequenced.

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 enumerates the resource families it writes (attributes, properties, material, style, classification), so an agent immediately knows this is the write path complementing list_properties/find_elements. Differentiation from siblings is partial: run_script is named only for the per-element-rename case and get_selection/find_elements only as target sources, so the full boundary against change_class or set_relation is left implicit.

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 real routing rules: targets must be guid, guids, or a set from find_elements/get_selection and 'never a filter'; PLAN_REQUIRED forces a dry_run then plan_id with expect_beyond; per-element differing values must go to run_script; null is explicitly not a removal. Guidance is strong but exclusions are scattered mid-paragraph rather than stated up front.

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