Skip to main content
Glama

social_360

Read-onlyIdempotent

Social 360 | the caller's OWN deterministic social performance report over their connected Facebook Page, Instagram, TikTok, YouTube, LinkedIn and Threads data, computed server-side (the numbers the user sees in the app, nothing estimated). Call it for "how are my social accounts doing", "which post worked best", "which format should I post more of", "what caused the follower jump", "how much of this came from ads", "how do I compare to my competitors". Sections: score (a 0-100 index per platform plus a reach-weighted blend from engagement rate on reach, follower growth and posting consistency, against the account OWN history; a part the platform cannot report is dropped, never zero), explorer (every channel as daily series for every KPI its platform reports, a support matrix naming WHY a KPI is missing, per channel the window sums of paid reach and paid engagements from Meta Ads, and the Instagram splits: views by content type incl. its Ads type, views and reach by followers vs non-followers, interactions by content type, story replies, reposts, contact button taps), posts (top posts sortable by engagement, reach, views, likes, comments, shares, saves and the rates on reach; format benchmark; frequency vs engagement; effectiveness vs the median post of the same format; Instagram posts with reposts, follows, profile visits and reel skip rate; stories as format STORY rows with replies, profile actions, link taps and navigation; every post and story row carries its type (post, reel, video, carousel, image, text, link, story) and not_reported names, per platform and type, the metrics the platform reported for no row of that type; PAID VS ORGANIC: a post a Meta ad promotes carries paid=true, paidReach, paidInteractions and the campaign next to its organic numbers, a post no ad names is organic by fact), geo (official country breakdowns: Instagram demographics, YouTube geography; plus follower age, gender and top cities), spikes (unusual follower or reach days with the posts of that window as CANDIDATES, never a claimed cause), peers (You vs tracked public accounts: follower gap, growth race, posting frequency, public engagement), findings (deterministic works / needs-attention list, each with a hedged reading and an evidence line), financials (SOCIAL ads only: Meta, TikTok, Pinterest, Snapchat, Reddit, LinkedIn Ads, with Google Ads in marketing_report; spend, CPC, CPM per account and campaign, the currency on every figure, revenue and ROAS only where the platform reports a money value, paid vs organic side by side, never summed), health (what each platform counts as reach, freshness, caveats). Works with ONE connected channel; an unconnected platform carries an honest not-connected state, never zeros. Requires the caller own autario account (API key or OAuth) with at least one social connector | see get_app_context("social-360").

Input Schema

