Simba MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Upload Data

upload_data

Upload CSV data to Simba for marketing mix modeling. Provide a file path or raw CSV text to create a dataset ready for model building.

Instructions

Upload a CSV dataset to Simba for use in model building.

Provide EXACTLY ONE of csv_content (raw CSV text) or csv_path (a file path on the machine running this MCP server). Prefer csv_path for anything beyond trivial size — it avoids passing megabytes of CSV through the conversation.

The CSV should follow the canonical schema: one row per time period with date, KPI, multiplier, hierarchy, media activity/spend columns, and optional control variables.

IMPORTANT:

CSV only (not Excel). Maximum file size: 10 MB (API-enforced).
Row minimum: check get_data_schema -> x-simba-constraints.min_rows for the declared minimum; enforcement may be more permissive, and the upload response's warnings field is authoritative. More rows = tighter posteriors (104+ weekly rows recommended).
Media columns must follow naming: {channel}_activity and {channel}_spend.
Use 0 for inactive periods, not blank or NA.
csv_path is only available when the server runs locally (stdio). On HTTP/SSE deployments it is disabled unless SIMBA_MCP_ALLOW_LOCAL_FILES=1.

Args: csv_content: The full CSV text content (not base64, just raw CSV text). csv_path: Path to a .csv file readable by the MCP server process. name: Optional dataset name for identification. Defaults to the file stem when csv_path is used. filename: Optional original filename to record alongside the dataset.

Returns the uploaded file ID (needed for create_model), row/column counts, and any validation warnings.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No
`csv_path`	No
`filename`	No
`csv_content`	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": "upload_dataDictOutput",
+  "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?

Beyond what the annotations provide, the description discloses the 10 MB API-enforced size limit, that the response's warnings field is authoritative, row-count guidance for posterior tightness, media-column naming conventions, and the rule to use 0 instead of blank/NA for inactive periods. It also explains a deployment-dependent behavior for csv_path, which is valuable non-obvious context.

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 every section earns its place: purpose first, then parameter-choice guidance, then canonical-schema and constraint bullets, then an Args block. The bulleted IMPORTANT list is scannable and front-loaded with the most operationally critical constraints.

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?

For a 4-parameter upload tool with no schema descriptions, this definition covers input formats, constraints, deployment conditions, related-tool references, and return semantics. The presence of an output schema covers the exact return shape, so no critical context an agent needs 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 coverage is 0%, but the description fully compensates by explaining all four parameters: csv_content must be raw CSV text and not base64, csv_path must be readable by the server process, name defaults to the file stem when csv_path is used, and filename is optional metadata. No parameter meaning is left to inference.

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 opening sentence states a specific verb and resource: 'Upload a CSV dataset to Simba for use in model building.' It clearly identifies the input format (CSV), the target system, and the downstream purpose, which distinguishes it from sibling tools like get_upload, list_uploads, and create_model.

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 gives explicit when/when-not guidance: prefer csv_path for non-trivial data, use csv_content otherwise, accept only CSV not Excel, and note that csv_path is unavailable on HTTP/SSE deployments unless SIMBA_MCP_ALLOW_LOCAL_FILES=1 is set. It also tells the agent to consult get_data_schema for the authoritative minimum row constraint before uploading.

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

Deploy Server