whatif

sim_diagnose

Destructive

Test a stored model without writing a fitness test for it. Reports generic gates (mass balance, dormant sources, whether staffing has a knee, whether any knob binds), every derived control ranked by MEASURED influence on the outcome (pool/source/patience/parameter knobs, rate-knob influence is signed), the parameter classes discovered among them, and four structural readings needing no run behind them (T-invariants, siphons/traps with deadlock witnesses, CTMC lumpability, constrained lumping). Pure read. Loss/success inference and objective framing can be corrected by tagging places or declaring simulation.objective — read the sim://docs/classification resource once for how to read influence and noise, the four structural readings, and the two corrections.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	model id
`seed`	No	seed shared by every run, so differences measure the knob and not the dice (default 7)
`hours`	No	horizon per run (default 8)
`realizations`	No	runs averaged per measurement, max 200. Leave unset and the default ADAPTS: a 24-realization pilot that doubles while the baseline outcome sits inside its own noise floor, up to 200 (or maxRealizations, if set); the report's realizations field and sample-size finding record where it settled and why. Set it and that exact count is used, never more. If the report still says underpowered after adapting, raise hours or set a count explicitly.
`inline_context`	No	embed the full JSON-LD @context map in the result instead of the URL it is served from (https://sim.pflow.xyz/ns/v1/context). Default false: the URL resolves to the identical map, so only set this for an offline consumer that cannot fetch it.
`maxRealizations`	No	bounds how far the adaptive default may escalate (default 200, the same ceiling an explicit realizations refuses above). Ignored once realizations is set. For a caller with its own latency budget, not for narrowing a report.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 16, 2026

TDQS

B3.3/5.0

Behavior1/5

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

The description explicitly claims 'Pure read,' but the annotations declare readOnlyHint=false and destructiveHint=true, a direct contradiction. This makes the tool's side-effect profile unreliable and fails to disclose any write/destructive behavior the annotations imply.

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 description is a single dense paragraph, but it front-loads the purpose and packs a lot of necessary output detail into a compact list. It earns its length given the tool's complexity, though bullet formatting would improve readability.

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?

There is no output schema, so the description carries the burden of explaining return values, and it does so thoroughly: gates, ranked influences, parameter classes, structural readings, and correction options. It even directs to a docs resource. The main gap is reconciling the 'Pure read' claim with the destructive annotation, which is already covered under behavioral transparency.

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?

The input schema covers 100% of the six parameters with descriptions, so the schema carries the parameter documentation burden. The description adds some context about realizations adapting and the report's realizations field, but does not need to compensate for schema gaps. Baseline 3 applies.

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 description states a specific action—'Test a stored model without writing a fitness test for it'—and enumerates a detailed set of diagnostic outputs, from generic gates to structural readings. The purpose is unmistakable, though it does not explicitly name a sibling tool to distinguish itself from.

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?

Gives clear context: use this when you want a read-only diagnostic without authoring a fitness test, and explains that corrections happen via tagging or declaring simulation.objective. It also points to a docs resource for interpreting results. It does not name sibling alternatives or state explicit exclusions, but the use case is sufficiently clear.

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?