Skip to main content
Glama

Edit terrain

edit_terrain
Destructive

Changes one terrain (guid) moddl derives from its ground: a pit (cut), a fill (embankment), surface heights (points) or entries taken out again (remove: their ids) - one of them per call. Every entry has an id, the same id replaces it in place; get_element include terrain lists them. The net is derived anew from the ground with every entry: heights in order, then the fills, then the pits; a point under a pit acts once the pit gets smaller (under_cut). fill: its slope runs down from the crown until it meets the ground; where the ground stands above top_z nothing is filled (crown_in_ground_m2). With layers or at a geomodel all fills form one fill layer of its own on top (layer_name; the top layer is never thickened). points: within 1 mm in plan of a point it sets that height, else it adds a point - a Delaunay terrain is triangulated again around it, given triangles are split; outside the rim only without layers. Raising thickens the top layer only; lowering cuts every layer boundary down to the new surface. A layered terrain is changed at its container, a single layer is refused. After a fresh upload or a change by another tool a known pit can only get deeper or wider. A vertical wall is insert_in_host. New revision, effect report. A call that succeeds is not a job that's done. The report's terrain_edit: the entries after the call, excavation_m3 measured at the net, source assumption where a pit, a height or the ground is not the user's; the volume per layer in layers[], changed layers in carried; a fill's volume, crown area and toe line in fill; pit: per floor edge the slope width, per corner the top of the ridge between two slopes, worth a look where the pit stands beside something.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "guid": "<guid>"
    },
    "name": "edit_terrain"
  }
}

Input Schema

NameRequiredDescriptionDefault
cutNoA pit
fillNoA fill (embankment)
guidYesThe terrain: IfcGeographicElement with a closed mesh body, the container of its layers, or an IfcGeomodel whose strata have thickness everywhere
noteNoYour note, stored with the new revision
pointsNoSurface heights
removeNoEntry ids to take out
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
request_idNoYour id for this call: a repeat answers the first result and writes nothing

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the destructiveHint=true/readOnlyHint=false annotations, it discloses what actually happens: the net is recomputed in a fixed order (heights, fills, pits), raising thickens only the top layer while lowering cuts every boundary, fills collapse into one fill layer at geomodels, fills above top_z do not fill, and out-of-rim points are rejected on layered terrain. It also states a new revision is produced, that dry_run previews checks, and that request_id makes repeats no-ops — behavior an agent could not infer from 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 with the purpose, but the body is a dense run-on stream of semicolon- and dash-joined clauses that is hard to parse, and lines like 'A call that succeeds is not a job that's done' or 'worth a look where the pit stands beside something' spend words without conveying a checkable rule. Nearly every clause carries information, so it is not padded — it is poorly structured rather than too long.

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 9-parameter nested mutation tool with no output schema, the description covers the report payload (terrain_edit, excavation_m3, layers[], carried, fill crown/toe, per-floor slope widths) and the derived-state rules, which is close to what an agent needs. Some report fields and the 'source assumption' semantics are described too allusively to be fully actionable.

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 baseline is 3, but the description adds genuine meaning on top: the id-reuse rule ('the same id replaces it in place', ids listed via get_element include terrain), the 1 mm plan-snap rule that decides whether a point sets a height or adds one, and the under_cut interaction between pits and points. Remaining gaps are minor since the schema already documents the nested fields thoroughly.

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 first sentence names the resource (one terrain by guid), the verb (changes), and enumerates the four mutually exclusive modes (cut/fill/points/remove) with 'one of them per call'. It also distinguishes itself from insert_in_host for the vertical-wall case, so an agent can route correctly 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 Guidelines4/5

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

It gives real when-conditions: a layered terrain must be edited at its container, a single layer is refused, a known pit can only get deeper or wider after an upload or another tool's change, and vertical walls belong to insert_in_host. It stops short of explicit routing to create_terrain for new terrain or to get_element for inspection, so it is strong but not exhaustive.

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