Simba MCP Server

Official

by getsimba-ai

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Get Scenario Results

get_scenario_results

Read-onlyIdempotent

Retrieve scenario prediction results and status. Use run_id to fetch a specific saved run and avoid overwritten data from newer scenarios.

Instructions

Get scenario prediction results.

Without run_id: returns the MODEL-LEVEL scenario state — status (pending/complete/failed) and, when complete, the full prediction data including predicted KPI per period, channel contributions, confidence intervals, and base components (intercept, seasonality, trend). This reflects the LATEST scenario on the model — a newer run overwrites it, so a poller can lose sight of the run it submitted.

With run_id (run_scenario's response includes it): fetches that specific saved run, immune to later runs — keys include run_id, model_hash, name, status, pinned, notes, tags, key_metrics, timestamps, inputs (the submitted payload), and results. Poll THIS form when you need to know whether your own run completed, or to disambiguate back-to-back scenarios.

NOTE: Failed scenarios return status "failed" with an error message in the JSON body (not an HTTP error). Always check the status field.

Args: model_hash: Hash of the model the scenario was run on. run_id: Optional scenario run id ("scn_..."), from run_scenario's response or list_runs(artifact="scenario").

Input Schema

TableJSON Schema

Name	Required	Description	Default
`run_id`	No
`model_hash`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.5.0Sep 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "get_scenario_resultsDictOutput",
+  "type": "object"
+}

First observedv0.3.2Aug 28, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior. The description adds meaningful behavioral context beyond these: a newer run overwrites the latest scenario, and failed scenarios return an HTTP 200 with status 'failed' plus an error message in the body, so callers must check the status field.

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

Conciseness5/5

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

The description is lengthy but earns its length: mode-by-mode behavior, a critical failure-mode note, and an Args block. The core distinction between the two forms is front-loaded, and every section adds necessary information with no filler.

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?

An output schema exists, so detailed return-value documentation is unnecessary. For a two-mode polling tool, the description covers overwrite semantics, failure representation, run_id provenance, and when to use each form, leaving no practical gap for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains model_hash as the hash of the model the scenario was run on, and defines run_id's format ('scn_...') plus where to obtain it: from run_scenario's response or list_runs(artifact='scenario'). This fully covers both parameters.

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-resource pairing ('Get scenario prediction results') and then defines two distinct behaviors: model-level latest state versus a specific saved run identified by run_id. This clearly distinguishes it from run_scenario and list_runs, which are the most related 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?

The description explicitly states the condition for each invocation form: without run_id returns the latest scenario state with overwrite risk, while with run_id fetches a specific saved run. It also says directly, 'Poll THIS form when you need to know whether your own run completed, or to disambiguate back-to-back scenarios,' which is unambiguous usage guidance.

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

Deploy Server