Skip to main content
Glama
LGDiMaggio

Predictive Maintenance MCP Server

by LGDiMaggio

extract_features_from_signal

Extract 17 statistical features (mean, RMS, kurtosis, entropy, etc.) from vibration signal segments using sliding windows. Requires a signal loaded via load_signal().

Instructions

    Extract time-domain features from a stored signal using sliding windows.

    Segments the signal into overlapping windows and extracts 17 statistical features
    from each segment. Features include: mean, std, RMS, kurtosis, crest factor, entropy, etc.
    Requires the signal loaded via load_signal() first; the sampling rate
    comes from the stored signal metadata. Returns an in-memory summary
    only — no CSV is written to data/signals/.

    Args:
        signal_id: ID of the stored signal (from load_signal).
        segment_duration: Duration of each segment in seconds (default: 0.1)
        overlap_ratio: Overlap between segments, 0-1 (default: 0.5 = 50%)
        ctx: MCP context for progress/logging

    Returns:
        FeatureExtractionResult with features matrix and metadata

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

    Example:
        extract_features_from_signal(
            "healthy_motor",
            segment_duration=0.2,
            overlap_ratio=0.5
        )
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
signal_idYes
overlap_ratioNo
segment_durationNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
num_segmentsYesNumber of segments extracted
feature_namesYesNames of extracted features
overlap_ratioYesOverlap ratio between segments
features_shapeYesShape of feature matrix [num_segments, num_features]
features_previewYesFirst 5 segments features (preview)
segment_duration_sYesDuration of each segment in seconds
segment_length_samplesYesSamples per segment
Behavior5/5

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

No annotations provided, so description carries full burden. Discloses extraction of 17 features, sliding window behavior, in-memory only result, and possible ValueError. Return type and error conditions are clear.

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?

Well-structured docstring with headline, details, Args, Returns, Raises, Example. Every sentence adds value; no redundancy.

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?

Covers all essential aspects: purpose, prerequisites, parameters, return type, errors, and example. Despite complexity (17 features, windowing), description is self-contained. Output schema exists but is separate.

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 coverage is 0%, but description fully compensates with Args section explaining each parameter's purpose, default values, and constraints (e.g., overlap_ratio 0-1). Adds meaning 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 the action ('Extract time-domain features') and resource ('stored signal') using sliding windows. Distinguishes from sibling tools like analyze_fft or analyze_statistics by specifying windowing and feature set.

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?

Explicitly requires signal to be loaded via load_signal() first. Mentions no CSV writing. Lacks explicit guidance on when not to use vs. alternatives like analyze_statistics, but provides a good prerequisite and example.

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