Skip to main content
Glama

sim_reach

Destructive

Returns whether the marking to is reachable from the marking from in ONE stored net (a model, or a system that is one net): yes with a firing trace, no with a re-checkable P-invariant (or after an exhaustive search), or unknown with every reason. A sim_compose result is one fused net, so it qualifies; a sim_bind binding or a collection links rates, not tokens, and answers unknown (not-one-net). A system id (sim_create_system) is answered on its one net when one member has every other embedded in it by a witnessed subnetOf or isomorphicTo edge or a chain of edges of one predicate (the answer carries via: an edge and witness per member, or the derivation sim_check_witness(derivation=…) re-checks); otherwise it answers unknown: not-one-net when it holds bindings (they link rates, not tokens) or no member qualifies, system-truncated when its witness bound was reached or the chain search stopped at a bound. On a one-net system, a key in from or to may name a member's place as : (the member's id, or its name when no other member shares it): it is translated into the net place that member's embedding maps it to, the answer's from and to are the translated question, and via.translation lists each key's member, place and net place, which sim_check_witness(reach=…) re-checks against the stored witnesses. Refused, naming the key: a member or place the system does not have, a data place, a key that reads more than one way, a place two valid witnesses of the member's edge map differently, and two keys landing on one net place with different counts; more than 16 other witnesses to compare answers unknown (translation-budget). from is a sparse override on the model's declared initial marking (unset = declared). to constrains only the places it names, each to exactly that count; naming every token place asks for an exact marking. Unknown or data places, negative or fractional counts and counts over the scenario caps (1,000,000 per place, 4,000,000 in total) are refused. Reachability here is untimed: each firing is one atomic step under the shared firing rule (read and inhibitor arcs, capacities, guards decidable from the marking); rates, schedules, delays and stages play no part. Answers: no with a P-invariant y whose weighted sum differs between from and to (when to leaves a place of y free, to alone must already exceed it), valid whatever read arcs, inhibitors, capacities or guards allow, since those only remove firings; no (exhaustive) when every marking reachable from from was searched; yes with a firing trace (shortest among the firings the search makes; reads says when it skipped some); unknown (unknownBecause lists each cause) when neither is found within 100,000 markings or 20,000,000 work units, when a firing would pass 1,000,000 tokens on a place, when a guard fails to evaluate at a reached marking, when a transition whose guard reads action parameters (or does not parse, or whose precondition was lost) was enabled and so left out, when the invariant algebra runs past its 20,000,000-operation budget, is cut short or needs coefficients over 2147483647, or when a found trace would cost the independent checker more than 200,000,000 work units to replay. Unknown is not a no. Every answer (unknown included) is stored: question is the content id of the question as asked (the id, from and to as written, the definition and the budgets), result the id of the answer with what it was computed over (the net, every model, edge and witness via rests on, the predicate registry and system view for a system); a repeated question is served from a per-instance cache with the same bytes, and storedNote says why an answer too large to store (over 262,144 bytes) was not. Public: no sign-in; costs 2 compute tokens (a search plus a store). Re-check a yes or an invariant no with sim_check_witness(reach=), which also re-checks via whole; re-check a stored answer end to end with sim_check_witness(reachResult=) or GET /api/lineage/.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesJSON object of the places to constrain, each to exactly that count, e.g. {"done": 1}. On a system, a key may be <model>:<place> for a member's place, translated into the net's
fromNoJSON object of place -> whole token count overriding the declared initial marking, e.g. {"queue": 3}; unset = the declared marking. On a system, a key may be <model>:<place> for a member's place
systemYescontent id of one stored model, or of a system (sim_create_system)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / from / description
      Previous value: -"JSON object of place -> whole token count overriding the declared initial marking, e.g. {\"queue\": 3}; unset = the declared marking"New value: +"JSON object of place -> whole token count overriding the declared initial marking, e.g. {\"queue\": 3}; unset = the declared marking. On a system, a key may be <model>:<place> for a member's place"
    • changedInput schema / properties / to / description
      Previous value: -"JSON object of the places to constrain, each to exactly that count, e.g. {\"done\": 1}"New value: +"JSON object of the places to constrain, each to exactly that count, e.g. {\"done\": 1}. On a system, a key may be <model>:<place> for a member's place, translated into the net's"
  2. Changed1 schema field changed
    • changedInput schema / properties / system / description
      Previous value: -"content id of one stored model (a sim_compose result is one fused net)"New value: +"content id of one stored model, or of a system (sim_create_system)"
  3. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, implying a write operation, which the description confirms by disclosing storage of every answer and a 2 compute token cost. It also discloses refusal conditions, unknown reasons, budget limits, and caching behavior. The destructiveHint is somewhat surprising for a reachability query, but the description clarifies it is a computation that persists results, adding useful context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely long, dense, and poorly structured, containing multiple run-on sentences and nested clauses. It front-loads the core purpose but then buries essential details in an overwhelming wall of text that is hard for an agent to parse efficiently.

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?

Given the complexity of reachability analysis, system translation, and multiple answer states, the description is remarkably complete. It covers input semantics, refusal cases, unknown conditions, storage behavior, and re-check paths, leaving no significant gaps for an agent to invoke it correctly.

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 coverage is 100%, so the schema already documents all three parameters including the sparse override and system key syntax. The description adds operational context like refusal rules for negative/fractional counts and data places, but doesn't introduce new parameter-level semantics beyond what the schema provides. Baseline 3 is appropriate.

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: returns whether a marking is reachable from another in one stored net, with the three possible outcomes spelled out. It distinguishes itself from sim_compose, sim_bind and sim_create_system by explaining exactly which inputs qualify as one net.

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?

Extensively specifies when this tool applies versus alternatives: a sim_compose result qualifies, a sim_bind binding does not, a collection is not one net, and a system qualifies only under witnessed embedding conditions. It also routes to sim_check_witness for re-checking. The when/when-not guidance is explicit and detailed.

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