Skip to main content
Glama

sim_system

Destructive

Returns a stored System's view ({id}), the models whose ports can bind to one declared port ({model, port, direction?, among?}), or the stored systems that name a model or a binding ({naming}); one form per call. {id}: the system's view, computed now and never stored (system-view-v2): each model (present, superseded), each binding with its binds-port check (v1, or v2 with its convert when it declares a unit conversion, or v3 with its delay when it declares one) and whether the set runs as a pipeline (with its loops and maxHours when it holds one), the isomorphicTo/subnetOf edges among the models with up to 128 witnesses re-checked (past that the view is truncated and the rest read unchecked), and the shape — one-net when one member has every other embedded in it by a direct witnessed edge or a chain of edges of one predicate through any stored model, every hop's witness and the composed map re-checked (net, embeddings: a direct one names edge and witness, a chained one its derivation, which sim_check_witness(derivation=…) re-checks; closure says what the chain search cost; sim_reach then answers on that net), pipeline when it holds bindings (they link rates, not tokens: sim_reach answers unknown), separate otherwise (notOneNet says why; a chain mixing subnetOf and isomorphicTo hops does not count), unknown when the witness bound was reached before any member qualified, or the chain search stopped at its hop, model or work bound (closure-incomplete: not a no). {model, port, direction?, among?}: what can bind to that declared port — every model with a port sim_bind would accept against it without a unit conversion (opposite direction, equal kind, units agreeing where both declare one), ranked units-agree first, then model id and port; each row carries the sim_bind arguments. A port whose declared unit differs is counted under excluded as unit-differs, not listed: it binds only through sim_bind with convertFrom, convertTo and convertFactor (binds-port-v2), and an empty answer means none binds without one. The universe is the visible catalog, or among (a collection's model members, at most 256, or a system's models, where a candidate that would take a bound port or close a loop of undelayed bindings is counted under excluded, never listed, and one that closes a loop already holding a delayed binding is listed with closesLoop: bindable-v3). Every model in the universe is searched (bindable-v2; bindable-v3 among a system), through a port index that keeps each model's ports by direction and kind, read once per content id and synced from the listing on every call (a model another instance stored is searched on the next call). At most 256 models the index does not hold yet are read per call (past it status is truncated with bound fetches and unscanned says how many were left; ask again and it continues), 100000 candidate ports checked and 50 rows listed: past any bound status is truncated, and if a member model cannot be read status is incomplete (listed under unreadable); in both cases the rows are in partialRows. candidates, scanned, unscanned, fromIndex, read and portChecks say exactly how far it searched; the index holds at most 16777216 bytes of ports (of which at most 2097152 for models no catalog-wide search has listed, such as an among search's or the asked model's) and at most 65536 bytes for one model, and a model past any of these is searched but not kept (notKept). The call's token covers its first 64 reads; each further 64 cost one more token, charged before they are read, and when the bucket cannot cover them status is truncated with bound rate. {naming}: every stored system whose models or bindings include that id (as: model or binding), sorted by system id, from an index synced from the store's listing on every call (a system another instance stored is seen on the next read). At most 100 systems listed (past it status is truncated, total says how many) and at most 256 not-yet-read systems fetched per call (past it status is incomplete and unindexed says how many are unread; ask again and it continues); the index holds at most 33554432 bytes of systems, and once full nothing more is indexed on that instance (status incomplete, unindexed says how many, and asking again does not change it); a stored system that cannot be decoded also keeps status incomplete (listed under unreadable), and asking again does not clear it; in every case the rows are in partialSystems. A system cannot be named (systems do not nest) and a collection is refused, naming the remedy; an id no entity holds any more (a deleted model) is answered when a system still names it. Systems are linkable and collectable: sim_link puts one in a collection (hasMember) and relates it with cites, about, broader and related. This is not refines: a system's edges are isomorphicTo and subnetOf (embeds by wiring / is the same coloured net). refines (trace inclusion with transitions matched by id) and preservesInvariant (the object's P-invariants pull back along an embedding) are proved one pair at a time by sim_prove and are never walked by closure, since neither is declared transitive. For "what contains this pattern?" ask sim_query with closure: {"select":["?m"],"where":[{"subject":"","predicate":"subnetOf","object":"?m","mode":"closure"}]} (isomorphicTo for copies; add {"subject":"","predicate":"hasMember","object":"?m"} to scope it), each row carrying a derivation sim_check_witness re-checks; a subnetOf row claims no behaviour inclusion. For "what does this model refine?" ask sim_query for one hop: {"select":["?m"],"where":[{"subject":"","predicate":"refines","object":"?m"}]}, each row an edge sim_prove recorded. A loop between models runs only through a binding that declares a delay (sim_bind delay; ROADMAP.md Phase 12j): a system may hold one, of at most 4 models, and its view lists it under pipeline.loops with pipeline.maxHours, the longest horizon sim_run_pipeline runs it at (0 when no horizon of 0.01 h or more does; pipeline.runnable covers only the checks that do not depend on the hours), where it is solved as an exact fixed point over the horizon (pipeline-loop-v1). A loop with no delayed binding is refused when a system is defined and by sim_run_pipeline, and sim_bind refuses a self-binding. A port search with among a system (bindable-v3) lists a candidate that closes a loop already holding a delayed binding, with that loop's models under closesLoop, and counts one that would close a loop of undelayed bindings under excluded as closes-loop (sim_bind with a delay can close it); a catalog or collection search does not consult stored bindings, so sim_create_system or sim_run_pipeline is where such a loop is refused. Public: no sign-in; costs 1 compute token (a port search, 1 more per 64 models read past its first 64); writes nothing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoa system id from sim_create_system: describe it
portNothe element id of model's declared port
amongNoa collection (at most 256 members) or system id to search instead of the visible catalog
modelNoa model id: with port, what can bind to that port
namingNoa model or binding id: list the stored systems that name it
directionNo"output" or "input", needed only when the element declares both

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / naming
      Added value: +{
      +  "description": "a model or binding id: list the stored systems that name it",
      +  "type": "string"
      +}
  2. Added

