Skip to main content
Glama
Sign In

Autario

by com.autario
OverviewDiscussionsAdmin

marketing_report

Read-onlyIdempotent

Marketing Report | the caller's OWN brand marketing report, read deterministically from the derived marketing_daily table server-side (the exact numbers the user sees in the app | nothing re-derived, nothing estimated, no LLM). In one sentence: what one brand spent across Meta Ads, Google Ads, TikTok Ads, Shopify, Amazon and Google Analytics, and what came back, under ONE definition of return on ad spend. Call it when a user asks "how did brand X do last week", "what did we spend on Meta vs Google", "which campaign has the best ROAS", "what is our cost per acquisition this month", "did spend go up compared to last week", "is any channel stale". Sections: overview (spend, conversions, revenue, conversion value, return on ad spend and cost per acquisition for the period, each with the same figure for the comparison period and the move between them, plus one real total PER CURRENCY and the printed definition of every ratio), channels (one row per channel | meta_ads, google_ads, tiktok_ads, shopify, amazon, ga4 | with the same columns, its share of the spend and its own move), campaigns (top campaigns by spend and by return on ad spend, each carrying the spend behind the ratio so a tiny campaign with a spectacular number is visibly tiny), daily (one row per day that actually reported, with spend and return on ad spend). THE HONESTY RULES, which are part of the data and not a disclaimer: money is NEVER converted between currencies, so a total over more than one currency is null with a reason naming them and the per-currency breakdown is the answer instead; conversions and conversion value are what each ad platform reported under its OWN attribution setting and are never de-duplicated across channels; shop revenue and analytics revenue are separate rows and must never be added; a day no platform reported is ABSENT from the daily series rather than present as a zero; a ratio with no denominator is null, never infinite and never zero. The comparison period is the same window shifted by its own rhythm (a week for the week presets, so Monday compares to Monday). Scope: one brand per call | pass brand to pick one (the older spelling client is still accepted), otherwise the brand selected in the autario app answers, and with none selected the account's Default brand. A brand that is not the caller's answers an error, never another brand's numbers. An account with nothing connected gets a named empty state saying which of the four reasons applies, never a zero. Requires the caller's own autario account (API key or OAuth) with at least one ad or shop connector | see get_app_context("marketing-report").

Input Schema

NameRequiredDescriptionDefault
toNoEnd day (YYYY-MM-DD) when period is "custom".
fromNoStart day (YYYY-MM-DD) when period is "custom". An unusable pair falls back to the default window rather than erroring.
brandNoThe brand id (uuid) to report on. Omitted means the brand selected in the autario app (the account's stored brand choice); with none selected, the account's Default brand, which is where every unassigned connector already belongs. Every response lists the caller's brands, so a first call without this argument tells you what to pass next.
clientNoDeprecated spelling of `brand`, still accepted so callers written before 2026-09-22 keep working. Pass `brand`.
formatNoOutput wire format for this MCP call. Default 'toon' (Token-Oriented Notation, fewest tokens, best for tabular rows). 'compact' = minified JSON. 'json' = pretty JSON for readability. The REST API always returns JSON regardless.
periodNoThe reporting window. Default last-30. "this-week" runs Monday to today and compares to the same weekdays one week earlier; "custom" needs `from` and `to`.
sectionsNoWhich report sections to return. Default ["overview"]. Request only what the question needs (token efficiency); call again for more.
instancesNoOptional comma-separated connector instance ids, to narrow the report to some of the connections inside the selected brand (for example one of two Search Console properties). Omitted means all of them. An id that is not yours, or not in that brand, answers an error rather than a quietly shorter report. The ids are the instance ids get_app_context returns for this app.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / brand / description
      Previous value: -"The brand id (uuid) to report on. Omitted means the account's Default brand, which is where every unassigned connector already belongs. Every response lists the caller's brands, so a first call without this argument tells you what to pass next."New value: +"The brand id (uuid) to report on. Omitted means the brand selected in the autario app (the account's stored brand choice); with none selected, the account's Default brand, which is where every unassigned connector already belongs. Every response lists the caller's brands, so a first call without this argument tells you what to pass next."
  2. Changed3 schema fields changed
    • addedInput schema / properties / brand
      Added value: +{
+  "description": "The brand id (uuid) to report on. Omitted means the account's Default brand, which is where every unassigned connector already belongs. Every response lists the caller's brands, so a first call without this argument tells you what to pass next.",
+  "type": "string"
+}
    • changedInput schema / properties / client / description
      Previous value: -"The client workspace id (uuid) to report on. Omitted means the account's Default workspace, which is where every unassigned connector already belongs. Every response lists the caller's clients, so a first call without this argument tells you what to pass next."New value: +"Deprecated spelling of `brand`, still accepted so callers written before 2026-09-22 keep working. Pass `brand`."
    • addedInput schema / properties / instances
      Added value: +{
+  "description": "Optional comma-separated connector instance ids, to narrow the report to some of the connections inside the selected brand (for example one of two Search Console properties). Omitted means all of them. An id that is not yours, or not in that brand, answers an error rather than a quietly shorter report. The ids are the instance ids get_app_context returns for this app.",
+  "type": "string"
+}
  3. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds substantial behavior: no currency conversion (multi-currency totals are null with a reason), no de-duplication of attributed conversions, shop vs analytics revenue must not be summed, absent days instead of zeros, null rather than infinite ratios. It also states auth requirements and the error/empty-state semantics.

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 core purpose is front-loaded and most sentences carry real information, but it is a single dense wall of pipe-delimited text of roughly 450 words with no structural breaks despite enumerating four sections. The honesty rules are valuable but the presentation makes it harder to scan than it needs to be.

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?

With no output schema and a genuinely complex multi-section report, the description compensates fully: it enumerates all four sections and their columns, explains the comparison-period logic, currency and attribution caveats, error and empty-state behavior, and the auth requirement. An agent has everything needed to call and interpret it.

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% and the schema descriptions for `brand`, `client`, `from`/`to`, `format`, `period` and `sections` are themselves detailed, so the baseline is 3. The description mostly restates the brand/client default behavior already in the schema, adding only light context (comparison-period rhythm), which is not enough to lift it above baseline.

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 names a specific resource and scope: the caller's own brand marketing report, read deterministically from the `marketing_daily` table, covering spend/return across Meta, Google, TikTok, Shopify, Amazon and GA4. This is precise enough to separate it from the many adjacent '360' and engine/traction report siblings even without naming them.

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?

It gives concrete trigger phrasings ('how did brand X do last week', 'which campaign has the best ROAS') and scope rules (one brand per call, non-owned brand errors, unconnected account returns a named empty state). What it lacks is explicit routing to named alternatives for adjacent report needs (e.g. seo_360, social_360), so it stops short of a 5.

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

All Autario toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources