Skip to main content
Glama

Edit mesh

edit_mesh

Edits the shape (guid, guids or set) directly: move points of a tessellated body (each checked against the file), push one face, set the top onto a sloped plane, close a hole, stretch it at a plane (a window 20 cm wider, holes and all), set the corners of a profile polygon, turn a mesh prism into an extrusion, or colour single faces of a face set. 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. repair: weld, drop degenerate and duplicate faces, close each hole a cap closes without crossing, face outward; writes only when defects fall; reports what changed and whether the body is closed.

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

Input Schema

NameRequiredDescriptionDefault
atNopush_face: a point on the face; close_hole: a point on the hole rim
byNopush_face: m along the outward normal (negative pushes in); move_points: offset [x,y,z] m for every from
opNoWhat to edit; an IfcSpace takes set_profile (floor corners) and to_extrusion (a prism body)
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
facesNocolour_faces: written as the IfcIndexedColourMap of a triangulated or polygonal face set, geometry unchanged; every other face keeps the colour it shows. get_element mesh face_colours reads it back
guidsNoThese elements (GlobalIds)
levelNoA mapped shape: this occurrence (cloned) or the type
planeNoto_plane: three points; the upward faces move vertically onto it
pointsNomove_points: each point where it is and where it goes (to, or by for all)
weld_mNorepair: points closer than this are one, default 0.000001
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
profileNoset_profile: corners in profile coordinates, at most 1000; replace the outer curve, arcs become edges (arcs_replaced), holes stay if inside. At an unfilled opening: [[u,v],...] m in the host as insert_in_host outline
stretchNostretch: tessellated body only; the other side stays
directionNoto_extrusion: the extrusion direction, world vector; one of the candidates a refusal names
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
profile_partNoset_profile on a composite profile: the part by ProfileName or 0-based index
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

A3.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that every edit creates a new revision, that the response is an effect report (n_changed, rejected, cloned, carried), that elements changed since reading are rejected individually while the rest are written, that dry_run/plan_id gate larger operations, and that repair writes only when defects are found. It also explains request_id repeat semantics and the PLAN_CHANGED clone ordering rule. This is substantial context the annotations do not carry.

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?

Information density is high and the operation list is front-loaded, but the text is one unstructured block of run-on clauses with whimsical asides ("a window 20 cm wider, holes and all") and a cryptic line ("A call that succeeds is not a job that's done"). It would benefit from splitting operations, targeting, and plan/repair behavior into distinct sentences.

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 22-parameter, zero-required, multi-mode tool with no output schema, the description covers the important operational facts: revisioning, the effect report fields, the plan/dry_run workflow, target selection, and repair's write condition. What remains thin is per-operation guidance on which parameters each op requires, though the schema largely fills that in.

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 description coverage is 100%, so all 22 parameters are already documented in the schema, which sets the baseline at 3. The description adds framing for the plan/dry_run pair and an illustrative stretch example, but contributes little per-parameter meaning beyond what the schema states.

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 description names a concrete verb plus the full operation set (move_points, push_face, to_plane, close_hole, stretch, set_profile, to_extrusion, repair, colour_faces) and states the target shapes. It is distinguishable from siblings like move_elements or split_element, though the operations are packed into one run-on sentence that makes the tool's scope harder to grasp at a glance.

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?

"Target: guid, guids or a set from find_elements/get_selection, never a filter" gives a clear routing rule for targets, and the plan/expect_beyond flow is referenced. However, there is no explicit when-not-to-use guidance against overlapping siblings such as move_elements, extend_element, split_element or change_class, so the agent must infer boundaries.

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