Skip to main content
Glama
getsimba-ai

Simba MCP Server

Official
by getsimba-ai

Run Optimizer

run_optimizer

Optimize budget allocation across channels to maximize predicted revenue or profit, respecting per-channel bounds, spend timing, and period costs.

Instructions

Run budget optimization on a completed model.

Finds the optimal budget allocation across channels to maximize predicted revenue — or predicted PROFIT with objective="profit" — within the given constraints.

PROFIT OBJECTIVE: objective="profit" requires a margin source. If the model was built with an operating margin, it is used automatically; otherwise you MUST pass forward_margin (e.g. 0.18 for an 18% margin) or the API returns an error. Result fields (Revenue, ROI, ExpectedResponse) are then on the profit basis.

IMPORTANT:

  • Channel names must exactly match model results (case-sensitive, space-sensitive). Results are keyed by the channel's ACTIVITY COLUMN name (e.g. "search_activity"), not by the channels[].name passed to create_model. Call get_model_results with sections="channel_summary" first to get exact names, or use get_scenario_template to discover channel names and their average CPM values.

  • bounds values are percentages of total_budget (0-100), not currency amounts.

  • laydown_weights and period_cpm must be ARRAYS of length num_periods, not scalars. Wrong: {"TV": 10}. Correct: {"TV": [10, 10, 10, 10]}.

  • The same channel keys must appear in all three: bounds, laydown_weights, and period_cpm.

  • All period_cpm values must be positive (> 0).

  • laydown_weights per channel must sum to a positive value (weights are normalized internally).

Returns 202 (async). Use get_optimizer_results to poll until status is "complete".

Args: model_hash: Hash of a completed model. total_budget: Total budget in currency units. num_periods: Number of periods to optimize over (matches your planning horizon). gamma: Uncertainty-aversion weight on the outcome spread (the objective is mean - gamma * spread). 0.0 = maximize expected return only (most aggressive); higher values penalize uncertainty harder (more conservative). The dashboard typically uses values in the 0-0.1 range. currency: Currency code (e.g. "USD", "GBP"). bounds: Per-channel min/max budget allocation as PERCENTAGES (0-100). Every channel must appear. Example: {"TV_Impressions": {"lower": 5, "upper": 40}, "Search_Clicks": {"lower": 10, "upper": 50}} laydown_weights: Per-channel spend timing weights. Each value is an array of length num_periods. Weights are relative (normalized internally). Use uniform [1, 1, ...] for even distribution across periods. Example: {"TV_Impressions": [1, 1, 1, 1]} period_cpm: Per-channel cost-per-metric for each period. Each value is an array of length num_periods with positive values. Get baseline CPM from get_scenario_template (avg_cpu_by_channel field). Example: {"TV_Impressions": [10.5, 10.5, 10.5, 10.5]} objective: "revenue" (default) or "profit". See PROFIT OBJECTIVE above. forward_margin: Decimal margin in (0, 1], e.g. 0.18 = 18%. Only used with objective="profit"; required when the model has no stored operating margin. period_multiplier: Optional array of length num_periods converting KPI units to revenue per period over the planning horizon (mirrors the model's multiplier_column, e.g. price). include_historical_effect: Include carryover from historical spend in the predicted response (default True). enable_warm_start: Warm-start the optimizer from a previous solution (default True). optimizer_engine: "slsqp" (hardened SLSQP, default) or "marginal" (water-fill engine: allocates until every funded channel shows the same marginal return; exact profit-hurdle semantics and the tightest optimality certificates, with automatic SLSQP fallback). sigma_penalty: How gamma penalizes outcome spread: "std" (default), "variance" or "frozen" (advanced; smoother alternatives for hard-to-converge runs - leave on "std" normally). group_bounds: Joint constraints over channel SETS (#570), e.g. [{"name": "trade", "channels": ["TV", "Search"], "lower": 40, "upper": 60}] with lower/upper in % of total_budget (same convention as bounds). Groups must be disjoint and jointly feasible with the members' per-channel bounds. Presence forces the slsqp engine. Results gain GroupBounds/GroupBoundsReport columns; a BINDING group's members legitimately sit off the global marginal (they share the group's shadow price).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gammaYes
boundsYes
currencyYes
objectiveNorevenue
model_hashYes
period_cpmYes
num_periodsYes
group_boundsNo
total_budgetYes
sigma_penaltyNostd
forward_marginNo
laydown_weightsYes
optimizer_engineNoslsqp
enable_warm_startNo
period_multiplierNo
include_historical_effectNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "title": "run_optimizerDictOutput",
      +  "type": "object"
      +}
  2. First observedv0.3.2

TDQS

A5/5.0
Behavior5/5

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

Annotations provide only generic booleans (readOnlyHint false, etc.), so the description must disclose all behavioral traits. It does: returns 202 asynchronously, requires polling, mandates exact channel names, treats bounds as percentages, enforces array lengths, requires positive CPM, and explains the objective function (mean - gamma*spread). It also covers error conditions like missing forward_margin. No contradiction with annotations exists.

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 justifiably so for a 16-parameter tool. It is well-structured: opening purpose, an 'IMPORTANT' section for critical gotchas, then an Args list. The most critical details (channel name exactness, bounds as percentages, array lengths) are front-loaded. Every sentence adds value, and redundancy between sections is minimal and serves emphasis. The length is proportionate to complexity.

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?

The tool is complex with many interacting constraints and a schema that provides zero descriptions. The description covers all prerequisites, parameter semantics, error conditions, engine choices, and the async flow. It even explains the effect of group_bounds on results. Since an output schema exists, the description appropriately defers return-value details to get_optimizer_results. Nothing an agent needs to invoke it correctly 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%, so the description carries full responsibility for parameter meaning. It does so comprehensively: each of the 16 parameters gets a detailed explanation with examples, constraints, defaults, and relationships. For instance, gamma is defined as uncertainty-aversion weight with a range suggestion, bounds are clarified as percentages, and group_bounds includes a full example. No parameter is left vague.

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: 'Run budget optimization on a completed model.' It clearly states the goal (optimal budget allocation to maximize revenue or profit) and distinguishes itself from sibling tools like get_optimizer_results (polling) and run_scenario (scenario runs). The purpose is unambiguous and immediately actionable.

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 instructs when to use related tools: call get_model_results first to obtain exact channel names, use get_scenario_template to discover CPM values, and poll get_optimizer_results after the 202 response. It also explains when the profit objective requires forward_margin and when the 'marginal' engine is appropriate. Clear prerequisites and follow-ups leave no room for confusion.

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