Predictive Maintenance MCP Server

get_signal_info

Retrieve metadata for a stored signal without loading its full array. Returns sampling rate, unit, shape, timestamps, and companion source metadata like RPM and reference frequencies.

Instructions

Get metadata for a stored signal without loading the full array.

Includes the COMPLETE companion-metadata dict (source_metadata: rpm/
shaft_speed, reference frequencies, ...) alongside the repository
fields (sampling_rate, declared signal_unit, shape, timestamps).

Args:
    ctx: MCP context. Unused — see this module's docstring on logging.
    signal_id: ID of a signal previously loaded via load_signal.

Returns:
    StoredSignalInfo with source_metadata populated from the companion
    _metadata.json (empty dict when the file has none).

Raises:
    ValueError: If the signal_id is not in the repository.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`signal_id`	Yes

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.3/5.0

Behavior4/5

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

With no annotations, the description carries the burden and mostly succeeds: it discloses that the full array is NOT loaded, that source_metadata comes from the companion _metadata.json (empty dict when absent), and that ValueError is raised for an unknown signal_id. It omits nothing critical for a local read-only repository call, though it never explicitly says the operation is read-only/non-mutating.

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 two lead paragraphs are front-loaded and earn their place, but the docstring-style Args/Returns/Raises block partially duplicates what the schema and output schema already provide, and the ctx note ('Unused — see this module's docstring on logging') is noise for an agent.

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?

Covers the precondition, the return payload, and the error case, which is enough for an agent to call it correctly. Because an output schema exists, the Returns paragraph is partly redundant, and there is no mention of behavior when the companion metadata file is malformed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (the single signal_id property is a bare string), so the description must compensate, and it does by defining signal_id as an ID of a signal previously loaded via load_signal. That added constraint is meaningful, though no format or error-adjacent detail beyond existence is given.

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 (Get), resource (metadata for a stored signal), and scope qualifier (without loading the full array), which implicitly contrasts with the sibling load_signal that retrieves the array itself. An agent can tell what this returns without opening the schema.

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?

Gives a clear precondition: the signal_id must be 'a signal previously loaded via load_signal', and the opening line frames the use case (metadata only, not the full array). It stops short of naming load_signal or list_signals as explicit alternatives or stating when not to use it.

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

Deploy Server