engineer-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.3/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![engineer-mcp MCP server](https://glama.ai/mcp/servers/DanielCuevas1208/engineer-mcp/badges/card.svg)](https://glama.ai/mcp/servers/DanielCuevas1208/engineer-mcp)

Score Badge

Copy to your README.md:

[![engineer-mcp MCP server](https://glama.ai/mcp/servers/DanielCuevas1208/engineer-mcp/badges/score.svg)](https://glama.ai/mcp/servers/DanielCuevas1208/engineer-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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