Skip to main content
Glama
Sign In

Neumann

by io.github.Kromatic-Innovation
OverviewDiscussionsAdmin

Check a simulation model for errors before running it

check_simulation_model
Read-onlyIdempotent

Checks a model for mistakes before you run it and lists every problem it finds. It looks for loops with no delay, nodes that are not connected, unknown distributions, missing or invalid distribution parameters, and broken formulas. A loop, including an edge from a node to itself, is allowed and is not an error when at least one edge in it has delay 1 or more. Use this when you have built or edited a model and want to fix it without spending a run. To see what a run will cost, use estimate_simulation_size_and_cost instead. It returns is_valid and a list of issues. Each issue gives the rule broken, a severity (error, warning or info, where info is only a note), a message, and the node and edge ids involved. If an edge points at a node that does not exist, you get an error message instead of the list. Cost: free; uses no credits and no free runs. Without an account, a model over 1,000 trials or 20 nodes is rejected, also at no cost.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "graph": "<graph>"
    },
    "name": "check_simulation_model"
  }
}

Input Schema

NameRequiredDescriptionDefault
graphYesThe model: root_nodes (uncertain inputs), calc_nodes (formulas), edges (links; formulas refer to them like {e1}) and run_params (trials and time periods). Same format as run_monte_carlo_simulation's graph, which documents formulas, periods, distributions and financial metrics in full.

Output Schema

NameRequiredDescriptionDefault
issuesNo
billingNoWho you are and what this call cost: principal, auth source, credits debited and balance, or the anonymous allowance left today.
is_validYestrue when there are no errors. Warnings and info notes do not make it false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • removedInput schema / properties / api_key
      Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Your Neumann API key. Optional: this tool is free either way. Pass it so the billing block in the result shows your account, and so the no-account limits of 1,000 trials and 20 nodes do not apply. Get one by creating an account (POST https://neumann.kromatic.com/api/v1/accounts, which returns the key once); setup docs: https://kromatic.com/mcp/neumann.",
-  "title": "Api Key"
-}
    • changedOutput schema / $defs / BillingInfo / properties / auth_source / description
      Previous value: -"How you were identified: bearer (a signed-in connection token), api_key (the api_key argument) or anonymous."New value: +"How you were identified: bearer (a credential sent in the Authorization: Bearer header) or anonymous."
    • changedOutput schema / $defs / BillingInfo / properties / auth_source / enum
      Previous value: -[
-  "bearer",
-  "api_key",
-  "anonymous"
-]New value: +[
+  "bearer",
+  "anonymous"
+]
    • changedOutput schema / $defs / BillingInfo / properties / charged_to / enum
      Previous value: -[
-  "anonymous_allowance",
-  "credits",
-  "none"
-]New value: +[
+  "anonymous_allowance",
+  "free_daily_run",
+  "credits",
+  "none"
+]
    • addedOutput schema / $defs / BillingInfo / properties / free_run_limits
      Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/SignedInLimits"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The free signed-in tier's bounds. Null unless the account signed in with Kromatic."
+}
    • addedOutput schema / $defs / BillingInfo / properties / free_runs_remaining_today
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Free signed-in runs left in the current UTC day, counting this call. Null unless the account signed in with Kromatic.",
+  "title": "Free Runs Remaining Today"
+}
    • addedOutput schema / $defs / BillingInfo / properties / free_runs_reset_at
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "ISO-8601 instant the free signed-in runs next refill (the next UTC midnight). Null unless the account signed in with Kromatic.",
+  "title": "Free Runs Reset At"
+}
    • addedOutput schema / $defs / SignedInLimits
      Added value: +{
+  "description": "The free signed-in tier's bounds (neumann#334), rendered from ``Settings``.",
+  "properties": {
+    "max_nodes": {
+      "description": "Maximum nodes in a free run's graph.",
+      "title": "Max Nodes",
+      "type": "integer"
+    },
+    "max_trials": {
+      "description": "Maximum trials in a free run.",
+      "title": "Max Trials",
+      "type": "integer"
+    },
+    "runs_per_day": {
+      "description": "Free runs per UTC calendar day.",
+      "title": "Runs Per Day",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "runs_per_day",
+    "max_trials",
+    "max_nodes"
+  ],
+  "title": "SignedInLimits",
+  "type": "object"
+}
  2. Added

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the readOnly/idempotent/non-destructive annotations: it discloses the validity rule for loops (allowed when any edge has delay >= 1, including self-loops), the degradation path when an edge targets a nonexistent node (error message instead of the issue list), and the cost/limit profile (free, no credits or free runs, models over 1,000 trials or 20 nodes rejected without an account). The only thing not covered is how many issues are returned or whether they are capped, which keeps it short of a 5 for a tool with such a broad validation surface.

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

Conciseness4/5

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

Front-loaded with what is checked, then the loop caveat, then usage, then return shape, then cost — a logical progression with no filler. It is longer than most definitions, but virtually every sentence (severity vocabulary, error fallback, free-tier node/trial cap) carries operational information an agent would otherwise have to discover by failure.

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?

Despite a deeply nested schema (graph -> root/calc nodes, edges, run_params) the description supplies the fault taxonomy, the false-positive rule for delay loops, the failure mode for dangling edges, and the cost/permission envelope. An output schema already exists so return values needed no explanation, yet the is_valid plus issues shape is summarized compactly, leaving no cue an agent needs in order to call this correctly.

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% and the single graph parameter is exhaustively documented in the schema, so the baseline is 3. The description earns one step above baseline by restating the loop/delay validity semantic that governs how the graph is judged — the one rule a model author is most likely to trip over — rather than merely repeating field names.

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 ("checks a model for mistakes before you run it") and immediately enumerates the exact fault classes it detects: delayless loops, disconnected nodes, unknown distributions, bad parameters, broken formulas. This is unmistakably distinct from run_monte_carlo_simulation and estimate_simulation_size_and_cost among the siblings.

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?

Gives an explicit trigger ("when you have built or edited a model and want to fix it without spending a run") plus a named alternative with its own condition ("to see what a run will cost, use estimate_simulation_size_and_cost instead"). Both the when and the when-otherwise are spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Neumann toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources