Skip to main content
Glama
LGDiMaggio

Predictive Maintenance MCP Server

by LGDiMaggio

diagnose_vibration

Analyze vibration signals to detect bearing faults, spectral anomalies, and ISO severity. Generates an actionable diagnostic report for predictive maintenance.

Instructions

Full integrated diagnosis: FFT + PSD + STFT + bearing faults + ISO severity.

Comprehensive vibration diagnostic pipeline. Loads signal from repository,
runs all analyses, and synthesizes results into an actionable report.
The ISO severity block uses ISO 20816-3 machine group/support type
(zone boundaries from ISO 10816-3:2009, provenance noted in output).

The diagnosis DEGRADES instead of failing when the ISO verdict cannot
be produced honestly: if the stored signal has no declared unit (or
the sampling rate cannot cover the ISO evaluation band), the
iso_severity block is a structured refusal (status='refused' with
reason and remedy) while the spectral, bearing, and anomaly blocks
still run. Units are never guessed from amplitude — declare them via
load_signal(signal_unit=...) or the companion _metadata.json.

Args:
    signal_id: ID of the stored signal.
    rpm: Machine operating speed in RPM.
    bearing_id: Bearing designation for fault detection (optional).
    machine_group: 1 (large, >300 kW) or 2 (medium, 15-300 kW).
        Default 2.
    support_type: 'rigid' or 'flexible'. Default 'rigid'.

Raises:
    ValueError: If the stored signal has no sampling rate.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rpmYes
signal_idYes
bearing_idNo
support_typeNorigid
machine_groupNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rpmYesMachine speed (RPM)
signal_idYesSignal identifier used
bearing_idNoBearing used (if any)
fft_summaryYesFFT key findings
psd_summaryYesPSD key findings
iso_severityYesISO severity assessment, or a structured refusal (status='refused' with reason + remedy) when the verdict cannot be produced honestly — e.g. undeclared signal unit or Nyquist below the ISO evaluation band. The other diagnosis blocks (spectral, bearing, anomaly) still run.
stft_summaryYesSTFT key findings
support_typeYesSupport type used for severity: 'rigid' or 'flexible'
machine_groupYesISO 20816-3 machine group used for severity: 1 (large) or 2 (medium)
bearing_faultsNoBearing fault results
recommendationsYesRecommended actions
anomaly_detectionNoAnomaly detection results (health, ratio, score)
evidence_strengthYesStrength of corroborating fault evidence: 'none', 'weak', 'moderate', or 'strong'. Derived from the number and quality of independent findings (bearing fault frequency matches, shaft signatures, anomaly detection, ISO severity) — NOT from severity alone and NOT a probability. 'none' means no fault evidence was found (machine appears healthy).
overall_diagnosisYesCombined diagnostic text
Behavior5/5

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

With no annotations, the description carries full behavioral burden. It thoroughly discloses the graceful degradation behavior, structured refusal for ISO severity (status='refused' with reason and remedy), the rule of never guessing units, and the ValueError condition. This gives the agent critical runtime expectations.

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 structured with a summary line, detailed behavior explanation, and an Args block. It is lengthy but every sentence provides necessary information. The only minor loss is slight redundancy in the ISO severity explanation, but it remains readable and efficient.

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 tool's complexity and that an output schema exists, the description covers purpose, parameters, behavioral edge cases, error conditions, and output semantics (e.g., the iso_severity block). It leaves no critical ambiguity for an agent deciding to use or invoke this tool.

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?

Schema description coverage is 0%, so the description must compensate. It explains every parameter: signal_id, rpm, bearing_id, machine_group, support_type, including enum meanings, defaults, and how to properly declare units via load_signal. This is essential context the schema alone lacks.

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 opens with 'Full integrated diagnosis' and lists specific analyses (FFT, PSD, STFT, bearing faults, ISO severity), clearly stating the tool's role as a comprehensive pipeline. This distinguishes it from sibling tools like analyze_fft or compute_power_spectral_density, which are single-purpose.

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 description implies use for complete vibration diagnosis, mentioning loading signals from the repository and synthesizing results into an actionable report. It does not explicitly name alternatives or state when not to use this tool, but the 'full integrated' framing provides clear context for its primary use case.

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