Skip to main content
Glama

sim_verify

Destructive

Verify declared properties of a stored model: a report with one verdict per property, proved, refuted or unknown (unknown is never a pass, and ok is true only when every property is proved), with evidence for a proof and a counterexample for a refutation, plus caveats naming anything the analysis net could not express. Unset properties check bounded and deadlock-free. Every check starts from the model's own initial marking. Each verdict's method says how far it reaches. structural: from the incidence matrix, with no state search. A structural bounded holds for every initial marking (every place is covered by a P-invariant), and so does a structural conserves (the token total is a P-invariant). A structural invariant or mutual-exclusion verdict rests on a P-invariant's value at this initial marking (its evidence names the P-invariant and the value), so it holds from this marking and from any other that gives that P-invariant the same value, not from every marking: two workers sharing one lock token are proved mutually exclusive, and the same net with two lock tokens is refuted. exhaustive: every state reachable from this initial marking. witness: a firing sequence found by targeted search, decisive for this initial marking (a cycle that grows a place without bound). partial: the search was truncated, so only a refutation is sound. vacuity holds one reading per verdict, in the same order, decided by the engine. proved-vacuously: a proved unreachable whose target needs a token on a place never marked from the initial marking, a proved invariant or mutual-exclusion whose places are all never marked, a proved mutual-exclusion whose marked places never hold more than the bound on their own (so they never compete), or a proved bounded, terminating or conserves when no transition can fire at all (deadlock-free is then refuted); neverMarked names the never-marked places the claim reads and deadTransitions the transitions that would mark them, which never fire. not-vacuous: each place the claim reads (for unreachable, each place its target asks a token on) that neverMarked does not list is marked at some reachable marking the search found; a listed place adds nothing, and a target that asks for no token is not-vacuous without a search. method says what decided it: structural (the arcs alone) or exhaustive (sim_reach's search of the model under its firing rule, evaluating the guards that read only the marking, up to 20000 markings or 20000000 work units). unknown is open, never a no: the search stopped at a bound, skipped a firing the model may make (a guard over action parameters, a lost precondition), or did not run (the model declares a delay, which a one-step search misreads), or a kind with no antecedent has only guarded transitions to fire; it may still list neverMarked. not-applicable: a verdict other than proved, a proved live or reachable (each rests on a firing sequence), or a kind with no antecedent where some transition can fire. ok, the counts and every verdict do not read vacuity: a proved-vacuously verdict still counts as proved. To ask about another starting marking, store the model with that marking (sim_extend's set_initial) and verify it. Read the Verification properties section of sim://docs/authoring for each kind's fields. Free (no compute token); writes nothing.

Input Schema

NameRequiredDescriptionDefault
idYesmodel id
propertiesNoJSON array of properties, each a kind plus the fields that kind reads: deadlock-free, bounded, live, terminating and conserves read none; reachable and unreachable read target (place → token count; places it leaves out are unconstrained); invariant reads expr (a linear relation over place ids, "a + 2*b <= 10"); mutual-exclusion reads places and bound (the token counts of places sum to at most bound at every reachable marking, default 1; for places that each hold at most one token, at most bound of them are marked at once). Any property may carry a name. E.g. [{"kind":"deadlock-free"},{"kind":"mutual-exclusion","places":["win_x","win_o"]},{"kind":"invariant","expr":"a + 2*b == 10"}]. Unset checks bounded and deadlock-free. An unknown kind or field, a field the kind does not read, a missing one, a negative target count, a bound of 0 or less, or a place named twice in places (the counts are summed, so a repeat would count that place twice) is refused with every reason at once, each with the likely meaning; a field sent as null is left out. A place id in places, target or expr that the model does not have is refused too, naming it with the place id it most likely meant, and so is a data place, which holds a value rather than a count; either is refused rather than answered unknown.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / properties / description
      Previous value: -"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."New value: +"JSON array of properties, each a kind plus the fields that kind reads: deadlock-free, bounded, live, terminating and conserves read none; reachable and unreachable read target (place → token count; places it leaves out are unconstrained); invariant reads expr (a linear relation over place ids, \"a + 2*b <= 10\"); mutual-exclusion reads places and bound (the token counts of places sum to at most bound at every reachable marking, default 1; for places that each hold at most one token, at most bound of them are marked at once). Any property may carry a name. E.g. [{\"kind\":\"deadlock-free\"},{\"kind\":\"mutual-exclusion\",\"places\":[\"win_x\",\"win_o\"]},{\"kind\":\"invariant\",\"expr\":\"a + 2*b == 10\"}]. Unset checks bounded and deadlock-free. An unknown kind or field, a field the kind does not read, a missing one, a negative target count, a bound of 0 or less, or a place named twice in places (the counts are summed, so a repeat would count that place twice) is refused with every reason at once, each with the likely meaning; a field sent as null is left out. A place id in places, target or expr that the model does not have is refused too, naming it with the place id it most likely meant, and so is a data place, which holds a value rather than a count; either is refused rather than answered unknown."
  2. First observed

TDQS

C2.9/5.0
Behavior1/5

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

The description ends with 'Free (no compute token); writes nothing', which directly conflicts with the annotations declaring readOnlyHint=false and destructiveHint=true. An agent reading the prose would treat this as a non-mutating inspection call, while the structured hints warn of destructive writes. The rich verdict semantics do not compensate for this contradiction about the tool's side effects.

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 the first sentence, but the remainder is a dense multi-hundred-word run-on mixing verdict semantics, vacuity rules, method taxonomy and error behaviour into a few sprawling sentences. Several clauses restate schema content, and the wall-of-text format makes the genuinely important distinction (ok is true only when every property is proved) easy to miss. It is over-specified rather than concise.

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?

For a tool with no output schema, the description does explain the return value thoroughly: per-property verdicts, ok semantics, evidence/counterexample, caveats, per-verdict method and vacuity readings. The main gap is that the write/no-write behaviour is stated inconsistently with the annotations, and the report shape is prose rather than structured. Otherwise an agent has what it needs to interpret results.

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% and the inline schema already documents `id` and the full property DSL, including the default of bounded + deadlock-free, field validation rules, and place-id error handling. The description repeats much of that ('Unset properties check bounded and deadlock-free') and adds only the initial-marking constraint. Baseline 3 applies since the schema carries the parameter burden.

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 opening clause states a specific verb and resource — 'Verify declared properties of a stored model' — and immediately names the artifact produced (one verdict per property: proved, refuted, unknown). It also positions itself against siblings by describing sim_reach as the underlying search and sim_extend's set_initial as the way to change the starting marking. It stops short of a clean one-line differentiation from near-neighbours like sim_prove or sim_invariants, but the core purpose is unambiguous.

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?

Usage is implied rather than stated: 'Unset properties check bounded and deadlock-free' and 'To ask about another starting marking, store the model with that marking (sim_extend's set_initial) and verify it' give one concrete routing rule to an alternative. There is no explicit when-not-to-use guidance versus sim_reach or sim_prove, and the pointer to sim://docs/authoring pushes semantics elsewhere. Adequate but not decisive.

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