Skip to main content
Glama
Sign In

FERS — structural FEM

by com.ferscloud
OverviewDiscussionsAdmin

Set member behaviour

set_member
Read-only

Set structural behaviour on one or more existing members: element type, end releases (hinges), rigid end offsets, cross-section rotation/mirroring and cable parameters. Mutates model.members (and model.member_hinges when a release is authored) and returns the model.

member_type: Normal (full 6-DOF beam), Truss (axial only — carries exactly zero moment), Tension (tie that drops out in compression), Compression (strut that drops out in tension), Rigid (near-rigid link; produces NO entry in results.member_results at all) or Cable (analytic elastic catenary; forces the whole solve onto the nonlinear path and only sags when analysis.options.enable_self_weight is true). Tension/Compression drop-out is governed by analysis.options.axial_slack in FORCE units — a member switches off when its axial force passes 0.5*axial_slack on the wrong side — so this tool lowers axial_slack to 1e-3 when it writes one (set keep_axial_slack to skip). With a coarse axial_slack the member never drops out and quietly behaves like a plain Truss. To build a truss use member_type Truss: two double-hinged Normal members meeting at a free node give a singular stiffness matrix.

END RELEASES ARE A TRISTATE and that is the whole point: for each release DOF, null (or simply not naming it) = RIGID, 0.0 = FULLY RELEASED, and a positive number = a spring of that stiffness (force/length for vx/vy/vz, force*length/rad for mx/my/mz/warp). Release DOFs are in the MEMBER LOCAL frame. Verified on an encastre beam under UDL: mz null gives support moment wL^2/12 and midspan wL^2/24; mz 0.0 gives 0 and wL^2/8, i.e. exactly simply supported. Each release object fully defines that end's hinge — DOFs you do not name are written as rigid — and passing "rigid" clears the release. A rotational release is rejected when it would leave a node with NO rotational stiffness at all, because that is a hard "Stiffness matrix is singular or near-singular": either a dead-end node (no other member frames in and the support does not restrain it) or a node where every member meeting there releases the same DOF. Note the asymmetry the check has to respect — an absent RX/RY/RZ on a support is read as FIXED, but an absent warping_condition really is free, so a plain pinned support does NOT hold a warp release. Releasing the same vx, vy, vz or mx at BOTH ends of one member is refused outright: that one is fatal at the element level whatever the model looks like ("apply_end_releases_to_local_beam_k: interface block is singular"), while my/mz/warp at both ends is just an ordinary pin-pin beam.

A release object may also carry rotation_axes: "Global" or {"User":{"x":[...],"y":[...]}} takes mx/my/mz, their curves and their moment-rotation diagrams about those axes instead of the member's own — a beam at an angle in plan, pinned about the axis of the girder it hangs from, needs {"mx":0.0,"rotation_axes":"Global"}. A user frame's first axis runs along x and its second along y made square to it. Translations stay member-local, member results stay in member axes, and the axes stay fixed in space on the corotational path. A model whose hinges release in other axes is written with schema_version 3 (engine 0.2.68), so an older engine refuses it instead of solving the release about the member's axes.

MemberHinge also carries seven capacity fields (max_tension_*, max_moment_*, max_bimoment_warp). They are accepted by the schema and carried through the model but are NEVER ENFORCED by the solver: nothing limits a hinge force by them and they trigger no nonlinearity. Do not author "yielding" hinges with them — this tool does not write them.

Offsets (start_offset/end_offset) are rigid arms between the node and the member work point in the GLOBAL frame, in model length units. rotation_angle_deg rolls the cross-section about the member axis in DEGREES, not radians: on a vertical column FERS builds the local frame from global Z, so sway along global X is resisted by the WEAK axis i_y unless you rotate 90 degrees (verified 13.8x difference on a cantilever column, with no warning from the solver). pretension is valid ONLY on Cable/Tension/Compression (a hard validation error elsewhere) and pins a tie permanently active; unstretched_length only does anything on a Cable and is silently ignored everywhere else. Sign convention for reading results back: local_start_forces.fx is COMPRESSION-POSITIVE.

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": {
      "member_ids": "<member_ids>"
    },
    "name": "set_member"
  }
}

Input Schema

NameRequiredDescriptionDefault
modelNoStringified FERS model JSON
mirrorNoMirror the cross-section.
model_refNoHandle from stash_model, used INSTEAD of `model`. Avoids sending the whole document on every step; the tool returns the same handle back.
end_offsetNoSame, at the end.
member_idsYesJSON array of member ids, e.g. [1,2,3], or the string "all".
pretensionNoCable / Tension / Compression members only.
end_releaseNoSame, at the END node.
member_typeNoNormal | Truss (pin-jointed, axial only) | Tension (drops out in compression) | Compression | Rigid | Cable.
start_offsetNoRigid arm at the start, GLOBAL frame, model length units: {"X":0,"Y":0.2,"Z":0}. null removes it.
start_releaseNoEnd release at the START node, in the MEMBER LOCAL frame: {"mz":0.0} releases the major-axis moment. CAREFUL: an unnamed DOF or null means RIGID, 0.0 means FULLY RELEASED, and a positive number is a rotational spring (N·m/rad). Add "rotation_axes":"Global" (or {"User":{"x":[...],"y":[...]}}) to take mx/my/mz about other axes. Use "rigid" to clear.
keep_axial_slackNoLeave analysis.options.axial_slack untouched.
rotation_angle_degNoRoll the cross-section about the member axis, in DEGREES. Use 90 on the columns of an XY-plane frame.
unstretched_lengthNoCable members only.

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 explicitly says the tool mutates model.members and model.member_hinges and returns the model, while the annotations declare readOnlyHint=true. That is a direct contradiction between the description's mutation behaviour and the structured safety 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 purpose is front-loaded in the first sentence and the remaining paragraphs are organised by parameter concern. It is dense and long, but most detail earns its place given the complexity of releases and nonlinear cable behaviour.

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?

For a complex 13-parameter mutation tool with no output schema, the description covers side effects, returned model, validation failures, solver behaviour, sign conventions, and parameter interactions. Nothing essential for correct invocation appears missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is already 100%, the description adds critical meaning the schema cannot: the tristate release semantics, local versus global release axes, spring units, offset frame, degree-based rotation_angle_deg, pretension restrictions, and ignored cable fields. This is exactly the kind of semantic depth that prevents incorrect calls.

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 first sentence states a precise verb and resource: set structural behaviour on existing members. It enumerates the specific behaviours controlled (element type, releases, offsets, rotation, cable parameters), so an agent can distinguish this from creation or design tools.

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?

The description gives clear usage conditions for many parameters, including truss guidance, cable-only fields, axial_slack behaviour, and the warning not to author yielding hinges. It does not explicitly route the agent away from sibling tools such as set_scissor_hinge or create_beam, so it stops short of full alternative selection guidance.

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 toolsInspect
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.

Resources