Skip to main content
Glama

gear_rating

Calculate spur-gear tooth bending stress and safety factor via the Lewis formula from tangential force or power and pinion speed, then check against allowable fatigue limits.

Instructions

Rate spur-gear tooth bending (Lewis): sigma=Ft/(bmY). Pass tangential_force_n, or power_w + pinion_speed_rpm. Returns {tangential_force_n, pitch_dia_mm, pitch_line_velocity_m_s, lewis_form_factor, bending_stress_mpa, allowable_bending_mpa, bending_sf, pass}. First-order screen, not full AGMA. The allowable defaults to the material's fatigue endurance (else 0.3·UTS); allowable_bending_mpa overrides it with an AGMA/spec number.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
teethYes
power_wNo
materialNoSteel-4140-QT
module_mmYes
face_width_mmYes
pinion_speed_rpmNo
lewis_form_factorNo
tangential_force_nNo
allowable_bending_mpaNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the formula used, the screening-vs-AGMA limitation, the allowable defaulting rule (material fatigue endurance, else 0.3·UTS), and the override path. It does not discuss unit conventions or failure/error behavior, so it is not exhaustive.

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?

Front-loads purpose and formula, then input strategy, then return shape, then caveats/defaults. Every sentence is load-bearing with no filler, unusual for a definition this information-dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter analysis tool with no output schema and no annotations, the description covers inputs, defaults, override behavior, and even the return key set inline. An agent has enough to call it correctly without opening any schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% across 9 parameters, so the description must compensate and largely does: it explains the force-input alternatives (tangential_force_n vs power_w+pinion_speed_rpm) and the override semantics of allowable_bending_mpa. It leaves module_mm, teeth, face_width_mm, and especially lewis_form_factor uncharacterized, so a gap remains.

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?

States a specific verb+resource ('Rate spur-gear tooth bending (Lewis)') and backs it with the governing equation sigma=Ft/(b*m*Y), so the agent knows exactly what computation runs. The 'not full AGMA' phrase distinguishes this screening tool from heavier siblings like fatigue_check or hertz_contact.

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?

Gives concrete input paths ('Pass tangential_force_n, or power_w + pinion_speed_rpm') and states the domain limit ('First-order screen, not full AGMA'), telling the agent when the result is adequate versus when to escalate. No alternatives are named explicitly, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools