Skip to main content
Glama
lucksmiler-A1

Predictive Maintenance MCP Server

get_asset_history

Read the asset ledger index or a single asset's measurement history, including points, baselines, lineages, and integrity data.

Instructions

Read the asset ledger: the index of the assets, or one asset's history.

Without asset_id (the index): every asset the ledger directory lists,
at most 50, each with its points (measurement counts, first and last
acquired_at, latest processing lineage, whether a baseline is
declared, declaration version), event count, ledger size and
integrity counters; truncated says whether more assets exist. With
asset_id: that asset's history read from its ledger alone, the last
max_measurements measurements newest first (identity, acquired_at,
signal_id, file location, declaration version, lineages, a preview of
the indicators of the latest snapshot, comparability grade and codes
against the point), the point declarations and baselines with their
history, the measurements re-attributed to another asset, and the
integrity block. measurement_point_id restricts the history to one
point and needs asset_id. An unknown asset or point is a typed
'not_found' naming the known ids, not an exception.

Args:
    ctx: MCP context. Unused, see this module's docstring on logging.
    asset_id: The asset (ledger id), or None for the index.
    measurement_point_id: Restrict to one point of the asset, or None.
    max_measurements: Measurements listed at most (1 to 200), newest
        first.

Returns:
    AssetHistoryResult with status 'index', 'found' or 'not_found'.

Raises:
    ValueError: measurement_point_id without asset_id, an invalid id,
        max_measurements outside 1..200, or a ledger that cannot be
        read.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
asset_idNo
max_measurementsNo
measurement_point_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
assetNoHistory of the asset (status 'found' only): summary, measurements newest first (measurement_id, measurement_point_id, acquired_at, signal_id, location, declaration_version, rpm, direction, sensor_id, lineages, snapshot_count, indicators preview from the latest snapshot, comparability grade and codes against the point), measurement_count, truncated, point_declarations and baselines (current plus history per point), reattributed, integrity, event_count, ledger_bytes
assetsYesIndex entries (status 'index' only, else empty): asset_id, points (measurement_point_id, measurement_count, first_acquired_at, last_acquired_at, latest_lineage, baseline_declared, declaration_version), point_count, measurement_count, first_acquired_at, last_acquired_at, reattributed_count, event_count, ledger_bytes, integrity (counters)
statusYes'index', 'found' or 'not_found' (see the class description)
messageYesOne-paragraph summary of the outcome
truncatedYesTrue when the index holds fewer assets than exist, or the history fewer measurements than max_measurements would have to cover
suggestionNoConcrete next step on a miss; None otherwise
known_assetsYesAsset ids the ledger directory lists (the listed ones for the index, every id for a miss; empty for a found asset, whose ledger is the only one read)
known_pointsYesPoints of the asset (declared or named by its measurements) when the asset is known; empty otherwise

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.13.0

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 full load and does much of it: it describes truncation at 50 assets, the integrity block, typed not_found behavior instead of exceptions, and ValueError conditions. It stops short of stating auth/permission requirements or read-only enforcement, but the error and truncation behavior are valuable and non-obvious.

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-mode structure is front-loaded and the Args/Returns/Raises sections are easy to scan. The prose is dense and some sentences pack multiple clauses, which slightly hurts readability but nothing is wasted.

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?

Given a 3-parameter tool with no annotations, an output schema that only declares status values, and a 0% schema description coverage, the description supplies the missing parameter semantics, mode selection, and error behavior. It is complete enough to invoke correctly, though it could note prerequisites such as whether the ledger must already exist.

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%, so the description must compensate, and it does: asset_id is described as the ledger id or None for index, max_measurements is bounded 1–200 newest first, and measurement_point_id is a point restriction requiring asset_id. Defaults (e.g., max_measurements default 20) are not repeated, but the operational meaning of each parameter is conveyed.

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 (Read) and resource (the asset ledger) and then bifurcates into the two distinct modes: index (all assets) and per-asset history. The reader knows exactly what the tool returns in either mode 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?

It clearly states the condition for each mode (without asset_id = index; with asset_id = history) and the constraint that measurement_point_id needs asset_id. It does not explicitly name alternative tools like get_signal_info, but for this tool the mode selection is the dominant decision and that is well documented.

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