Skip to main content
Glama

sim_scenario

Destructive

Run a seeded what-if scenario against a stored model: marking overrides, rate overrides, piecewise rate schedules, and params assignments to the model's declared structural parameters (arc weights, capacities — batch sizes and shelf sizes). Pure read — asking cannot change the model. Returns trajectory, final marking, metrics, depleted, contended, waitingForWork, neverFired (all three described below), caveats and assumptions. "samples" (default 60) is the trajectory's resolution: the number of evenly spaced points from 0 to hours inclusive at which times and every place's series (mean and std_dev per point) are reported — it sizes the answer, not the run, since metrics (throughput, mean, p95, utilization, inFlight) are time-weighted over every firing and do not change with the grid. "summary": true omits the times and series arrays entirely (the keys are absent, not null) and returns just final, finalStdDev, metrics, depleted, contended, waitingForWork, neverFired, caveats and assumptions — the verdict without the chart data, and the right form when nothing will be plotted. finalStdDev, summarized or not, is each place's spread across realizations at the horizon beside final's mean (absent at one realization and on the ode engine). Transitions declaring stages (phase-type durations) run with the declared lower spread — the engine expands them structurally and reports in the model's own vocabulary. A model-declared schedule (the day shape on a transition) is honored by every run; the scenario's own schedule or rate override still wins for that transition. "engine" picks the reading: "ssa" (default, discrete Gillespie — the right choice whenever counts are small enough that variance is the answer, or a schedule is in play) or "ode" (continuous mass-action; refuses a schedule, and refuses outright rather than silently misread a model carrying a read arc, inhibitor, reached capacity, guard or non-kinetic arc — Forecast's caveats name which). See docs/engine-selection.md for the full decision rule, including why an arc weight above 1 gets a genuinely different rate law from each engine, and sim_crosscheck to run both readings side by side. Contention arrives split three ways. contended holds only what the run was short of, something an operator could buy more of: kind conserved (a fixed pool such as staff) or bounded (a shelf with a declared capacity), each entry with fraction (the share of the run, across every realization, in which that place was the only input missing for the transitions under blocking), longest wait first. waitingForWork holds the engine's other entries in the same shape, and neither of its kinds is a shortage: queue (filled only by the model's own flow, such as waiting customers or work in service) means the work had not arrived, a statement about demand; state (a marker of which phase of a cycle the model is in, such as a stoplight's colour) means the model was in another phase. neverFired is one note per entry whose place never held a token in any run and whose transitions never fired, e.g. "work" never fired in any run: its input "q" never held a token. A queue or state entry like that appears only as its note; a conserved or bounded one keeps its contended row as well, since the run was short of it. The run cannot tell why a place stayed empty. Either it starts empty and nothing fills it (check its initial count and what produces it), or its producer was switched off (a rate of 0, or a scenario marking of 0 on it or upstream of it), or what fills it is rarer than this run's hours and realizations can sample (raise either; once the place fills, the note goes). sim_receipt and the HTTP scenario routes return the engine's unsplit contended list instead, each entry with its kind.

Input Schema

NameRequiredDescriptionDefault
idYesmodel id
scenarioNoscenario JSON, e.g. {"hours":8,"samples":60,"realizations":16,"seed":7,"marking":{"staff/available":3},"params":{"batch_size":6},"schedule":{"arrive":[{"until":2,"value":12},{"until":8,"value":4}]},"engine":"ssa","summary":false}; hours defaults to 8, samples to 60, realizations to 16, seed to 20260809, summary to false (full trajectory); hours above 10000, realizations above 200 or samples above 5000 are refused

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / scenario / description
      Previous value: -"scenario JSON, e.g. {\"hours\":8,\"samples\":60,\"realizations\":16,\"seed\":7,\"marking\":{\"staff\":3},\"params\":{\"batch_size\":6},\"schedule\":{\"arrive\":[{\"until\":2,\"value\":12},{\"until\":8,\"value\":4}]},\"engine\":\"ssa\",\"summary\":false}; hours defaults to 8, samples to 60, realizations to 16, summary to false (full trajectory)"New value: +"scenario JSON, e.g. {\"hours\":8,\"samples\":60,\"realizations\":16,\"seed\":7,\"marking\":{\"staff/available\":3},\"params\":{\"batch_size\":6},\"schedule\":{\"arrive\":[{\"until\":2,\"value\":12},{\"until\":8,\"value\":4}]},\"engine\":\"ssa\",\"summary\":false}; hours defaults to 8, samples to 60, realizations to 16, seed to 20260809, summary to false (full trajectory); hours above 10000, realizations above 200 or samples above 5000 are refused"
  2. First observed

TDQS

A4/5.0
Behavior1/5

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

The description asserts 'Pure read — asking cannot change the model', which directly contradicts the annotations readOnlyHint=false and destructiveHint=true. Per the rubric this inconsistency forces a 1 and an annotation-contradiction flag, even though the text otherwise discloses rich behavior (engine refusals, one-realization finalStdDev absence, schedule precedence rules).

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

Conciseness3/5

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

Purpose is front-loaded, but the description is a dense wall of prose mixing interface contract with troubleshooting (the three reasons a place stays empty) that the text itself says lives in docs/engine-selection.md. Sentences mostly carry content, yet the neverFired/contended/waitingForWork elaboration is disproportionately long for a parameter-level description.

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 2-parameter, no-output-schema tool, the description covers output shape (trajectory, final, metrics, depleted, contended, waitingForWork, neverFired, caveats/assumptions), defaults, refusal thresholds, and engine trade-offs. Nothing an agent needs to call it correctly is missing, apart from the annotation mismatch noted above.

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 already 100%, yet the description adds real meaning beyond it: 'samples' 'sizes the answer, not the run' because metrics are time-weighted over every firing, and 'summary: true omits the times and series arrays entirely (the keys are absent, not null)'. It also explains the engine values and the refused-limit semantics, far exceeding the schema's example blob.

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?

Opens with a concrete verb+resource: 'Run a seeded what-if scenario against a stored model', then enumerates exactly what an override can touch (markings, rates, schedules, structural params). It explicitly separates itself from sibling tools by naming sim_crosscheck, sim_receipt, and the HTTP scenario routes, so an agent can route without opening another 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?

Gives explicit selection rules: ssa is 'the right choice whenever counts are small enough that variance is the answer, or a schedule is in play', while ode 'refuses a schedule' and refuses models with read arcs/inhibitors/guards. It also states when summary:true is the right form ('when nothing will be plotted') and points to docs/engine-selection.md and sim_crosscheck for the full decision rule.

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