FERS — structural FEM

Let a continuous beam turn on what it crosses

set_scissor_hinge

Read-only

Let a continuous beam turn or slide on the members it crosses (a scissor hinge, engine 0.2.68), with no link member or extra node: a rail resting on beams, a bracing pair crossing at a bolt. Name the beam by member_ids (or an existing member_set_id) and give the releases. Returns the model.

releases is an object over tx, ty, tz (translations) and rx, ry, rz (rotations): 0.0 FREES that axis, a positive number is a spring between the beam and the node (force/length for t*, forcelength/rad for r), and an axis you do not name is HELD — the same tristate as a member hinge. {"rz":0.0} lets a beam in the XY plane turn on what it crosses; {"tx":0.0} lets it slide along X.

The hinge goes on a MEMBER SET and applies wherever one of the set's members meets a member OUTSIDE the set (or a plate). Inside the set the members stay joined to each other, so the beam stays continuous. A set holding every member meets nothing and the solver refuses it, so when no set holds exactly these members they leave their sets for a new one; info lists the sets they were taken from. at_nodes limits the hinge to those nodes of the beam (a rail that slides over its first post only); omit it for every crossing.

axes: "Global" (the default) or {"User":{"x":[...],"y":[...]}} for a rack turned in plan — the first axis runs along x, the second along y made square to it. "Local" is refused: the set's members need not share one.

Supports and nodal loads at a released node act on the members outside the set, and a node's reported displacement is theirs; the beam's own motion there is in its members' local end displacements. The solver refuses a member point load or moment exactly at a released end of the beam. In second order, a model with scissor hinges takes the corotational correction only when analysis.options.nonlinear_method is COROTATIONAL. The model is written with schema_version 3, so an engine older than 0.2.68 refuses it instead of solving every crossing rigid. scissor_hinge_id reuses (and with releases or axes, rewrites) one definition for several beams; clear:true takes the hinge off the beam's set.

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

Input Schema

Name	Required	Description
`axes`	No	"Global" (default) or {"User":{"x":[1,0,0],"y":[0,1,0]}} for a frame turned in plan. "Local" is refused.
`clear`	No	Take the scissor hinge off the beam's member set.
`model`	No	Stringified FERS model JSON
`at_nodes`	No	JSON array of the beam's node ids where the hinge applies; omit for every node where the beam meets another member.
`releases`	No	Axes to release: {"rz":0.0} frees rotation about global Z, {"tx":0.0} lets the beam slide along X, a positive number is a spring (force/length for tx/ty/tz, force*length/rad for rx/ry/rz). An axis not named is HELD.
`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.
`member_ids`	No	JSON array of the continuous beam's member ids, e.g. [4,5,6]. They get a member set of their own unless one already holds exactly them.
`member_set_id`	No	Instead of member_ids: put the hinge on this existing member set.
`scissor_hinge_id`	No	Reuse this existing scissor hinge definition (and rewrite it when releases or axes are given).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Far beyond the annotations, it discloses the tristate release semantics (0.0 frees, positive = spring with units, unnamed = held), that the hinge attaches to a member set and only acts at crossings with members outside it, that the solver refuses a set containing everything, that the model is written with schema_version 3 and older engines reject it, the corotational requirement for second order, and that solver refusals occur for point loads at a released end. The one ambiguity is that readOnlyHint:true reads oddly against described document changes (members leaving sets, clear:true removing a hinge); the description never confirms it returns a new document rather than persisting changes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and identification are front-loaded, which is good, but the body is four dense paragraphs of multi-clause sentences, and the final paragraph is a grab-bag of caveats (supports and nodal loads, point-load refusals, corotational, schema_version, id reuse, clear). Most content earns its place, yet the length and density make the critical calling rules harder to extract than they need be.

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 9-parameter tool with no output schema it covers unusual ground well — returns the model, member-set side effects and where the affected members came from, solver refusals, engine version gating. The gap is that zero parameters are required, and the description never says that model or model_ref must be supplied (nor what error results if neither is).

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 the baseline is 3, but the description adds real meaning: the tristate rule for releases, units for the spring terms (force/length for t*, force*length/rad for r*), worked examples ({"rz":0.0}, {"tx":0.0}), what at_nodes scopes to ('a rail that slides over its first post only'), and how axes maps its two user vectors (first along x, second made square to it). These go well past the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the specific resource and effect — a scissor hinge that lets a continuous beam turn or slide on the members it crosses — and grounds it in concrete cases (rail on beams, bracing pair crossing at a bolt). It implicitly distinguishes itself from a member hinge by noting the same tristate 'as a member hinge' and by explaining the member-set scoping rule, though the phrasing 'let a continuous beam turn' is metaphorical rather than a clean verb+resource statement.

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?

Use contexts are given (rail resting on beams, bracing crossing at a bolt) and the three identification routes are contrasted: member_ids, an existing member_set_id, or reusing/rewriting a scissor_hinge_id. It also explains when to omit at_nodes and why 'Local' axes are refused. What is missing is an explicit 'use this instead of set_member/a member hinge when…' routing statement.

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.