Skip to main content
Glama
lucksmiler-A1

Predictive Maintenance MCP Server

assess_asset_change

Assess one measurement point's change against its declared or historical reference, classifying amplitude indicators and bearing evidence as no change, isolated, unconfirmed, or persistent.

Instructions

Assess the change of one measurement point against its reference.

Needs nothing but the asset and the point: the measurements, their
snapshots and the declarations are read from the ledger. The reference
is the active declared baseline when one exists (health_declared True,
declarer cited), else the first reference_measurements comparable
acquisitions of the point, reported as a relative comparison whose
health is not declared. For every amplitude indicator (rms, peak, 1x,
ISO velocity, envelope amplitude at each bearing fault frequency) the
reference band is mean plus or minus max(3 sigma, 25 percent) and the
post-reference acquisitions are classified as no_change,
isolated_episode, unconfirmed_single_acquisition or persistent_change
with the criterion spelled out; bearing evidence is counted over the
last_k acquisitions; the overall verdict is the most severe. Every
comparability qualification is reported and non-comparable
acquisitions are listed, never silently dropped. The result carries at
most one suggested_verification, no list of recommendations.

Snapshots are comparable only on one processing lineage. When no
lineage covers every evaluated acquisition the status is
processing_not_homogeneous and the remedy is this call with
reprocess=True, which first recomputes the stale snapshots with the
current lineage: idempotent (a repeated call recomputes nothing that
is already current), bounded to 10 measurements per call (reference
members first, then the most recent), verified against the recorded
file hash, and the reprocess block names the exact next call while
measurements remain. Old snapshots are never deleted.

Args:
    ctx: MCP context. Unused, see this module's docstring on logging.
    asset_id: The asset (ledger id).
    measurement_point_id: The point (ledger id).
    acquired_since: ISO 8601 lower bound of the assessed post-reference
        acquisitions (the reference is always used), or None.
    acquired_until: ISO 8601 upper bound, or None.
    last_k: Acquisitions listed for drill-down and scanned for bearing
        evidence (1 to 50).
    reference_measurements: Size of the automatic reference window
        when no baseline is declared (3 to 100).
    reprocess: Recompute up to 10 stale snapshots with the current
        lineage before assessing.

Returns:
    AssetChangeAssessment with status 'assessed', 'not_found',
    'insufficient_history' or 'processing_not_homogeneous'.

Raises:
    ValueError: Invalid ids, last_k or reference_measurements outside
        their range, a bound that is not ISO 8601, or a ledger that
        cannot be read.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
last_kNo
asset_idYes
reprocessNo
acquired_sinceNo
acquired_untilNo
measurement_point_idYes
reference_measurementsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
remedyNoConcrete action for 'insufficient_history' or 'processing_not_homogeneous' (the exact re-processing call); None otherwise
statusYesOutcome discriminator (see the class description)
derivedNoDerived comparisons: deltas per indicator against the reference mean, exceedance_runs, drift regressions, iso_change (change against 25 percent of the ISO 20816-3 B/C boundary when group and support are known) and per_indicator classifications with their criterion; None unless assessed
lineageNoProcessing lineage the assessment used: processing_id, algorithm_version, covered slots, candidates per lineage, current_processing_id, is_current, missing_for_current, stale_context; None unless assessed
messageYesOne-paragraph summary of the outcome
assessedNoThe verdict: classification ('no_change', 'isolated_episode', 'unconfirmed_single_acquisition', 'persistent_change'), direction ('increase' or 'decrease'), sudden, criterion, indicators_driving, onset_measurement_id, onset_acquired_at, onset_coincides_with (qualifications of the onset acquisition) and evidence per bearing label; None unless assessed
asset_idYesThe assessed asset (ledger id)
lineagesNoCovered evaluated slots per processing lineage ('processing_not_homogeneous')
observedNoObserved values: reference_statistics per indicator (mean, std, n, band, unit), latest values, latest_measurement_id, latest_acquired_at, evidence_presence per bearing label over the last K acquisitions, indicators_unavailable with reasons, acquisitions_assessed, slots_assessed, measurement_ids_assessed; None unless assessed
requiredNoSlots required ('insufficient_history')
availableNoUsable acquisition slots available ('insufficient_history')
referenceNoThe reference used: kind ('automatic_window' or 'declared_baseline'), health_declared (True only for a declared baseline), message (cites declared_by, declared_at and note of a baseline verbatim), measurement_ids, count, acquired_from, acquired_to, provisional, statistics_quality ('relative_only', 'provisional', 'full'), qualification_codes of the reference slots, outside_window, baseline, withdrawn_baseline, excluded_inside_span; None for a miss
reprocessNoOutcome of the re-processing run before the assessment when reprocess=True: processing_id, stale, reprocessed, not_reprocessable, up_to_date, remaining, results per attempted measurement, next_call (the exact call to continue, or None) and message; None when reprocess was False
suggestionNoConcrete next step on 'not_found'; None otherwise
known_assetsYesAsset ids the ledger directory lists (for a miss); else empty
known_pointsYesPoints of a known asset when the point is unknown; else empty
comparabilityNoComparability of the point's acquisitions: counts per grade, qualifications (code, count, detail), excluded measurements with reasons and collapsed duplicates; None for a miss
evaluated_slotsNoEvaluated slots, reference plus post-reference ('processing_not_homogeneous')
missing_for_currentNoEvaluated slots without a snapshot on the current lineage ('processing_not_homogeneous')
measurement_point_idYesThe assessed point (ledger id)
current_processing_idNoThe current processing lineage ('processing_not_homogeneous')
suggested_verificationNoAt most ONE verification sentence the evidence calls for; None when no verification is needed or the point was not assessed

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.13.0

TDQS

A4.1/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 so well: it details the reference selection logic, classification criteria, severity aggregation, comparability handling, and the exact reprocess behavior (idempotent, bounded to 10, hash-verified, next-call guidance). It also mentions return statuses and exceptions. The only minor gap is not stating whether the tool mutates state—reprocess=True does modify snapshots, but that is implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and front-loads the core logic, but it is quite long with multiple embedded clauses and parenthetical details. The structure is logical yet verbose, and some sentences could be streamlined. It earns its place but is not tightly 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 tool's complexity (7 parameters, 0% schema coverage, output schema present, no annotations), the description is remarkably complete. It covers reference logic, classification, comparability, reprocessing, return statuses, and exceptions. An agent has enough context to invoke it correctly without external documentation.

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 description coverage is 0%, so the description must compensate. It explains asset_id, measurement_point_id, acquired_since/until (as ISO 8601 bounds), last_k (1 to 50), reference_measurements (3 to 100), and reprocess. It adds meaning beyond the schema, such as the reference window size when no baseline is declared and the role of last_k in bearing evidence. The //ctx parameter is noted as unused but not fully described.

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+resource: 'Assess the change of one measurement point against its reference.' It distinguishes itself from siblings like declare_healthy_baseline and analyze_signal_trend by focusing on a single measurement point and a declared or automatic reference. An agent can immediately tell it evaluates change status for an asset point.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the core use case and mentions reprocess=True when processing lineage is not homogeneous, which implies when to use that flag. However, it does not explicitly compare against alternatives like assess_severity or analyze_signal_trend, nor does it state when-not to use this tool. Usage guidance is implied but lacks explicit routing.

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