Skip to main content
Glama

Summarize worst, median and best outcomes

summarize_outcome_scenarios

Runs a model once and reports one outcome's worst, median and best values. By default, worst is the lowest value in any trial, median is the middle value, and best is the highest value. Worst always means lowest, so for a cost the worst case is the cheapest one. You can ask for other percentiles instead, such as the 10th and 90th. Use this when you want a short worst, typical and best case story rather than the full distribution. For the full distribution, use run_monte_carlo_simulation. To find which input matters most, use rank_inputs_by_impact. It returns each scenario's outcome value and every input's own value at the same percentile. Those input values are an estimate, not the exact inputs of that trial. It also returns a run_id; a long run comes back as status running, and get_simulation_results gives you progress and then the result. Cost: without an account, 1 of your 3 free runs per UTC day (models up to 1,000 trials and 20 nodes); with an account, 1 credit for a small run or 5 for a large one, currently $0.50 per credit. A model that is invalid or over the no-account limits is rejected before running and costs nothing. If it fails mid-run: anonymous, the free run is used; account, not charged.

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": "summarize_outcome_scenarios"
  }
}

Input Schema

NameRequiredDescriptionDefault
seedNoOptional whole number that fixes the random draws, so repeating the call gives the same result. Exact repeats are guaranteed only for small runs, where trials × nodes × time periods is at most 100,000.
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.
percentilesNoA list of percentiles of the outcome to report. Each is a fraction from 0 to 1: 0.1 is the 10th percentile, the value 10% of trials fall below. Default [0, 0.5, 1]: 0 is the lowest trial (labelled worst), 0.5 the median, and 1 the highest trial (labelled best). Other values are labelled like p10 (10th percentile). Values between 0 and 1 are estimated from a histogram. The labels assume higher is better: for a cost or a duration, 'worst' is the lowest (cheapest or fastest) trial, so ask for percentiles such as 0.1 and 0.9 and read them as low and high.
time_periodNoIndex of the time period to measure, counting from 0: with 12 monthly periods, 11 is month 12. Defaults to the last period. This measures the node's value in that one period, not a total. For a cumulative figure such as year-one profit, add a running-total calc node with formula {e1} + {e2}, where e1 brings in the per-period value and e2 is an edge from the running-total node to itself with delay 1. Then target that node at index 11. This delayed self-edge is allowed; only loops with no delay are errors. In run_monte_carlo_simulation, use a cumsum metric instead.
target_node_idNoThe id of the outcome node to measure. Defaults to the last calc node in the model, which is usually the final outcome.

Output Schema

NameRequiredDescriptionDefault
run_idNo
statusNocompleted
trialsYesNumber of trials in the run.
billingNoWho you are and what this call cost: principal, auth source, credits debited and balance, or the anonymous allowance left today.
progressNoPresent while the run is queued or running.
next_stepNoWhat to do next while the run is still going.
scenariosNoOne entry per percentile, lowest first.
time_periodYesThe period measured (index counted from 0).
runs_executedYesAlways 1; one run is reused for every scenario.
target_node_idYesThe outcome node measured.
credits_debitedNoCredits charged (0 without an account).
estimated_secondsNoRough total run time, in seconds.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed14 schema fields changed
    • removedInput schema / properties / api_key
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "Your Neumann API key. 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. Leave it out if your connection is already signed in, or to use the free no-account tier.",
      -  "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 / RunProgress
      Added value: +{
      +  "description": "How far a queued or running run has got.",
      +  "properties": {
      +    "done": {
      +      "title": "Done",
      +      "type": "integer"
      +    },
      +    "percent": {
      +      "description": "0 to 100.",
      +      "title": "Percent",
      +      "type": "number"
      +    },
      +    "total": {
      +      "title": "Total",
      +      "type": "integer"
      +    },
      +    "unit": {
      +      "description": "trials for a simulation; runs (internal simulations) for a sensitivity sweep.",
      +      "enum": [
      +        "trials",
      +        "runs"
      +      ],
      +      "title": "Unit",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "percent",
      +    "done",
      +    "total",
      +    "unit"
      +  ],
      +  "title": "RunProgress",
      +  "type": "object"
      +}
    • 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: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Rough total run time, in seconds.",
      +  "title": "Estimated Seconds"
      +}
    • addedOutput schema / properties / next_step
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "What to do next while the run is still going.",
      +  "title": "Next Step"
      +}
    • addedOutput schema / properties / progress
      Added value: +{
      +  "anyOf": [
      +    {
      +      "$ref": "#/$defs/RunProgress"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Present while the run is queued or running."
      +}
    • addedOutput schema / properties / run_id
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Run Id"
      +}
    • addedOutput schema / properties / status
      Added value: +{
      +  "default": "completed",
      +  "enum": [
      +    "completed",
      +    "running",
      +    "queued"
      +  ],
      +  "title": "Status",
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / percentiles / description
      Previous value: -"A list of percentiles of the outcome to report. Each is a fraction from 0 to 1: 0.1 is the 10th percentile, the value 10% of trials fall below. Default [0, 0.5, 1]: 0 is the lowest trial (labelled worst), 0.5 the median, and 1 the highest trial (labelled best). Other values are labelled like p10 (10th percentile). Values between 0 and 1 are estimated from a histogram."New value: +"A list of percentiles of the outcome to report. Each is a fraction from 0 to 1: 0.1 is the 10th percentile, the value 10% of trials fall below. Default [0, 0.5, 1]: 0 is the lowest trial (labelled worst), 0.5 the median, and 1 the highest trial (labelled best). Other values are labelled like p10 (10th percentile). Values between 0 and 1 are estimated from a histogram. The labels assume higher is better: for a cost or a duration, 'worst' is the lowest (cheapest or fastest) trial, so ask for percentiles such as 0.1 and 0.9 and read them as low and high."
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that the result includes each scenario's value and input values at the same percentile, that those input values are estimates, that a long run returns status running with get_simulation_results for progress, and the full credit/free-run cost model including rejection and mid-run failure charging. This is unusually rich behavioral context for a non-read-only tool.

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?

The purpose is front-loaded, followed by semantics, alternatives, return behavior, and cost. It is longer than typical but justified by a complex simulation tool with credit consumption; a few points, such as the percentile-label inversion, overlap with the schema rather than adding new information.

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 nested graph schema and five parameters, the description supplies the critical context an agent needs: what the tool returns, how async runs work, how to continue with get_simulation_results, and how costs are incurred. With an output schema present, it does not need to document return shapes further.

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 baseline is 3. The description adds some interpretive guidance about percentile labels (notably that 'worst' means lowest, which is inverted for costs), but it does not explain seed, time_period, or target_node_id, so it does not meaningfully outperform the already detailed schema descriptions.

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 opens with a specific verb and resource: it runs a model once and reports one outcome's worst, median and best values. It explicitly distinguishes itself from run_monte_carlo_simulation (full distribution) and rank_inputs_by_impact (which input matters most), so an agent can tell which sibling to pick.

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 an explicit selection rule: use this when you want a short worst/typical/best case story rather than the full distribution. It names the alternative tools for the full distribution and for input ranking, making the routing decision unambiguous.

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