Skip to main content
Glama
LGDiMaggio

Predictive Maintenance MCP Server

by LGDiMaggio

analyze_signal_trend

Detect feature trends and degradation onset in a signal recording by segmenting it, computing per-segment features, testing statistical significance, and flagging deviations from baseline.

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. Unused — see this module's docstring on logging.
    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
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does so thoroughly: it explains the statistical test (slope p < 0.05), the onset detection logic (segment after baseline, baseline mean plus threshold standard deviations), the limitation that onset inside the baseline cannot be detected, and the prerequisite of a loaded signal with sampling rate. It also discloses that ctx is unused and the error conditions that raise ValueError. This is exemplary transparency.

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, methodology explanation, usage caveats, and Args/Returns/Raises sections. It is front-loaded with the core purpose. However, there is minor redundancy between the first sentence and the second ('Within-recording screening...' and 'THE unified screening tool: feature trend AND degradation onset in one call.'). Overall, it is appropriately sized for the tool's complexity, but slightly verbose.

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, the absence of annotations, and the bare schema, the description is exceptionally complete. It covers the algorithm, statistical methods, input requirements, output structure, error conditions, and usage caveats. It even explains why this is a screening tool and how to use it for RUL, leaving no significant gaps.

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 schema has 0% description coverage, so the description must compensate. The Args section provides clear semantic meaning for each parameter: signal_id is the ID from load_signal, feature_name is a time-domain feature with default 'rms', segment_duration is in seconds, overlap_ratio is a 0-1 ratio, and onset_threshold_sigma is the number of standard deviations above the baseline mean. This fully compensates for 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?

The description opens with a specific and informative summary: 'Within-recording screening: feature trend + degradation onset.' It clearly states the tool's function: segmenting a recording, extracting features, testing for statistical trends, and detecting onset. It also distinguishes itself from sibling tools by positioning itself as 'THE unified screening tool' and explicitly contrasting with estimate_rul for prognosis, making its unique purpose clear.

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?

Usage guidance is explicit: it states the tool is for screening within a single recording, not for prognosis, and directs users to estimate_rul for Remaining Useful Life. It also notes the prerequisite of calling load_signal() first and explains how to use the per-segment series for RUL analysis. This clearly tells the agent when to use this tool versus alternatives.

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