Simba MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Create Var Model

create_var_model

Fit a VAR model to capture joint dynamics of multiple series and compute long-run elasticities for marketing mix analysis.

Instructions

Create and start fitting a long-term (VAR) model (#569).

VAR models capture the joint dynamics of several series (e.g. sales and brand-equity metrics) and produce the long-run elasticity bridge behind the MMM's long_run_rollup results section. Fit one, then link it to an MMM with link_var_model.

Args: uploaded_file_id: Dataset id from upload_data (must contain every named column). date_column: Date column name. Cannot also be a series. endogenous_vars: At least two column names — the jointly-modeled series. exogenous_vars: Optional outside drivers; must not overlap the endogenous set. lags: VAR order (>= 1). The dataset needs at least lags + 10 rows with no missing values across the modeled columns. forecast_horizon: Periods forecast for diagnostics (default 12). base_variable: The outcome series (must be endogenous) long-run multipliers are measured against. Required for long-run effects. equity_variables: Endogenous columns (excluding the base) whose long-run IRF multipliers are estimated. Required for long-run effects. lre_horizon: Long-run effects horizon in periods (default 156). lre_ci: Credible-interval mass for the effects table, in (0, 1). var_priors: Advanced prior overrides (lag_coefs / alpha / coefs / noise_chol); unknown keys are rejected. name: Display name for the created model, honoured verbatim (#575). Falls back to a generated API_VAR_* string when omitted.

Returns 202-style payload with model_hash; poll get_model_status.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`lags`	No
`name`	No
`lre_ci`	No
`var_priors`	No
`date_column`	Yes
`lre_horizon`	No
`base_variable`	No
`exogenous_vars`	No
`endogenous_vars`	Yes
`equity_variables`	No
`forecast_horizon`	No
`uploaded_file_id`	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": "create_var_modelDictOutput",
+  "type": "object"
+}

First observedv0.3.2Aug 28, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, indicating mutation but no destruction. The description adds important behavioral details: it returns a 202-style payload with model_hash, requires polling get_model_status, and notes that unknown keys in var_priors are rejected. It also specifies that fitting starts asynchronously, which is beyond what annotations provide. No contradiction with annotations.

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 well-structured with a purpose statement, contextual background, a detailed Args section, and a Returns note. Each sentence serves a purpose, explaining either the tool's role or parameter constraints. It's slightly verbose but justified given the 12 parameters and the need to compensate for zero schema coverage. The key information is front-loaded.

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 complexity (12 params, no schema coverage, mutation, asynchronous behavior), the description is remarkably complete. It covers prerequisites (dataset content, row count), parameter relationships, defaults for optional params, and the return type with follow-up action. Nothing an agent needs to invoke 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 the full burden for parameter documentation. It explains every parameter in the Args section, adding meaning well beyond the schema: e.g., uploaded_file_id must contain every named column, date_column cannot also be a series, endogenous_vars must have at least two, lags requires enough rows, base_variable must be endogenous, etc. This is essential for correct invocation.

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 clearly states the action: 'Create and start fitting a long-term (VAR) model'. It distinguishes itself from the sibling link_var_model by explaining that this tool creates the model while link_var_model connects it to an MMM. The reference to the MMM's long_run_rollup gives domain context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: for modeling joint dynamics of series and producing long-run elasticity. It explicitly mentions the follow-up step of linking with link_var_model, which guides the agent on the workflow. However, it doesn't explicitly state when NOT to use this tool or list alternative model-creation tools (like create_model), so it's not fully explicit about exclusions.

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

Deploy Server