Skip to main content
Glama
LGDiMaggio

Predictive Maintenance MCP Server

by LGDiMaggio

train_anomaly_model

Train an anomaly detection model on healthy data to identify machinery faults, using PCA and OneClassSVM or LocalOutlierFactor with unsupervised or semi-supervised learning.

Instructions

Train ML-based anomaly detection model on healthy data (UNSUPERVISED/SEMI-SUPERVISED).

All signals are referenced by signal_id: load them first with
load_signal — its batch form accepts a list of file paths, e.g.
load_signal(filepath=["real_train/baseline_1.csv", ...]). Each
signal's sampling rate comes from its stored metadata.

Complete pipeline:
1. Extract features from healthy signals (segmentation + time-domain features)
2. Standardize features (StandardScaler - fitted on training data only)
3. Dimensionality reduction (PCA with specified variance explained)
4. Train novelty detection model (OneClassSVM or LocalOutlierFactor) on HEALTHY DATA ONLY
5. Optional hyperparameter tuning using validation data (semi-supervised)
6. Save model, scaler, and PCA transformer

**Training Mode:**
- UNSUPERVISED: Train only on healthy data with automatic hyperparameters
- SEMI-SUPERVISED: Train on healthy data, tune hyperparameters using validation set (healthy + fault)

**Note:** This is NOT supervised learning. OneClassSVM/LOF are trained ONLY on healthy data.
Fault data (if provided) is used ONLY for hyperparameter tuning after training.

**Validation Strategy:**
- If healthy_validation_ids provided: Use those explicitly (no split)
- If healthy_validation_ids NOT provided: Automatic 80/20 split of training data
- If fault_signal_ids provided: Enable semi-supervised mode (hyperparameter tuning)

Args:
    healthy_signal_ids: Stored signal IDs with healthy machine data (for training)
    segment_duration: Segment duration in seconds (default: 0.1)
    overlap_ratio: Overlap ratio 0-1 (default: 0.5)
    model_type: 'OneClassSVM' or 'LocalOutlierFactor' (default: 'OneClassSVM')
    pca_variance: Cumulative variance to explain with PCA (default: 0.95)
    fault_signal_ids: Optional stored signal IDs for HYPERPARAMETER TUNING (semi-supervised)
    healthy_validation_ids: Optional stored healthy signal IDs for validation (specificity check).
                              If not provided, 20% of training data will be used.
    model_name: Name for saved model files (default: 'anomaly_model')
    ctx: MCP context. Unused — see this module's docstring on logging.

Returns:
    AnomalyModelResult with model paths and performance metrics

Raises:
    ValueError: If a signal_id is not loaded or has no sampling rate,
        or model_name/model_type is invalid.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
model_nameNoanomaly_model
model_typeNoOneClassSVM
pca_varianceNo
overlap_ratioNo
fault_signal_idsNo
segment_durationNo
healthy_signal_idsYes
healthy_validation_idsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pca_pathYesPath to saved PCA file (.pkl)
model_nameYesName under which the model was saved — pass this to predict_anomalies(model_name=...)
model_pathYesPath to saved model file (.pkl)
model_typeYesType of model: 'OneClassSVM' or 'LocalOutlierFactor'
scaler_pathYesPath to saved scaler file (.pkl)
model_paramsYesBest model hyperparameters
num_features_pcaYesNumber of PCA components (features after dimensionality reduction)
validation_detailsNoValidation details with healthy and fault metrics
validation_metricsNoDetailed validation metrics (healthy/fault accuracy breakdown)
variance_explainedYesCumulative variance explained by PCA components
validation_accuracyNoOverall balanced accuracy on healthy + fault validation data
num_training_samplesYesNumber of healthy samples used for training
num_features_originalYesNumber of original features
Behavior5/5

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

With no annotations provided, the description fully carries the behavioral disclosure burden. It reveals that the model is trained ONLY on healthy data, fault data is used only for tuning, standardization is fitted on training data only, and it saves model/scaler/PCA. It also discloses the validation strategy and possible ValueError conditions.

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?

The description is long but appropriately structured with numbered pipeline steps, bolded section headers, and labeled sections (Args, Returns, Raises). Every sentence adds value, and the key message (unsupervised training on healthy data) is front-loaded.

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?

Despite the tool's complexity (8 params, pipeline steps, training modes, validation logic), the description covers all essentials. It explains the output (AnomalyModelResult with model paths and metrics), error conditions, and prerequisites, making it complete for an agent to use correctly.

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?

The input schema has 0% description coverage (only titles/defaults), so the description's 'Args' section is essential. It explains each parameter in detail, including defaults and semantic roles—e.g., fault_signal_ids for hyperparameter tuning, healthy_validation_ids for explicit validation with automatic 80/20 fallback.

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 a specific verb+resource: 'Train ML-based anomaly detection model on healthy data'. It clearly differentiates from siblings like predict_anomalies and check_bearing_faults by stating it trains an unsupervised/semi-supervised model, and it names the exact algorithms (OneClassSVM, LocalOutlierFactor).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a complete pipeline, explicitly states when to use unsupervised vs semi-supervised modes, explains how validation splits work, and warns 'This is NOT supervised learning'. It also instructs to load signals first with load_signal, giving a clear prerequisite and alternative.

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