Simba MCP Server

Official

by getsimba-ai

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Get Optimizer Results

get_optimizer_results

Read-onlyIdempotent

Retrieve budget optimization status and results. Pass a run_id to poll a specific optimization run instead of the latest model-level state.

Instructions

Get budget optimization status and results.

Without run_id: returns the MODEL-LEVEL optimizer state. Top-level keys: optimizer_status ("none"/"pending"/"under way"/"complete"/"failed"), progress + progress_text while running, and results when complete. This reflects the LATEST run on the model — a newer run overwrites it, so a poller can lose sight of the run it submitted.

With run_id (run_optimizer's response includes it): fetches that specific run, immune to later runs. Top-level keys include run_id, model_hash, status, created_at, label, inputs, and results. Poll THIS form when you need to know whether your own run completed.

Reading results rows — the columns come from DIFFERENT conventions and must not be treated as interchangeable:

Revenue / ROI: the optimizer's DECISION math — removal-lift counterfactual revenue at the allocated spend. This is what the solver optimized.
OptimizedEvalRevenue / OptimizedEvalROI and HistoricalRevenue / HistoricalROI: fitted-convention COMPARISON columns — the reconciled accounting view matching the model's Contributions panel. Same spend, different question; never mix them with Revenue/ROI in one summary.
ObjectiveMarginal: the decision-math marginal return at the optimum (the quantity the solver equalizes across unconstrained channels).
MroiAtOptimized / MroiAtOptimizedHdi3 / MroiAtOptimizedHdi97: posterior mROI evaluated at the optimized spend (94% HDI bounds) — a DIFFERENT quantity from ObjectiveMarginal (they can differ by several times); quote the one matching the question asked.
Convergence / KKT certificate fields report solver health. All-None placeholder arrays (PeriodResponse etc.) are stripped server-side.

Args: model_hash: Hash of the model that was optimized. run_id: Optional optimization run id from run_optimizer's response. Pass it to poll a specific run's status/results.

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_optimizer_resultsDictOutput",
+  "type": "object"
+}

First observedv0.3.2Aug 28, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds substantial behavioral context: the overwrite semantics of the latest run, the distinction between decision-math and fitted-convention columns, the stripping of all-None placeholder arrays, and the warning that ObjectiveMarginal and MroiAtOptimized are different quantities. This goes far beyond what annotations provide.

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 description is long but every section earns its place: the two-mode distinction, the column-convention warning, and the parameter explanations are all necessary for correct use. It is front-loaded with the core purpose and mode distinction, then details. Slightly dense, but not bloated.

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 tool's complexity — two modes, multiple result conventions, and a rich output schema — the description is remarkably complete. It explains the top-level keys for both modes, warns about column incompatibility, and clarifies which quantity answers which question. The output schema exists, so return-value details are not the description's job, and the description still adds the interpretive context the schema cannot.

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 description coverage is 0%, so the description must carry the parameter meaning. It does: model_hash is 'Hash of the model that was optimized,' and run_id is 'Optional optimization run id from run_optimizer's response' with guidance to pass it to poll a specific run. The description could add a bit more about the format of model_hash, but it fully compensates for the schema gap.

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 states a specific verb ('Get') and resource ('budget optimization status and results'), and immediately distinguishes two modes: without run_id returns model-level state, with run_id returns a specific run. This clearly differentiates it from siblings like run_optimizer, get_model_results, and get_scenario_results.

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 tells the agent when to use each form: poll without run_id for the latest model-level state, and pass run_id to poll a specific run's completion. It also warns that a newer run overwrites the latest state, so a poller can lose sight of its own run — a clear when-not-to-use signal.

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

Deploy Server