Skip to main content
Glama

FERS — structural FEM

Add a plate or slab

add_plate_surface
Read-only

Add a meshed plate/shell surface (slab, wall, deck, panel) to a FERS model. You give the corner points; the tool creates the boundary nodes, optionally the full edge-node grid with a support, and appends the PlateSurface to model.plate_surfaces. The SOLVER meshes it at solve time — never author plate_elements for a surface yourself. Load it with add_load kind:"plate_pressure" (surface_id), not with distributed_loads.

MESHING DECIDES WHETHER YOUR MODEL IS CORRECT. The mesher only ever creates NODES and PLATE ELEMENTS: it never splits members and never adds supports, so a plate connects to the rest of the structure ONLY through nodes it shares by exact coordinate. (1) Leave the mesh unset and the surface becomes TWO TRIANGLES spanning the corners — it still solves and reactions still equal q x A, so nothing looks wrong; this tool rejects that instead. (2) A supported or member-connected EDGE only exists where a node sits at an exact mesh-grid coordinate: structured meshing has predictable positions so edge_support can pre-create them, unstructured/Delaunay does not, so edge_support with unstructured meshing is rejected. (3) If a beam runs along a plate edge, split that beam into segments ending on the grid, or the plate hangs off its two end nodes only (measured 4.2x too flexible, beam moment 2.5x too low) with no warning.

THEORY — THE ENGINE DEFAULT IS WRONG FOR THIN PLATES. PlateTheory "Auto" is resolved unconditionally to Mindlin (the OpenAPI text claiming otherwise is stale). Mindlin (DSG3) shear-locks: on a simply-supported square slab at span/thickness 80 the centre-deflection error was -86.1% / -55.2% / -8.1% / -0.4% at 4x4 / 8x8 / 16x16 / 32x32, where Kirchhoff (DKT, rewritten and patch-test-exact in 0.2.44) gave -5.5% / -1.4% / -0.3% / -0.03%. So: span/thickness >= 20 -> "kirchhoff"; span/thickness < 10 -> "mindlin" plus a fine mesh (it correctly adds the ~10% shear deflection Kirchhoff misses). theory:"auto" (the default) makes that choice from the SMALLER IN-PLANE DIMENSION of your boundary (not its shortest edge, which collapses the moment an edge carries intermediate nodes) and tells you which it picked and why.

BOUNDARY POINTS: give the ring OPEN. A closing point that repeats the first is dropped for you (and said so in the notes); any other repeated point is refused, because coincident points collapse onto one node and leave boundary_node_ids with a duplicate id — measured, that solves with no error, balances the load to exactly q x A, and is 513% wrong on deflection.

ALSO TRUE OF EVERY PLATE: plates carry NO self-weight (enable_self_weight loops over members only) — add density x thickness x g as a pressure. Plates contribute NO geometric stiffness, so alpha_cr from a model where plate stability governs is unconservative. behavior "membrane" does not remove bending stiffness, it scales it by 1e-6, so an out-of-plane load on a membrane plate returns absurd deflections rather than an error. Boundary point ORDER sets the element normal and therefore the sign of mx/my/mxy. Keep total model nodes under ~2000: the engine allocates a dense (7 x nodes)^2 block and aborts above that with a raw wasm trap, so both meshers are rejected here once the projected node count crosses it (Delaunay produces ~1.7 nodes per target_size^2 of area, measured, so target_size 0.1 on a 4 m x 4 m slab is already fatal).

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

Input Schema

NameRequiredDescriptionDefault
nameNoLabel for the surface.
modelNoStringified FERS model JSON
offsetNoOffset of the plate mid-surface, metres.
theoryNoauto (default: picks from span/thickness) | kirchhoff (best for thin plates) | mindlin (shear-flexible but coarse-mesh stiff) | engine_auto.
behaviorNoshell (default) | membrane.
model_refNoHandle from stash_model, used INSTEAD of `model`. Avoids sending the whole document on every step; the tool returns the same handle back.
thicknessNoPlate thickness in metres. Required, > 0.
surface_idNoOverwrite this surface id instead of allocating a new one.
divisions_uNoStructured mesh divisions along the first edge. Use >= 8 for Kirchhoff, >= 16-32 for Mindlin.
divisions_vNoDivisions along the other edge. Omit one and it is inferred from the edge-length ratio.
material_idNoExisting model.materials id. Defaults to the first material.
mesh_methodNoauto | structured | unstructured (Delaunay — required for openings).
plane_stateNoplane_stress (default) | plane_strain.
target_sizeNoElement edge length for the unstructured mesher, in metres.
edge_supportNonone (default) | pinned | fixed — supports the generated perimeter nodes.
corner_pointsNoJSON array of [x,y,z] corner points forming an OPEN planar ring (do not repeat the first point). At least 3; exactly 4 for the structured mesher. Give this OR boundary_node_ids.
element_shapeNoauto | triangle | quad.
classificationNoFree-text group name.
edge_support_idNoReuse an existing nodal_supports id for the edge.
boundary_node_idsNoJSON array of EXISTING node ids to hang the plate off, e.g. [1,3,8,6].
local_x_directionNo[x,y,z] setting the plate's local axes, which fix the sign and meaning of mx/my/mxy. Defaults to the first edge.
stiffness_modifier_shearNoMultiplier on shear stiffness.
stiffness_modifier_bendingNoMultiplier on bending stiffness (0.5 doubles deflection).
stiffness_modifier_membraneNoMultiplier on membrane stiffness.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior1/5

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

The description is rich in behavioral detail about meshing, supports, self-weight, geometric stiffness, membrane behavior, and node limits. However, the annotations declare readOnlyHint=true while the description repeatedly says the tool creates boundary nodes and appends a PlateSurface to the model, which is a direct contradiction of the read-only annotation.

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?

The description is front-loaded with a clear first paragraph and uses headings to separate meshing, theory, boundary points, and general plate caveats. It is long and dense, with repeated empirical figures and warnings, but most of that content is relevant to correct invocation of a complex 24-parameter engineering tool.

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?

Given the tool's complexity, the description is unusually complete about meshing behavior, theory choice, boundary handling, support creation, loading guidance, and failure modes. The main gap is that there is no output schema and the description does not explain the general return shape or exactly what identifiers are returned after a successful add.

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 description coverage is 100%, so the schema already carries the baseline parameter meaning. The description still adds important operational semantics for key parameters, including theory auto-selection, open-ring corner_points, rejection of edge_support with unstructured meshing, and target_size/node-count constraints, though not every one of the 24 parameters receives extra narrative explanation.

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 description uses a specific verb and resource: adding a meshed plate/shell surface to a FERS model, and it names concrete variants such as slab, wall, deck, and panel. It also distinguishes the operation from related workflows by saying to load it with add_load kind:"plate_pressure" rather than distributed_loads, and never to author plate_elements for a surface directly.

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?

It gives explicit when-to-use and when-not-to-use guidance: use this tool for plate/shell surfaces, load via add_load kind:"plate_pressure", do not author plate_elements manually, and avoid edge_support with unstructured meshing. It also gives conditions for theory selection and boundary-point formatting, so the agent has clear operational rules rather than inferred usage.

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.