Skip to main content
Glama
LGDiMaggio

Predictive Maintenance MCP Server

by LGDiMaggio

check_bearing_faults

Analyze stored vibration signals to identify bearing faults by matching expected frequencies from catalog, explicit frequencies, or geometry.

Instructions

Check expected fault frequencies in a stored signal's envelope spectrum.

THE unified bearing-check tool: catalog lookup, explicit
frequencies, or explicit geometry in one call. Requires the signal
loaded via load_signal() first.

Expected-frequency routes (exactly ONE required):
- bearing_id: catalog lookup (verified entries only) — BPFO/BPFI/BSF/
  FTF computed from the catalog geometry; the entry's source citation
  is echoed in the result.
- frequencies: explicit {label: hz} dict — for bearings not in the
  catalog or non-bearing checks such as a gearbox GMF
  (e.g. {"GMF": 350.0}). Labels BPFO/BPFI/BSF/FTF map to the
  canonical fault vocabulary; other labels have no canonical form.
- explicit geometry: num_balls + ball_diameter_mm + pitch_diameter_mm
  (+ contact_angle_deg) — frequencies computed from user-provided
  geometry (out-of-catalog path).

Each check reports fault_type_canonical (outer_race / inner_race /
ball / cage) alongside the acronym.

Args:
    ctx: MCP context.
    signal_id: ID of the stored signal.
    rpm: Shaft speed in RPM.
    bearing_id: Bearing designation (e.g. '6205', 'SKF 6205-2RS').
    frequencies: Explicit expected frequencies {label: hz}, all > 0.
    num_balls: Number of rolling elements (explicit-geometry route).
    ball_diameter_mm: Ball/roller diameter Bd in mm.
    pitch_diameter_mm: Pitch circle diameter Pd in mm.
    contact_angle_deg: Contact angle in degrees (default 0.0).
    tolerance_pct: Frequency matching tolerance in percent (default 5).

Returns:
    BearingFaultsSummary with one check per expected frequency,
    overall assessment, most likely fault (+ canonical form), and the
    provenance of the expected frequencies (`source`).

Raises:
    ValueError: If the signal is not loaded / has no sampling rate, if
        not exactly one route is given, if the geometry is incomplete,
        if the bearing is not in the catalog, or if frequencies is
        empty / non-positive.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rpmYes
num_ballsNo
signal_idYes
bearing_idNo
frequenciesNo
tolerance_pctNo
ball_diameter_mmNo
contact_angle_degNo
pitch_diameter_mmNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rpmYesShaft speed (RPM)
sourceNoProvenance of the expected frequencies: the catalog entry's source citation (bearing_id route), or a note for user-provided geometry/frequencies
signal_idYesSignal identifier used
bearing_idNoBearing designation (catalog route); None for the explicit-frequencies and explicit-geometry routes
fault_checksYesResults for each checked frequency
most_likely_faultNoMost likely fault label if any
overall_assessmentYesSummary assessment text
shaft_frequency_hzYesShaft frequency (Hz)
bearing_frequenciesYesExpected frequencies checked (Hz), plus shaft_freq_hz
most_likely_fault_canonicalNoCanonical form of most_likely_fault (None for arbitrary labels)
Behavior4/5

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

No annotations provided, so description carries full burden. It details error conditions (ValueError for various misuses), return structure (BearingFaultsSummary with provenance and canonical fault types), and input constraints (exactly one route). Lacks information on side effects or performance characteristics, but covers behavioral aspects well.

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?

Well-structured with headings and bullet points. Every sentence adds value: purpose, routes, prerequisites, parameters, return, errors. Front-loaded with the main action ('Check expected fault frequencies in a stored signal's envelope spectrum'). No redundant information despite thoroughness.

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?

Given the complexity (9 parameters, 3 conditional routes, output schema), the description covers all necessary aspects: prerequisites, input formats, error handling, return structure. Assumes output schema exists, which is referenced. No major gaps.

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

Parameters5/5

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

With 0% schema coverage, description adds extensive meaning. It explains each parameter's role in the three routes, provides examples (catalog IDs, explicit frequency dicts), and clarifies special labels (BPFO/BPFI/BSF/FTF map to canonical vocabulary). Defaults for contact_angle_deg and tolerance_pct are noted. All conditional requirements are clearly documented.

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?

Description clearly states the tool checks expected fault frequencies in a stored signal's envelope spectrum. It positions itself as the unified bearing-check tool covering catalog lookup, explicit frequencies, or explicit geometry, distinguishing it from sibling tools like calculate_bearing_characteristic_frequencies.

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?

Explicitly states prerequisite (signal loaded via load_signal()), describes three mutually exclusive routes with exactly one required, and provides examples for each route. However, it does not directly compare to sibling tools like diagnose_vibration or calculate_bearing_characteristic_frequencies, leaving some ambiguity about when to use this tool versus alternatives.

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

Install Server

Other Tools

Latest Blog Posts

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/LGDiMaggio/predictive-maintenance-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server