Skip to main content
Glama

Marketing Intelligence & Optimization

by ai.saifs

Marketing Intelligence — Get Analysis Script (large payloads)

marketing_intelligence_get_engine
Read-only

ALWAYS call this tool (do not analyse large marketing files yourself) for payloads LARGER than 200 rows in any data array. Returns a complete, runnable Python script that runs market basket rules, MMM (adstock + saturation + bootstrap CIs) + budget moves, A/B with power/peeking guards, Bass diffusion, and unit economics. Run it in your code sandbox against the user's files. The rows never pass through you as tokens. Needs numpy only (no scipy). Prints ranked decisions; writes full result to tmp/mi_run/marketing_intelligence_result.json. ALL created files must stay under tmp/mi_run/ (not repo root, not _mi_data*, not source folders, not beside user CSVs). PATH lines may read the user's files in place. No marketing data reaches this server on this path. SAVE AND RUN THE RETURNED SCRIPT VERBATIM as tmp/mi_run/marketing.py — only the PATH / option lines at the bottom may be edited. For ≤200 rows use marketing_intelligence instead.

When to call this tool:

  • ANY large marketing export when this MCP is connected — always call, never analyse yourself

  • Analyse a spend/sales/basket export with more than 200 rows

  • Any marketing file too large to send as tool arguments

  • Score attached CSVs without moving the data anywhere

  • Large Meta/Google + Shopify dumps for MMM / baskets / CAC

  • Run full marketing intelligence locally in a code sandbox

When NOT to call this tool:

  • 200 rows or fewer in every array — use marketing_intelligence

  • No code sandbox — say so rather than sending huge payloads

  • Intent to rewrite/shorten/reimplement the script rather than run it

  • Writing script/OUT/helpers outside tmp/mi_run/ (repo root, _mi_data*, source, beside user CSVs)

  • Forecasting unrelated non-marketing series without marketing inputs

  • Skipping this tool to analyse large CSVs with mental math yourself

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
as_ofNoAnalysis date YYYY-MM-DD.
currencyNoISO currency code for display (INR, USD, EUR…).USD
data_pathNoOptional path to a JSON envelope with API-shaped keys (transactions, spend, sales, ab_tests, …). Individual *_path arguments override keys from this file.
sales_pathNoSandbox path to sales/revenue series file.
spend_pathNoSandbox path to spend-by-channel file.
ab_tests_pathNoSandbox path to A/B test counts file.
adoption_pathNoSandbox path to adoption / Bass series file.
controls_pathNoSandbox path to MMM control drivers file.
currency_symbolNoOverride display symbol (e.g. ₹, $).
acquisitions_pathNoSandbox path to acquisitions-by-channel file.
gross_margin_rateNoGross margin fraction for honest LTV:CAC.
transactions_pathNoSandbox path to basket/order CSV/TSV/JSON/JSONL.
customer_revenue_pathNoSandbox path to customer revenue events file.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
notesNo
scriptYesComplete runnable Python analysis script — save and run verbatim.
currencyNo
languageNo
requiresNo
paths_usedNo
writes_fileNo
instructionsNo
sandbox_rootNo
code_integrityNo
engine_versionYes
data_requirementsNo
network_access_requiredNo

TDQS

A4.5/5.0
Behavior5/5

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

Annotations readOnlyHint=true, openWorldHint=true, destructiveHint=false are consistent with the description. The description adds extensive behavioral context beyond annotations: it returns a script to run in a sandbox, rows never pass through as tokens, script writes to tmp/mi_run/, files must stay under tmp/mi_run/, path lines may read user's files, script must be saved verbatim, and only PATH/option lines are editable. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long and contains redundant information (e.g., 'For ≤200 rows use marketing_intelligence instead' appears in both the opening paragraph and the not-call list). It is well-structured with sections, but not concise; every sentence does not earn its place.

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 highly complex tool with 13 parameters and no required parameters, the description is extremely complete: it covers data size thresholds, environment requirements, output location, safety constraints, and alternative usage. Output schema exists, so return values needn't be detailed, but the high-level workflow is fully described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add per-parameter semantics beyond the schema, but it provides helpful context that all paths refer to user's local files that the script reads in place and that only PATH/option lines may be edited. This is marginal added meaning, so a 3 is appropriate.

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 a specific verb+resource: 'Get Analysis Script' that returns a complete, runnable Python script for large marketing data analytics. It distinguishes itself from the sibling tool by explicitly saying 'For ≤200 rows use marketing_intelligence instead,' making the purpose unambiguous.

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 includes explicit 'When to call' and 'When NOT to call' sections, naming the alternative (marketing_intelligence for ≤200 rows), conditions (code sandbox required), and exclusions (non-marketing forecasts, rewriting script). It also opens with 'ALWAYS call this tool... for payloads LARGER than 200 rows,' providing clear when-to-use guidance.

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

All Marketing Intelligence & Optimization toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

The two tools are cleanly separated by a clear, explicit threshold (≤200 rows vs. >200 rows per array). There is no overlap in purpose: one handles small payloads directly, the other returns a script for large data. An agent can unambiguously choose which to call based on data size.

Naming Consistency4/5

Both tools share the common prefix 'marketing_intelligence', making their relationship obvious. The second tool adds '_get_engine' to indicate a different execution mode, which is clear but not a standard verb_noun pattern. The naming is consistent and predictable within the pair.

Tool Count3/5

With only two tools, the server appears thin at first glance, but each tool is extremely dense, covering a wide variety of marketing analyses in one request or one generated script. The threshold-based split justifies the count for the intended scope. Still, it is on the lower end of the typical range.

Completeness4/5

The tools cover a broad range of marketing intelligence: MMM, A/B testing, market basket analysis, Bass diffusion, CAC/LTV, and budget reallocation. There are no obvious missing operations for the stated domain, though the bundled nature means individual analyses cannot be invoked separately. Minor gaps like a standalone data-validation tool exist but are not critical.

Resources