Simba MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Run Scenario

run_scenario

Run what-if scenario predictions on a completed model by submitting future channel activity values, and get KPI forecasts for your planned marketing activities.

Instructions

Run a "what-if" scenario prediction on a completed model.

Takes a set of future period rows with channel activity values and predicts the KPI outcome. Use get_scenario_template first to get the expected format, channel names, and baseline values. Channel names are the activity-column keys from the template/results (e.g. "search_activity"), not the channels[].name passed to create_model.

IMPORTANT: Before submitting, replace any NaN/null values in scenario_data with 0. The template from get_scenario_template may contain NaN for channels without historical data, which will cause the prediction to fail.

This is async (returns 202 with status "pending"). Poll get_scenario_results until status is "complete" or "failed".

Workflow: get_scenario_template -> modify values -> run_scenario -> poll get_scenario_results

Args: model_hash: Hash of a completed model. scenario_data: Array of period rows, each a dict with "Date" (YYYY-MM-DD format) and channel activity columns. Channel names must match exactly what get_scenario_template returns in the "channels" field. Example: [{"Date": "2025-01-06", "TV_Impressions": 50000, "Search_Clicks": 1200}] spend_metadata: Optional per-channel spend info for ROI calculation in results. Each entry: {"channel": "TV_Impressions", "metric": "impressions", "cpm": 25.0, "total_spend": 125000, "weekly_spend": [25000, 25000, ...]} rebuild_model: Recompile the model graph before prediction. Must be True (default) for API-initiated scenarios where the model graph is not in memory. evaluate_holdout: Evaluate the scenario against held-out actuals when the scenario period overlaps observed data (default False). skip_slicing: Skip per-channel contribution slicing in the prediction output — faster when only the KPI total is needed (default False). proxy_channels: Optional list of proxy-channel mappings, each mapping a scenario channel to a fitted channel whose transforms it borrows (for channels without their own history).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`model_hash`	Yes
`skip_slicing`	No
`rebuild_model`	No
`scenario_data`	Yes
`proxy_channels`	No
`spend_metadata`	No
`evaluate_holdout`	No

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": "run_scenarioDictOutput",
+  "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?

Discloses critical behavioral details beyond the annotations: the operation is async returning 202 with status pending, NaN values must be replaced with 0, and rebuild_model must be True for API-initiated scenarios. No contradiction with annotations is present.

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 long but well-structured and dense with useful information, including an IMPORTANT warning and a workflow line. Each section earns its place, especially given the parameter count and zero schema coverage.

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?

Covers all seven parameters, prerequisites, async behavior, failure mode, and post-invocation polling. Since an output schema exists, not detailing return values is acceptable, and nothing needed for correct invocation is missing.

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%, and the description fully compensates by explaining every parameter with types, defaults, examples, and constraints. It even clarifies channel naming provenance and provides a concrete scenario_data example.

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: running a what-if scenario prediction on a completed model. It also differentiates itself from the related siblings by referencing the get_scenario_template -> run_scenario -> get_scenario_results workflow.

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?

Explicitly instructs to call get_scenario_template first to obtain the expected format and channel names, and to poll get_scenario_results until completion or failure. Provides a clear workflow and prerequisite ordering, leaving little to inference.

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

Deploy Server