Skip to main content
Glama
LGDiMaggio

Predictive Maintenance MCP Server

by LGDiMaggio

analyze_signal_trend

Screen a signal recording for significant feature trend and degradation onset using per-segment analysis and baseline comparison.

Instructions

Within-recording screening: feature trend + degradation onset.

    THE unified screening tool: feature trend AND degradation
    onset in one call. Segments a single recording
    (seconds of data), extracts the requested feature per segment,
    tests whether the per-segment values show a statistically
    significant trend (slope p < 0.05), and detects the first segment
    AFTER the baseline window (first half of the series) whose value
    exceeds baseline mean + onset_threshold_sigma standard deviations.
    Onset inside the baseline window cannot be detected (the baseline
    defines "normal"). Requires the signal loaded via load_signal()
    first; the sampling rate comes from the stored signal metadata.

    This is a SCREENING tool, not a prognosis: a trend inside seconds
    of signal says whether the recording is stationary, not how long
    the machine will live. For Remaining Useful Life, collect repeated
    measurements over days/weeks (one recording per session) and pass
    them to estimate_rul — this tool returns the per-segment feature
    series so each recording can be reduced to one measurement point.

    Args:
        ctx: MCP context for user communication.
        signal_id: ID of the stored signal (from load_signal).
        feature_name: Time-domain feature to analyze (default: "rms").
        segment_duration: Duration of each segment in seconds.
        overlap_ratio: Overlap between segments (0-1).
        onset_threshold_sigma: Baseline standard deviations above the
            baseline mean that trigger onset detection (default: 3.0).

    Returns:
        TrendAnalysisResult with slope, direction (p-value based),
        fit quality, the (truncated) per-segment feature series, and
        the onset-detection outcome (onset_detected,
        onset_segment_index, onset_time_s, baseline_segments).

    Raises:
        ValueError: If the signal_id is not loaded, or the stored
            signal has no sampling rate.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
signal_idYes
feature_nameNorms
overlap_ratioNo
segment_durationNo
onset_threshold_sigmaNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
slopeYesTrend slope in feature units per second (within the recording)
p_valueNoTwo-sided p-value of the slope (None when not computable)
interceptYesTrend intercept
r_squaredYesR-squared goodness of fit of the linear trend
feature_nameYesFeature analyzed
num_segmentsYesNumber of segments analyzed
onset_time_sNoCenter time (s) of the onset segment within the recording
analysis_scopeYesAlways 'within_recording_screening': this trend spans seconds of one recording, not the machine's life
feature_seriesYesPer-segment feature values (evenly subsampled to at most 50 points). One recording yields ONE point for estimate_rul (e.g. the recording's overall feature value) — accumulate recordings over time to build its input series.
onset_detectedYesWhether a degradation onset was detected after the baseline window (first value exceeding baseline mean + onset_threshold_sigma * std)
segment_times_sYesSegment center times in seconds for feature_series (same subsampling)
trend_directionYesincreasing, decreasing, or stable — based on the slope significance test (p < 0.05), not on an R-squared cutoff
series_truncatedYesTrue when feature_series was subsampled to the 50-point cap
baseline_segmentsYesNumber of leading segments used as the baseline window. Onset is only searched AFTER this window; degradation starting inside the baseline cannot be detected by this method.
onset_segment_indexNoSegment index where degradation starts (always >= baseline_segments); None when no onset detected
onset_threshold_sigmaYesBaseline standard deviations used as the onset trigger
Behavior4/5

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

With no annotations provided, the description discloses the core algorithm (segmentation, feature extraction, trend test, onset detection) and its limitations. It does not explicitly state it is read-only, but the analytical nature is clear. Minor omission of side effects or permissions.

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 well-structured with a front-loaded summary and clear sections. It is somewhat lengthy but every sentence adds value. Could be slightly more concise.

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 output schema exists, the description explains the return value (TrendAnalysisResult components) and raises exceptions. It covers inputs, outputs, errors, and usage context completely.

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?

Despite 0% schema coverage, the description provides detailed explanations for all parameters in the Args section, including defaults and the role of onset_threshold_sigma. This compensates fully for the missing schema descriptions.

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 clearly states it is a screening tool for feature trend and degradation onset within a single recording, distinguishing it from the prognosis tool estimate_rul.

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?

Explicitly states when to use this tool (within-recording screening) vs when not to (use estimate_rul for prognosis over days/weeks). Lists prerequisites (load_signal first) and limitations (cannot detect onset inside baseline window).

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