FERS — structural FEM

Cut an opening in a plate

add_plate_opening

Read-only

Cut a hole (stairwell, duct, riser) in an existing PlateSurface: creates the hole's boundary nodes and appends a PlateOpening to that surface's openings. The hole ring must be coplanar with, and lie strictly inside, the outer boundary; elements whose centroid falls in the hole are dropped, so the applied load drops with the removed area (verified: a 1x1 m hole in a 4x4 m slab under 10 kPa took the total reaction from 160000 N to exactly 150000 N).

HARD CONSTRAINT: openings only work with the Delaunay mesher. The structured mesher rejects them outright ("PlateSurface N Structured meshing does not support openings."), so this tool switches the surface to mesh method "Unstructured" with a target_size and tells you it did. That makes the surface's edge-node positions unpredictable, which is why the tool REFUSES to convert a surface whose structured edge grid is carrying a support: those pre-created edge nodes would be stranded off the new mesh and the plate would silently fall back to hanging on its corners (measured 6x too flexible, with the load still balancing exactly). If you need both an opening and a supported edge, author the surface as unstructured from the start and support it by other means.

TARGET SIZE IS A WHOLE-SURFACE SETTING, so a SMALL hole is the expensive case, not the cheap one: left to default (half the shortest hole edge) a 200 mm duct in a 6 m x 6 m slab asks for ~6100 mesh nodes and the engine aborts on that with a raw wasm trap. The default is therefore clamped to what the node budget allows — which means the hole is resolved coarsely and its stress concentration is NOT converged; model the region around the opening as its own smaller surface if you need it sharp. An explicit target_size that busts the budget is refused rather than clamped.

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

Input Schema

Name	Required	Description
`model`	No	Stringified FERS model JSON
`model_ref`	No	Handle from stash_model, used INSTEAD of `model`. Avoids sending the whole document on every step; the tool returns the same handle back.
`opening_id`	No	Overwrite this opening id.
`surface_id`	No	id of the plate surface to cut the hole in.
`target_size`	No	Mesh size around the hole, metres. Openings force the Delaunay mesher.
`corner_points`	No	JSON array of [x,y,z] points bounding the hole, inside the surface and in its plane.
`boundary_node_ids`	No	Existing node ids bounding the hole instead.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Discloses behavior far beyond the annotations: it silently switches the surface to mesh method 'Unstructured', clamps the default target_size to the node budget, refuses (rather than clamps) an explicit over-budget target_size, drops elements whose centroid falls in the hole (with load consequences), and can abort with a raw wasm trap. Failure modes are quantified with measured evidence. The only tension is that the tool mutates model state while readOnlyHint=true; in this toolset authoring tools return a modified model document rather than persisting, so I read that as scope-of-read-only rather than a contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and then the hard constraints, so the important warning (supported edges are refused) is easy to find. It is on the long side and the two quantified verification anecdotes could be trimmed, but each paragraph carries decision-relevant information.

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?

With 7 parameters, no output schema, and mutation semantics, the description covers nearly everything an agent needs: preconditions, meshing side effects, clamping/refusal behavior, and the threat of a wasm trap. It stops short of describing exactly what the response contains beyond returning the model_ref handle and a notice about the mesh-method switch.

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 real meaning: target_size is a whole-surface setting whose default is clamped and whose explicit value may be refused, and corner_points must form a ring that is coplanar with and strictly inside the outer boundary. It does not, however, contrast corner_points vs boundary_node_ids beyond what the schema already says.

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?

States a precise verb and resource ('Cut a hole ... in an existing PlateSurface') and then spells out the concrete effects: creates boundary nodes, appends a PlateOpening to the surface's `openings`. This is clearly distinguishable from siblings such as add_plate_surface and add_plate_grid_elements.

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?

Gives explicit when/when-not guidance and named alternatives: openings require the Delaunay mesher, the tool refuses surfaces whose structured edge grid carries a support, and the description tells the agent to author the surface as unstructured from the start or model the region as its own smaller surface if a sharp stress concentration is needed.

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

All FERS — structural FEM tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.