Skip to main content
Glama

sim_prove

Destructive

Prove a structural relation between two stored models and record it with its witness. isomorphicTo: an exact canonical-labelling search (the one behind sim_canonical, seeded with exactly what the check compares) finds a place/transition bijection preserving arcs (direction, type, weight, kinetic), place sort, initial marking, capacity, rate or delay and refine.* tags. It does not compare guards, stages, schedules, constraints, non-refine tags (outcome, port.*), data-place types and initial values, objectives, players or asserted classes; those the pair carries are listed as notCompared, so proved is not 'behaves the same'. subnetOf: a bounded embedding search finds an injective, sort-preserving map (token places to token places, data places to data places, transitions to transitions) of the subject's places and transitions into the object's whose arcs among the image are exactly the subject's (initial markings, capacities, rates, delays and tags are not compared). preservesInvariant (invariant-pullback-v1): an induced embedding as subnetOf's along which every P-invariant of the object pulls back to a P-invariant of the subject (the incidence the shared firing rule implies: consuming and producing arcs on token places). Proved carries the map and a cover — per subject transition, rational coefficients of object transitions with the same incidence — which proves it for every invariant at once, plus invariantDimension (0 means vacuous: the object conserves nothing). Embeddings are tried one image at a time (embeddings onto one image differ by a symmetry of the subject, which keeps or breaks the pullback with them), at most 16 images. refines (id-simulation-v1): every firing sequence of the subject from its initial marking, transitions the object has no transition of (by id) dropped as silent, is one of the object from its own; untimed, guards and fixed delays refused (unknown: a delay is a timer whose in-flight markings an atomic step skips), rates not compared, at least one shared transition id required. Proved carries a simulation relation (pairs of markings closed under the subject's firings, at most 4,096; relationPairs counts them, GET /api/lineage/ lists them), which makes the claim unbounded; neverFired lists the shared transitions the subject never fires from its initial marking, and vacuous: true says it never fires any of them, so the proof (still recorded) has no visible step to match. Neither is declared transitive, so sim_query never closes over them. The answer is proved (with the map, in the caller's direction, or the relation), refuted (exhaustive, with the reason; a refuted refines, or a refuted preservesInvariant where the subject embeds at all, carries refutation, a counterexample sim_check_witness(refutation=…) re-checks: a trace for refines, an invariant per embedding for preservesInvariant, whose list of embeddings is the search's claim; a preservesInvariant refuted because no embedding exists carries none, as a refuted subnetOf carries none) or unknown (a search budget ran out; nothing is recorded, retrying gives the same answer, and unknown is not a no). Needs sign-in (opens OAuth the first time), including with record=false. Costs 3 compute tokens from your account's bucket, or 2 with record=false. Budgets: 1,000,000 refinement steps for both nets' canonical labelling together (isomorphicTo), 2,000,000 embedding steps (subnetOf), 4,000,000 units for elimination, embedding and tests together (preservesInvariant), 20,000,000 firing-rule units and 4,096 pairs (refines); the whole call is also bounded by the 55 s request limit. Writes, only when proved and record is true (the default): one witness, then one relation; isomorphicTo is stored with the smaller id as subject, and storedAs says so when that turned the call round. Otherwise it writes nothing. sim_check_witness re-checks either at any time. With via, sim_prove promotes instead of searching: it takes a structural fact sim_query derived (two to eight stored witnesses composed), re-derives it here from the stored witnesses — every step's witness re-checked against both stored models now, the chain, the composed map's digest, and the composed map checked against the two end models by pkg/morphism — and records the composed map as one direct witness through the same write gate as a search's, so the edge has the same id (one per subject, predicate and object) and is trusted exactly as far. The witness records the derivation as promotedFrom; re-promoting the same derivation writes nothing new (existing: true). A derivation that re-checks invalid or uncheckable is refused and nothing is written; an unknown is never promoted. Costs 2 compute tokens (a derivation re-check plus a store) instead of 3; record=false is refused with via.

Input Schema

NameRequiredDescriptionDefault
viaNopromote a fact sim_query derived instead of searching (JSON, as a string or an object): {"derivation": <a row's support[].derivation>} or {"result": "<sim_query result id>", "row": n, "support": k} (support only when the row carries more than one derivation; 0-based). The derivation must name exactly this subject, predicate and object (either order for isomorphicTo)
objectYescontent id of the stored model the edge points to
recordNowhen proved, store the witness and then the edge; false answers without writing (default true)
subjectYescontent id of the stored model the edge starts from
predicateYesisomorphicTo, subnetOf, preservesInvariant or refines

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / predicate / description
      Previous value: -"isomorphicTo or subnetOf"New value: +"isomorphicTo, subnetOf, preservesInvariant or refines"
    • addedInput schema / properties / via
      Added value: +{
      +  "description": "promote a fact sim_query derived instead of searching (JSON, as a string or an object): {\"derivation\": <a row's support[].derivation>} or {\"result\": \"<sim_query result id>\", \"row\": n, \"support\": k} (support only when the row carries more than one derivation; 0-based). The derivation must name exactly this subject, predicate and object (either order for isomorphicTo)",
      +  "type": "string"
      +}
  2. Added

TDQS

A4.4/5.0
Behavior4/5

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

Goes well beyond annotations: states the write gate (only when proved and record true, one witness then one relation), sign-in requirement, compute-token costs (3 vs 2), per-predicate search budgets and the 55 s request limit, and unknown-is-not-a-no semantics. Annotations already flag writes and destructiveness, so this is strong supplementary context. Minor deduction only because the single-block prose makes some of this easy to miss.

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 substantive but delivered as one monolithic paragraph with no headings or bullet structure, making it very hard to scan. Front-loading is poor: costs, budgets and write behavior are buried mid-paragraph. Length alone is forgivable for a complex tool, but the lack of structure is not.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, yet the description defines the response shapes (proved/refuted/unknown) including what each carries, and covers costs, budgets, auth, write behavior and witness re-checking. An agent has everything needed to call this correctly despite the tool's complexity.

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; however the description adds real meaning beyond the schema for predicate values (the four relation semantics), via promotion mechanics, and record gating. It also adds directional semantics ('isomorphicTo is stored with the smaller id as subject') not captured in the schema.

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?

The opening sentence gives a specific verb and resource ('Prove a structural relation between two stored models and record it with its witness') and the description then enumerates all four predicates with concrete semantics. Siblings like sim_check_witness and sim_query are explicitly distinguished by role.

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?

Explicitly says when to search vs. promote with via, names alternatives (sim_check_witness re-checks, sim_query derives), and states refusal/unknown conditions. It even clarifies that record=false is refused with via, and that re-promoting writes nothing new.

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