Skip to main content
Glama

FERS — structural FEM

Set buckling / design data

set_member_design
Read-only

Set the design (code-check) data that lives on a MemberSet — buckling restraints, buckling lengths, LTB length, effective-length factors — plus the per-member chi override.

THESE FIELDS CHANGE NOTHING IN THE STATICS. Displacements, reactions and member forces come back bit-identical; the values only feed the EN 1993-1-1 unity-check evaluator. If the model has no Ec3Steel unity check and a matching load combination you will see no effect at all anywhere in the results, so add one with add_unity_check first.

A MemberSet is one physical beam: the ordered chain of collinear FE members that make it up. Design lengths resolve per axis with this precedence: explicit buckling_length_* > effective_length_factor_* > buckling_restraints spacing > member length. WATCH THE TWO BASELINES — an explicit length and a restraint spacing are measured along the WHOLE chain, but effective_length_factor_y/z multiplies the length of the INDIVIDUAL FE member. Verified on a 6 m column split into 4 x 1.5 m members: buckling_length = 6.0 reproduces the default exactly, buckling_length = 12.0 quarters N_cr, but effective_length_factor = 2.0 gives L_cr = 3.0 m (2 x 1.5 m), not 12 m.

buckling_restraints are named by the member LOCAL axis they hold (restrains_local_y / restrains_local_z / restrains_torsion), not strong/weak — which one is strong depends on the section orientation and rotation_angle. A restraint's node_id must actually lie on one of the set's own members or the whole model fails validation.

chi is a per-MEMBER override of the EN 1993-1-1 flexural-buckling reduction factor. It replaces the section-curve chi for BOTH flexural axes (the slenderness stays physical) and is written onto every member of the targeted sets; pass "clear" to remove it.

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_set_ids": "<member_set_ids>"
    },
    "name": "set_member_design"
  }
}

Input Schema

NameRequiredDescriptionDefault
chiNoEN 1993-1-1 reduction factor override in (0,1], written onto every member of the set.
modelNoStringified FERS model JSON
model_refNoHandle from stash_model, used INSTEAD of `model`. Avoids sending the whole document on every step; the tool returns the same handle back.
ltb_lengthNoLateral-torsional buckling length.
classificationNoAlternative selector: exact match on the set's classification.
member_set_idsYesJSON array of member-set ids, or "all". Give this or `classification`.
buckling_length_tNoTorsional buckling length.
buckling_length_yNoL_cr about local y, in model length units, measured along the whole member chain.
buckling_length_zNoL_cr about local z.
set_classificationNoRename the set's classification.
buckling_restraintsNo[{"node_id":3,"restrains_local_y":true,"restrains_local_z":true,"restrains_torsion":true}]. Replaces the set's list; nodes must lie on the set's own members. [] clears them.
effective_length_factor_yNoK about y — multiplies the INDIVIDUAL element's length, not the chain's.
effective_length_factor_zNoK about z, same caveat.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Adds substantial context beyond the annotations: the values do not affect statics, results are bit-identical, a bad restraint node_id fails whole-model validation, chi is written to every member of targeted sets and replaces the section-curve value for both flexural axes. The description also implicitly reconciles readOnlyHint=true by explaining the operation only feeds the unity-check evaluator and changes no analysis output. The one residual gap is that it never says whether omitted fields are left untouched or cleared.

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?

Purpose is front-loaded in sentence one and every section carries non-redundant information, but the numeric walkthrough and the all-caps warnings make it longer than necessary; the worked example could be compressed without losing the chain-vs-element caveat.

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 13-parameter mutation with no output schema it covers targeting (ids vs classification), validation failure modes, prerequisite tooling, and unit/axis semantics. It is not fully complete because it never specifies partial-update behavior for fields omitted from the call, nor how member_set_ids and classification interact if both are supplied.

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 already 100%, and the description still adds meaning the schema cannot: the precedence chain (explicit length > K factor > restraint spacing > member length), the chain-vs-individual-member baseline for K factors with a worked 6 m / 4 x 1.5 m example, the local-axis meaning of restrains_local_y/z, and the undocumented 'clear' sentinel for chi.

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?

Opens with a specific verb and resource ('Set the design (code-check) data that lives on a MemberSet') and enumerates the exact field families it controls (buckling restraints, buckling lengths, LTB length, effective-length factors, chi). This is distinguishable at a glance from set_member and set_analysis 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?

States the precondition explicitly ('If the model has no Ec3Steel unity check and a matching load combination you will see no effect at all... so add one with add_unity_check first') and names the sibling to call first. It also gives the resolution precedence among the four design-length mechanisms, so the agent knows which parameter wins when several are supplied.

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.