Skip to main content
Glama
getsimba-ai

Simba MCP Server

Official
by getsimba-ai

Run Optimizer

run_optimizer

Run budget optimization on a completed model.

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: Optional. Leave it out: the run uses the model's declared currency, and a different code is refused because nothing converts between currencies. On a model that declares none, a supported code labels this run; without one, money is a bare number. Never guess one. 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

NameRequiredDescriptionDefault
gammaYes
boundsYes
currencyNo
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

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.18.0
    • addedInput schema / properties / currency / anyOf
      Added value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • addedInput schema / properties / currency / default
      Added value: +null
    • removedInput schema / properties / currency / type
      Removed value: -"string"
    • changedInput schema / required
      Previous value: -[
      -  "model_hash",
      -  "total_budget",
      -  "num_periods",
      -  "gamma",
      -  "currency",
      -  "bounds",
      -  "laydown_weights",
      -  "period_cpm"
      -]New value: +[
      +  "model_hash",
      +  "total_budget",
      +  "num_periods",
      +  "gamma",
      +  "bounds",
      +  "laydown_weights",
      +  "period_cpm"
      +]
  2. Changed1 schema field changedv0.5.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "title": "run_optimizerDictOutput",
      +  "type": "object"
      +}
  3. First observedv0.3.2

TDQS

A4.9/5.0
Behavior5/5

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

Annotations (readOnlyHint=false, idempotentHint=false, openWorldHint=true) signal a non-idempotent open-world mutation, and the description adds substantial operational context beyond them: async 202 response with required polling, an API error condition for profit runs without a margin source, validation rules (weights sum positive, CPM positive, matching channel keys), and engine-fallback semantics. Nothing is left implicit for a mutating run.

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?

Long, but justified for a 16-parameter tool with a 0%-annotated schema, and it is well front-loaded: one-line purpose, then PROFIT OBJECTIVE, then IMPORTANT constraints, then Args. Some repetition exists (array-length rules restated in both the bullet block and the per-parameter docs), which keeps it just short of a 5.

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 return values need not be enumerated, and the definition still notes the 202 async handoff and the profit-basis result fields. Given five sibling tools in the optimizer/scenario cluster and nested-object parameters, the description supplies everything needed to construct a correct call.

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 the full burden — and it does: gamma's mean-minus-spread interpretation and typical dashboard range, currency refusal behavior, bounds as percentages (not currency), laydown_weights/period_cpm array-length rules with explicit wrong/right examples, and forward_margin requirements. This is significantly richer than the bare-type schema.

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 + resource + scope ('Run budget optimization on a completed model') and immediately clarifies what the optimization produces (optimal budget allocation across channels to maximize predicted revenue or profit). An agent can distinguish it from run_scenario, get_optimizer_results, and show_optimizer_allocation without opening any schema.

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 routes the agent: call get_model_results with sections="channel_summary" first to get exact channel names, use get_scenario_template to discover channel names/CPM baselines, then poll with get_optimizer_results until status is "complete". It also scopes engine choice (group_bounds forces slsqp; marginal for profit-hurdle semantics) and objective selection.

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

Deploy Server

Other Tools