Predictive Maintenance MCP Server

generate_test_signal

Generate synthetic vibration test signals for bearing, gear, imbalance, or normal data, then save and auto-register them for immediate analysis, diagnosis, and ISO severity assessment.

Instructions

Generate a synthetic test signal, save it, and load it into the repository.

The signal is written to data/signals/ with a timestamped filename and a
companion _metadata.json declaring sampling_rate and signal_unit='g'
(synthetic acceleration), then auto-registered in the repository — the
returned signal_id is immediately usable by every analysis, diagnosis,
and ISO severity tool with no manual steps.

Signal content: 'bearing_fault' = 10 Hz impacts modulating a 1 kHz
carrier; 'gear_fault' = 200 Hz mesh tone + harmonics; 'imbalance' =
25 Hz (1500 RPM) tone; 'normal' = broadband noise.

Args:
    signal_type: Synthetic fault pattern to generate.
    duration: Signal duration in seconds (10 s gives 0.1 Hz resolution).
    sampling_rate: Sampling frequency in Hz.
    noise_level: Additive white-noise amplitude.
    random_seed: Seed for reproducible noise (None = non-deterministic).
    ctx: MCP context. Unused — see this module's docstring on logging.

Returns:
    StoredSignalInfo of the auto-loaded signal (signal_id, declared
    sampling_rate and unit 'g').

Input Schema

TableJSON Schema

Name	Required	Default
`duration`	No
`noise_level`	No
`random_seed`	No
`signal_type`	No	bearing_fault
`sampling_rate`	No

Output Schema

TableJSON Schema

Name	Required	Description
`shape`	Yes	Shape of the signal array
`filepath`	Yes	Original file path
`signal_id`	Yes	Unique identifier for the stored signal
`duration_s`	No	Duration in seconds
`raw_format`	No	EFFECTIVE raw-binary decode parameters (sample_format, byte_order, n_channels, channel_index, header_offset, scale_factor) after the explicit > companion > default merge — recorded as provenance so get_signal_info can answer 'how was this file decoded'. None for self-describing formats.
`size_bytes`	Yes	Approximate memory size in bytes
`measurement`	No	Normalized measurement identity declared in the companion's "measurement" object: asset_id, measurement_point_id, acquired_at (ISO 8601 normalized to UTC), timezone_declared, timestamp_suspect, rpm, load, operating_state, sensor_id, direction, declared_by, measurement_id (first 16 hex of the SHA-256 of the file bytes plus the channel index), channel_index, content_sha256 (full digest of the file bytes) and size_bytes (file size). This block is AUTHORITATIVE over the verbatim object kept in source_metadata. None when the companion declares no measurement object (the file behaves exactly as before). The value RETURNED BY load_signal carries, in addition, the outcome of the asset-ledger registration: ledger_status ('recorded' \| 'already_recorded' \| 'superseded' \| 'not_recorded'), reason (None, or why the status or the snapshot is not nominal), changed (keys that differ from the previous declaration of the same measurement, 'location' when the file moved), reattributed_from (asset the measurement was recorded under by mistake, or None), declaration_version, snapshot_status ('complete' \| 'partial' \| 'failed' \| 'skipped'), snapshot_id, processing_id (the snapshot lineage), comparability ({grade, qualifications} against the current declaration of the measurement point, informational, never stored) and missing ({block: {reason, remedy}} of the snapshot blocks the declared context could not support). get_signal_info and list_signals show the identity only.
`num_samples`	Yes	Number of samples
`signal_unit`	No	DECLARED signal unit — from load_signal(signal_unit=...) or the companion _metadata.json ('signal_unit' field). Never guessed. None means undeclared: ISO severity verdicts will be refused until the unit is declared.
`sampling_rate`	No	Sampling rate in Hz (must be positive when set)
`load_timestamp`	Yes	ISO 8601 timestamp when signal was loaded
`source_metadata`	No	Complete companion _metadata.json of the source file (rpm/shaft_speed, reference frequencies, ...). Empty when the file has no companion metadata.
`companion_warning`	No	Set when a companion _metadata.json exists but could not be used (not valid JSON, or not a JSON object): names the file and the case, and the signal was loaded exactly as if it had no companion. None when the companion was read fine or is absent.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.13.0Oct 6, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the write path (data/signals/ with timestamped filename), a companion _metadata.json declaring sampling_rate and unit 'g', auto-registration in the repository, and the exact signal content per fault type. It omits permissions, overwrite behavior, and error handling, but overall transparency is strong.

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?

Front-loaded with the core purpose and side effects, followed by signal content and a conventional Args/Returns block; every section earns its place. There is minor redundancy between 'no manual steps' and 'auto-loaded... immediately usable,' but the structure is clean.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter mutation tool with no annotations, the description covers purpose, persistence side effects, fault-type content, and all parameters. An output schema exists, so the brief Returns section is sufficient; only permission and failure-mode details are absent.

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%, and 5 params are undocumented in the schema, so the description must compensate — and it does, documenting all of them via an Args block: signal_type purpose, duration with a resolution hint (10 s = 0.1 Hz), sampling_rate, noise_level, and random_seed (None = non-deterministic).

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?

States a specific verb and resource ('Generate a synthetic test signal') plus its full lifecycle ('save it, and load it into the repository'). This clearly distinguishes it from siblings like load_signal or list_signals, which operate on existing data.

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?

The description establishes clear context: this produces synthetic fault patterns and the returned signal_id is 'immediately usable by every analysis, diagnosis, and ISO severity tool.' However, it never explicitly states when to prefer this over load_signal (e.g., when no real measurement data exists), so there are no named alternatives or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server