moddl

Delete elements

delete_elements

Destructive

Deletes elements with everything that exists only through them (openings, parts); relations name each space boundary that goes along. 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. PLAN_REQUIRED where fills would lose their host or over 20 boundaries of staying spaces go. Also removes an EMPTY spatial node named by guid (IfcSpace, IfcBuildingStorey, IfcBuilding, IfcSite): one still holding elements or nodes is rejected alone and names what to clear first, so a tree empties from the bottom up; the IfcProject stays. An IfcOpeningElement without fill named by guid goes alone: its host keeps its GlobalId and loses the hole; a filled one is rejected, its try deletes the fill, which takes it along. A type object named by guid goes when it types nothing or all its occurrences are named too; one still typing others is rejected (the occurrences named with it too). A group, zone or system by guid goes alone: its members stay, the memberships ended stand in relations.

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

Input Schema

Name	Required	Description
`set`	No	A 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
`guid`	No	One element (GlobalId)
`note`	No	Your note, stored with the new revision
`guids`	No	These elements (GlobalIds)
`dry_run`	No	Preview: the planned effect and a plan_id, nothing written
`plan_id`	No	Execute 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_id`	No	Your id for this call: a repeat answers the first result and writes nothing
`expect_count`	No	With set: how many elements the set holds - guards against a mixed-up set id
`expect_beyond`	No	With plan_id: how many elements the plan reaches beyond those named (n_beyond of PLAN_REQUIRED or the dry_run)
`keep_openings`	No	true: a door or window goes without its opening, which stays in the host empty (carried, effect kept_empty), ready for insert_in_host opening or set_relation FillsVoids; default false takes it along

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already flag destructive/non-idempotent, but the description goes far beyond them: cascade consequences (host keeps its GlobalId and loses the hole; group members stay while memberships end in relations), revision creation, the named effect-report counters, the dry_run/plan_id two-phase protocol with PLAN_CHANGED on stale clones, and per-shape rejection rules with what to clear first. This is exactly the behavioral context annotations cannot convey.

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?

It is front-loaded correctly — purpose, then target, then escalation, then edge cases — and nearly every clause carries information. But the telegraphic fragments ("relations name each space boundary that goes along", "A call that succeeds is not a job that's done", "its try deletes the fill") are hard to parse and cost the agent a re-read on a destructive operation, which is where clarity matters most.

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 10-parameter destructive tool with no output schema, the description supplies the return shape (n_changed, rejected, cloned, carried), the failure codes it depends on, and the behavior of every object class it can encounter. What is missing is minor: the full effect-report/rejection payload structure and whether relations entries are returned or only written.

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 defines each parameter, establishing a baseline of 3. The description adds genuine meaning on top: that the target is a guid, guids, or a set and "never a filter", that a set is a frozen snapshot whose stale element is rejected alone, and that expect_beyond pairs with plan_id from PLAN_REQUIRED. It stops short of adding anything for note or request_id beyond what the schema states.

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?

Names a specific verb and resource ("Deletes elements") and immediately defines the cascade scope: what is deleted along with it (openings, parts), what is recorded (relations naming space boundaries), and what is produced (a new revision plus an effect report). It also enumerates the degenerate cases handled in the same call (empty spatial node, orphan opening, unused type, group/zone/system), which lets an agent tell this apart from siblings like split_element 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?

Explicitly constrains targeting ("guid, guids or a set from find_elements/get_selection, never a filter") and names alternatives for the non-delete path (insert_in_host opening, set_relation FillsVoids with keep_openings). It states exactly when extra steps are required — PLAN_REQUIRED for beyond-named effects, and to run its plan_id with expect_beyond — plus the two trigger conditions (fills losing host, over 20 staying-space boundaries).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All moddl tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?