FERS — structural FEM

Solve a structural model

solve_model

Read-only

Run the FERS FEM solver on a structural model. Input is the full model JSON (as a string). Returns displacements, internal forces and reactions. 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. Results are returned at detail: standard by default — ask for 'summary' when you only need peak values, and 'full' only when you genuinely need every sample point.

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

Input Schema

Name	Required	Description
`model`	No	Stringified JSON of the FERS structural model
`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 the same value when retrying a solve so the retry is recognised as the same request.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations only say readOnly/openWorld=false, so the description carries the important burden and does: it discloses that the solve does NOT execute on this server but returns an open_url for browser execution — the single most non-obvious fact about the tool — plus the token cost of 'full' and the purpose of idempotency_key for retries. It stops short of describing failure modes when validation fails or how long the parked model lives, which keeps it off a 5.

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?

Dense and mostly front-loaded: purpose, input, return values come first, then the critical hosted-server caveat, then detail-level guidance. No filler sentences, though the hosted-server caveat arguably deserves to lead rather than sit in the third sentence.

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 six-parameter tool with no output schema, the description covers return content, the redirected execution model, the stash_model handle path, and detail tradeoffs — enough to call it correctly. What's missing is behavior on validation failure and what the open_url response looks like structurally, which would complete the picture.

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 earns above that by adding decision-relevant meaning — default detail: standard, when to downshift to summary, and that model_ref comes from stash_model as a substitute for the full model blob. result_filter and include_report are left to the schema, which is fine given their thorough field descriptions.

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 — run the FERS FEM solver on a structural model — and immediately qualifies what it returns (displacements, internal forces, reactions). The hosted-server caveat distinguishes it sharply from validate_model and run_unity_checks, so an agent knows exactly which sibling to pick.

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?

Explicitly tells the agent what to do in this environment (validate, park, hand the user the open_url) and names the alternative for in-chat results (local FERS MCP server). It also gives conditional guidance for each detail level: 'summary' when peaks suffice, 'full' only when every sample point 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.