Skip to main content
Glama

sim_check_witness

Destructive

Re-check a stored structural witness against both stored models with the independent checker (pkg/morphism), which does no search. Given a structural edge's id, checks every witness of that edge; an edge with none answers unwitnessed (unproven, not disproved). Verdicts: valid, invalid (the map is not a morphism of the stored models), or uncheckable (a model was deleted, a net is malformed, or the predicate is now checked under a newer definition). Public: no sign-in. A witness or edge id is free (no compute tokens). With derivation (from sim_query): re-checks every step's witness, the chain, the composed map's digest and the composed map against both end models, and answers {verdict, reason, hops} (the body POST /api/derivation/check returns); a derivation naming a definition other than the predicate's current one is uncheckable; costs 1 compute token. With reach (a sim_reach answer): replays a trace through metamodel.Enabled/Fire and the guards, or re-checks an invariant witness against the stored model, answering {verdict, reason}; from and to are held to the scenario caps (1,000,000 per place, 4,000,000 in total), and a replay is priced before its first firing and is uncheckable over 200,000,000 work units; an exhaustive no is uncheckable (re-run sim_reach); an unknown answer is refused; costs 1 compute token (POST /api/reach/check). With reach on a system's answer, via is re-checked whole with it: the system is stored and holds the net, every other model has exactly one embedding, each embedding's witness or derivation re-checks valid now, and any translation of component places follows them. With reachResult (the result id sim_reach returns): re-checks a stored answer end to end — the record (its bytes hash to its id, its stored question asks what the answer answers under the budgets it records, and over names what it rests on), via as above, and the witness — answering {verdict, reason, parts, answer, currency}; an unknown answer stays unknown (its witness part is uncheckable, never a no); currency says whether this server would compute the same result (definition, budgets, registry, view, every model still stored) and lists superseded models without flipping current; costs 1 compute token (POST /api/reach/check with {"result": …}, or GET /api/lineage/). With refutation (a refuted sim_prove answer's refutation, ROADMAP.md Phase 12i): re-checks its counterexample against both stored models with pkg/morphism — a refines trace replayed through the shared firing rule on both nets, or for preservesInvariant each embedding re-checked as an induced embedding, its invariant re-checked as a P-invariant of the object (y·C = 0 for every transition) and its pullback shown to break at the subject transition named (that the list holds every embedding is the search's claim and is not re-checked) — answering {verdict, reason}; costs 1 compute token (POST /api/refutation/check). A preservesInvariant or refines witness id re-checks its cover or simulation relation the same way (free, bounded: at most 4,096 cover terms, or 4,096 pairs and 20,000,000 firing-rule units). Give exactly one of id, derivation, reach, reachResult or refutation. Writes nothing.

Input Schema

