whatif

sim_receipt

Destructive

Run a seeded scenario and get back the result PLUS a signed run receipt: an Ed25519 certificate over (model id, scenario, result hash, service revision) and the inputs the engine recorded for this run: inputs.modelDigest (the model after params), method, hours, samples, realizations and seed as run (with the scenario argument's defaults filled in, and samples at the engine's 60 when unset or below 2), marking (the scenario's overrides), rates (each constant rate the engine ran at; a delayed transition, and one running a schedule, has none), schedule, solver (entry point and options) and engine (go-pflow version from build info, "unknown" when the build carries none, and Go version). evidenceLevel is bound at issue; only POST /api/receipts/verify can report replayed, which it computes from its own re-run, and a scenario-run receipt never reaches proved. A receipt over the 1,048,576-byte body /api/receipts/verify reads (compact JSON) is refused before the run rather than issued (the inputs repeat each override, so a scenario overriding every rate of a very wide model can reach it), and so is engine: "ode": the continuous engine is not bit-reproducible, so its result hash could not be checked; take the receipt on the discrete engine. Anyone can check it two ways — verify the signature offline against the embedded public key (proves this service reported this result), and POST it to /api/receipts/verify (no auth) to replay the run and confirm the result hash reproduces (proves the run is reproducible, not invented); when what the engine reads now differs from the recorded inputs it names the changed keys in inputsChanged, with the new record in inputsNow. The current signing key is at GET /api/receipts/key. Reproducibility is the bottom rung of the trust ladder receipts build: play the model, check the anchors, re-run the seed, verify the certificate. The result is the engine's own form, the one POST /api/models/{id}/scenario returns: contended is the unsplit list with each entry's kind (only conserved and bounded are shortages; queue means the work had not arrived, and state that the model was in another phase of its cycle), not sim_scenario's split into contended, waitingForWork and neverFired, because the result hash covers the result exactly as returned. Costs 1 token from your account's compute bucket.

Input Schema

Name	Required	Description	Default
`id`	Yes	model id to run
`scenario`	No	scenario JSON (hours, samples, seed, marking, rates, schedule, summary — the same shape sim_scenario takes); sim_scenario's defaults (hours 8, realizations 16, seed 20260809) fill whatever is omitted, and the receipt's scenario records the filled-in values so its replay reproduces this run. The result hash covers the result as returned, so a summary: true scenario certifies the summarized form and replays to it

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 30, 2026

changedInput schema / properties / scenario / description

Previous value: -"scenario JSON (hours, samples, seed, marking, rates, schedule, summary — the same shape sim_scenario takes); defaults apply when omitted. The result hash covers the result as returned, so a summary: true scenario certifies the summarized form and replays to it"New value: +"scenario JSON (hours, samples, seed, marking, rates, schedule, summary — the same shape sim_scenario takes); sim_scenario's defaults (hours 8, realizations 16, seed 20260809) fill whatever is omitted, and the receipt's scenario records the filled-in values so its replay reproduces this run. The result hash covers the result as returned, so a summary: true scenario certifies the summarized form and replays to it"

First observedSep 16, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Far exceeds the annotations: discloses cost (1 compute token), pre-run refusals (1,048,576-byte compact-JSON body, and engine 'ode' as non-bit-reproducible), how evidenceLevel is bound and that a scenario-run receipt never reaches 'proved', and the inputsChanged/inputsNow behavior when the engine's reads differ. Annotations only say destructive/open-world/non-idempotent; the description supplies the concrete limits and side effects an agent actually needs.

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?

The purpose is front-loaded in sentence one, but the body is a several-hundred-word run-on thick with nested parentheticals (rate/schedule/solver/engine enumeration, trust-ladder aphorism) for a two-parameter tool. Much of it is useful, yet it is organized as a wall rather than scannable statements, and lines like the trust ladder and key-endpoint pointer could be trimmed or moved.

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?

There is no output schema, so the description must carry the return shape, and it does: it enumerates the receipt's inputs fields, evidenceLevel, verification paths, and the result-form contract that the hash covers. Despite its verbosity, an agent has everything needed to call it and interpret the result 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 meaning beyond the schema: defaults are filled in and recorded so replay reproduces the run, samples is clamped to the engine's 60 when unset or below 2, and a summary:true scenario certifies and replays the summarized form. That is real added semantics about how the scenario argument is normalized.

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: run a seeded scenario and return the result plus an Ed25519-signed run receipt over (model id, scenario, result hash, service revision). It also explicitly distinguishes its output shape from sim_scenario's (contended as unsplit list vs. split into contended/waitingForWork/neverFired), so an agent can tell the two apart without opening schemas.

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?

Names concrete alternatives and their roles: POST /api/models/{id}/scenario for the plain result, /api/receipts/verify for replay (no auth), GET /api/receipts/key for the signing key, and sim_scenario for the alternate result form. It also gives an explicit directive to take the receipt on the discrete engine because the ode engine is refused. It never states a clean 'use this instead of sim_scenario when you need proof' rule, so the choice is inferable rather than spelled out.

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

All whatif tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?