Skip to main content
Glama
lucksmiler-A1

Predictive Maintenance MCP Server

declare_measurement_point

Define a measurement point's context—bearing, design speed, ISO group, expected unit, sensor, and direction—so health snapshots and vibration diagnostics apply the correct defaults.

Instructions

Declare the context of a measurement point in the local asset ledger.

The declaration is what the health snapshots and diagnose_vibration
default to for every measurement of the point: the bearing at the
point (bearing_id from the verified catalog, or fault_orders as
multiples of the shaft frequency: BPFO, BPFI, BSF, FTF), the design
speed nominal_rpm (distinct from the rpm a measurement declares, which
wins when present), the ISO 20816-3 machine_group and support_type
(undeclared means no ISO block, never a silent default), the rated
power, and what the point expects of its measurements: signal unit,
sensor and direction (a measurement contradicting them is excluded
from the trend, one omitting them is qualified).

Versioned per point: a re-declaration that changes nothing appends
nothing and returns the current version; one that changes a value
appends the next version and reports the changed keys. Measurements
whose snapshot was computed with a previous context are counted in
measurements_with_stale_context together with the exact
assess_asset_change(..., reprocess=True) call that recomputes them (a
note-only change makes nothing stale).

Args:
    ctx: MCP context. Unused, see this module's docstring on logging.
    asset_id: The asset (letters, digits, '_', '-', '.', starting with
        a letter or digit; case-sensitive).
    measurement_point_id: The point on the asset (same grammar).
    bearing_id: Catalog designation of the bearing at the point.
    fault_orders: {label: order} with labels BPFO, BPFI, BSF, FTF and
        orders in multiples of the shaft frequency (e.g. BPFO 3.58).
    machine_group: ISO 20816-3 group, 1 (large) or 2 (medium).
    support_type: 'rigid' or 'flexible'.
    machine_power_kw: Rated power in kW (positive).
    expected_signal_unit: Unit the point's measurements are expected in.
    expected_sensor_id: Sensor expected at the point (free text, at
        most 200 characters, one line).
    expected_direction: Expected measurement direction.
    nominal_rpm: Design speed of the point in rev/min (positive).
    declared_by: Who declares (free text, at most 200 characters).
    note: Free-text note (at most 200 characters, one line).

Returns:
    MeasurementPointDeclarationResult with the version, whether an
    event was appended, the changed keys, the stale-snapshot count and
    remedy, the recorded declaration and a summary message.

Raises:
    ValueError: Invalid ids, a value outside its vocabulary, a
        non-positive number, free text over the limit or with control
        characters (one message names every problem), or a ledger
        that cannot be read or written.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
asset_idYes
bearing_idNo
declared_byNo
nominal_rpmNo
fault_ordersNo
support_typeNo
machine_groupNo
machine_power_kwNo
expected_directionNo
expected_sensor_idNo
expected_signal_unitNo
measurement_point_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
remedyNoThe exact assess_asset_change(..., reprocess=True) call that recomputes the stale snapshots (bounded per call); None when nothing is stale
changedYesDeclared keys whose value differs from the previous version (every key declared with a value for version 1; empty when nothing was appended)
messageYesOne-paragraph summary of the outcome
appendedYesTrue when a new declaration version was appended to the ledger; False when the declaration equals the current version
asset_idYesAsset the point belongs to (ledger id)
event_idNoId of the appended ledger event; None when nothing was appended
declarationYesThe point declaration as recorded in the ledger: measurement_point_id, declaration_version, bearing_id, fault_orders, machine_group, support_type, machine_power_kw, expected_signal_unit, expected_sensor_id, expected_direction, nominal_rpm (the design speed of the point, distinct from the observed rpm of a measurement), declared_by, note, changed
previous_versionNoVersion this declaration supersedes; None for a first declaration
bearing_in_catalogNoWhether the declared bearing_id is in the verified bearing catalog (a bearing outside it leaves the bearing block of every snapshot missing); None when no bearing_id is declared
declaration_versionYesVersion of the point's declaration after this call (1-based, per point); unchanged when nothing was appended
measurement_point_idYesThe declared point (ledger id)
measurements_with_stale_contextYesRecorded measurements of the point that lack a health snapshot computed with the current declared context and the current processing lineage; their existing snapshots are kept

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.13.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers: versioning semantics (a no-op re-declaration appends nothing and returns the current version; a change appends and reports changed keys), precedence rules (a measurement's rpm wins over nominal_rpm), contradiction handling (contradicting measurements are excluded, omitting ones qualified), the 'no silent default' ISO behavior, and the stale-snapshot count plus the exact reprocess remedy call.

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?

Args/Returns/Raises headers give good structure and the purpose is front-loaded, so the length is defensible for a 13-parameter, versioned tool. It loses a point for dense, parenthesis-heavy prose and for a Returns section that duplicates the existing output schema.

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?

For a high-complexity versioned mutation with 0% schema coverage and no annotations, the description covers all parameters, the versioning/staleness model, the remedy call, and the ValueError conditions in one place. An agent has everything needed to invoke it correctly, even though the output schema already exists.

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%, so the description must compensate, and it does: it documents id grammar (letters/digits/underscore/dash/dot, leading alnum, case-sensitive), fault_orders labels and shaft-multiple convention, machine_group 1/2, support_type values, positive-number constraints on nominal_rpm and machine_power_kw, and the 200-char one-line limits on free text. This meaning is not recoverable from the schema alone.

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 names a specific verb (declare) and resource (the context of a measurement point in the local asset ledger), then enumerates exactly what that context comprises. It also positions the tool relative to consumers like health snapshots and diagnose_vibration, so an agent can tell what it does 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 Guidelines3/5

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

It explains what the declaration feeds (snapshots and diagnose_vibration defaults) and when stale context arises, which implies usage. However it never states when to prefer this over the sibling declare_healthy_baseline, nor gives an explicit when-to-use / when-not-to-use rule, leaving routing to inference.

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