Skip to main content
Glama
Sign In

moddl

by site.moddl
OverviewDiscussionsAdmin

Edit alignment

edit_alignment
Destructive

Changes the layouts of one IfcAlignment (guid) after creating it: each key of alignment named replaces its layout whole (start, start_direction_deg and horizontal the horizontal one; vertical; cant; start_station_m and station_equations the stationing), every key left out stays row for row. get_element include alignment lists the rows in this form (kind, turn). 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. The IfcAlignment keeps GlobalId, attributes and placement; its curves keep their identity, so referents and placements on them follow. Elements positioned at the alignment (at_station, along, to_station) follow only through the plan_id (expect_beyond): a place keeps station and offsets, a body along it gets its curve anew. The report's alignment_edit: before and after read back, on_alignment with elements and not_carried.

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

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)
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
alignmentNoThe layouts to replace, in the create_elements alignment form; at least one key
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
on_alignmentNostay changes the alignment alone and leaves the elements positioned at it
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/5.0
Behavior5/5

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

Annotations only say destructive/not-read-only/not-idempotent; the description goes far beyond that, disclosing that named layout keys are replaced whole while omitted keys persist, that a new revision is produced with a report (n_changed, rejected, cloned, carried), that a successful call is not the end of the job, that curves keep identity so referents follow, and that station-positioned elements move only via plan_id. Error codes PLAN_REQUIRED and PLAN_CHANGED are surfaced too. This is unusually rich disclosure for a destructive mutation and is consistent with the 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?

It is front-loaded and nearly every clause carries information, with no filler sentences. However, the telegraphic fragment style ('New revision, effect report (n_changed, rejected, cloned, carried). A call that succeeds is not a job that's done.') makes it hard to parse and forces the reader to reconstruct subjects and verbs. Density comes at the cost of structure.

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 destructive, nested-schema mutation with no output schema, the description covers the important gaps: revisioning, the shape of the effect report (alignment_edit, before/after read-back, on_alignment with elements and not_carried), and the two-phase dry_run/plan_id workflow. What is missing is mainly ordering/atomicity nuance for multi-element targets, which the schema partially covers.

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

Parameters3/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 eleven parameters and the nested layout objects, making 3 the baseline. The description adds some genuine meaning beyond the schema, notably the whole-layout replacement rule for alignment keys, the 'never a filter' targeting constraint, and what expect_beyond counts. That extra meaning is real but scattered rather than systematically covering the parameters.

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?

States a specific verb and resource: it changes the layouts of one IfcAlignment, and explicitly frames that as happening 'after creating it', which separates it from create_elements. The partial-replacement rule (named keys replace whole layouts, omitted keys stay row for row) further pins down what the tool does. It never names the neighbouring edit_* tools, so sibling differentiation beyond create_elements is 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?

Gives real when-to-use routing: target must be guid/guids or a set from find_elements/get_selection, 'never a filter', and effects on positioned elements go through the PLAN_REQUIRED/plan_id path with expect_beyond. It also signals the on_alignment='stay' alternative. It does not state when to use this versus edit_grid or set_properties, so it stops short of explicit exclusions.

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

All moddl toolsInspect
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