NameRequiredDescriptionDefault
daysNoAnalysis window in days (7-90, default 28). Each platform anchors it at the newest day of ITS OWN connector table, because connectors refresh on different rhythms.
sortNoHow the cross-platform top-post list is ranked (posts section). Default engagement. The three rates rank only posts whose platform reports them (Instagram today).
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 brand that is not yours answers an error, never another brand's numbers.
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.
sectionsNoWhich report sections to return. Default ["score","health"]. Request only what the question needs (token efficiency); call again for more. activity = the activity table: every post with platform, content type, topic, post type, sentiment and language, per-dimension pivots and the (platform, content type, topic, language) groups that beat the platform median; labels come from the user's own classification run.
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
    • addedInput schema / properties / brand
      Added value: +{
      +  "description": "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 brand that is not yours answers an error, never another brand's numbers.",
      +  "type": "string"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / sort / description
      Previous value: -"How the cross-platform top-post list is ranked (posts section). Default engagement."New value: +"How the cross-platform top-post list is ranked (posts section). Default engagement. The three rates rank only posts whose platform reports them (Instagram today)."
    • changedInput schema / properties / sort / enum
      Previous value: -[
      -  "engagement",
      -  "reach",
      -  "views",
      -  "likes",
      -  "comments",
      -  "shares",
      -  "saves"
      -]New value: +[
      +  "engagement",
      +  "reach",
      +  "views",
      +  "likes",
      +  "comments",
      +  "shares",
      +  "saves",
      +  "saveRate",
      +  "shareRate",
      +  "engagementRateReach"
      +]
  3. Changed1 schema field changed
    • 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"
      +}
  4. Changed2 schema fields changed
    • changedInput schema / properties / sections / description
      Previous value: -"Which report sections to return. Default [\"score\",\"health\"]. Request only what the question needs (token efficiency); call again for more."New value: +"Which report sections to return. Default [\"score\",\"health\"]. Request only what the question needs (token efficiency); call again for more. activity = the activity table: every post with platform, content type, topic, post type, sentiment and language, per-dimension pivots and the (platform, content type, topic, language) groups that beat the platform median; labels come from the user's own classification run."
    • changedInput schema / properties / sections / items / enum
      Previous value: -[
      -  "score",
      -  "explorer",
      -  "posts",
      -  "geo",
      -  "spikes",
      -  "peers",
      -  "financials",
      -  "findings",
      -  "health"
      -]New value: +[
      +  "score",
      +  "explorer",
      +  "posts",
      +  "activity",
      +  "geo",
      +  "spikes",
      +  "peers",
      +  "financials",
      +  "findings",
      +  "health"
      +]
  5. Changed1 schema field changed
    • changedInput schema / properties / sections / items / enum
      Previous value: -[
      -  "score",
      -  "explorer",
      -  "posts",
      -  "geo",
      -  "spikes",
      -  "peers",
      -  "health"
      -]New value: +[
      +  "score",
      +  "explorer",
      +  "posts",
      +  "geo",
      +  "spikes",
      +  "peers",
      +  "financials",
      +  "findings",
      +  "health"
      +]
  6. Changed2 schema fields changed
    • changedInput schema / properties / sections / items / enum
      Previous value: -[
      -  "score",
      -  "posts",
      -  "spikes",
      -  "peers",
      -  "health"
      -]New value: +[
      +  "score",
      +  "explorer",
      +  "posts",
      +  "geo",
      +  "spikes",
      +  "peers",
      +  "health"
      +]
    • changedInput schema / properties / sort / enum
      Previous value: -[
      -  "engagement",
      -  "reach",
      -  "views",
      -  "likes",
      -  "comments",
      -  "shares"
      -]New value: +[
      +  "engagement",
      +  "reach",
      +  "views",
      +  "likes",
      +  "comments",
      +  "shares",
      +  "saves"
      +]
  7. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: numbers are computed server-side and never estimated, a KPI the platform cannot report is dropped rather than zeroed, an unconnected platform returns an honest not-connected state, unreported metrics are named per platform and type, and another brand's data returns an error. These are exactly the trust and failure-mode facts an agent needs before presenting results.

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?

Purpose is front-loaded, and the labeled section names (score, explorer, posts, geo...) give the wall of text some parseable structure. However, the body is a single enormous run-on that enumerates far more internal detail than an agent needs to select the tool, and much of the per-section metric inventory overlaps the sections parameter description in the schema.

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?

Given a complex multi-section analytics report with no output schema, the description covers scope, defaults (sections default to score+health), single-channel behavior, auth requirements, isolation semantics and per-section caveats. There is little an agent could get wrong from missing context.

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, but the description adds real meaning to the sections parameter by explaining what score, explorer, posts, geo, spikes, peers, findings, financials and health each contain, including the paid-vs-organic distinction and the fact that spike posts are candidates rather than causes. It adds little on days, sort, brand, format and instances beyond what the schema already says.

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 opening sentence states a specific verb and resource (a deterministic social performance report) plus the exact platforms covered, and scopes it to the caller's OWN connected connectors. It is unambiguous against siblings like marketing_report and ai_visibility_360, and the section list makes the payload's composition concrete.

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 literal trigger questions ("which post worked best", "what caused the follower jump") that map intent to the right sections, and names the alternative explicitly: social ad spend lives here while Google Ads lives in marketing_report. It also states the prerequisites (autario account with at least one social connector) and points to get_app_context for setup.

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