Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

xyz.pflow.sim/whatif

REMOTE · SIM.PFLOW.XYZ · SCANNED OCT 7

Conversational what-if simulation: build, diagnose and compare Petri-net models; CC0 catalog.

Available components

+2 this week 69 Trust /100

Recent critical change

Authorization (17 Sept 2026). See the changelog before you install this server.

Trust breakdown (7 categories)

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →

Endpoint Security57
Transport & Reachability100
Schema Quality & AI Usability76
  • 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
  • AI-judged instruction clarity (excellent).Pass
  • Context-footprint check failed: tool/resource definitions use about 19535 tokens (~348/item across 56 items; 55 tools + 1 resources), over budget; trim descriptions and params. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management67
  • Stability observed for 20 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 100% of tool parameters carry a description.Pass
Tool Safety50
  • Injection-marker check failed: the description of parameter "system" on tool "sim_reroll" contains an instruction override, the text "override the original prompt", at byte 0 of that field, plus 1 further marker(s) of the same kind. See how to fix → Fail
  • All 4 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
  • An AI judge read all 56 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities60
  • Spec-recency check failed: implements MCP spec 2025-06-18; the latest is 2026-07-28. See how to fix → Fail
Install

How do I install the xyz.pflow.sim/whatif MCP server?

xyz.pflow.sim/whatif is a hosted endpoint at https://sim.pflow.xyz/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

remote · sim.pflow.xyz

# add to Claude Code
claude mcp add --transport http xyz-pflow-sim-whatif 'https://sim.pflow.xyz/mcp'
// .cursor/mcp.json
{
  "mcpServers": {
    "xyz-pflow-sim-whatif": {
      "url": "https://sim.pflow.xyz/mcp"
    }
  }
}
// .vscode/mcp.json
{
  "servers": {
    "xyz-pflow-sim-whatif": {
      "type": "http",
      "url": "https://sim.pflow.xyz/mcp"
    }
  }
}
# ~/.codex/config.toml
[mcp_servers.xyz-pflow-sim-whatif]
url = "https://sim.pflow.xyz/mcp"
// opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "xyz-pflow-sim-whatif": {
      "type": "remote",
      "url": "https://sim.pflow.xyz/mcp",
      "enabled": true
    }
  }
}
# add to OpenClaw
openclaw mcp add xyz-pflow-sim-whatif --url 'https://sim.pflow.xyz/mcp' --transport streamable-http
# ~/.hermes/config.yaml
mcp_servers:
  xyz-pflow-sim-whatif:
    url: "https://sim.pflow.xyz/mcp"
