Skip to main content
Glama

Autario

by com.autario
OverviewDiscussionsAdmin

audience_360

Read-onlyIdempotent

Audience 360 | the caller's OWN audience report over their connected Google Search Console + GA4 + social (Facebook Page, Instagram, TikTok) connector data, computed deterministically server-side (the exact numbers the user sees in the app | nothing re-derived, nothing estimated). Use this FIRST for any interpretation question about a user's traffic/audience ("why is my AI traffic falling", "which queries are rising", "which pages do AI assistants cite", "how is my funnel doing") | it is far more token-efficient and more faithful than rebuilding KPIs from raw connector tables. Pick only the sections you need: overview (funnel stages + audience segments), channels (weekly channel mix + AI-share shift + brand-vs-generic clicks), queries (top brand/generic queries + 28d risers/fallers + high-impression-low-click opportunities), content (per-page sessions x engagement joined with search demand + AI-cited pages), audience (countries, devices, new-vs-returning, totals), conversions (GA4 key events), social (connected Facebook Page / Instagram / TikTok reach, follower trends, top posts, post-format engagement + IG follower demographics), health (report-vs-API cross-checks). Lists are capped and weekly series bounded; every truncation is marked with an omitted count. Filter with range/channel/countries to sharpen the question. Requires the caller's own autario account (API key or OAuth) with the Audience 360 app connected | see get_app_context("audience-360") for the data map behind it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoCustom window end (YYYY-MM-DD), only with range=custom.
fromNoCustom window start (YYYY-MM-DD), only with range=custom.
brandNoThe brand (connector grouping) id to report on, as a uuid. A non-uuid value is read as `brand_term` instead, so a caller written before 2026-09-22 keeps working.
rangeNoTime window preset. Relative presets anchor at the newest data day. Default 90d. Use "custom" together with from/to.
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.
channelNoOptional single-channel filter (sections that cannot honor it say so in notes).
sectionsNoWhich report sections to return. Default ["overview","channels"]. Request only what the question needs (token efficiency); call again for more.
countriesNoOptional comma-separated ISO country codes filter, e.g. "DEU,USA".
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.
brand_termNoOptional brand TERM override for the brand-vs-generic query split (default: derived from the GSC property). Renamed from `brand` on 2026-09-22, when that word became the connector grouping everywhere; a non-uuid `brand` is still read as this.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / brand / description
      Previous value: -"Optional brand term override for the brand-vs-generic query split (default: derived from the GSC property)."New value: +"The brand (connector grouping) id to report on, as a uuid. A non-uuid value is read as `brand_term` instead, so a caller written before 2026-09-22 keeps working."
    • addedInput schema / properties / brand_term
      Added value: +{
+  "description": "Optional brand TERM override for the brand-vs-generic query split (default: derived from the GSC property). Renamed from `brand` on 2026-09-22, when that word became the connector grouping everywhere; a non-uuid `brand` is still read as this.",
+  "type": "string"
+}
    • 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. Changed1 schema field changed
    • changedInput schema / properties / sections / items / enum
      Previous value: -[
-  "overview",
-  "channels",
-  "queries",
-  "content",
-  "audience",
-  "conversions",
-  "health"
-]New value: +[
+  "overview",
+  "channels",
+  "queries",
+  "content",
+  "audience",
+  "conversions",
+  "social",
+  "health"
+]
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description states numbers are 'computed deterministically server-side' and 'nothing re-derived, nothing estimated', emphasizing accuracy. It also discloses that lists are 'capped' with truncations marked, and notes the prerequisite of an autario account with the app connected, pointing to get_app_context for the data map.

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 dense but every sentence adds value, from listing the eight sections to filtering guidance and prerequisites. It could be broken into paragraphs for readability, but it is appropriately sized for a tool with 10 parameters and 8 sections, and it front-loads the purpose with the 'use this FIRST' directive.

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 complex tool with no output schema, the description covers all essentials: section options, filtering, truncation behavior with omitted counts, prerequisites, and where to find the data map. It also warns about instance validation errors, so an agent can call it correctly without missing critical information.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents parameters. The description adds valuable context: the brand/brand_term backward compatibility, the range= custom pairing with from/to, the default sections and selection advice, and the instance validation behavior. This enriches schema definitions but a few parameters (like countries) remain self-explanatory in the 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 clearly identifies the tool as an 'Audience 360' report on the caller's own audience data from Google Search Console, GA4, and social connectors. It explicitly states 'computed deterministically server-side' and differentiates from rebuilding KPIs from raw connector tables, making its purpose distinct among sibling tools like seo_360 and social_360.

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 explicitly says 'Use this FIRST for any interpretation question about a user's traffic/audience' and provides example questions like 'why is my AI traffic falling' and 'which queries are rising'. It contrasts with rebuilding from raw tables, advises picking only needed sections, and suggests filtering with range/channel/countries, giving concrete and actionable usage guidance.

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