TDQS

B3.2/5.0
Behavior1/5

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

The description closes with 'Public: no sign-in; costs 1 compute token ... writes nothing', i.e. it presents the tool as a pure read/search with no mutation and zero destructive effect. The annotations declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, which directly contradicts that claim. Per the rubric this is an annotation contradiction.

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?

For a 6-parameter tool this is a massive wall of text with deeply nested parentheticals and version tags (system-view-v2, binds-port-v3, bindable-v3, pipeline-loop-v1). The three forms are listed up front, which helps, but the volume is wildly disproportionate and most sentences are not skimmable.

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?

Given no output schema, the description carries the return-shape burden and does so exhaustively: view fields (models, bindings, edges, shape), row contents, and failure statuses (truncated, incomplete, unreadable, notKept, partialRows/partialSystems). Combined with token charges and index bounds, an agent has nearly everything needed despite the absence of an output schema.

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 description coverage is 100%, so baseline is 3, and the description adds real meaning the schema lacks: 'among (a collection's model members, at most 256, or a system's models)' with its excluded/closesLoop semantics, and direction 'needed only when the element declares both'. It does not add syntax beyond that, so not a 5.

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 first sentence enumerates the three call forms precisely ({id} system view, {model, port, direction?, among?} bindable-port search, {naming} reverse lookup) and repeatedly contrasts itself with siblings like sim_query, sim_reach and sim_bind. That is far more specific than a tautology, but the actual purpose is buried under thousands of words of nested detail, so an agent must excavate it rather than read it.

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

Usage Guidelines4/5

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

It names alternatives explicitly and gives routing conditions: 'For "what contains this pattern?" ask sim_query with closure', the sim_query snippet for refines, and the note that 'This is not refines' and 'sim_reach then answers on that net'. That is genuine when-to-use guidance, though it is scattered rather than front-loaded and there are no clean exclusions up front.

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