Neumann

Estimate a simulation's cost and size before running it

estimate_simulation_size_and_cost

Read-onlyIdempotent

Predicts how large a run of a model will be and how many credits it will cost, without running it. Use this before running a large or unfamiliar model, or to check that an account can afford it. It does not look for mistakes; use check_simulation_model for that. It returns the number of trials, time periods, nodes and edges, the estimated peak memory in MB, a complexity score, the size tier (small or large), the credit cost for an account, and a rough run time in seconds for run_monte_carlo_simulation and for rank_inputs_by_impact (which runs the model many times). Runs over about 40 seconds continue in the background and are collected with get_simulation_results. A run is small when trials × nodes × time periods is at most 100,000, and large otherwise. Accounts have no fixed trial or node limit. That cost is what run_monte_carlo_simulation, summarize_outcome_scenarios and rank_inputs_by_impact each charge for this model. A model with mistakes returns an error instead of an estimate. 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": "estimate_simulation_size_and_cost"
  }
}

Input Schema

Name	Required	Description	Default
`graph`	Yes	The 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

Name	Required	Description
`tier`	Yes	small when trials × nodes × time periods is at most 100,000, otherwise large.
`trials`	Yes
`billing`	No	Who you are and what this call cost: principal, auth source, credits debited and balance, or the anonymous allowance left today.
`edge_count`	Yes
`node_count`	Yes
`credit_cost`	Yes	Credits an account would be charged by run_monte_carlo_simulation, summarize_outcome_scenarios or rank_inputs_by_impact for this model.
`time_periods`	Yes
`graph_complexity`	Yes	A relative complexity score; higher means heavier.
`estimated_seconds`	No	Rough run time of one run_monte_carlo_simulation or summarize_outcome_scenarios call, in seconds.
`estimated_memory_mb`	Yes	Estimated peak memory, in MB.
`estimated_seconds_rank_inputs`	No	Rough run time of rank_inputs_by_impact with its default three values per input, in seconds. Over about 40 seconds, it finishes in the background.

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedNov 2, 2026

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"
+}

addedOutput schema / properties / estimated_seconds

Added value: +{
+  "default": 0,
+  "description": "Rough run time of one run_monte_carlo_simulation or summarize_outcome_scenarios call, in seconds.",
+  "title": "Estimated Seconds",
+  "type": "number"
+}

addedOutput schema / properties / estimated_seconds_rank_inputs

Added value: +{
+  "default": 0,
+  "description": "Rough run time of rank_inputs_by_impact with its default three values per input, in seconds. Over about 40 seconds, it finishes in the background.",
+  "title": "Estimated Seconds Rank Inputs",
+  "type": "number"
+}

AddedOct 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well past the readOnly/idempotent annotations: it discloses that the call is free and consumes no credits or free runs, that runs over ~40 seconds continue in the background and are collected via get_simulation_results, that invalid models return an error rather than an estimate, and that unauthenticated callers are rejected above 1,000 trials or 20 nodes. It also defines the small/large threshold concretely (trials × nodes × time periods ≤ 100,000).

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?

Purpose and the key exclusion are front-loaded, and almost every sentence adds operational information. It is dense but slightly sprawling, and the 'Cost: free; uses no credits and no free runs' line partly repeats the rejection-at-no-cost note later in the same paragraph.

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 pre-flight estimation tool this is complete: it covers when to call it, what it returns, cost implications, timeout/background behavior, error behavior, and unauthenticated limits. Nothing an agent needs in order to call it correctly or interpret the answer is missing, and the output schema covers the return shape.

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?

The single `graph` parameter already carries 100% schema description coverage including a full example, so the schema does most of the work. The description adds one genuinely new semantic — the size formula used for classification and cost — but does not otherwise explain the graph structure. Baseline 3 is appropriate when schema coverage is this complete.

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 precise verb and resource — 'Predicts how large a run of a model will be and how many credits it will cost, without running it' — and immediately separates itself from check_simulation_model and from the actual run tools. An agent can pick this tool over its siblings without reading the 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?

Gives explicit conditions: 'Use this before running a large or unfamiliar model, or to check that an account can afford it', plus the negative case 'It does not look for mistakes; use check_simulation_model for that.' The alternative and its selecting condition are both named.

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

All Neumann tools Inspect

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

Need Help?