Skip to main content
Glama

read_event_history

Read-onlyIdempotent

Read OPC UA events stored in a past time range to recover alarms and changes that live subscriptions missed, such as what happened overnight or before a line stopped.

Instructions

Read events the OPC UA server stored, for a time range that has already passed. subscribe_events only sees what arrives after you subscribe, so it cannot answer 'what happened overnight' or 'what fired in the ten minutes before the line stopped' — the events are gone by the time anyone asks. This reads them back out of the server's own event archive instead. Same records as read_events and the same fields, so an alarm looks identical whether it was watched live or recovered afterwards. Needs a server that reports AccessHistoryEventsCapability — storing values and storing events are separate features and many servers do one without the other — and against one that does not, a call is refused with capability_not_supported and what to use instead. Point node_id at the notifier that emits the events — the Server object by default, which is where events are collected on most servers. The structured result's completeness says whether the range held more events than came back.

Input Schema

NameRequiredDescriptionDefault
node_idNoThe notifier node whose stored events to read. Defaults to the Server object 'ns=0;i=2253', which is where most servers collect events. This is the same node subscribe_events takes.
end_timeNoEnd of the time range, ISO-8601 with a timezone. Defaults to now.
num_valuesNoMaximum number of events to return, capped at 5000. 0 (the default) means as many as that cap allows, not every event in the range — an alarm burst can be tens of thousands of events, and asking for all of them is a request that never returns.
start_timeNoStart of the time range, ISO-8601 with a timezone: '2026-09-09T12:00:00Z' or '2026-09-09T14:00:00+02:00'. A timestamp with no timezone is refused rather than guessed. Defaults to one hour before `end_time`.
severity_minNoKeep only events of at least this OPC UA severity (1-1000). Default 0, which keeps every event. Filtered here rather than by the server, exactly as subscribe_events does, so a server that mishandles a filter cannot silently drop events.

Output Schema

NameRequiredDescriptionDefault
resultYes
completenessYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnly/idempotent/non-destructive; the description adds substantially beyond them: a server capability prerequisite, the specific failure code capability_not_supported, the 5000-event cap, the risk of unbounded bursts, and that filtering happens client-side to avoid server misbehavior. It also explains that the `completeness` field reports truncation, which is real behavioral context.

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?

It is front-loaded with the purpose and the sibling distinction before prerequisites and parameters, and no sentence is filler. It runs long and restates a couple of schema facts (defaults, node id value), which keeps it from a 5.

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 five-parameter historical-read tool it covers the prerequisite, the failure mode, defaults, cap behavior, and truncation signal; an output schema exists so return-shape explanation is not owed. Nothing needed to call it correctly is missing.

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 100%, so the baseline is 3, but the description adds cross-tool meaning: node_id is the notifier and the same node subscribe_events takes, and the result's `completeness` ties back to range size. Most other parameter detail (ISO-8601 formats, defaults, cap) duplicates the schema rather than extending it.

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 opening sentence names a specific verb and resource ('Read events the OPC UA server stored') and immediately scopes the time range to the past. It explicitly distinguishes itself from both subscribe_events (live only) and read_events (identical records, different path), so an agent can pick it without inspecting schemas.

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?

It gives a concrete when-to-use framing ('what happened overnight', 'what fired in the ten minutes before the line stopped') plus the exclusion that subscribe_events cannot answer retrospective questions. It also names when the call will be refused (no AccessHistoryEventsCapability) and what that refusal returns.

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