Skip to main content
Glama

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

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. Omitted means the brand selected in the autario app (the account's stored brand choice), so you see what the user sees on screen; with no brand selected, all of the account's brands. 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. Changed1 schema field changed
    • changedInput schema / properties / brand / description
      Previous 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."New value: +"The brand (connector grouping) id to report on, as a uuid. Omitted means the brand selected in the autario app (the account's stored brand choice), so you see what the user sees on screen; with no brand selected, all of the account's brands. A non-uuid value is read as `brand_term` instead, so a caller written before 2026-09-22 keeps working."
  2. 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"
      +}
  3. 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"
      +]
  4. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations carry the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds substantial behavior beyond them: values are deterministic server-side, nothing is re-derived or estimated, lists are capped with omitted counts marked, and it requires the caller's own authenticated account with the app connected.

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?

Purpose and the FIRST-to-use directive are front-loaded, and the pipe-separated clauses keep it scannable. It is on the long side and a few clauses (e.g. the re-derivation aside) border on redundant, but each block carries distinct operational information.

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 10-parameter tool with no output schema, the description is remarkably complete: it covers data sources, section selection, filtering, truncation/capping behavior, output formats, and auth prerequisites, leaving no gap an agent needs to fill before calling.

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 baseline is 3; the description goes beyond by enumerating the contents of every `sections` value (overview, channels, queries, content, audience, conversions, social, health) and by explaining that range/channel/countries sharpen results, adding meaning the enum alone doesn't convey.

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?

States a specific resource (the caller's own audience report) and its exact data provenance (connected GSC + GA4 + social connectors, computed server-side). It is clearly differentiated from siblings seo_360 / social_360 / ai_visibility_360 by being the cross-source audience report, and even names the underlying app context call.

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?

Gives explicit routing ('Use this FIRST for any interpretation question about a user's traffic/audience'), concrete example questions, and a stated alternative to avoid ('rebuilding KPIs from raw connector tables'). Also instructs how to narrow scope via sections and range/channel/countries filters.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources