Skip to main content
Glama

sim_conformance_stream

Destructive

Online conformance: replay an ORDERED event stream against a stored model and get a running verdict — does the model still match, or which event was the first that did not, and why. Unlike sim_conformance (whole finished cases, aggregate fitness) the order of events IS the stream's order, cases may interleave, and the answer names the first non-conforming event: its position, case, activity, whether the activity is unknown to the model or the transition was not enabled, the places that blocked it (need vs have), the case's marking just before it, and repair — the shortest unobserved transitions that would have enabled it (a local alignment of that one step, bounded; absent when none is found within repairDepth). This is token replay, not trace alignment. A divergent event is force-fired so the case resynchronises and later events are judged on their own. fitness is conforming events / events; tokenFitness is 1 - missing/consumed tokens: 1 while nothing has been consumed, and below 0 when more tokens are missing than were consumed. Missing tokens are counted as sim_conformance's replay counts them (an unknown activity and a blocking inhibitor each count one, an unmet read arc its shortfall), except where that replay ignores capacity or merges parallel arcs, which its caveats name. Give the stream as events (JSON array of {case, activity, timestamp?}) or log (CSV with a case_id, activity header, timestamp optional; rows are taken in the order given, not sorted). Activities are transition ids. Each case replays from the model's initial marking, so the model should be the per-case workflow; guard expressions are not evaluated and timestamps are not checked against delays (caveats says so). keepSteps adds the per-event running signal. Costs 2 tokens from your account's compute bucket. With outlook (JSON {"goal": {place: count}, "avoid": {place: count}, "cases": [case ids]}) the reply adds outlook, separate from conforming and firstDivergence: from the marking each case is in after the replay, whether goal is reached on every way the net can go on and avoid on none. Each target constrains only the places it names, to exactly that count, as sim_reach's to does. Each verdict is guaranteed, forced-violated, open (some continuations satisfy it and some do not) or unknown, which names the budget, cap, guard or timer that stopped the search and is never a yes or a no. A verdict rests on the case's marking itself, a sim_reach answer from that marking (reach; re-check a yes or an invariant no with sim_check_witness(reach=…)), an escape (a deadlock or a cycle that never reaches the target, re-checked before it is returned), or a search of every marking before the target, which has no smaller certificate. No fairness is assumed: a loop that can repeat forever makes a goal open, unless a delayed transition stays enabled along it unfired (the simulator starts a timer the instant it is enabled), which is unknown. Guards decidable from the marking are enforced, though the replay ignores them; a transition whose guard reads action parameters is never fired. Cases are grouped by marking, at most 4 distinct markings per call (outlook.cases, default every case in the stream, narrows it), and each search is bounded by sim_reach's 100,000-state and 20,000,000-unit budgets. The outlook costs 2 more tokens per distinct marking and predicate the marking does not already decide (one for each reachability search it may run, as sim_reach's search costs 1; at most 16), charged before any runs, even when the first search decides it; a refused outlook costs nothing more.

Input Schema

NameRequiredDescriptionDefault
idYesmodel id
logNothe stream as CSV text (case_id, activity[, timestamp]) in stream order; used when events is not given
eventsNoJSON array of {"case": ..., "activity": ..., "timestamp": ...} in stream order
outlookNoJSON object {"goal": {place: count}, "avoid": {place: count}, "cases": [case ids]}: judge, from each case's marking after the replay, whether goal is reached on every continuation and avoid on none (guaranteed, forced-violated, open or unknown). Give goal, avoid or both; cases defaults to every case in the stream; at most 4 distinct case markings. Unset: no outlook
keepStepsNoinclude the per-event running fitness (one entry per event)
repairDepthNomost unobserved transitions a repair may use (default 4, at most 64; negative turns repair off)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / outlook
      Added value: +{
      +  "description": "JSON object {\"goal\": {place: count}, \"avoid\": {place: count}, \"cases\": [case ids]}: judge, from each case's marking after the replay, whether goal is reached on every continuation and avoid on none (guaranteed, forced-violated, open or unknown). Give goal, avoid or both; cases defaults to every case in the stream; at most 4 distinct case markings. Unset: no outlook",
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / repairDepth / description
      Previous value: -"most unobserved transitions a repair may use (default 4; negative turns repair off)"New value: +"most unobserved transitions a repair may use (default 4, at most 64; negative turns repair off)"
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

With annotations already declaring destructive/open-world/non-idempotent behavior, the description adds substantial operational context: compute-token charges, search budgets, bounded repair, handling of guards and timers, no fairness assumption, and the precise charging/refusal rules for outlook. It does not contradict the annotations.

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 purpose, sibling distinction, and primary input/output behavior are front-loaded, and most sentences carry substantive information for a complex tool with no output schema. It is long and somewhat overstuffed, especially around outlook charging, but it is not padded or repetitive.

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?

Despite having no output schema, the description explains the verdict shape, first-divergence fields (position, case, activity, blocking places, marking, repair), fitness definitions, and outlook result types. For a complex online conformance tool, an agent has enough information to invoke it and interpret its response correctly.

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 real meaning beyond the schema: events/log precedence and ordering, activities as transition ids, per-case replay from the initial marking, and repairDepth semantics including negative disabling. The added semantics are material for correct invocation.

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 — replay an ordered event stream against a stored model for a running conformance verdict — and explicitly contrasts itself with the sibling sim_conformance (whole finished cases, aggregate fitness). An agent can distinguish this from sim_conformance 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?

Names the alternative (sim_conformance) and the exact condition that selects this tool: ordered streaming, possibly interleaved cases, and interest in the first non-conforming event. It also specifies input formats (events vs log), when the optional outlook applies, and the cost model.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources