Skip to main content
Glama

Insert in host

insert_in_host
Destructive

Inserts a door or window into a wall, or an empty opening into a wall or slab, in one call; moddl builds IfcOpeningElement, IfcRelVoidsElement and IfcRelFillsElement. Position as distance from the host start along its axis and sill height (a mesh wall runs along its largest vertical face from its -x, else -y end; its thickness is measured there); an empty opening may instead take an outline polygon, or around an element passing through (chimney, duct). Refused if the opening leaves the host; a door or window also if its opening meets an existing one or the wall has several bodies (layered), while an empty opening there takes the full thickness and read_as names any overlap. An IfcVoidingFeature (notch, hole) is cut as an empty opening. Beam, column, member or plate: offset refuses (no wall axis), outline cuts in its placement x/y only (a plate face; a bar its cross-section); holes drills a hole pattern in one call. A wall whose body subtracts solids from its sweep (studs out of an infill) is placed along that sweep (source assumption); the opening must stay within the measured body and meet its material, the subtractions it reaches are named. An existing empty opening is filled with opening instead of host; a window also into the empty opening of a slab (class IfcWindow with lining); a panel of a curtain wall as host gives its whole field to a door or window (class with lining) and is deleted. New revision, effect report. A call that succeeds is not a job that's done. Example: {"host":"1kTv...","like":"","offset":"1,20 m"}

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

Input Schema

NameRequiredDescriptionDefault
faceNoWith depth below the host thickness: the niche ends flush at this face, written as RECESS; wall +t/-t (frame), else +h/-h (upper/lower)
hostNoA wall for a door or window; an empty opening also a slab, roof, plate, beam, column or member; a panel (IfcPlate) of a curtain wall: class with lining takes its whole field, the panel goes. Required unless opening names the place
likeNoTemplate door/window: occurrence or type object of the model
noteNoYour note, stored with the new revision
sillNoHeight of the opening bottom above the host bottom; default with like the template's above its own host's bottom, else 0
classNoWithout template; typed by the type of the file pattern or a new one - like carries a body. IfcVoidingFeature: an empty cut, attributes.PredefinedType from its enum (NOTCH, HOLE ...), else none; IfcEarthworksCut is refused: edit_terrain cut
depthNoEmpty opening (offset or outline) only: its depth through the host; default the host thickness, refused host_thickness_ambiguous where profile and layers disagree; below the host thickness name face
holesNoInstead of offset/outline/around: one IfcVoidingFeature HOLE (cylinder) per entry in one revision, all or none; axis = normal of the planar face pair at at, through_m their measured distance; refused with the hole index where a hole meets no planar face, leaves it or meets another
hostsNoWith around or outline instead of host: one empty opening per host (a duct through wall and slab) in one revision; outline in hosts[0] coordinates, mapped through world into each level slab (a shaft); one host refused writes none, read_as names the group
widthNoWithout template: opening width = frame outside (OverallWidth); clear width = width - 2 x lining.thickness
anchorNoWhich point of the opening offset reaches; default start
aroundNoEmpty opening shaped by this element through the host (it stays)
heightNoWithout template: opening height = frame outside (OverallHeight); clear height = height - lining.thickness (door) or - 2 x lining.thickness (window)
liningNoRequired with class IfcDoor/IfcWindow: builds the body (frame + glass or leaf); every value named, no default
offsetNoDistance from the host start along its axis to the point anchor names
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 its checks, nothing written
openingNoInstead of host: an empty IfcOpeningElement that stands, filled at its own place and size by like or class with lining (only the fill and IfcRelFillsElement are written), or a part of it with fill_within (also beside the fills it holds); like whose own opening differs by over 1 mm is refused; one in a slab or plate takes a window only (class IfcWindow with lining; read_as names its width and height axes)
outlineNoEmpty opening instead of offset/sill/width/height: [[u,v],...] m, 3-256 corners; wall: u along axis from start, v up from bottom; else u/v in the host own x/y from its placement origin (usually the slab corner), not world x/y
clearanceNoWith around: gap, default 0
attributesNoFor the door or window; with class also OperationType (IfcDoor) or PartitioningType (IfcWindow), written at its type, one leaf with lining (IFC left/right seen along +y, the swing direction; DIN 107 sees from the other side: IFC LEFT = DIN right); an empty opening takes Name only here (set_properties writes its other attributes after)
request_idNoYour id for this call: a repeat answers the first result and writes nothing
fill_withinNoWith opening: the fill (class with lining, width and height) takes this part of it, from its low corner on its own axes (a wall: along the axis and up), inside it and clear of the fills it holds (fill_overlaps_fill names by_m): a door beside a side light, a transom above
around_shapeNoWith around: hull (default; must pass through) or exact (its own body, no clearance; stopping inside the host is written as RECESS)
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.6/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds real substance beyond them: that a curtain-wall panel host is deleted, that dry_run previews without writing, that request_id makes a repeat answer the first result and write nothing (a useful nuance against idempotentHint=false), and that each call writes a new revision with an effect report. It also enumerates the exact refusal reasons (opening leaves host, meets an existing opening, host_thickness_ambiguous), which is behavior an agent cannot infer from annotations.

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 front-loaded and strong, but the remainder is a dense run-on block of parenthetical clauses with no separation between positioning, refusals, and host-type special cases. Every sentence conveys a rule, so little is truly wasted, yet the final line 'A call that succeeds is not a job that's done' is cryptic and would cost an agent little to lose or better to phrase as a follow-up check.

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 25-parameter, deeply nested, destructive tool with no output schema, the description covers positioning, host-type branches, idempotency, preview, and refusal modes. It nods at the return with 'effect report' and repeated 'read_as names ...' phrasing but never states what the result contains, which is the main residual gap given there is no output schema to fall back on.

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 100%, so the schema already carries most parameter meaning and the baseline would be 3. The description nevertheless adds semantics not in the schema, notably the mesh-wall orientation convention ('runs along its largest vertical face from its -x, else -y end') and the rule that a wall whose body subtracts solids is placed along that sweep. Some of it restates offset/sill that the schema already documents.

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 opening clause names a specific verb and resource set: 'Inserts a door or window into a wall, or an empty opening into a wall or slab, in one call' and states exactly what IFC entities are built (IfcOpeningElement, IfcRelVoidsElement, IfcRelFillsElement). It further segments itself from siblings by naming the cases handled elsewhere (edit_terrain cut, set_properties for opening attributes). An agent can distinguish this from create_elements or set_relation 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Routing rules are explicit and conditional: use 'opening' instead of 'host' to fill a standing IfcOpeningElement, 'holes' instead of offset/outline/around for a hole pattern, 'hosts' for one opening across several hosts, and IfcEarthworksCut is refused with a redirect to edit_terrain cut. Refusal conditions are spelled out per host type (beam/column/plate offset refuses, layered walls, overlapping openings), which is effectively 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