Skip to main content
Glama

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 account's Default brand answers. 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

TableJSON 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 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. 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"
+}
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

The description goes well beyond the readOnly/idempotent/non-destructive annotations by disclosing exact operational behavior: no currency conversion, no attribution deduplication, absence instead of zeros for no-report days, null ratios when the denominator is missing, and explicit error/empty-state behavior. This makes call outcomes highly predictable before invocation.

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 text is front-loaded with purpose and call triggers)Skip and uses labeled sections for scope and honesty rules Mend, which helps navigation. It is dense and somewhat long, with some repetition (e.g., 'one brand per call' appears more than once), so it earns high marks without being perfectly minimal.

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 present, the description fully compensates by enumerating all report sections (overview, channels, campaigns, daily), defining the metrics, explaining ratio semantics, and covering format choices, errors, and prerequisites. Everything needed to invoke and interpret the report is present.

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?

Even though the schema already documents every parameter, the description adds meaningful layer: default brand behavior, deprecated client alias, section-selection guidance for token efficiency, instance ownership errors, and fallback behavior for unusable custom dates. These details materially improve correct parameter choice beyond the raw 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?

The description names a specific resource — the caller's own brand marketing report — and pins it to a concrete server-side source (marketing_daily) and exact metric definitions. It is clearly distinguishable from sibling analytics tools by scope (own brand), data domains (Meta, Google, TikTok, Shopify, Amazon, GA4), and the deterministic/no-LLM guarantee.

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?

It gives explicit invocation triggers with example user questions, such as 'how did brand X do last week' and 'which campaign has the best ROAS'. It also states when not to expect an answer: non-caller brands error, unconnected accounts return a named empty state, and multi-currency totals become null rather than converted.

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