Skip to main content
Glama
LGDiMaggio

Predictive Maintenance MCP Server

by LGDiMaggio

generate_test_signal

Generate synthetic vibration signals for bearing faults, gear faults, imbalance, or normal conditions, automatically save and register them for immediate use in analysis and diagnosis tools.

Instructions

Generate a synthetic test signal, save it, and load it into the repository.

The signal is written to data/signals/ with a timestamped filename and a
companion _metadata.json declaring sampling_rate and signal_unit='g'
(synthetic acceleration), then auto-registered in the repository — the
returned signal_id is immediately usable by every analysis, diagnosis,
and ISO severity tool with no manual steps.

Signal content: 'bearing_fault' = 10 Hz impacts modulating a 1 kHz
carrier; 'gear_fault' = 200 Hz mesh tone + harmonics; 'imbalance' =
25 Hz (1500 RPM) tone; 'normal' = broadband noise.

Args:
    signal_type: Synthetic fault pattern to generate.
    duration: Signal duration in seconds (10 s gives 0.1 Hz resolution).
    sampling_rate: Sampling frequency in Hz.
    noise_level: Additive white-noise amplitude.
    random_seed: Seed for reproducible noise (None = non-deterministic).
    ctx: MCP context.

Returns:
    StoredSignalInfo of the auto-loaded signal (signal_id, declared
    sampling_rate and unit 'g').

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
durationNo
noise_levelNo
random_seedNo
signal_typeNobearing_fault
sampling_rateNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
shapeYesShape of the signal array
filepathYesOriginal file path
signal_idYesUnique identifier for the stored signal
duration_sNoDuration in seconds
size_bytesYesApproximate memory size in bytes
num_samplesYesNumber of samples
signal_unitNoDECLARED signal unit — from load_signal(signal_unit=...) or the companion _metadata.json ('signal_unit' field). Never guessed. None means undeclared: ISO severity verdicts will be refused until the unit is declared.
sampling_rateNoSampling rate in Hz (must be positive when set)
load_timestampYesISO 8601 timestamp when signal was loaded
source_metadataNoComplete companion _metadata.json of the source file (rpm/shaft_speed, reference frequencies, ...). Empty when the file has no companion metadata.
Behavior4/5

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

Describes file storage location (data/signals/), metadata creation, auto-registration, and signal content. No annotations exist, so description carries burden well. Does not mention side effects or permissions, but is mostly transparent.

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?

Well-structured: main action first, then storage details, then signal content, then parameter docs. Front-loaded and clear, though slightly long for a tool description.

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?

Comprehensive for a generative tool with 5 optional parameters and an output schema. Explains signal types, storage, and immediate usability. Output schema covers return type, so no missing info.

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?

Description includes parameter docs (signal_type, duration, etc.) with explanations that add meaning beyond schema defaults and enums. Covers all 5 parameters with context like 'Synthetic fault pattern to generate'.

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 explicitly states the tool generates a synthetic test signal, saves it, loads it into the repository, and returns a usable signal_id. It distinguishes itself from sibling tools which are analysis-focused.

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?

Usage is implied: generate synthetic signals for testing. No explicit when-to-use or when-not-to-use compared to alternatives. Siblings are clearly analysis tools, but no direct guidance is provided.

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