NameRequiredDescriptionDefault
idNoa witness id, or a structural edge's relation id
reachNoa sim_reach answer, the object exactly as returned (or that object serialized as a string)
derivationNoa sim_query derivation (JSON, as an object or a string holding one): {"predicate", "definition", "subject", "object", "steps": [{"edge", "witness", "inverse"}], "composed"}
refutationNoa refuted sim_prove answer's refutation, the object exactly as returned (or that object serialized as a string): {"predicate", "subject", "object", "counterexample"}
reachResultNothe content id of a stored sim_reach answer (sim_reach's result)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / derivation / description
      Previous value: -"a sim_query derivation as a JSON string: {\"predicate\", \"definition\", \"subject\", \"object\", \"steps\": [{\"edge\", \"witness\", \"inverse\"}], \"composed\"}"New value: +"a sim_query derivation (JSON, as an object or a string holding one): {\"predicate\", \"definition\", \"subject\", \"object\", \"steps\": [{\"edge\", \"witness\", \"inverse\"}], \"composed\"}"
    • changedInput schema / properties / reach / description
      Previous value: -"a sim_reach answer as a JSON string: the object exactly as returned, serialized"New value: +"a sim_reach answer, the object exactly as returned (or that object serialized as a string)"
    • changedInput schema / properties / refutation / description
      Previous value: -"a refuted sim_prove answer's refutation as a JSON string: the object exactly as returned, serialized ({\"predicate\", \"subject\", \"object\", \"counterexample\"})"New value: +"a refuted sim_prove answer's refutation, the object exactly as returned (or that object serialized as a string): {\"predicate\", \"subject\", \"object\", \"counterexample\"}"
  2. Changed4 schema fields changed
    • changedInput schema / properties / derivation / description
      Previous value: -"a sim_query derivation as JSON: {\"predicate\", \"definition\", \"subject\", \"object\", \"steps\": [{\"edge\", \"witness\", \"inverse\"}], \"composed\"}"New value: +"a sim_query derivation as a JSON string: {\"predicate\", \"definition\", \"subject\", \"object\", \"steps\": [{\"edge\", \"witness\", \"inverse\"}], \"composed\"}"
    • changedInput schema / properties / reach / description
      Previous value: -"a sim_reach answer as JSON, exactly as returned"New value: +"a sim_reach answer as a JSON string: the object exactly as returned, serialized"
    • addedInput schema / properties / reachResult
      Added value: +{
      +  "description": "the content id of a stored sim_reach answer (sim_reach's result)",
      +  "type": "string"
      +}
    • addedInput schema / properties / refutation
      Added value: +{
      +  "description": "a refuted sim_prove answer's refutation as a JSON string: the object exactly as returned, serialized ({\"predicate\", \"subject\", \"object\", \"counterexample\"})",
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • addedInput schema / properties / reach
      Added value: +{
      +  "description": "a sim_reach answer as JSON, exactly as returned",
      +  "type": "string"
      +}
  4. Changed2 schema fields changed
    • addedInput schema / properties / derivation
      Added value: +{
      +  "description": "a sim_query derivation as JSON: {\"predicate\", \"definition\", \"subject\", \"object\", \"steps\": [{\"edge\", \"witness\", \"inverse\"}], \"composed\"}",
      +  "type": "string"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "id"
      -]
  5. Added

TDQS

A3.7/5.0
Behavior1/5

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

The description closes with an unqualified 'Writes nothing', i.e., it presents the tool as a pure read/verify operation, yet the annotations declare destructiveHint=true and readOnlyHint=false. That is a direct contradiction of the structured safety contract (Annotation Contradiction), which is exactly the case the rubric scores 1 — notwithstanding the otherwise rich disclosure of verdicts, caps, token costs and refusal paths.

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 content is one enormous undifferentiated paragraph of roughly 450 words with no headers, bullets or mode breakdown, so an agent must parse a wall of text to find the branch relevant to its input. The core purpose is front-loaded, but the sizing is far beyond what a single tool definition warrants.

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 must (and does) enumerate the return shapes per mode: {verdict, reason, hops}, {verdict, reason}/ {verdict, reason, parts, answer, currency}, and the three verdict values with their meanings. Given a five-parameter multi-mode tool this is close to complete, with only error/edge-case responses left implicit.

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; the description goes beyond it by explaining that exactly one of the five parameters may be supplied, that id covers either a witness id or an edge relation id, and that derivation/reach/reachResult/refutation each trigger a different priced code path. The schema already carries the field-level meaning, so it stops short of 5.

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: 'Re-check a stored structural witness against both stored models with the independent checker (pkg/morphism), which does no search.' It explicitly contrasts with search-based siblings (sim_query/sim_prove/sim_reach) by noting the checker 'does no search', so an agent can separate it from those tools without opening the schemas.

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

Usage Guidelines5/5

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

Gives per-mode conditions ('With derivation (from sim_query): ...', 'With reach (a sim_reach answer): ...', 'With reachResult ...', 'With refutation ...') plus the selection rule 'Give exactly one of id, derivation, reach, reachResult or refutation.' It also states what is free vs what costs compute tokens and which inputs are refused, leaving little to inference.

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