Skip to main content
Glama
lucksmiler-A1

Predictive Maintenance MCP Server

declare_healthy_baseline

Declare measured points as a healthy reference so change assessments compare against a vetted baseline instead of the first acquisitions.

Instructions

Declare which recorded measurements are the healthy reference of a point.

Until a baseline is declared, assess_asset_change compares against the
first comparable acquisitions of the point and says so
(health_declared False); a declared baseline is the only reference
reported as declared healthy, and every assessment cites declared_by,
the date and the note verbatim. The ids come from load_signal or
get_asset_history (measurement_id); every member must be a recorded
measurement of THIS point, comparable or qualified against the point's
current declaration and against the other members (a contradicting
unit, direction or speed is refused with the reason), and no two may
share an acquisition slot. At least 3 members. An empty
measurement_ids withdraws the active baseline and requires a note;
later assessments fall back to the automatic window and name the
withdrawal. Each member records the declaration versions it was
validated against, so a later re-declaration excludes it with a
qualification instead of silently changing the reference.

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).
    measurement_ids: measurement_id values of the members (at least 3,
        at most 100), or an empty list to withdraw.
    declared_by: Who declares (required, free text, at most 200
        characters, one line); quoted verbatim in later assessments.
    note: Free-text note (at most 200 characters); required for a
        withdrawal.

Returns:
    BaselineDeclarationResult with the baseline_id, the members with
    their recorded versions, the superseded baseline and a summary.

Raises:
    ValueError: Invalid ids or free text, an empty declared_by, an
        asset without a ledger (naming the known assets), an id that is
        not a measurement of the point (naming the valid ids), fewer
        than 3 members, two members in one acquisition slot, a member
        that is not comparable (naming the reason), a withdrawal
        without a note or without an active baseline, or a ledger that
        cannot be read or written.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
asset_idYes
declared_byYes
measurement_idsYes
measurement_point_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoFree-text note of the declarer, as given; None when absent
membersYesOne entry per member: measurement_id, declaration_version of the measurement and point_declaration_version it was validated against (a later re-declaration excludes the member at query time with a qualification, never silently)
messageYesOne-paragraph summary of the outcome
asset_idYesAsset the point belongs to (ledger id)
event_idYesId of the appended ledger event
withdrawnYesTrue when this call withdrew the active baseline (empty list)
baseline_idYesDeterministic id of this baseline declaration (hash of the point, the sorted measurement ids and the declaration instant)
declared_atYesDeclaration instant (ISO 8601, UTC)
declared_byYesWho declared the baseline, as given by the caller; quoted verbatim in every assessment that uses it
measurement_idsYesMembers of the baseline in acquisition order; empty for a withdrawal
measurement_point_idYesThe point (ledger id)
superseded_baseline_idNoId of the baseline that was active before this call; None when the point had none

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.13.0

TDQS

A4.9/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 does so: eligibility rules (members must be recorded measurements of THIS point, comparable or qualified against the current declaration, no two sharing an acquisition slot, 3-100 members), versioning semantics after re-declaration, withdrawal behavior, and a Raises section enumerating every rejection reason. This is far beyond what structured fields provide.

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-loads the core purpose and is organized into Args/Returns/Raises, but some material is redundant with structured fields (the Returns block restates the output schema, and the Raises list is long). The length is justified by tool complexity, though it could be trimmed slightly.

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 mutation tool with five parameters, no annotations, and a complex validation model, the description covers invocation, constraints, side effects on assess_asset_change, withdrawal semantics, and error conditions. An output schema exists, so the extra return detail is a bonus rather than a necessity.

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%, and the description fully compensates: it names each argument, gives the source of measurement_ids, the 3-100 bounds, the free-text limits (200 chars, one line) for declared_by and note, and the withdrawal-only requirement for note. Nothing is left for the agent to infer.

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: 'Declare which recorded measurements are the healthy reference of a point.' It also positions the tool against its main sibling by explaining that assess_asset_change uses this baseline, so an agent can tell the two apart without opening either schema.

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

Usage Guidelines5/5

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

Explicitly describes the condition under which the tool matters (until declared, assess_asset_change falls back to first comparable acquisitions), where the ids come from (load_signal, get_asset_history), and the alternative behavior of passing an empty list to withdraw, including the requirement of a note and the resulting fallback to the automatic window.

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