Skip to main content
Glama

Wear Estimate

wear_estimate
Read-only

Calculate sliding wear volume loss and depth with Archard's law, using load, distance, material hardness, and wear coefficient, then verify depth remains within a set limit.

Instructions

Estimate sliding wear (Archard): V = k·F·s/H. k (wear_coef) is empirical — pass it, or it's looked up by the material_pair's category pair (order-of- magnitude). H (hardness_mpa) defaults to Tabor 3·σ_y of the softer member. With apparent_area_mm2 a mean depth is reported and gated by max_depth_mm. Returns {wear_coef, hardness_mpa, volume_loss_mm3, depth_loss_mm, coef_basis, hardness_basis, pass}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
load_nYes
wear_coefNo
hardness_mpaNo
max_depth_mmNo
material_pairNo
sliding_dist_mYes
apparent_area_mm2No

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already indicate read-only behavior (readOnlyHint=true), so the bar is lower. The description goes far beyond by explaining the Archard formula, how k is derived (empirical or from material_pair), the Tabor hardness default, the gating by max_depth_mm, and the exact return structure. This gives an agent a full picture of the computation and its effects.

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 dense paragraph that packs the formula, defaults, gating condition, and return object into a few sentences. It is front-loaded with the core purpose and efficiently conveys the necessary technical details without unnecessary fluff.

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 an engineering calculation tool with no output schema and zero parameter descriptions, this description is remarkably complete. It covers the governing equation, parameter semantics, default behavior, output fields, and the pass/fail gating. An agent has everything needed to call the tool correctly and interpret results.

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 description coverage is 0%, so the description must compensate. It explains the roles of wear_coef, hardness_mpa, material_pair, apparent_area_mm2, and max_depth_mm, and implicitly covers load_n and sliding_dist_m via the formula (F and s). It does not explicitly name every parameter, but it provides sufficient semantic context for all required and optional inputs.

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 estimates sliding wear using the Archard equation, including the formula and the specific outputs. It is unambiguous and distinguishes itself from sibling tools like cost_estimate or bearing_life by being specifically about wear.

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 usage (estimating sliding wear) and explains the calculation mechanics, but it does not explicitly state when to prefer this tool over alternatives or mention any exclusions. There is no guidance on when not to use it or which sibling might be more appropriate.

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