FERS — structural FEM

Run code checks

run_unity_checks

Read-only

Solve a model and return its code-check (unity-check) results: per-entity utilizations, status, and the calculation trace behind each rule. The model's analysis.unity_checks must already be defined (see add_unity_check). On this hosted server the solve does NOT run here: the tool validates the model, parks it and returns an open_url that solves it in the user's browser, where the results are shown. Tell the user to open the link; for results inside the chat they can install the local FERS MCP server. Set include_report=true to also get the rendered HTML hand-calc report.

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

Input Schema

Name	Required	Description
`model`	No	Stringified FERS model JSON that includes analysis.unity_checks
`detail`	No	How much result data to return. 'summary' (peak forces, displacements and reactions with where they occur — smallest, usually enough), 'standard' (default: envelopes + node displacements + reactions), or 'full' (adds section forces and the complete internal-force series; can be hundreds of thousands of tokens on a real model).
`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.
`result_filter`	No	Advanced: emit only these result blocks, overriding `detail`. Any of: local_envelopes, global_envelopes, local_end_forces, global_end_forces, section_forces, internal_force_series, local_displacements, node_displacements, reactions. An empty list is a maximal strip. Unity checks, summaries and diagnostics are never filtered.
`include_report`	No	Embed the rendered HTML hand-calc report in the response. Default false — it is large. Use the free render_report tool on a saved result instead.
`idempotency_key`	No	Optional. Reuse when retrying so the retry is recognised as the same request.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The readOnlyHint annotation is already there, but the description adds crucial context the annotations cannot: the solve does not happen here — the model is validated, parked, and an open_url is returned for the user's browser, and the agent must tell the user to open it. It also warns that full detail and the embedded report are large responses.

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, then prerequisite, then the hosted-server caveat, then the report option — a logical order with no filler sentences. It is slightly dense with parentheticals, but every sentence carries information the agent needs.

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, six parameters, and an unusual hosted execution model, the description covers what the agent must know: what is returned, where the calculation actually runs, what URL to surface, and how to avoid oversized responses. There is no material gap for calling it correctly.

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 baseline is 3; the description still earns credit by recommending include_report=true only for the HTML hand-calc report and steering agents toward render_report on a saved result instead. It adds no extra semantics to detail, model_ref, result_filter, or idempotency_key, which the schema already covers well.

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 opening states a specific verb and resource — 'Solve a model and return its code-check (unity-check) results' — and enumerates what comes back (per-entity utilizations, status, calculation trace). 'Unity-check' is distinctive enough to separate it from the sibling add_unity_check (defines checks) and solve_model (plain analysis).

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 names the prerequisite explicitly ('analysis.unity_checks must already be defined (see add_unity_check)') and routes the agent to alternatives: install the local FERS MCP server for in-chat results, or use render_report instead of include_report=true. It never directly compares itself to solve_model, which is the most likely sibling confusion given both 'solve a model'.

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.