Skip to main content
Glama

sim_sequences

Destructive

Returns a deterministic suite of firing sequences generated from ONE stored model, for replaying against an implementation outside sim (for example the code a sim_code_to_flow model came from): every transition fired once, a refusal probe for each transition at a marking where the model refuses it, and each conflict found (two enabled transitions where firing one disables the other) fired then probed. Each sequence starts from the declared initial marking: fire each of fires in order (the model fires each), then try refused once when it is set (the model refuses it); covers names its targets and final is the model's nonzero marking after fires. calls counts every fire and probe, not the resets. The reading is untimed, as sim_reach's is: each firing is one atomic step under the shared firing rule (read and inhibitor arcs, capacities, guards decidable from the marking); rates, schedules, delays and stages play no part, and a transition whose guard reads action parameters (or does not parse, or whose precondition was lost) is never fired or probed (excluded lists it). Each target is covered; unreachable, said only after an exhaustive search; or not-covered with a reason: depth-bound (markings or targets were left unexplored past depth: ask a larger depth), state-budget or work-budget (the 20,000-marking or 10,000,000-unit search budget), token-cap, guard-error, excluded-live (an excluded transition was enabled, so markings past it were not searched), excluded, or suite-budget (past 20,000 calls or 100,000 listed entries, each fire, probe and final-marking place counting one). notCovered gives each reason's detail and remedy, and coverage.conflict.complete is true only after an exhaustive search. depth is 1..16, default 8; a model over 128 transitions is refused. defects (0..200, default 50; 0 omits the figure) seeds up to that many single-point net mutants (all of them when the model has fewer; defects.candidates and defects.seeded say how many) (drop-arc, weight-up, weight-down, test-flip, read-to-consume, initial-up, initial-down, capacity-down, capacity-drop, guard-drop; rates and timing are never mutated), picked by seed (default 1), replays the suite against each with markings compared, and runs 8 seeded random testers (seeds seed to seed+7) against each with the suite's own call budget, resetting every depth fires. defects.suite.detected counts seeded mutants the suite told apart from the model, beside defects.random.detected's mean, min and max across the runs; it is a count of seeded defects, never a share of real bugs. survivors lists the mutants the suite missed: a survivor may be equivalent (no sequence of any length tells it apart), and this figure does not decide which. A mutant no suite sequence told apart and at least one could not drive to an answer (a firing it cannot decide, such as one past the token cap) is undecided: undecidedDefects lists it with its first error, and it counts in neither figure. The score is priced before it runs (defects.price) and refused over 2,000,000,000 work units: each call costs its arc test, its guard and passes over the model's token places, and each mutant its compile. summary true omits the sequences array (the key is absent, not null). MCP only: there is no HTTP route. Public: no sign-in; costs 2 compute tokens (one bounded search plus a priced replay battery). Writes nothing.

Input Schema

NameRequiredDescriptionDefault
idYescontent id of one stored model (a sim_compose result is one)
seedNopicks the mutants and seeds the 8 random testers (seed to seed+7): a whole number 0 or more, default 1
depthNothe longest sequence, in fires before its probe: a whole number 1..16, default 8
defectsNohow many net mutants to seed: a whole number 0..200, default 50; 0 omits the seeded-defect figure
summaryNotrue omits the sequences array (the key is absent); default false

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.1/5.0
Behavior1/5

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

The description's closing claim 'Writes nothing' directly conflicts with annotations declaring readOnlyHint=false and destructiveHint=true, and its emphasis on a deterministic, seed-picked suite conflicts with idempotentHint=false. The narrative does add genuinely useful behavior (20,000-marking / 10,000,000-unit budgets, 128-transition refusal, 2,000,000,000-unit price cap, 20,000-call suite budget, 2 compute tokens), but the side-effect profile the agent must trust is stated inconsistently with the structured hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single ~450-word paragraph in which budgets, mutant types, refusal reasons, costing rules and encoding details run together with no structure, so the two things an agent needs first (what it returns and when to call it) are buried under enumeration. Nearly every sentence carries information, but the density and lack of separation make it poor for scanning.

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?

With no output schema, the description carries the return-shape burden and does it well: sequences/final/calls/covers, coverage.conflict.complete, defects.suite.detected vs defects.random.detected, survivors and undecidedDefects are all explained, along with every not-covered reason and its remedy. Only the contradiction around side effects keeps this from being fully complete for a 5-parameter, budgeted compute tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter (id, seed, depth, defects, summary) is already documented with type, range and default, which sets the baseline at 3. The description mostly restates those ranges plus one genuine addition — a model over 128 transitions is refused — but adds no new meaning about how seed interacts with tester seeding beyond what the schema says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource — returning a deterministic suite of firing sequences from ONE stored model for replay against an external implementation — and ties it to a concrete sibling (a sim_code_to_flow model). It is highly specific, but it never distinguishes itself from other generation/checking siblings (sim_generate, sim_conformance, sim_scenario, sim_distinguish), so an agent choosing among them still has to infer.

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 gives a clear use context: replaying against an implementation outside sim, e.g. the code a sim_code_to_flow model came from, and notes the reading is untimed 'as sim_reach's is', which orients the agent. There is no explicit when-not guidance or statement of which sibling to pick for an in-sim alternative.

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