Skip to main content
Glama

FERS — structural FEM

Summarize plate results

summarize_plate_results
Read-onlyIdempotent

Reduce a solved FERS document to the plate numbers an engineer actually reads, and derive extreme-fibre stresses. READ-ONLY: it returns a summary, not a model.

You need this because plate results cannot be read back through the model. The mesh is generated on an internal working copy, so the returned document has model.plate_elements = [] and plate_surfaces[].generated_plate_element_ids = [], and the mesh node ids in displacement_nodes have no coordinates anywhere in model.nodes. The only georeferenced plate output is results.<case|combination>.plate_results, keyed by element id, carrying centroid {X,Y,Z}, centroid_displacement_global/local and the stress resultants.

UNITS AND CONVENTION, from the engine's own denormalisation: nx, ny, nxy, qx, qy are membrane forces and transverse shears per unit width, in force/length (N/m); mx, my, mxy are moments per unit width, in force (N.m/m, numerically N). mx is the moment PRODUCING sigma_x (conjugate to curvature about local y), not "the moment about x" — on a rectangular slab spanning the short way with local_x along the long side, the large resultant is my. The sign of mx/my/mxy follows the element normal, which follows the boundary/connectivity ordering, so reversing it flips all three; von Mises and |principal| are immune. qx and qy are identically ZERO for Kirchhoff/DKT plates by construction, so non-zero transverse shear is itself proof the Mindlin element was used. results..summary.total_plate_forces is a COUNT of plate results, not a force.

Give thickness and the tool derives the extreme-fibre stresses exactly as the engine's own plate unity check does: sigma_x = nx/t +/- 6mx/t^2, sigma_y = ny/t +/- 6my/t^2, tau_xy = nxy/t +/- 6mxy/t^2, evaluated at both fibres with the governing (larger von Mises) one reported, then vonMises = sqrt(sx^2 - sx.sy + sy^2 + 3txy^2) and the in-plane principals. Add yield_stress for a utilisation.

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": {
      "results": "<results>"
    },
    "name": "summarize_plate_results"
  }
}

Input Schema

NameRequiredDescriptionDefault
top_nNoHow many governing elements to list per quantity (default 5).
resultsYesA solved FERS document (or just its `results` block) from solve_model.
thicknessNoPlate thickness in metres — needed to turn moments and forces into extreme-fibre stresses.
quantitiesNoJSON array from: deflection, nx, ny, nxy, mx, my, mxy, qx, qy, von_mises, sigma_x, sigma_y, tau_xy, principal_max, principal_min.
yield_stressNoYield stress in Pa — adds a von Mises utilization if given.
case_or_combinationNoName of one load case or combination. Omit for all of them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover readOnly/idempotent/closed-world, but the description adds substantial context beyond that: units (N/m, N.m/m), the mx-vs-my conjugate-moment trap, sign flipping with element normal, qx/qy identically zero for Kirchhoff proving a Mindlin element, and that total_plate_forces is a count not a force. These are exactly the behavioral details that prevent misinterpretation.

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?

Purpose is front-loaded and the paragraphs are organized by concern (why needed, units/convention, what thickness derives). It is dense and long, and some of the formula detail sits closer to documentation than tool-selection guidance, but the content is domain-relevant and largely earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still characterizes the returned data (plate_results keyed by element id, centroid, centroid_displacement, stress resultants) and explains the conventions needed to read it correctly. For a 6-parameter analysis-summary tool, nothing an agent needs to call it correctly is missing.

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; the description still adds meaning for thickness and yield_stress by giving the exact extreme-fibre formulas and stating that yield_stress adds a utilisation. top_n, quantities, and case_or_combination are left to the schema, so it is not a full 5.

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 specific verb and resource: 'Reduce a solved FERS document to the plate numbers an engineer actually reads, and derive extreme-fibre stresses.' It also distinguishes itself from solve_model and run_unity_checks by declaring 'READ-ONLY: it returns a summary, not a model.'

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?

Explains why the tool is needed ('plate results cannot be read back through the model' because the mesh is on an internal working copy), which gives clear usage context tied to solve_model output. It does not explicitly name when-not to use it or route to a named alternative such as run_unity_checks, so it stops short of a 5.

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.