Skip to main content
Glama
LGDiMaggio

Predictive Maintenance MCP Server

by LGDiMaggio

train_anomaly_model

Train an unsupervised anomaly detection model on healthy machine data. Extracts features, applies PCA, and fits OneClassSVM or LocalOutlierFactor to detect faults.

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 for progress/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
Behavior4/5

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

No annotations provided, so description carries full burden. It discloses the entire pipeline, data requirements (healthy only), validation split behavior, and error conditions. It mentions side effects like saving models. No contradictions.

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 with sections for pipeline, training mode, validation strategy, args, returns, raises. Front-loaded with key purpose. Slightly verbose but justified for a complex tool.

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?

Complete for a complex tool with 8 parameters and no annotations. Covers prerequisites, pipeline, modes, validation, errors. Output schema exists, so return values are appropriately omitted. No gaps identified.

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%, but description fully compensates with detailed Args section explaining each parameter, defaults, and purpose. Required parameter is clearly indicated. Adds significant value beyond the bare schema.

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?

Clearly states it trains an ML-based anomaly detection model on healthy data, specifying unsupervised/semi-supervised modes. Distinguishes from sibling tools like predict_anomalies.

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?

Provides extensive guidance on when to use (after loading signals with load_signal), explains pipeline steps, training modes, and validation strategy. Explicitly notes it is NOT supervised learning and how fault data should be used. While alternatives are not explicitly named, the context is sufficient.

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