Skip to main content
Glama
Sign In

whatif

by xyz.pflow.sim
OverviewDiscussionsAdmin

sim_diagnose

Destructive

Returns what one more of each resource (and a change in each rate) is worth to the outcome, each ranked against a measured noise floor — no fitness test to write. Also reports generic gates (mass balance, dormant sources, staffing knee and practical knee, whether any knob binds), parameter classes among the controls, and four structural readings needing no run (T-invariants, siphons/traps with deadlock witnesses, CTMC lumpability, constrained lumping); a lumping or siphon reading that does not apply is one "not applicable" line unless verbose. 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, noise, the knee and structural readings.

Input Schema

NameRequiredDescriptionDefault
idYesmodel id
seedNoseed shared by every run, so differences measure the knob and not the dice (default 7)
hoursNohorizon per run (default 8, max 168)
verboseNodefault false: a structural reading that does not apply (ctmcLumping, constrainedLumping, or siphons when its search did not finish) keeps applicable: false and one refusals line, "not applicable: <reason>", without its fixed scope text. true returns every refusal and scope in full. Changes no measurement and costs nothing extra.
realizationsNoruns 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_contextNoembed 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.
maxRealizationsNobounds 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.

  1. Changed1 schema field changed
    • addedInput schema / properties / verbose
      Added value: +{
+  "description": "default false: a structural reading that does not apply (ctmcLumping, constrainedLumping, or siphons when its search did not finish) keeps applicable: false and one refusals line, \"not applicable: <reason>\", without its fixed scope text. true returns every refusal and scope in full. Changes no measurement and costs nothing extra.",
+  "type": "boolean"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / hours / description
      Previous value: -"horizon per run (default 8)"New value: +"horizon per run (default 8, max 168)"
  3. First observed

TDQS

B3/5.0
Behavior1/5

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

The description asserts 'Pure read', but the annotations declare readOnlyHint=false and destructiveHint=true. A read-only claim directly conflicts with a declared destructive, non-read-only operation, so the behavioral signal is actively misleading. This is an Annotation Contradiction.

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?

It is front-loaded with the core return value, which is good, but the prose is a dense run-on packed with parentheticals and semicolon-chained clauses that make it hard to parse. Some of the enumeration of structural readings is justified by the tool's complexity, but the packaging is not clean.

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 and seven parameters, the description carries the return-value burden and does name the major return categories (influence, noise floor, gates, parameter classes, four structural readings) plus where to learn interpreting them. It is fairly complete, though the precise report structure remains only loosely described.

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 the schema already documents all seven parameters in detail (seed, hours, verbose, realizations, inline_context, maxRealizations). The description adds only marginal parameter color (the 'unless verbose' clause). Baseline 3 applies when the schema does the heavy lifting.

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 gives a concrete purpose: it returns the marginal value of one more unit of each resource (and rate changes) ranked against a measured noise floor, plus gates and structural readings. That is a specific verb+resource an agent can act on. It stops short of naming which sibling (e.g. sim_evaluate, sim_param_heatmap, sim_invariants) it replaces or overlaps with, so sibling differentiation is missing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies when to use it ('no fitness test to write') and gives a prerequisite ('read the sim://docs/classification resource once') plus corrective steps (tagging places, declaring simulation.objective). However, it never explicitly says when to prefer this over alternatives or when it is unnecessary, leaving usage largely inferred.

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

All whatif toolsInspect
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