// ~/.netclaw/config/netclaw.json
{
  "McpServers": {
    "xyz-pflow-sim-whatif": {
      "Transport": "http",
      "Url": "https://sim.pflow.xyz/mcp"
    }
  }
}
# add to Vellum
assistant mcp add xyz-pflow-sim-whatif -t streamable-http -u 'https://sim.pflow.xyz/mcp'
// mcp.json
{
  "mcpServers": {
    "xyz-pflow-sim-whatif": {
      "type": "http",
      "url": "https://sim.pflow.xyz/mcp"
    }
  }
}

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 7 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 57 to 67. That category is still filling its 30-day observation window: 17 days of observed history at the previous scan, 20 at this one. The score rises as the window fills, whether or not the server changes.

  • 4 Oct 26 +1
    • Tool “sim_run_pipeline” rewrote its description, which is the text the model reads security
  • 3 Oct 26 0
    • New tool “sim_accept_migration”, which the server declares destructive security
    • New tool “sim_create_system”, which the server declares destructive security
    • New tool “sim_migration_offers”, which the server declares destructive security
    • New tool “sim_system”, which the server declares destructive security
    • Tool “sim_bind” rewrote its description, which is the text the model reads security
    • Tool “sim_check_witness” rewrote its description, which is the text the model reads security
    • Tool “sim_create_collection” rewrote its description, which is the text the model reads security
    • Tool “sim_edges” rewrote its description, which is the text the model reads security
    • Tool “sim_get_binding” rewrote its description, which is the text the model reads security
    • Tool “sim_link” rewrote its description, which is the text the model reads security
    • Tool “sim_neighbors” rewrote its description, which is the text the model reads security
    • Tool “sim_prove” rewrote its description, which is the text the model reads security
    • Tool “sim_query” rewrote its description, which is the text the model reads security
    • Tool “sim_reach” rewrote its description, which is the text the model reads security
    • Tool “sim_run_pipeline” rewrote its description, which is the text the model reads security
    • Tool “sim_supersede_model” rewrote its description, which is the text the model reads security
    • Schema quality: 239 → 346 ▼ functional
    • “sim_bind” added an optional parameter “convertFactor” cosmetic
    • “sim_bind” added an optional parameter “convertFrom” cosmetic
    • “sim_bind” added an optional parameter “convertTo” cosmetic
    • “sim_bind” added an optional parameter “delay” cosmetic
    • “sim_check_witness” added an optional parameter “reachResult” cosmetic
    • “sim_check_witness” added an optional parameter “refutation” cosmetic
    • “sim_prove” added an optional parameter “via” cosmetic
    • “sim_bind” reworded the description of “fromPort” cosmetic
    • “sim_bind” reworded the description of “toPort” cosmetic
    • “sim_bind” reworded the description of “transform” cosmetic
    • “sim_check_witness” reworded the description of “derivation” cosmetic
    • “sim_check_witness” reworded the description of “reach” cosmetic
    • “sim_prove” reworded the description of “predicate” cosmetic
    • “sim_reach” reworded the description of “from” cosmetic
    • “sim_reach” reworded the description of “system” cosmetic
    • “sim_reach” reworded the description of “to” cosmetic
  • 2 Oct 26 0
    • New tool “sim_check_witness”, which the server declares destructive security
    • New tool “sim_prove”, which the server declares destructive security
    • New tool “sim_query”, which the server declares destructive security
    • New tool “sim_reach”, which the server declares destructive security
    • Tool “sim_bind” rewrote its description, which is the text the model reads security
    • Tool “sim_canonical” rewrote its description, which is the text the model reads security
    • Tool “sim_classify” rewrote its description, which is the text the model reads security
    • Tool “sim_create_collection” rewrote its description, which is the text the model reads security
    • Tool “sim_edges” rewrote its description, which is the text the model reads security
    • Tool “sim_link” rewrote its description, which is the text the model reads security
    • Tool “sim_neighbors” rewrote its description, which is the text the model reads security
    • Tool “sim_supersede_model” rewrote its description, which is the text the model reads security
    • Schema quality: 196 → 239 ▼ functional
    • “sim_link” reworded the description of “object” cosmetic
    • “sim_link” reworded the description of “predicate” cosmetic
    • “sim_link” reworded the description of “subject” cosmetic
  • 30 Sept 26 +1
    • Tool “sim_calibrate” rewrote its description, which is the text the model reads security
    • Tool “sim_code_to_flow” rewrote its description, which is the text the model reads security
    • Tool “sim_compare” rewrote its description, which is the text the model reads security
    • Tool “sim_conformance” rewrote its description, which is the text the model reads security
    • Tool “sim_create_model” rewrote its description, which is the text the model reads security
    • Tool “sim_diagnose” rewrote its description, which is the text the model reads security
    • Tool “sim_distill” rewrote its description, which is the text the model reads security
    • Tool “sim_evaluate” rewrote its description, which is the text the model reads security
    • Tool “sim_link” rewrote its description, which is the text the model reads security
    • Tool “sim_optimize” rewrote its description, which is the text the model reads security
    • Tool “sim_param_heatmap” rewrote its description, which is the text the model reads security
    • Tool “sim_propose_types” rewrote its description, which is the text the model reads security
    • Tool “sim_publish” rewrote its description, which is the text the model reads security
    • Tool “sim_publish_app” rewrote its description, which is the text the model reads security
    • Tool “sim_publish_compare” rewrote its description, which is the text the model reads security
    • Tool “sim_receipt” rewrote its description, which is the text the model reads security
    • Tool “sim_refine” rewrote its description, which is the text the model reads security
    • Tool “sim_run_pipeline” rewrote its description, which is the text the model reads security
    • Schema quality: 178 → 196 ▼ functional
    • “sim_bind” reworded the description of “transform” cosmetic
    • “sim_compare” reworded the description of “scenarios” cosmetic
    • “sim_crosscheck” reworded the description of “hours” cosmetic
    • “sim_diagnose” reworded the description of “hours” cosmetic
    • “sim_distill” reworded the description of “options” cosmetic
    • “sim_evaluate” reworded the description of “horizon” cosmetic
    • “sim_evaluate” reworded the description of “realizations” cosmetic
    • “sim_optimize” reworded the description of “hours” cosmetic
    • “sim_optimize” reworded the description of “samples” cosmetic
    • “sim_optimize” reworded the description of “seed” cosmetic
    • “sim_param_heatmap” reworded the description of “hours” cosmetic
    • “sim_param_heatmap” reworded the description of “range_x” cosmetic
    • “sim_param_heatmap” reworded the description of “range_y” cosmetic
    • “sim_propose_types” reworded the description of “limit” cosmetic
    • “sim_propose_types” reworded the description of “realizations” cosmetic
    • “sim_publish” reworded the description of “scenario” cosmetic
    • “sim_publish_compare” reworded the description of “scenarios” cosmetic
    • “sim_receipt” reworded the description of “scenario” cosmetic
    • “sim_run_pipeline” reworded the description of “realizations” cosmetic
    • “sim_scenario” reworded the description of “scenario” cosmetic
  • 28 Sept 26 +1
    • We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
  • 25 Sept 26 +1
    • We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
  • 23 Sept 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 9 Oct 2026 · Probed https://sim.pflow.xyz/mcp

