Engineer MCP is a Model Context Protocol server that provides verified mechanical-engineering calculations to AI coding agents, with full provenance on every result — formulas, methods, cited sources, and explicit warnings.
Available tools:
beam_bending — Bending stress, deflection, and safety factor for simply supported or cantilever beams under point/uniform loads. Supports rectangle, circle, hollow circle, I-beam, and box cross-sections (Euler-Bernoulli theory, cited to Roark's and Mechanics of Materials).
section_properties — Area, moments of inertia, section moduli, and radius of gyration for standard cross-sections (rectangle, circle, hollow circle, I-beam, box).
bolt_strength — Tensile stress area, proof strength, recommended preload, and safety factor for metric bolts (M5–M36 coarse threads, ISO 898 classes like 8.8 and 10.9).
spring_design — Spring rate, shear stress, solid height, deflection, working length, Wahl factor, and safety factor for helical compression springs (round wire, squared and ground ends, per Shigley's and Machinery's Handbook).
shaft_analysis — Torsion stress, angle of twist, and first lateral critical speed for solid or hollow shafts.
bearing_life — ISO 281 basic rating life L10 in revolutions and hours for ball and roller bearings.
von_mises — Equivalent stress, maximum shear stress, and yield safety factor from principal (σ1–σ3) or Cartesian stress components (2D/3D).
unit_convert — Dimension-safe conversion between compatible units (e.g., MPa↔psi, mm↔in), with rejection of incompatible conversions (e.g., N·m to J).
material_lookup — Curated database of common engineering materials, searchable by name with case-insensitive matching.
Key guarantees: Pure-function calculation engines (deterministic, offline, ~98 tests), unit-dimension checking throughout, provenance with every output (method, formula, references), and no hidden assumptions — safety factors appear only when yield strength is provided.
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., "@engineer-mcp What's the bending stress on a 3m steel beam with a 20kN center load?"
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.
Engineer MCP is a Model Context Protocol server for mechanical-engineering calculations. It gives coding agents verified answers for beams, bolts, springs, shafts, bearings, stress, sections, fits, and units. Every result shows the formula, the method, and the source.
Use Engineer MCP inside an AI coding agent. The agent calls a tool and receives a complete engineering answer. The answer includes numbers, units, assumptions, and citations.
The release covers these domains:
Beam bending stress and deflection.
Bolt tensile design to ISO 898.
Helical compression spring design.
Shaft torsion and first critical speed.
Bearing rating life to ISO 281.
von Mises equivalent stress.
Fatigue analysis for cyclic loads.
Cross-section properties.
Press and shrink fit analysis by Lamé theory.
Standard steel section catalog to EN 10365. The catalog returns the separate source for published section properties.
Bearer authentication and browser origin allow-lists for HTTP clients.
Dimension-safe unit conversion, including viscosity and thermal conductivity.
Material property lookup.
Stdio and HTTP transports. The HTTP mode serves the same tools over the Streamable HTTP protocol.
Related MCP server: eq-reference-mcp
Each result carries its provenance. The envelope lists the method, the formula, and the notes. It also lists the cited standards and texts.
Units are checked at every step. The unit layer knows the dimension of every unit. It rejects a conversion between incompatible quantities. For example, it rejects a torque-to-energy conversion.
Safety factors appear only when you provide the data they need. The tool never hides an assumption. Warnings surface when a method uses an approximation.
Tool | What it does |
| Bending stress, deflection, and safety factor. |
| Area, inertia, and section modulus of a shape. |
| Stress area, preload, and capacity of a bolt. |
| Interface pressure, hoop stresses, and friction capacity of a press or shrink fit. |
| Spring rate, shear stress, and safety factor of a compression spring. |
| Torsion stress, twist, and critical speed. |
| ISO 281 rating life in revolutions and hours. |
| Equivalent stress and yield safety factor. |
| Endurance limit and fatigue safety factor for cyclic loads. |
| Conversion between compatible units. |
| Curated mechanical properties of materials. |
| Published IPE, HEA, HEB, and UPN steel sections. |
See docs/mcp-tools.md for the full reference. See docs/section-catalog.md for the covered range, the value provenance, and the data audit. See docs/units.md for the unit model and the full category list. See docs/transport.md for the HTTP transport reference.
Engineer MCP keeps the math separate from the server. Pure engine functions take SI numbers and return plain objects. The server layer adds unit conversion, material lookup, and provenance. The database seeds from JSON files on first start.
flowchart LR
Agent[AI coding agent] -->|stdio| Server[MCP server]
Agent -->|HTTP| Security[HTTP security policy]
Security --> Server
Server --> Tools[Tools layer]
Tools --> Engines[Calculation engines]
Tools --> Units[Unit layer]
Tools --> Db[SQLite data]
Engines --> Provenance[Method and references]Key directories:
Path | Role |
| Pure calculation functions. |
| Dimension-safe unit conversion. |
| SQLite schema and seeding. |
| Tool orchestration and result envelopes. |
| Streamable HTTP transport and session registry. |
| Bearer authentication and browser-origin policy. |
| CLI entry point and transport selection. |
| Material, fastener, section, and reference data. |
Install Node.js 22.13 or newer.
Clone or copy this repository to your machine.
Run npm install to install dependencies.
Run npm run build to compile the server.
Run npm run demo to see the demo output.
The demo prints results for every tool. It runs against an in-memory database. It needs no API keys and no network access.
Configure HTTP authentication with ENGINEER_MCP_AUTH_TOKEN.
Configure browser access with ENGINEER_MCP_ALLOWED_ORIGINS.
Run the server over standard input and output.
node dist/index.jsAdd it to your MCP client configuration.
See examples/mcp-config.example.json for a template.
Set ENGINEER_MCP_DB or pass --db <path> to choose the database file.
The default database file is engineer-mcp.sqlite in the working directory.
Run the server with the HTTP transport.
node dist/index.js --transport httpThe server listens on http://127.0.0.1:3000/mcp.
Set --host and --port to change the bind address.
Set --response-mode sse when the client requires Server-Sent Events.
The default response mode is JSON.
Set ENGINEER_MCP_TRANSPORT, ENGINEER_MCP_HOST, and ENGINEER_MCP_PORT to configure the same values.
Set ENGINEER_MCP_HTTP_RESPONSE_MODE to json or sse.
See docs/transport.md for client configuration and curl examples.
Use a port of 0 to let the operating system choose a free port.
The server prints the real port to standard error.
A call to beam_bending with a 20 kN point load on a 3 m S355 I-beam:
Maximum bending moment 15 kN·m
Maximum bending stress 25.36 MPa
Maximum deflection 0.6039 mm
Bending safety factor 14
Method: Euler-Bernoulli beam theory
Formula: simply supported, point: M = FL/4, delta = FL^3/(48EI)
References:
- Roark's Formulas for Stress and Strain (Eighth edition, 2011)
- Mechanics of Materials (Euler-Bernoulli beam theory)A call to spring_design for a steel spring under 2 kN with squared and ground ends:
Spring index 5
Wahl factor 1.31
Total coils 6
Solid height 48 mm
Spring rate 158.6 N/mm
Deflection at load 12.61 mm
Working length 77.39 mm
Maximum shear stress 521.4 MPa
Spring safety factor 1.342
Method: Helical compression spring design
Formula: C = D/d, K_w = (4C-1)/(4C-4) + 0.615/C, tau = K_w 8FD/(pi d^3), k = G d^4/(8 D^3 Na), delta = F/k, Ls = d Nt
References:
- Shigley's Mechanical Engineering Design (Tenth edition, 2015)
- Machinery's Handbook (Thirty-first edition)A call to interference_fit for a steel hub on a solid steel shaft with 50 µm of diametral interference:
Interface pressure 77.62 MPa
Hub tangential stress 129.4 MPa
Shaft tangential stress 77.62 MPa
Axial force capacity 73.16 kN
Torque capacity 1.829 kN·m
Shaft safety factor 3.865
Hub safety factor 1.656
Torque safety factor 1.829
Method: Interference fit by Lamé thick-cylinder theory
Formula: p = delta / (d K); K = (1/Eh)((Ro^2+r^2)/(Ro^2-r^2)+nu_h) + (1/Ei)((r^2+ri^2)/(r^2-ri^2)-nu_i); F = 2 pi r L p mu; T = F r
References:
- Shigley's Mechanical Engineering Design (Tenth edition, 2015)
- Machinery's Handbook (Thirty-first edition)
- Theory of Elasticity (Lamé solution for thick-walled cylinders)A call to fatigue_analysis for a ground steel part at 90% reliability with a 120 MPa alternating stress on an 80 MPa mean stress:
Endurance limit 280.5 MPa
Static yield safety factor 2.9
Fatigue safety factor 1.839
Method: Fatigue analysis by endurance limit and mean-stress criterion
Formula: Se' = 0.5 Sut for steel, Se = ka kb kc kd ke kf Se', 1/n = sigma_a/Se + sigma_m/Sut
References:
- Shigley's Mechanical Engineering Design (Tenth edition, 2015)A call to unit_convert with a torque-to-energy request fails safely:
Error: Category mismatch: N·m is torque, J is energy.
Use a unit of the same quantity.A call to unit_convert for a 100 cP lubricant converts to the SI unit:
Converted value 0.1 Pa·s
Value of 100 cP expressed in Pa·s.
Value of 100 cP in the SI base unit Pa·s.
Factor: 0.001 (dynamic viscosity)A call to unit_convert for copper with 401 W/(m·K) converts to the imperial unit:
Converted value 231.7 BTU/(ft·h·°F)
Value of 401 W/(m·K) expressed in BTU/(ft·h·°F).
Value of 401 W/(m·K) in the SI base unit W/(m·K).
Factor: 1 (thermal conductivity)A call to section_catalog for the HEB series returns the published sections:
Rows:
- HEB 100 | h 100 mm | I 450 cm4 | W 89.9 cm3 | 20.4 kg/m | dims en-10365 | props arcelormittal-sections
- HEB 120 | h 120 mm | I 864 cm4 | W 144 cm3 | 26.7 kg/m | dims en-10365 | props arcelormittal-sections
- HEB 140 | h 140 mm | I 1509 cm4 | W 216 cm3 | 33.7 kg/m
- HEB 160 | h 160 mm | I 2492 cm4 | W 311 cm3 | 42.6 kg/m
Method: Standard section catalog lookup
References:
- EN 10365 - Hot rolled steel channels, I and H sections - Dimensions and masses
- European sections - dimensions and section propertiesPass a catalog designation to beam_bending to use the published section properties:
Maximum bending moment 15 kN·m
Maximum bending stress 26.93 MPa
Maximum deflection 0.6411 mm
Bending safety factor 13.18
References:
- Roark's Formulas for Stress and Strain (Eighth edition, 2011)
- Mechanics of Materials (Euler-Bernoulli beam theory)
- EN 10365 - Hot rolled steel channels, I and H sections - Dimensions and masses
- European sections - dimensions and section propertiesIn SSE mode, an initialize response uses this event format:
event: message
data: { "jsonrpc": "2.0", "id": 1, "result": ... }The same tools run over HTTP.
Start the server with --transport http, then start a session with curl:
curl -s -D - http://127.0.0.1:3000/mcp \
-H "content-type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"curl","version":"1.0"}}}'The response carries the session id in the Mcp-Session-Id header.
Send that header on every later request:
curl -s http://127.0.0.1:3000/mcp \
-H "content-type: application/json" \
-H "mcp-session-id: <session id>" \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}'See docs/transport.md for the full HTTP reference.
Command | Purpose |
| Run the TypeScript compiler. |
| Run the deterministic test suite. |
| Emit |
| Run the end-to-end demo. |
| Run the HTTP transport smoke check. |
| Start the server from source. |
The test suite is deterministic and offline. It covers the engines, the unit layer, the database, the tools, the catalog data, and the HTTP transport.
189 tests across 15 files.
The CI matrix tests Node 22 and Node 24.
The HTTP tests run a real server on an ephemeral port. They complete the full handshake over a real TCP connection. They cover JSON and Server-Sent Events responses.
The CI workflow runs typecheck, tests, build, demo, a package check, and the HTTP smoke check.
The CI workflow verifies the CLI contract over standard output.
The CI workflow verifies both transport modes.
Run npm test to reproduce the results.
The beam theory applies to small elastic deflections.
The material table covers common engineering grades only.
The bolt tables cover coarse metric threads from M5 to M36.
The bearing factors are typical values for deep-groove ball bearings.
The critical speed is a first-mode approximation.
The spring design covers static round-wire springs only.
It does not estimate fatigue life for cyclic loads.
Use the fatigue_analysis tool for a separate cyclic-load check.
The fatigue analysis estimates the endurance limit for steel only. The tool applies to infinite-life design and does not model finite-life crack growth. Surface and reliability factors follow the standard table values.
The press-fit theory assumes elastic material behavior and uniform friction. It does not model residual stress after yield.
The section catalog covers common IPE, HEA, HEB, and UPN sizes. It does not include every size in the standard.
The viscosity and thermal conductivity units cover common engineering units. They do not cover every named unit in older texts.
The HTTP transport binds to the local host by default.
Authentication is optional.
Set ENGINEER_MCP_AUTH_TOKEN before a protected deployment.
Browser clients need an explicit origin allow-list.
Set ENGINEER_MCP_ALLOWED_ORIGINS with comma-separated origins.
The transport does not provide TLS.
Use a reverse proxy for public deployment.
The HTTP transport keeps session state in memory. A restart clears every active session.
SSE responses are not stored for reconnect. The server does not configure an event store.
The built-in SQLite module of Node.js is still experimental.
Check the cited sources for exact values.
The server grows in independent releases. Each release stays useful on its own.
Helical compression spring design.
The spring_design tool reports the spring rate, the shear stress, and the safety factor.
Standard steel section catalog and data audit.
The section_catalog tool searches the published IPE, HEA, HEB, and UPN series.
Each row carries source IDs for dimensions and section properties.
The beam_bending and section_properties tools accept a catalog designation.
The result cites EN 10365 for dimensions and masses.
It cites ArcelorMittal for section properties.
Press and shrink fit analysis.
The interference_fit tool reports the interface pressure, the hoop stresses, and the friction capacity.
Fatigue analysis.
The fatigue_analysis tool estimates the endurance limit for steel and reports the fatigue safety factor for a selected mean-stress criterion.
Viscosity and thermal conductivity units.
The unit_convert tool converts dynamic viscosity, kinematic viscosity, and thermal conductivity.
The registry covers centipoise, centistokes, and the imperial conductivity units.
HTTP transport.
The server runs over stdio or Streamable HTTP.
The --transport http option starts an HTTP endpoint with stateful sessions.
HTTP transport security. The server supports bearer authentication. It rejects browser origins outside the configured allow-list.
Configurable HTTP response mode.
JSON remains the default response mode.
SSE serves text/event-stream responses for clients that require streaming.
No additional item is scheduled in this release.
See docs/integration.md for the EngineerKit plan.
Engineer MCP is part of the EngineerKit family.
The family shares conventions for calculations, units, and provenance.
Other EngineerKit servers can import @engineerkit/engineer-mcp/engine and @engineerkit/engineer-mcp/units.
Read the boundary rules in docs/integration.md.
MIT. See LICENSE.
Bending stress, deflection, and safety factor for a simply supported or cantilever beam with a point or uniform load.
| Name | Required | Description | Default |
|---|---|---|---|
| load | Yes | Load type. Point is a concentrated force, uniform is a distributed load. | |
| length | Yes | Beam length in metres. | |
| section | No | Cross-section shape. Provides the moment of inertia and section modulus. | |
| support | Yes | Support type of the beam. | |
| material | No | Material name from the database. Provides the elastic modulus and yield strength. | |
| outputUnits | No | Optional map of quantity key to requested output unit. Example: { maxBendingStress: "MPa", maxDeflection: "mm" }. | |
| loadMagnitude | Yes | Load magnitude. Newtons for a point load, newtons per metre for a uniform load. | |
| yieldStrength | No | Tensile yield strength in pascals. Enables the safety factor. | |
| elasticModulus | No | Young's modulus in pascals. Optional when material is set. | |
| sectionModulus | No | Section modulus in m^3. Used when no section is given. | |
| secondMomentOfArea | No | Second moment of area in m^4. Used when no section is given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only behavioral disclosure. It explains that the tool computes bending stress, deflection, and safety factor, and restricts inputs to two supports and two load types, but it does not mention assumptions like elastic beam theory, unit defaults, or how optional parameter interactions (e.g., material vs. elasticModulus) affect behavior.
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 that names the key outputs and scope without any filler or redundancy. 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?
Despite a rich schema, the description is too sparse for a tool with 11 parameters, nested objects, and no output schema. It fails to clarify that material and section are optional when equivalent strength properties are supplied, nor does it explain the output format or units. Users are left to reverse-engineer the configuration from the schema alone.
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 100%, so the baseline is 3. The description only echoes the support/load enums and adds no additional meaning about parameter relationships, such as when to use 'section' versus 'sectionModulus' or 'material' versus 'elasticModulus'. It does not compensate with extra clarity 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 names three specific outputs (bending stress, deflection, safety factor) and scopes the tool to simply supported or cantilever beams with point or uniform loads, making its purpose clear. It lacks an explicit verb like 'calculate' but is unambiguous and distinct from siblings like bolt_strength or shaft_analysis.
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 when to use the tool by enumerating supported beam and load types, but it does not explicitly contrast with sibling tools or state exclusions. Users must infer that this is the tool for basic beam bending problems, not for shaft-specific or bolted-joint analyses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ISO 281 basic rating life L10 for ball and roller bearings, in revolutions and hours.
| Name | Required | Description | Default |
|---|---|---|---|
| speedRpm | No | Operating speed in revolutions per minute. Enables life in hours. | |
| axialLoad | No | Applied axial load in newtons. Used to derive P. | |
| radialLoad | No | Applied radial load in newtons. Used to derive P. | |
| bearingType | Yes | Bearing type. Ball uses a life exponent of 3, roller uses 10/3. | |
| outputUnits | No | Optional map of quantity key to requested output unit. Example: { maxBendingStress: "MPa", maxDeflection: "mm" }. | |
| equivalentLoad | No | Equivalent dynamic radial load P in newtons. | |
| dynamicLoadRating | Yes | Basic dynamic load rating C in newtons. | |
| requiredLifeHours | No | Required service life in hours. Enables the life margin. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It reveals that the tool uses ISO 281 and returns life in revolutions/hours, but it does not mention assumptions (e.g., how equivalent load is derived), side effects, or limitations. The lack of detail leaves the agent to infer behavior from the schema.
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 that front-loads the core purpose and standard. There is no fluff, and every word contributes to identifying the tool. For a complex tool it is brief, but it is not padded or redundant.
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 tool has 8 parameters, a nested object, and no output schema, so the description should clarify what the tool returns and how inputs combine. It does state outputs in revolutions and hours, but it does not mention optional life margin, how loads are used, or the role of outputUnits. The schema covers parameter semantics, but the description falls short of providing a complete mental model.
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 descriptions for all 8 parameters, so the baseline is 3. The tool description adds minimal parameter-specific value—only the mention of 'revolutions and hours' loosely relates to the speedRpm parameter, but it does not enrich understanding beyond what the schema already 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 that the tool computes ISO 281 basic rating life L10 for ball and roller bearings, with outputs in revolutions and hours. It is specific about the resource and the calculation, though it does not contrast with sibling tools like shaft_analysis or bolt_strength.
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 explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It simply states what the tool does without contextualizing its role among sibling engineering calculation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tensile stress area, proof strength, recommended preload, and safety factor for metric bolts.
| Name | Required | Description | Default |
|---|---|---|---|
| pitchMm | No | Thread pitch in millimetres. Defaults to the coarse pitch from the database. | |
| axialLoad | Yes | Applied axial load in newtons. | |
| outputUnits | No | Optional map of quantity key to requested output unit. Example: { maxBendingStress: "MPa", maxDeflection: "mm" }. | |
| propertyClass | Yes | ISO 898 property class, for example 8.8 or 10.9. | |
| preloadFraction | No | Preload as a fraction of proof load. Defaults to 0.75. | |
| nominalDiameterMm | Yes | Nominal bolt diameter in millimetres. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only names output quantities and does not explain assumptions (e.g., static loading, ISO 898 standard), default preload fraction, or behavior with invalid inputs. The tool's internal calculations and limitations remain opaque.
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, compact sentence with no filler or redundancy. While it is under-specified, it efficiently conveys the core outputs and subject scope without wasting 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?
For a tool with six parameters, a nested outputUnits object, and no output schema, the description is too sparse. It does not explain how to specify units, what the safety factor is relative to, or any default behavior, leaving the agent to infer much from the schema alone.
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 has 100% description coverage for all six parameters, so the description adds no additional parameter meaning. The phrase 'metric bolts' aligns with nominalDiameterMm and propertyClass, but this is minimal beyond what the schema already 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 lists specific outputs (tensile stress area, proof strength, recommended preload, safety factor) for metric bolts, which clearly identifies the tool's domain and distinguishes it from siblings like beam_bending and shaft_analysis. However, it lacks an explicit verb such as 'calculate' or 'return', so the action is implied rather than stated.
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 like shaft_analysis or material_lookup. The description does not mention appropriate scenarios, exclusions, or alternative tools, leaving the usage context entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up mechanical properties for common engineering materials from the curated database.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of rows to return. Defaults to 10. | |
| query | Yes | Material name or category to search. Matches are case-insensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states data comes from a curated database, implying a read-only operation, but lacks information about response format, range of properties, pagination, or any limitations. This minimal disclosure leaves significant behavioral traits unstated.
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 redundant words. It efficiently conveys the core purpose without unnecessary detail, making it appropriately concise for the tool's simplicity.
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 an output schema and annotations, the description should elaborate on what mechanical properties are included and what qualifies as 'common engineering materials'. It does not, leaving an agent to infer these details, which is a notable gap for a complete understanding.
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 input schema already fully documents both parameters (query and limit) with descriptions for case-insensitivity and default value. The description adds no additional meaning about the parameters beyond the schema's coverage, so the baseline score of 3 applies.
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 function: looking up mechanical properties for common engineering materials. The verb 'look up' and the resource 'mechanical properties' are specific, and the context of a curated database distinguishes it from sibling analysis tools like beam_bending and bolt_strength.
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 its use when material property data is needed, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The mention of 'curated database' hints at a read-only lookup but no direct guidance on selecting this tool over others is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Area, moments of inertia, section moduli, and radius of gyration for standard cross-sections.
| Name | Required | Description | Default |
|---|---|---|---|
| section | Yes | Cross-section shape and dimensions in metres. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It lists output properties but does not mention return format, units of results, handling of unsupported shapes, or error behavior. This is a significant gap for a calculation tool with no output schema.
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 that efficiently lists the computed properties. Every word contributes to understanding, and there is no redundancy or filler.
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 tool has a complex input schema with five shape variants, and the description does not enumerate them (though the schema does). Without an output schema, the description should state output units and return behavior, but it only lists property names. This is adequate but leaves important gaps.
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 each dimension property having units (e.g., 'Width in metres.'). The description adds only the phrase 'standard cross-sections' but does not clarify which shapes are supported or add meaning beyond the schema. Baseline 3 is appropriate.
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 computes area, moments of inertia, section moduli, and radius of gyration for standard cross-sections. This distinguishes it from sibling tools like beam_bending or shaft_analysis, though it lacks an explicit verb like 'calculates'.
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 contextual hints about typical use cases. It simply states what the tool does without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Torsion stress, angle of twist, and first lateral critical speed for solid or hollow shafts.
| Name | Required | Description | Default |
|---|---|---|---|
| length | Yes | Shaft length in metres. | |
| torque | Yes | Applied torque in newton metres. May be negative for direction. | |
| density | No | Density in kilograms per cubic metre. | |
| material | No | Material name from the database. Provides stiffness and density. | |
| outputUnits | No | Optional map of quantity key to requested output unit. Example: { maxBendingStress: "MPa", maxDeflection: "mm" }. | |
| shearModulus | No | Shear modulus in pascals. | |
| innerDiameter | No | Inner diameter in metres for a hollow shaft. | |
| outerDiameter | Yes | Outer diameter in metres. | |
| elasticModulus | No | Young's modulus in pascals. | |
| shearYieldStrength | No | Shear yield strength in pascals. Enables the safety factor. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It lists outputs but does not describe output format, how results are returned, the safety factor calculation enabled by shearYieldStrength, or any unit handling conventions. The description offers only the core analytic scope without behavioral detail.
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 15-word sentence that is easy to scan and free of filler. It front-loads the key outputs and shaft type, though it omits some useful context.
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 tool with 10 parameters, nested objects, and no output schema, the description is stark. It mentions three outputs but omits the safety factor output, how material vs property inputs interact, and what the response structure might be. Combined with absent annotations, the agent lacks a full picture for invoking this tool confidently.
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 input schema already provides 100% parameter coverage with detailed descriptions for all 10 fields, including units and optionality. The description adds no parameter-level meaning beyond stating solid/hollow shaft geometry, so a baseline score of 3 is appropriate.
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 names three specific engineering outputs (torsion stress, angle of twist, first lateral critical speed) and the shaft scope (solid/hollow), distinguishing it from siblings like beam_bending and section_properties. However, it lacks an explicit verb such as 'calculates,' making it slightly less directive.
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 use for shaft torsion and critical speed analysis, but it does not explicitly state when to prefer this tool over beam_bending or other siblings, nor does it provide exclusions. The context is clear enough to infer usage but lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a value between compatible units. Rejects mismatched dimensions and quantity categories.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Target unit symbol. Examples: psi, m, N, degF. | |
| from | Yes | Source unit symbol. Examples: MPa, mm, lbf, degC. | |
| value | Yes | Numeric value to convert. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: rejection of mismatched dimensions and quantity categories. This adds value beyond the basic 'convert' action, though it does not describe return format or error handling details.
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 concise sentences, front-loaded with the main action, and contains no redundant or filler 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?
For a simple 3-parameter tool with well-documented schema, the description is sufficient. It covers the core purpose and a key validation behavior. It could mention the return value explicitly, but that is largely implied by the conversion action.
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 input schema has 100% coverage: each parameter (value, from, to) has a description with examples. The description does not add significant semantic detail beyond the schema, so the baseline of 3 applies.
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 states a specific action ('Convert a value between compatible units') with a clear resource and scope. It also mentions rejection of mismatched dimensions, which distinguishes it from the sibling engineering calculation 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?
The context is clear: use this tool when you need unit conversion. It implies 'compatible units' and rejects mismatches, but does not explicitly name alternatives or say when not to use it. The sibling names make the boundary obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
von Mises equivalent stress, maximum shear stress, and yield safety factor for a stress state.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Stress input mode. Principal uses sigma1-3. Cartesian uses sigmaX, sigmaY, and shear terms. | |
| tauXY | No | Shear stress in the xy plane, pascals. | |
| tauXZ | No | Shear stress in the xz plane, pascals. | |
| tauYZ | No | Shear stress in the yz plane, pascals. | |
| sigma1 | No | First principal stress in pascals. Required in principal mode. | |
| sigma2 | No | Second principal stress in pascals. Required in principal mode. | |
| sigma3 | No | Third principal stress in pascals. Required in principal mode. | |
| sigmaX | No | Normal stress in the x direction, pascals. Required in cartesian mode. | |
| sigmaY | No | Normal stress in the y direction, pascals. Required in cartesian mode. | |
| sigmaZ | No | Normal stress in the z direction, pascals. | |
| yieldStrength | No | Tensile yield strength in pascals. Enables the safety factor. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It lists outputs but omits critical traits such as the need for mode selection (principal vs. cartesian), that yieldStrength enables the safety factor, or that inputs are in pascals. The tool's behavior is significantly under-specified.
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 that immediately names the three outputs. It is concise and front-loaded, with no unnecessary words or repetition.
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 tool has 11 parameters, two modes, and no output schema or annotations. The description is too minimal to convey the tool's full complexity and usage context. It does not explain the two input modes, which parameters are needed for each, or what the output format looks like.
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 covers 100% of parameters with descriptions, including mode-dependent requirements, so the description does not need to add parameter details. The description adds no parameter specifics, which is acceptable given the schema's high 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?
The description clearly states the tool computes von Mises equivalent stress, maximum shear stress, and yield safety factor from a stress state. This distinguishes it from sibling tools like beam_bending or shaft_analysis, which address different structural calculations.
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 phrase 'for a stress state' implies the tool is used to analyze stress states, but there is no explicit guidance on when to choose this tool over alternatives, when not to use it, or any prerequisites like mode selection or yield strength input. Usage is implied rather than explicitly directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool addresses a distinct analysis domain: beam bending, section geometry, bolt strength, shaft torsion, bearing life, stress equivalence, unit conversion, and material lookup. There is no overlap or ambiguity among these eight tools.
All tool names follow a uniform lowercase_snake_case convention with two components (e.g., beam_bending, unit_convert, material_lookup). While not strictly verb_noun, the naming is consistent and predictable across the set.
With exactly 8 tools, the set is well-scoped for a mechanical engineering calculation server. Each tool fills a distinct need, and the count is neither overwhelming nor sparse.
The toolkit covers essential mechanical design calculations: beams, sections, bolts, shafts, bearings, stress states, units, and materials. Minor gaps exist (e.g., fatigue analysis or column buckling), but these are not critical for the apparent purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Engineering calculation MCP server for oil and gas engineering applications.
MCP server for AI agent profiles and smart notes. 60+ coding prompt packs with expert personas.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Official MCP server for subfeed.app — the cloud for agents. 15+ tools for AI agents to register, build, and deploy other agents. Zero human required. Start here: subfeed.app/skill.md
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DanielCuevas1208/engineer-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
