Skip to main content
Glama

FERS — structural FEM

Set a support condition

set_support
Read-only

Write a nodal support (boundary condition) and point one or more nodes at it: creates or overwrites an entry in model.nodal_supports and sets node.nodal_support on every node you name. Returns the updated model — feed it to solve_model.

All 7 DOFs are set independently, in the GLOBAL frame: X/Y/Z (translations), RX/RY/RZ (rotations about the global axes) and warping (the 7th DOF, only live when analysis.options.include_warping is true and the section has i_w). Condition types are case-sensitive: Fixed (rigid), Free (no restraint), Spring (needs the matching _stiffness > 0 — N/m for translations, N*m/rad for rotations), PositiveOnly (one-way: may only push in the +global direction, i.e. lift-off) and NegativeOnly (the mirror image). A one-way condition may also carry a _stiffness, which from engine 0.2.65 is the bedding stiffness it acts through while in contact — a base plate on a slab is not infinitely stiff. Released, it is free regardless. On 0.2.64 and earlier that number was accepted, range-checked and then silently discarded, so the model solved as rigid contact.

THERE IS NO "FREE BY OMISSION". Once a node references a support, any DOF you leave out is treated by the solver as FULLY FIXED — a support of literally {"id":1} is an encastre, and the OpenAPI text claiming an absent field means free is wrong. This tool therefore always writes all six translation/rotation conditions explicitly, and anything you do not name is written as Free. Use preset to fill them in one go: fixed (encastre), pinned (X/Y/Z fixed, rotations free), free, roller_x/roller_y/roller_z (ONLY that translation fixed, everything else free), ground_contact_y (X/Z fixed, Y PositiveOnly, rotations free — a base plate that can lift off). Per-DOF fields are applied on top of the preset. Warping is the one exception: leaving it out really does mean free.

ONE-WAY SUPPORTS have a prerequisite this tool checks for you: analysis.options.rigid_strategy must be RigidMember (LinearMpc is a hard validation error). Tension/Compression members are fine alongside them from engine 0.2.65 -- before that the combination was refused at validation, so if you are reading advice written against an older engine, that restriction is gone. There is also a SILENT prerequisite — the release tolerance is 0.5*axial_slack in force units, so a coarse axial_slack leaves the DOF engaged while still reporting its reaction as 0, and the printed reactions stop summing to the applied load. This tool lowers axial_slack to 1e-3 when it writes a one-way condition (set keep_axial_slack to skip that). Beware that a support which lifts off can leave the structure unrestrained, and that a one-way support can break an eigen solve if the model also has a modal or buckling block.

Reactions use ONE SIGN CONVENTION for every support type from engine 0.2.60: each row is the force the support applies to the structure, so reactions can be summed against the applied load without checking which kind of support produced each one. (Up to 0.2.59 a Spring DOF reported the spring force k*u, the negative of what a Fixed DOF reported for the same physical situation. If you are reading results solved on an older engine, that flip is still in them.) A stiffness curve (stiffness_curves) makes the spring load-dependent, forces the DOF to Spring and requires a NONLINEAR analysis order — and note its driver is the EXTERNAL nodal load at that node, not the reaction, so a base-plate curve with no direct nodal load degenerates to the first point's stiffness.

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": {
      "node_ids": "<node_ids>"
    },
    "name": "set_support"
  }
}

Input Schema

NameRequiredDescriptionDefault
XNoFixed | Free | Spring | PositiveOnly | NegativeOnly (global X translation).
YNoSame, global Y (vertical in these models).
ZNoSame, global Z.
RXNoSame, rotation about global X.
RYNoSame, rotation about global Y.
RZNoSame, rotation about global Z.
modelNoStringified FERS model JSON
presetNofixed | pinned | free | roller_x | roller_y | roller_z | ground_contact_y. Applied first; the per-DOF fields below then override it.
warpingNoWarping DOF condition.
node_idsYesJSON array of node ids to support, e.g. [1,2], or the string "all". They all share one support definition.
model_refNoHandle from stash_model, used INSTEAD of `model`. Avoids sending the whole document on every step; the tool returns the same handle back.
support_idNoOverwrite this existing nodal_supports entry; omit to allocate a new one.
X_stiffnessNoN/m — required when X is Spring.
Y_stiffnessNoN/m — required when Y is Spring.
Z_stiffnessNoN/m — required when Z is Spring.
RX_stiffnessNoN·m/rad — required when RX is Spring.
RY_stiffnessNoN·m/rad — required when RY is Spring.
RZ_stiffnessNoN·m/rad — required when RZ is Spring.
classificationNoFree-text label.
keep_axial_slackNoLeave analysis.options.axial_slack untouched when writing a one-way support.
stiffness_curvesNoNonlinear support springs: {"Y":{"depends_on":"Fy","points":[[0,1e5],[10000,1e6]]}}. Forces that DOF to Spring and the analysis to NONLINEAR.
warping_stiffnessNoRequired when warping is Spring.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Goes far beyond the annotations: the 'FREE BY OMISSION' encastre gotcha, the silent axial_slack release tolerance that fakes a zero reaction, the engine-version behavior changes (0.2.60 sign flip, 0.2.64 discarded stiffness, 0.2.65 tension/compression, pre-0.2.65 warp), the eigen-solve hazard, and the stiffness-curve driver caveat (external nodal load, not reaction). The readOnlyHint=true annotation sits in some tension with 'creates or overwrites', but the model is an in-memory document passed in and returned, so this reads as consistent rather than contradictory — and the description is carrying the real behavioral weight here.

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 the purpose before the caveats, and essentially every sentence carries load (engine-version deltas, silent prerequisites, sign convention). It is a dense wall of text, though — the engine-version asides could be segmented or deferred, and the sheer length makes scanning harder for an agent.

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 22-parameter mutation tool with no output schema, the description covers the failure modes, prerequisites, cross-tool contract (solve_model), and result-interpretation guidance (sign convention, reaction sanity check). Nothing an agent needs to call it correctly or interpret its output is 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?

Schema coverage is 100%, so baseline is 3, but the description adds substantial meaning beyond it: preset composition semantics, the warping-is-exempt-from-free-by-omission exception, and the meaning of <DOF>_stiffness on one-way supports (bedding stiffness while in contact, units called out). It explains why Spring requires <DOF>_stiffness>0 rather than just restating the field.

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?

First sentence gives a specific verb (write/create-overwrite), resource (nodal_supports entry), and side effect (sets node.nodal_support on named nodes), plus the downstream contract ('feed it to solve_model'). An agent can distinguish this from set_member, set_analysis, or add_load without opening the schema.

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 states when to use presets vs per-DOF fields (preset applied first, per-DOF overrides), when warping applies (include_warping + i_w), and the prerequisites for one-way supports (rigid_strategy=RigidMember, keep_axial_slack). Names alternatives (preset values) and the exact failure conditions rather than leaving them to inference.

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.