Skip to main content
Glama

sim_create_system

Destructive

Define a System (ROADMAP.md Phase 11f): a content-addressed, stored set of models and the bindings between them, so the catalog can answer questions about them together. Pass collection (snapshot its model and binding members now; other members are listed under skipped, and a grown collection is a new system, the old id still readable) or models and bindings (JSON arrays of ids), not both. Every binding's endpoints join the models (listed under implied); every binding must pass the check sim_bind applies now (binds-port-v1, or binds-port-v2 for one that declares a unit conversion, or binds-port-v3 for one that declares a delay, and the system then records bindingCheck binds-port-v2 or binds-port-v3, v3 first; a legacy binding sim_bind would refuse today is refused here) and the set must close no loop without a delayed binding, take each input port once, fit the schedule-segment cap and hold no loop over the model limit — the checks sim_run_pipeline applies before it knows the hours. At most 64 models and 64 bindings, and a snapshotted collection of at most 256 members. The id is the hash of the sorted lists, the name and the snapshotted collection (if any), so the same call gives the same id; a snapshot and an explicit list of the same ids are different systems. Returns the id and the view sim_system computes (checks, the structural edges among the models with up to 128 witnesses re-checked now, and the shape: one-net, pipeline, separate or unknown). 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. Needs sign-in (opens OAuth the first time); costs 2 compute tokens; writes one System.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoa name for the system (at most 256 bytes); part of its id
modelsNoJSON array of model ids, e.g. ["id1","id2"]
bindingsNoJSON array of binding ids sim_bind returned; their models are included automatically
collectionNoa collection id whose model and binding members to snapshot (instead of models/bindings); at most 256 members; part of the id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly=false, destructive=true, idempotent=false, and openWorld=true, but the description adds substantial context: it writes one System, needs sign-in with OAuth the first time, costs 2 compute tokens, snapshots collections, enforces caps, applies binding checks, and explains determinism of the id. These are meaningful behavioral traits beyond the annotation layer.

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 description is extremely long and dense, with nested clauses and tangential query examples that are not necessary for selecting or invoking sim_create_system. While the opening sentence is front-loaded, the remainder reads as an unstructured wall of constraints and sibling behavior rather than a concise tool definition.

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?

For a complex creation tool with four parameters, no output schema, and rich annotations, the description is complete enough to call correctly: it covers inputs, mutual exclusivity, id determinism, stored checks, loop constraints, auth, cost, and what is returned. No critical invocation detail is missing.

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 the baseline would be 3, but the description adds important semantics not in the schema: collection and models/bindings are mutually exclusive, collection snapshots members and affects the id, explicit lists and snapshots of the same ids are different systems, and size limits apply. It stops short of fully documenting every edge case in the parameter text.

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: it defines a System as a content-addressed, stored set of models and bindings so the catalog can answer questions about them together. It also distinguishes the tool from closely related siblings such as sim_refine, sim_prove, sim_query, sim_bind, and sim_run_pipeline, so an agent can tell what this tool is for without opening another 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/when-not guidance: pass either collection or models and bindings, not both. It also names alternatives for related questions (use sim_query for containment or refinement queries; use sim_prove for pair proofs) and clarifies where loop refusal happens versus where it is not consulted, leaving little ambiguity about routing.

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