TLS valid

Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .

Subject Issuer Valid from Valid until Key Signature Serial
CN=sim.pflow.xyz CN=WR3,O=Google Trust Services,C=US 1 Oct 2026 30 Dec 2026 RSA 2048 SHA256-RSA feaa8ca4234680401049f2e85024e248
SANs: sim.pflow.xyz
CN=WR3,O=Google Trust Services,C=US (CA) CN=GTS Root R1,O=Google Trust Services LLC,C=US 13 Dec 2023 20 Feb 2029 RSA 2048 SHA256-RSA 7ff005a91568d63abc22861684aa4b5a
CN=GTS Root R1,O=Google Trust Services LLC,C=US (CA) CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE 19 Jun 2020 28 Jan 2028 RSA 4096 SHA256-RSA 77bd0d6cdb36f91aea210fc4f058d30d

Background: What to check on a remote MCP endpoint →

DNSSEC insecure

Validation of sim.pflow.xyz. — Not signed

Zone DS Keys Algorithms Outcome
. trust_anchor 20326, 38696 8, 8 Verified
xyz. present 3599, 18130 8, 8 Verified
pflow.xyz. absent Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation
Authentication No authorisation required

The endpoint answered without asking for a token. Anyone who knows the URL can reach it.

Result No authorisation required
HTTP status 200

Background: How OAuth 2.1 works in the 2026 MCP spec →

Transports 2 probes
Transport URL Outcome Status Location
streamable-http https://sim.pflow.xyz/mcp Verified 200
http (plaintext) http://sim.pflow.xyz/mcp HTTPS enforced 302 https://sim.pflow.xyz/mcp
MCP tools · 55 exposed · ~19,475 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
sim_run_pipeline ~1,158

Returns one scenario result per model that a set of stored Bindings (see sim_bind) touches, run as a composed pipeline, with the assumptions the composition makes, inTransit (per delayed binding, the source's flow its delay carried past the horizon) and, when the set holds a loop, the loop's reading (loop, pipeline-loop-v1: verdict, claim, components with sweepsNeeded and sweepsRun, sweepsRun, residual). Costs 1 compute token per model run, charged up front, before any model is read, for the most runs the set can take — one per model outside a loop, and a loop's models times the most sweeps it can take — and not refunded when a loop settles in fewer. Defaults: hours 8, seed 1, realizations 0 (one SSA trajectory per model; set it, e.g. 16 as sim_scenario does, since bindings and loops couple means). Caps: hours up to 10000, realizations up to 200, as sim_scenario. Each model runs through its own ordinary scenario in topological order, an output port's trajectory resampled into the target's input-transition schedule, one seed and horizon shared by every model (the discipline sim_compare enforces within one model). A declared conversion is applied exactly as declared: the resampled rate is multiplied by any numeric transform, then by the convert factor. A binding with a delay drives its target that many hours later; before then the target runs on its own declared rate. A loop between models runs only when some binding on it declares a delay. It is solved by sweeps, each running every member once with one delayed binding (cut) driven by the previous sweep, until a sweep reproduces the previous one's schedules bit for bit: verdict fixed-point, whose claim (also assumptions' first line) is that this is the unique fixed point of the coupling over 0 to hours at the seed, followed by its four limits — each model was driven by the other's mean across realizations (mean-field: for joint dynamics build one net with sim_extend), each delay is declared, not measured, before its…

NameTypeReqDescription
bindingIdsstringyesJSON array of binding ids to run together, e.g. ["id1","id2"] — every model these bindings touch is included automatically.
hoursnumber–horizon in hours, shared across every model in the pipeline (default 8)
realizationsnumber–realizations per model (default 0, which the engine runs as a single realization — one SSA trajectory per model, so set it, e.g. 16 as sim_scenario defaults to, when the resampled series should be a…
seednumber–shared seed across every model's run (default 1)

No output schema declared.

No examples provided.

sim_scenario ~547

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, contention, 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, metrics, depleted, contended, caveats and assumptions — the verdict without the chart data, and the right form when nothing will be plotted. 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.

NameTypeReqDescription
idstringyesmodel id
scenariostring–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}]},"…

No output schema declared.

No examples provided.

sim_supersede_model ~214

