This server provides deterministic mechanical engineering calculation and lookup tools for AI assistants, ensuring accurate, checkable answers.
Material Properties Lookup (material_properties): Retrieve typical room-temperature mechanical and thermal properties (density, Young's modulus, yield/ultimate strength, thermal conductivity, CTE) for common engineering materials using names or shorthand (e.g., 6061, Ti-6Al-4V, 304, aluminum).
Beam Analysis (beam_analysis): Calculate maximum deflection, bending moment, and bending stress for four standard loading cases (cantilever with end or uniform load, simply supported with center or uniform load), with optional factor of safety against yield for circular or rectangular cross-sections.
Unit Conversion (convert_units): Perform dimension-aware conversions across length, mass, force, pressure/stress, energy, power, area, volume, and temperature — refusing invalid cross-dimension conversions (e.g., force to length) instead of returning a wrong number.
List Supported Units (list_units): Display all supported unit symbols grouped by physical dimension, useful for discovering valid inputs for unit conversion.
Curve Fitting (fit_correlation): Perform least-squares curve fitting on paired (x, y) data using a linear model (y = m*x + c) or power-law model (y = C * x^n, fit in log-log space), returning coefficients, R², and a formula string — ideal for dimensionless correlations like Nu = C * Re^n.
Click on "Deploy 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., "@mcp-engineering-tools What's the factor of safety on a 1 m 6061 cantilever, 50 by 100 mm, carrying 1 kN at the tip?"
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.
An MCP server that gives an AI assistant a set of real mechanical-engineering tools. Instead of asking a model to recall a material property or do a beam calculation in its head (where it can quietly be wrong), the model calls a tool that returns a deterministic, checkable answer.
I'm a mechanical engineering student, and I built this to sit at the boundary I actually work at: hardware analysis on one side, AI tooling on the other. The Model Context Protocol is Anthropic's open standard for connecting models to external tools, so this is a small, complete example of exposing engineering domain logic through it.
Tool | What it does |
| Typical properties (density, modulus, yield/ultimate strength, thermal conductivity, CTE) for common materials. Accepts shorthand like |
| Max deflection, moment, and bending stress for four standard beam cases, with an optional factor of safety against yield. |
| Dimension-aware unit conversion. Refuses nonsense like force-to-length instead of returning a wrong number. |
| Lists every supported unit, grouped by dimension. |
| Least-squares curve fit (linear or power law) of experimental data, returning coefficients, R^2, and a formula. |
The fit_correlation power-law mode is the form used to build dimensionless heat-transfer correlations like Nu = C * Re^n: it fits a straight line in log-log space and reads the exponent off the slope.
Related MCP server: MCP Learning Project
bun run demo runs the server and calls each tool with a realistic question. A few of the answers:
A loaded steel rod that actually fails. The tool returns a factor of safety below 1, so it flags the failure with numbers instead of a guess:
beam_analysis cantilever, 0.8 m, 20 mm dia, 500 N at the tip, steel
-> max_bending_stress_MPa: 509.3 (yield is 370 MPa)
factor_of_safety: 0.73 // < 1: this rod yields
max_deflection_m: 0.053Building a heat-transfer correlation from data. Five (Re, Nu) points fit straight to the standard form:
fit_correlation power-law on (Re, Nu) data
-> formula: "y = 0.1459 * x^0.6609"
rSquaredLogSpace: 0.99999Refusing a meaningless request instead of returning a wrong number:
convert_units 100 N -> m
-> Dimension mismatch: "N" is force, "m" is length. These are not convertible.Every value above is computed by the server, which is the point: the model calls a tool and gets a checkable answer rather than recalling one that might be subtly wrong.
bun run showcase is the compact version I use to demonstrate the project. It starts the actual MCP server, sends an AI-style beam request through MCP, compares the returned values against an independent Euler-Bernoulli calculation in the walkthrough script, and then runs the real automated test suite. The checked cantilever benchmark produces 0.400 mm deflection, 12.0 MPa bending stress, and a factor of safety of 23.0.
A few deliberate choices, since the point of this repo is the engineering, not the line count:
The curve fit is implemented from scratch (src/regression.ts), not pulled from a numerics library. Ordinary least squares is short, and writing it keeps the behavior fully known and testable.
Units carry their dimension. Conversion is only allowed within a dimension, and temperature is handled as an affine transform (offset, not just a scale) rather than being forced into the factor model.
Material values state their condition (temper, processing). A strength number without a condition is not a real number, so each entry says what it corresponds to. These are first-pass handbook values, not certification data.
Every input is validated with zod at the tool boundary, so bad calls fail with a clear message instead of a NaN.
Requires Bun (dev) or Node 18+ (built output).
bun install
bun test # 26 tests across the four modules
bun run typecheck
bun run build # compiles to dist/
bun run demo # starts the server and calls each tool with a real question
bun run showcase # runs an MCP call, an independent hand check, and bun test
node scripts/smoke.mjs # minimal end-to-end smoke checkAdd the built server to an MCP client. For Claude Desktop, edit its config file (claude_desktop_config.json):
{
"mcpServers": {
"engineering-tools": {
"command": "node",
"args": ["/absolute/path/to/mcp-engineering-tools/dist/server.js"]
}
}
}For Claude Code:
claude mcp add engineering-tools -- node /absolute/path/to/mcp-engineering-tools/dist/server.jsThen ask, for example: "What's the factor of safety on a 1 m 6061 cantilever, 50 by 100 mm, carrying 1 kN at the tip?" and the model will call material_properties and beam_analysis and answer from the returned numbers.
Possible future directions, not commitments. The point of listing them is to show where the domain logic could grow:
More beam cases (distributed loads, fixed-fixed, overhanging) and combined loading.
Column buckling (Euler critical load) and a slenderness check.
Fatigue screening against an endurance limit, with a stress-concentration factor input.
A wider materials table (more alloys, polymers, and composites) with temperature-dependent values.
Optional uncertainty on fitted correlations (confidence bounds on the coefficient and exponent).
MIT, see LICENSE.
Compute max deflection, max bending moment, and max bending stress for a beam under one of four standard loadings. Optionally returns a factor of safety against yield. Euler-Bernoulli, linear-elastic, small-deflection theory.
| Name | Required | Description | Default |
|---|---|---|---|
| load | Yes | Point load in N (point cases) or distributed load in N/m (uniform cases). | |
| section | Yes | Cross-section geometry. | |
| beamCase | Yes | Loading case. | |
| length_m | Yes | Span or support spacing, meters. | |
| yield_strength_MPa | No | Optional yield strength, MPa; if given, a factor of safety is returned. | |
| youngs_modulus_GPa | Yes | Young's modulus, GPa. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the underlying theory (Euler-Bernoulli, linear-elastic, small-deflection) and the computed outputs. With no annotations, it carries the full burden and does well, though it could mention output format or units explicitly.
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, front-loaded with the main purpose, no wasted words. Efficient and to the point.
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's complexity (multiple load cases, optional yield), the description covers the main outputs and theory. It lacks explicit mention of return format or error handling, but the outputs listed are sufficient for an engineering 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 100%, so the baseline is 3. The description adds context like 'four standard loadings' and clarifies the load parameter units, but this largely overlaps with schema descriptions.
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 max deflection, bending moment, and stress for beams under four standard loadings, with optional factor of safety. It specifies the theory (Euler-Bernoulli, linear-elastic, small-deflection), distinguishing it from sibling tools like convert_units or material_properties.
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 standard beam loadings but does not provide explicit guidance on when not to use or mention alternative tools. However, the context of standard loadings and the sibling tools list makes usage clear.
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 engineering units within the same physical dimension (length, mass, force, pressure/stress, energy, power, area, volume, temperature). Refuses cross-dimension conversions such as force to length.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Target unit symbol, e.g. 'psi', 'mm', 'N', 'F'. | |
| from | Yes | Source unit symbol, e.g. 'MPa', 'in', 'lbf', 'C'. | |
| value | Yes | Numeric value to convert. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It mentions refusal of cross-dimension conversions but omits details on error handling, precision, or output format. The absence of an output schema makes the missing return value description a notable gap.
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, zero waste. Front-loaded with the core action and constraint, then a concise example of refused behavior. 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?
The description covers the tool's purpose and a key behavioral constraint, but given the lack of output schema, it should state that the tool returns the converted numeric value. Without this, the description feels slightly incomplete for an agent.
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 adds context about dimensional constraints but does not enhance parameter meaning beyond the schema's examples and types.
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 (convert) and the resource (a value between engineering units), and specifies that conversions must be within the same physical dimension, listing examples. This distinguishes it from sibling tools like list_units or material_properties.
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 explicitly warns against cross-dimension conversions, providing a clear when-not-to-use condition. However, it does not mention alternatives like list_units for checking available units, which could enhance guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fit a least-squares model to paired (x, y) experimental data and return the coefficients, R^2, and a formula string. Use 'power' for dimensionless correlations like Nu = CRe^n (fit in log-log space; x and y must be positive) or 'linear' for y = mx + c.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | Independent-variable values. | |
| y | Yes | Dependent-variable values (same length as x). | |
| model | Yes | Which model to fit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses the fitting behavior, return values, and constraints (e.g., positive values for power). It could mention error handling for invalid inputs, but overall transparent.
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 the main action and return values front-loaded. Every sentence adds crucial information without 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?
For a tool with no output schema, the description covers return values (coefficients, R^2, formula string), usage constraints, and model types. It is complete and self-sufficient for an AI agent.
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 covers all three parameters fully (100% coverage). Description adds significant meaning: explains model choices (power vs. linear), the requirement of positive values for power, and the paired nature of x and y.
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 explicitly states the tool fits a least-squares model to paired experimental data and returns coefficients, R^2, and a formula string. It clearly distinguishes between 'linear' and 'power' models, providing specific context for each.
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 explicit guidance on when to use 'power' (dimensionless correlations, log-log fit, positive values) versus 'linear' (direct linear fit). It also explains the mathematical transformation for power model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every unit symbol the converter supports, grouped by physical dimension.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description implies a read-only operation ('list') with no side effects. It could explicitly mention it is safe, but the context is clear.
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?
One sentence, 12 words, conveying all necessary information without 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?
Given zero parameters and no output schema, the description completely covers what the tool does and how the result is structured.
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?
There are no parameters, so baseline is 4. The description adds value by stating the output is grouped by dimension, which is not in 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 the verb 'list' and the resource 'unit symbols', and adds 'grouped by physical dimension' for specificity. This distinguishes it from the sibling 'convert_units' which performs conversions.
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 this tool (to see supported units), but does not explicitly state when not to use it or compare with siblings like 'beam_analysis' or 'material_properties'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up typical room-temperature mechanical and thermal properties for a common engineering material (density, Young's modulus, yield and ultimate strength, thermal conductivity, CTE). Accepts names or shorthand like 'aluminum', '6061', 'Ti-6Al-4V', '304'.
| Name | Required | Description | Default |
|---|---|---|---|
| material | Yes | Material name or shorthand, e.g. 'aluminum 6061' or 'steel'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses 'typical room-temperature' and 'common engineering material', but lacks details on behavior for unrecognized material, output format, or assumptions.
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: one states purpose, another adds examples. No filler, efficient and front-loaded. Every sentence adds meaningful 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?
No output schema, so description lists returned properties (density, modulus, etc.), which is helpful. However, missing details on behavior for missing material, units, or multiple matches. 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 100% but description adds value by providing specific shorthand examples ('6061', 'Ti-6Al-4V', '304') not in the schema description. This helps agents understand acceptable input formats.
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 'look up' and resource 'mechanical and thermal properties for a common engineering material', with examples of acceptable inputs. Distinguishes from siblings like beam_analysis or convert_units.
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?
Implied usage for quick room-temperature property lookups, but no explicit guidance on when to use versus alternatives like beam_analysis. Does not mention limitations or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0beam_analysisconvert_unitsfit_correlationlist_unitsmaterial_propertiesScored across 5 tools
Each tool addresses a distinct engineering task: beam analysis, unit conversion, data fitting, unit listing, and material properties. No overlap in functionality.
Most tools follow a verb_noun pattern (convert_units, fit_correlation, list_units), but material_properties and beam_analysis deviate slightly. However, all use consistent snake_case.
Five tools is appropriate for the server's scope—enough to cover core engineering needs without being overwhelming or too sparse.
The tool set covers essential engineering tasks, but lacks some common analyses (e.g., stress transformation, section properties). Minor gaps exist but do not hinder most workflows.
Educational MCP server with 17 math/stats tools, visualizations, and persistent workspace
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
