The beam-analysis server is a lightweight MCP server for linear-static structural analysis of 3D beam and truss models — bridges and building frames — enabling you to build, analyze, visualize, and export structural models.
Environment Check: Verify availability of the built-in solver, CalculiX (ccx), and FreeCAD (freecadcmd) on the host machine.
Model Management: Create, list, inspect (counts, materials, sections, loads, bounding box), and delete models within the session.
Manual Model Building (step-by-step):
Add nodes (3D coordinates)
Add materials (Young's modulus, Poisson ratio, density, yield strength)
Add cross-sections (rectangle, box, pipe, circle, I-section, or generic)
Add members (beam for 6-DOF frame elements or truss for axial-only)
Add supports (fixed, pinned, roller, custom 6-flag, etc.)
Add loads (nodal forces/moments, member UDLs in global or local axes, self-weight)
Parametric Generation: Instantly generate complete structures from presets — girder/truss/arch/cable-stayed bridges, portal frames, multi-story moment/braced frames, and roof trusses — with customizable parameters.
Structural Analysis:
Built-in direct-stiffness beam solver (fast, Euler-Bernoulli, pure JS)
External calculix FEM solver (B32R beam elements)
Run both simultaneously for cross-validation
Retrieve nodal displacements, support reactions, member force envelopes (N, V, M, T), stresses, and utilization ratios (σ/fy)
Visualization: Render SVG figures showing geometry, deformed shape, and force/moment/stress diagrams.
Export: Export solid 3D models to FreeCAD (.FCStd) or write CalculiX input decks (.inp) without solving.
Export structural analysis models as solid 3D FreeCAD documents (.FCStd) that can be opened and inspected in FreeCAD.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@beam-analysis Generate a 3-span girder bridge and run analysis with both engines."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A lightweight MCP (Model Context Protocol) server for linear-static structural analysis of bridges and building frames, written in Node.js with no heavy dependencies.
It gives an AI client (Claude Desktop, Claude Code, Cursor, ...) tools to:
Build 3D beam/truss models (nodes, members, sections, materials, supports, loads) or generate complete structures from parametric typology presets (girder bridges, Pratt/Howe/Warren truss bridges, arch bridges, cable-stayed bridges, portal frames, moment frames, 3D braced buildings, roof trusses).
Analyze them with two engines:
beam — built-in 3D direct-stiffness frame solver (pure JavaScript, instant). Euler-Bernoulli elements with consistent fixed-end forces and exact in-span deflection/moment recovery — one element per member is enough.
calculix — writes a CalculiX input deck (B32R beam elements), runs ccx, and parses displacements/reactions. Use engine: "both" to cross-check the two solvers.
Export to FreeCAD — builds a solid 3D model of the structure and saves a .FCStd document you can open and inspect in FreeCAD.
Get member force envelopes (N, V, M, T), stresses, and utilization (σ/fy), reactions, and displacements.
No CalculiX install needed if you have FreeCAD: FreeCAD bundles
ccxwith its FEM workbench, and this server auto-detects it (e.g.C:\Program Files\FreeCAD 1.1\bin\ccx.exe).
Node.js ≥ 18
Optional: FreeCAD (provides both freecadcmd for export and the bundled CalculiX solver)
Optional: standalone CalculiX (ccx) if you don't use FreeCAD
Related MCP server: FreeCAD Robust MCP Server
git clone https://github.com/StructuralWizard/beam-analysis-mcp.git
cd beam-analysis-mcp
npm install
npm test # closed-form validation + MCP e2e + CalculiX cross-check
npm run typologies # analyze 10 bridge/building typologies with both enginesAdd to claude_desktop_config.json (or .mcp.json for Claude Code):
{
"mcpServers": {
"beam-analysis": {
"command": "node",
"args": ["C:/path/to/beam-analysis-mcp/src/server.js"]
}
}
}Optional environment variables:
Variable | Purpose |
| Explicit path to the CalculiX |
| Explicit path to |
| Default directory for exported |
Tool | Purpose |
| Report Node/ccx/freecadcmd availability and unit conventions |
| Create an empty model |
| List parametric typology generators and their defaults |
| Build a complete bridge/building from a preset + parameter overrides |
| Manual model building |
| Run linear-static analysis ( |
| Detailed displacements, reactions, or member force envelopes |
| Render an SVG figure: geometry, mesh, deformed shape, moment/shear/axial diagrams, stress/strain maps |
| Save a solid 3D |
| Write the CalculiX |
| Session management |
Preset | Typology |
| Simply supported or continuous girder bridge (1..n spans) |
| 3D through-truss bridge — |
| Deck arch bridge: parabolic rib + spandrel columns + deck girder |
| Single-pylon fan-pattern cable-stayed bridge |
| Gable portal frame (warehouse/industrial shed) |
| Multi-story multi-bay moment-resisting frame |
| Full 3D building with columns, two-way beams, perimeter X-bracing |
| Triangular (Howe-style) roof truss |
Example conversation with an MCP client:
"Generate a 3-span continuous girder bridge (30 m + 40 m + 30 m), analyze it with both engines, and export it to FreeCAD."
which maps to generate_structure {preset: "beam_bridge", params: {spans: [30,40,30]}} → analyze {engine: "both"} → export_freecad.
Units: SI — meters, Newtons, Pascals, kg/m³. Downward loads are negative fz/wz.
Axes: global +Z is up. Member local x runs along the member; for non-vertical members local z lies in the vertical plane, so section depth h resists gravity bending (strong axis = Iy).
Supports: fixed, pinned, roller (uz), roller-yz (bridge sliding bearing), planar-xz (out-of-plane restraint for 2D models), or a custom 6-flag string like "111100" (ux,uy,uz,rx,ry,rz).
Member types: beam (6-DOF frame element) or truss (axial only — braces, cables, truss webs).
Full test documentation — every test case, the theory it checks against, tolerances, and the investigation notes behind the cross-engine differences — is in docs/VALIDATION.md.
An illustrated per-structure validation report for all 10 typologies — geometry/supports/loads figures, CalculiX meshes, load cases with superposition checks, deformed shapes (built-in vs CalculiX overlay), moment/shear/axial diagrams, stress & strain maps, CalculiX von Mises fields parsed from .frd, and 35 analytical hand-calculation checks — is in docs/validation/.
npm test checks the solver against closed-form solutions:
Simply supported beam under UDL: 5wL⁴/384EI deflection and wL²/8 moment (exact to 1e-6)
Cantilever tip load / UDL: PL³/3EI, wL⁴/8EI, fixed-end moments
Two-bar truss axial force P/(2 sin θ)
Equilibrium (ΣR = ΣF) on every generator preset
Cross-validation against CalculiX (skipped automatically if ccx is not installed)
npm run typologies builds and analyzes 10 typologies end-to-end and prints a built-in vs CalculiX comparison table. Results on the reference machine (FreeCAD 1.1 bundled CalculiX 2.22, Windows 11):
# | Typology | Nodes/Members | Max defl. beam [mm] | Max defl. ccx [mm] | Diff | Equilibrium |
1 | Simply supported girder bridge (35 m) | 7/6 | 137.40 | 138.11 | 0.5% | ok |
2 | Continuous girder bridge (30+40+30 m) | 19/18 | 56.65 | 57.83 | 2.0% | ok |
3 | Pratt truss bridge (60 m) | 32/74 | 48.46 | 48.23 | 0.5% | ok |
4 | Warren truss bridge (64 m) | 34/79 | 69.51 | 69.27 | 0.3% | ok |
5 | Deck arch bridge (90 m) | 34/47 | 10.72 | 10.74 | 0.2% | ok |
6 | Cable-stayed bridge (140 m) | 15/26 | 118.90 | 118.72 | 0.2% | ok |
7 | Portal frame warehouse (30 m) | 5/4 | 136.30 | 131.22 | 3.7% | ok |
8 | 5-story moment frame | 24/35 | 5.60 | 5.59 | 0.3% | ok |
9 | 6-story 3D braced tower | 63/174 | 11.51 | 19.64 | 41%* | ok |
10 | Howe roof truss (28 m) | 16/29 | 13.86 | 13.22 | 4.6% | ok |
* Expected: the tower mixes several cross-sections, and CalculiX models joints between members of different sections as flexible "knots" (see Limitations). Re-run with uniform sections and the two engines agree within 6%.
Linear static only: no buckling, no dynamics, no P-Δ, no nonlinear cable sag (stays are modeled as linear truss members that can also take compression).
The two engines answer slightly different questions: the built-in solver assumes ideal rigid joints (classic beam theory), while CalculiX expands beams into solid elements and models joints between members of different sections as "knots", which are more flexible. Agreement is sub-1% on determinate structures and within a few % on frames with uniform sections, but expect larger differences (which ccx reports as a note) on tall 3D frames mixing many sections.
CalculiX backend reports displacements and reactions; member force envelopes come from the built-in engine.
I-sections and generic sections are mapped to an equivalent rectangle in the CalculiX deck (ccx beam sections support RECT/CIRC/PIPE/BOX only).
Results are for preliminary/educational analysis — not a substitute for design verification by a qualified engineer.
MIT
Add nodal loads [N, N·m], member uniformly distributed loads [N/m], and/or set the self-weight factor (1 = full gravity). Downward = negative fz/wz. UDL sys "global" (default) or "local" (member axes).
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| nodal | No | ||
| memberUDL | No | ||
| selfWeightFactor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details like sign convention (downward negative) and coordinate system options, which go beyond basic annotations. However, it does not mention whether loads replace or accumulate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the main purpose and key details, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers inputs adequately but lacks output schema info and does not specify whether loads are added incrementally or overwrite. Slightly incomplete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning: units, sign conventions, and sys enum semantics. However, it does not fully detail all parameters like wx, wy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds nodal loads, member UDLs, and self-weight factor, with specific units and sign conventions. It distinguishes well from sibling tools like add_members or add_supports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for load definition but does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria. No guidance on prerequisites or sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a material. E = Young's modulus [Pa], nu = Poisson ratio, density [kg/m3] (needed for self-weight), fy = yield/design strength [Pa] (needed for utilization checks). Example steel: E=210e9, nu=0.3, density=7850, fy=355e6.
| Name | Required | Description | Default |
|---|---|---|---|
| E | Yes | ||
| fy | No | ||
| nu | No | ||
| name | Yes | ||
| model | Yes | ||
| density | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as whether adding a material is destructive, requires authorization, or how it behaves if a material with the same name already exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences plus an example, which is efficient and front-loaded. It could be slightly more structured, but there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers parameter semantics and includes an example. However, it lacks details on return values, error conditions, or behavior on duplicate names, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must and does explain each parameter's meaning (E = Young's modulus, nu = Poisson ratio, density = for self-weight, fy = for utilization checks) and provides a helpful steel example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a material and enumerates the key parameters with their physical meanings (E, nu, density, fy). This distinguishes it from sibling tools like add_loads, add_members, etc., which handle different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor does it mention prerequisites (e.g., model must exist) or any order of operations. The description only explains parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add beam or truss members between existing nodes. type "beam" (default, 6 DOF frame element) or "truss" (axial only, for braces/cables/truss webs). rollDeg rotates the section about the member axis.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| members | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It explains beam vs truss (6 DOF vs axial) and rollDeg rotation, but doesn't disclose error behavior (e.g., if nodes don't exist) or side effects. Partially adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. First sentence defines purpose, second adds key details on type and rotation. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations or output schema, the description should cover more. It lacks explanation of how to specify node indices ('from', 'to'), section and material references, and array structure. Incomplete for a complex parametric tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains 'type' and 'rollDeg', but fails to clarify critical parameters like 'from', 'to', 'section', 'material', and the structure of the 'members' array. Only partial coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Add', resource 'beam or truss members', and context 'between existing nodes'. It distinguishes from sibling tools like add_nodes and add_loads by specifying the action and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly indicates that nodes must exist before adding members. No explicit when-not or alternative tool references, but the context is clear enough for an agent to understand basic usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add nodes to a model. Coordinates in meters, global +Z up. Node ids are optional (auto-assigned integers).
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| nodes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses coordinate system and optional ids, but omits behavior like model existence requirement, id conflict handling, and return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, no filler. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema info (return value, created node IDs) and prerequisites. Partially sufficient given tool simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description adds critical context: coordinate units (meters), orientation (+Z up), and id optionality. Provides meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Add' and resource 'nodes', differentiating from sibling tools like add_loads. Specifies coordinates and optional ids, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives, but implied context from sibling tools. The description does not guide on prerequisites like model existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a cross-section. Shapes and required params [m]: rectangle{b,h}, box{b,h,t}, pipe{d,t}, circle{d}, isection{b,h,tf,tw}, generic{A,Iy,Iz,J[,cy,cz]}. Convention: b = width (local y), h = depth (local z); for horizontal members local z is vertical, so Iy is the strong axis for gravity bending. Valid shapes: rectangle, box, pipe, circle, isection, generic.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| model | Yes | ||
| shape | Yes | ||
| params | Yes | Shape parameters, e.g. {"b":0.3,"h":0.6,"t":0.02} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the unit convention [m] and axis orientation, which is helpful. However, it does not mention whether the tool creates a new section, updates existing ones, or any side effects like overwriting. Basic behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words. It front-loads the action, then lists shapes and conventions efficiently. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the tool's complexity (multiple shape types with varying parameters), the description covers the input well but fails to mention what the tool returns (e.g., confirmation, ID). Missing return value info and no guidance on the 'name' and 'model' parameters, though they are standard.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only 'params' has a minimal description). The description compensates fully by listing each shape with its required parameters in a clear format, specifying units, and explaining the convention for b, h, Iy, Iz. This adds significant meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a cross-section' as the verb+resource, and lists all valid shapes with required parameters, making it unambiguous and distinct from sibling tools which deal with loads, materials, members, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. However, the sibling tools are all distinct (add_loads, add_members, etc.), so the context implies its use case. Lacks exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add supports at nodes. type is one of fixed, pinned, roller, roller-yz, planar-xz, or a 6-character 0/1 string for (ux,uy,uz,rx,ry,rz), e.g. "111100". "roller-yz" is a typical bridge sliding bearing; "planar-xz" restrains out-of-plane DOFs for 2D models in the XZ plane.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| supports | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only states 'Add supports' but does not disclose behavioral traits such as whether supports replace existing ones, if the tool is destructive, or any required permissions. The mutation aspect is implied but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the main purpose. It provides essential details about the type parameter without wasting words, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotation support, the description lacks completeness. It does not explain return values, preconditions (e.g., nodes must exist), or postconditions. The tool modifies the structure, but the description omits many contextual details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains the 'type' parameter with examples and meanings (fixed, pinned, roller-yz, planar-xz, or binary string). However, it does not explain the 'model' or 'node' parameters, which are left to the schema with no additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add supports at nodes' which specifies the verb and resource. It explains the type parameter with examples, distinguishing from sibling tools like add_loads or add_members. However, it could be more explicit about the specific structural context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives usage examples for the type parameter but does not provide guidance on when to use this tool versus alternatives (e.g., add_loads). It does not specify prerequisites like node existence or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run linear-static analysis. engine "beam" = built-in 3D direct-stiffness solver (fast, exact for Euler-Bernoulli frames); "calculix" = CalculiX FEM (B32R beam elements); "both" = run both and compare max displacements. Returns displacements, reactions, member force envelopes, stresses and utilization (stress/fy).
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | ||
| engine | No | Default "beam" | |
| subdivisions | No | CalculiX elements per member (default 4) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden. It details return values (displacements, reactions, etc.) but does not mention side effects like model mutation or data persistence. The description is informative but incomplete regarding behavioral impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences efficiently cover purpose, engine options, and outputs. Every clause adds value, and the structure is front-loaded with the core action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good detail on engines and outputs, the description does not clarify whether the results are directly returned or stored for later retrieval (e.g., via get_results). This gap could confuse an agent unfamiliar with the workflow. A brief note about result storage would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 2 of 3 parameters (engine and subdivisions) but the description adds significant meaning to the 'engine' parameter by explaining each option's solver and accuracy. The 'model' parameter lacks explanation, but the overall added value is strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run linear-static analysis' and specifies the three engine options (beam, calculix, both) with their characteristics. This distinguishes it from sibling tools that focus on model construction (add_loads, add_members) or data export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after model setup but does not explicitly state prerequisites or when not to use. No comparison with alternatives is given, leaving the agent to infer based on sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report availability of the built-in solver, CalculiX (ccx) and FreeCAD (freecadcmd) on this machine.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description indicates a safe read-only operation. Could detail return format (e.g., boolean or structured status) for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no wasted words. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple zero-parameter tool, but missing output schema details could slightly hinder agent understanding of what 'report' means.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist and schema coverage is 100%. Baseline 4 applies as description adds no extra meta-meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Report' and resource 'availability of built-in solver, CalculiX and FreeCAD', fully distinguishing from sibling modeling/analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies diagnostic use but lacks explicit guidance on when to use vs alternatives (e.g., before running analysis). No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new empty structural model. Use add_nodes/add_material/add_section/add_members/add_supports/add_loads to build it, or use generate_structure for common typologies.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Unique model name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses the tool creates an empty model, implying no destructive behavior. Could mention permissions or side effects, but for a simple creation tool, it's adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Purpose is front-loaded, followed by usage guidance. Highly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one parameter and no output schema. Description covers creation purpose and directs to sibling tools for further actions. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear description for the single parameter 'name'. Description adds no additional semantics beyond what schema provides, meeting baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a new empty structural model' with specific verb and resource. It distinguishes from sibling tools by referencing building tools like add_nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (to create an empty model) and provides alternatives: use add_nodes etc. to build it, or generate_structure for common typologies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a model from the session.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits such as permanence, error conditions, or dependencies. The bare 'delete' statement is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise, the description is under-specified. It is a single sentence that provides minimal value, so brevity does not outweigh the lack of informative content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is critically incomplete. It does not clarify side effects, session scope, or what 'delete' entails operationally.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'model' is a string with no description in the schema (0% coverage). The tool description adds no meaning beyond its name, leaving the agent to guess the expected format or value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a model from the session' uses a specific verb and resource, clearly distinguishing it from sibling tools like create_model and list_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites, or consequences. The description lacks any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write the CalculiX .inp input deck for the model (B32R beam elements) without running the solver.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Output .inp path (default: <output dir>/<model>.inp) | |
| model | Yes | ||
| subdivisions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. It only states the output is a .inp file without running solver. It fails to disclose error handling, file overwrite behavior, or whether the model must have certain properties (e.g., loads, supports).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, which is appropriate for a simple tool. However, it could benefit from a brief parameter overview without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is incomplete. It lacks parameter explanations and output behavior details. A more comprehensive description is needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%), with only 'path' described. The description does not explain 'model' or 'subdivisions' parameters, leaving their meaning and usage unclear. Adding parameter details would significantly improve this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a CalculiX .inp input deck for the model, specifying B32R beam elements and explicitly noting it does not run the solver. This distinguishes it from sibling tools like 'analyze' and 'export_freecad'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when only the input deck is needed, not analysis. However, it does not explicitly state when to use this tool versus alternatives like 'export_freecad', nor does it mention prerequisites like the model must exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a solid 3D representation of the model (member solids + support markers) and save it as a FreeCAD .FCStd document you can open in FreeCAD. Runs headless freecadcmd; takes ~5-20 s.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Output .FCStd path (default: <output dir>/<model>.FCStd) | |
| model | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool runs headless and gives a time estimate, but does not explain side effects (e.g., whether it modifies the model), required permissions, or error handling. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and content, second gives runtime and execution method. No extraneous words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a simple task, the description covers the main functional aspects. It mentions runtime and headless execution, but lacks details on failure modes or prerequisites (e.g., model must exist). Still, it is mostly complete for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; the path parameter has a description, model does not. The description adds context about the default path and export format but does not explain the model parameter beyond being required. The description partially compensates for missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Build a solid 3D representation...and save it as a FreeCAD .FCStd document'. It uses specific verbs and resources, and distinguishes it from sibling tools like export_calculix_inp which exports to a different format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (headless freecadcmd, ~5-20 s) and implies when to use (for FreeCAD export vs. other export formats). It does not explicitly state when not to use or provide alternatives, but the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a complete model (geometry, sections, supports, loads) from a parametric typology preset: beam_bridge, truss_bridge (pratt/howe/warren), arch_bridge, cable_stayed_bridge, portal_frame, moment_frame_building, braced_frame_building, roof_truss. Params override preset defaults (see list_structure_presets).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Model name (defaults to preset name) | |
| params | No | Overrides for the preset defaults, e.g. {"span": 80, "panels": 10, "type": "warren"} | |
| preset | Yes | Preset name, e.g. "truss_bridge" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool creates geometry, sections, supports, and loads, which is a clear behavioral summary. It could mention side effects like overwriting existing models, but the 'Create' verb implies no destruction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first sentence packs the core action and options; the second adds a crucial reference. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex parametric generation tool with no output schema, the description covers preset list, param override behavior, and the creation scope. It could mention that the output is a model object, but the completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by listing available presets and explaining that params override defaults with an example, going beyond bare schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('complete model... from a parametric typology preset'), listing exact presets like truss_bridge and noting parameter overrides. It clearly distinguishes from siblings like create_model and list_structure_presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that params override preset defaults and directs to list_structure_presets for details, providing clear context for use. However, it does not explicitly exclude cases or mention alternatives beyond the preset listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve detailed results from the last analysis: "displacements" (per node), "reactions" (per support), or "member_forces" (end forces + envelopes per member). Optionally filter by ids.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Node ids or member ids to filter | |
| what | Yes | ||
| model | Yes | ||
| engine | No | Default "beam" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates a read-only operation ('retrieve'), with no hint of side effects. For a simple retrieval tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and types, then the filter option. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and filter, but lacks explanation of the 'engine' parameter and the output format. Given the complexity (4 parameters, no output schema), it is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, meaning two parameters lack schema descriptions. The description adds meaning for the 'ids' parameter (explaining it filters by node or member ids) and lists the 'what' options, but does not mention the 'engine' parameter. This adds some value beyond the schema but not full compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'detailed results', listing the three result types (displacements, reactions, member_forces). This distinguishes it from sibling tools like analyze or add_loads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that results come from 'the last analysis', implying it should be used after an analysis has been run. It does not explicitly state when not to use or provide alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all models in this session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as idempotency, what happens with no models, or the format of the returned list. The description is too minimal to guide agent expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should describe what information the listing returns (e.g., model IDs, names). It does not, leaving the agent without crucial context about the tool's output. Additionally, the description is incomplete for a 'list' operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema coverage is 100% trivially. The description adds no parameter-level detail, but the 'in this session' phrase provides contextual scope. According to guidelines, zero parameters warrant a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list') and the resource ('all models in this session'), making the tool's purpose unambiguous. It distinguishes from siblings like create_model and delete_model, and the session scoping is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing models but provides no explicit guidance on when to use this tool versus siblings like model_info (for details) or get_results. No when-not-to-use advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List parametric structure generators (bridge and building typologies) with their default parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It implies a read-only operation with no side effects but does not explicitly state that it is safe or non-destructive. The description is adequate but lacks explicit behavioral disclosure beyond the implied listing action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, front-loaded with the action 'List,' and contains no unnecessary words or repetition. It is extremely concise while conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no parameters and no output schema, the description provides basic purpose but does not detail the format or content of the returned presets (e.g., fields, structure). It is minimally complete for a simple tool but could benefit from mentioning what information each preset entry contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%. The description adds meaning by stating the output includes 'default parameters,' which is relevant context. For a parameter-less tool, the baseline is 4, and the description meets this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists parametric structure generators (bridge and building typologies) with their default parameters. The verb 'list' and resource 'structure presets' are specific, and the description distinguishes this from siblings such as 'generate_structure' and 'list_models'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no context about prerequisites or typical use cases. It simply describes what it does without usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summary of a model: counts, materials, sections, loads, bounding box.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists the returned summary items, but lacks details on behavior such as read-only nature, error handling for missing models, or any side effects. No annotations are provided, so the description carries full burden; it is adequate but not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key information. It is not verbose, but every word contributes. Could be slightly expanded without losing structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and no output schema, the description provides the core return fields but omits details on preconditions (e.g., model existence) and error conditions. The context from sibling tools implies some usage context, but the description itself is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'model' is a string with no description in the schema (0% coverage). The tool description does not clarify the expected format (e.g., model name or ID). The description adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a summary of a model, including specific attributes like counts, materials, sections, loads, and bounding box. It effectively distinguishes from sibling tools like analyze or list_models by focusing on static model metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., model must exist) or exclusions (e.g., not for analysis results). The agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose. The add_* tools each add a different aspect (nodes, materials, sections, members, supports, loads), and all other tools (analyze, export, list, delete, etc.) are uniquely identifiable. There is no overlap or confusion between tools.
Most tool names follow a consistent verb_noun pattern (e.g., add_nodes, list_models, get_results). However, 'model_info' is a noun_info construction and 'analyze' is a bare verb, which deviates slightly from the predominant pattern, so it is not perfectly consistent.
With 17 tools, the server covers a comprehensive workflow for parametric structural analysis: model creation, component addition, analysis, results retrieval, export, and management. The count is well-scoped for its domain, each tool earning its place.
The tool set covers the core workflow (create, add components, analyze, get results, export), but lacks update or delete operations for individual components (e.g., no tool to modify a node or remove a member). This is a notable gap for iterative design, though the essential lifecycle is present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
This MCP server enables users to perform scientific computations regarding linear algebra and vect…
A MCP server built for developers enabling Git based project management with project and personal…
Token-free MCP server for structured RevoGrid Core, Pro, and Enterprise knowledge retrieval.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/StructuralWizard/beam-analysis-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server