Skip to main content
Glama

sim_distinguish

Destructive

Compare the behaviour of two stored models of one process — typically a net formalized from a document and a net sim_code_to_flow read out of code — and return proved (no word of visible steps separates them), refuted (with separation: the shortest firing sequence one net can make and the other cannot, or after which only one can stop) or unknown. Definition corresponded-traces-v1: correspondence maps subject transitions one-to-one to object transitions (unset: every transition id the two share); each mapped pair is a visible label, and every transition left out is hidden on its own side and closed over, so an internal step the code takes that the document does not name is not a difference. With outcomes (default true) it also compares where each net can stop (a marking where no transition, hidden ones included, is enabled), reading the observed places correspondence.places maps (unset: none, so it compares only whether each can stop); set outcomes=false for nets meant to run forever, such as a server loop. Untimed and interleaving through the shared firing rule: rates, delays and schedules are not compared; a guard, a precondition the net's source carried and it could not represent (guardUnrepresentable, as sim_code_to_flow can leave), a fixed delay, or two consuming arcs from one place into one transition make the answer unknown (nothing is compared). Budgets: 20,000,000 work units, 4,096 joint states, 4,096 markings per side after one word, 262,144 markings held across every joint state kept, 4,096 steps in a run, 1,000,000 tokens per place; the whole call is also bounded by the 55 s request limit. A budget that runs out answers unknown, with agreesThroughLength once the empty word was compared (no word of at most that many labels separates them), and never counts as agreement; retrying gives the same answer. A refuted answer's separation was re-checked by pkg/morphism before it was returned; pass it back as separation, with nothing else, to re-check it against both stored models now, with no search (valid, invalid, or uncheckable: a model was deleted, a net carries a guard, a lost precondition or a fixed delay, the separation names another definition, or the check is over the checker's bounds). A proved answer carries no certificate. Every answer carries means: a refutation shows the two NETS differ; whether the document and the code differ, or a formalization or the correspondence is wrong, the engine does not decide; a proof is agreement between two readings, not fidelity. Unlike sim_prove's refines (one direction, by id, no hidden steps, recorded), it is symmetric and records nothing; unlike sim_diff (the text of two models), it compares behaviour. Needs sign-in (opens OAuth the first time). Costs 2 compute tokens to compare, 1 to re-check a separation. Writes nothing.

Input Schema

NameRequiredDescriptionDefault
objectNocontent id of the other stored model, e.g. the net sim_code_to_flow made from the code
subjectNocontent id of one stored model, e.g. the net formalized from the document
outcomesNoalso compare where each net can stop (default true); false for nets meant to run forever
separationNoa refuted sim_distinguish answer's separation, the object exactly as returned (or that object as a string): {"subject", "object", "witness"}; re-checked with no search. Give it alone
correspondenceNoJSON (an object, or a string holding one): {"transitions": {"<subject transition>": "<object transition>", …}, "places": {"<subject token place>": "<object token place>", …}}, each one-to-one; places optional (the observed places, read where a net stops). Unset: transitions matched by identical id, no observed places. At most 65,536 bytes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior1/5

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

The description explicitly says 'Writes nothing', but the annotations declare destructiveHint=true. This is a direct contradiction about whether the tool can cause destructive effects. Although the description otherwise provides rich behavioral context (budgets, OAuth, token costs, unknown conditions), the contradiction is serious enough to score 1 here.

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?

The description is front-loaded with a clear purpose and contains little obvious repetition, but it is a very dense wall of text. For a tool of this complexity, much of the content earns its place, but the presentation is not concise and could be more structured.

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?

With no output schema and a complex behavior, the description covers return values, certificates, means, budgets, unknown conditions, auth needs, token costs, and re-check behavior. It is complete enough for an agent to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds substantial meaning beyond the schema: it defines correspondence semantics (one-to-one transition mapping, hidden transitions, places), explains the separation re-check mode, and clarifies when outcomes should be false. This is well above the baseline for a fully documented 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 description states a specific verb and resource: compare the behaviour of two stored models and return proved, refuted, or unknown. It explicitly distinguishes this tool from sim_prove (one-directional refinement) and sim_diff (text comparison), so an agent can identify its role without opening a schema.

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?

It gives explicit when-to-use guidance (comparing a document formalization against sim_code_to_flow output), when to set outcomes=false (nets meant to run forever), and how to re-check a refuted separation. It also names alternatives (sim_prove, sim_diff) and the condition that selects them.

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