Mark an old version of your model as replaced by a newer one. The old id keeps working and its commons dedication (if any) stands — only the listing moves on to the successor. Both models must be yours. It also records a supersededBy edge (old → new), so sim_edges(old) and sim_neighbors(old, "supersededBy") show that the supersession happened. Re-pointing an old model to a different successor keeps the earlier edge too, and these edges carry no timestamp, so their order says nothing about which came last: the current successor is the `current` this tool returns (the model's own supersededBy record), not the edge list. Taxonomic edges on the old model are offered for migration to the current successor (sim_migration_offers, accepted with sim_accept_migration), never moved; structural and tool-written edges stay with it.

NameTypeReqDescription
newstringyesmodel id of the successor
oldstringyesmodel id being replaced

No output schema declared.

No examples provided.

sim_system ~1,679

Returns a stored System's view ({id}), the models whose ports can bind to one declared port ({model, port, direction?, among?}), or the stored systems that name a model or a binding ({naming}); one form per call. {id}: the system's view, computed now and never stored (system-view-v2): each model (present, superseded), each binding with its binds-port check (v1, or v2 with its convert when it declares a unit conversion, or v3 with its delay when it declares one) and whether the set runs as a pipeline (with its loops and maxHours when it holds one), the isomorphicTo/subnetOf edges among the models with up to 128 witnesses re-checked (past that the view is truncated and the rest read unchecked), and the shape — one-net when one member has every other embedded in it by a direct witnessed edge or a chain of edges of one predicate through any stored model, every hop's witness and the composed map re-checked (net, embeddings: a direct one names edge and witness, a chained one its derivation, which sim_check_witness(derivation=…) re-checks; closure says what the chain search cost; sim_reach then answers on that net), pipeline when it holds bindings (they link rates, not tokens: sim_reach answers unknown), separate otherwise (notOneNet says why; a chain mixing subnetOf and isomorphicTo hops does not count), unknown when the witness bound was reached before any member qualified, or the chain search stopped at its hop, model or work bound (closure-incomplete: not a no). {model, port, direction?, among?}: what can bind to that declared port — every model with a port sim_bind would accept against it without a unit conversion (opposite direction, equal kind, units agreeing where both declare one), ranked units-agree first, then model id and port; each row carries the sim_bind arguments. A port whose declared unit differs is counted under excluded as unit-differs, not listed: it binds only through sim_bind with convertFrom, convertTo and convertFactor (binds-port-v2), and an empt…

NameTypeReqDescription
amongstring–a collection (at most 256 members) or system id to search instead of the visible catalog
directionstring–"output" or "input", needed only when the element declares both
idstring–a system id from sim_create_system: describe it
modelstring–a model id: with port, what can bind to that port
namingstring–a model or binding id: list the stored systems that name it
portstring–the element id of model's declared port

No output schema declared.

No examples provided.

sim_verify ~176

Verify declared properties of a stored model: deadlock-free, bounded, mutual-exclusion, invariant expressions, reachable/unreachable targets. Verdicts are proved/refuted/unknown — unknown is never a pass — and each carries a method: structural means it holds for ANY initial marking (linear algebra on the incidence matrix, the strongest claim available), exhaustive means this marking's full state space, partial means truncated (only refutations sound). Caveats name anything the analysis net could not express.

NameTypeReqDescription
idstringyesmodel id
propertiesstring–JSON array of properties, e.g. [{"kind":"deadlock-free"},{"kind":"mutual-exclusion","places":["win_x","win_o"]},{"kind":"invariant","expr":"a + 2*b == 10"}]. Default: bounded + deadlock-free.

No output schema declared.

No examples provided.

Common questions

What is the xyz.pflow.sim/whatif MCP server?

xyz.pflow.sim/whatif is an MCP server listed in the public MCP registry as xyz.pflow.sim/whatif. Conversational what-if simulation: build, diagnose and compare Petri-net models; CC0 catalog. This page covers its hosted endpoint (https://sim.pflow.xyz/mcp).

Is the xyz.pflow.sim/whatif MCP server safe to use?

xyz.pflow.sim/whatif scores 69 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

What tools does the xyz.pflow.sim/whatif MCP server expose?

xyz.pflow.sim/whatif exposes 55 tools: sim_accept_migration, sim_bind, sim_calibrate, sim_canonical, sim_check_witness, and 50 more. Their descriptions and schemas cost roughly 19,475 tokens of context every time the server is loaded.

Does the xyz.pflow.sim/whatif MCP server require authentication?

No. We connected to xyz.pflow.sim/whatif without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

Is the xyz.pflow.sim/whatif MCP server still maintained?

xyz.pflow.sim/whatif is still listed as active in the MCP registry. We last reached this channel on 7 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.