Skip to main content
Glama

Autario

by com.autario
OverviewDiscussionsAdmin

social_360

Read-onlyIdempotent

Social 360 | the caller's OWN deterministic social performance report over their connected Facebook Page, Instagram, TikTok, YouTube and LinkedIn (own profile and page) data, computed server-side (the exact numbers the user sees in the app | nothing re-derived, nothing estimated). Call it when a user asks "how are my social accounts doing", "is my account growing", "which post worked best", "which format should I post more of", "when should I post", "what caused the follower jump", "how do I compare to my competitors". Sections: score (a 0-100 index per platform plus a reach-weighted blended total from engagement rate on reach, follower growth rate and posting consistency, with a trend | an index against the account's OWN history, never an industry benchmark; a component the platform cannot report is DROPPED and the weights renormalized, never counted as zero), explorer (EVERY connected channel as its own daily series for every KPI the platform officially reports | followers, new followers, posts, engagements, likes, comments, shares, views, reach | plus a per-KPI support matrix naming WHY a platform cannot answer a KPI, so a missing number is never read as a zero), posts (cross-platform top posts sortable by engagement/reach/views/likes/comments/shares/saves, the per-format benchmark inside the own account with low-sample flags, posting frequency vs engagement per week, and per-post effectiveness against the median post of the same format on the same channel), geo (the country breakdowns the platforms OFFICIALLY publish: Instagram audience demographics and the YouTube geography report; Facebook and TikTok publish none and say so), spikes (statistically unusual follower or reach days with the posts published in that window listed as CANDIDATES | hedged by design, never a claimed cause), peers (You vs the public accounts the user tracks under Settings > Competitors, via the shared daily benchmark store on Instagram Business Discovery and the YouTube Data API: follower gap, growth race, posting frequency, public post engagement; a YouTube peer carries follower/view/video counts only, with the reason), findings (the deterministic works / needs-attention list: format leaders and decays, channel momentum, reach declines at stable posting, unanswered spikes | each with a hedged reading and an evidence line citing the numbers), financials (paid performance from the connected ads accounts | Meta Ads, Google Ads, TikTok Ads: spend, impressions, clicks, CPC and CPM per account and per campaign with the currency on every figure, revenue and ROAS ONLY where the ad platform itself reports a money value, plus an honest paid vs organic side-by-side that never sums the two), health (what each platform counts as reach, connector freshness, days and posts in the window, and the caveats that explain an empty section). Reads EVERY connected channel per platform (a user with four Instagram accounts gets four), and a platform figure is the fold of its channels. Works with ONE connected channel; every unconnected platform carries an honest not-connected state instead of zeros. Deeper than audience_360 (which answers "who comes from where" and keeps a high-level social reach section): this one judges social performance and names the post behind it. Requires the caller's own autario account (API key or OAuth) with at least one social connector | see get_app_context("social-360").

Input Schema

TableJSON 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.
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 / 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. 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"
+]
  3. 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"
+]
  4. 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"
+]
  5. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds substantial behavior: 'nothing re-derived, nothing estimated', 'a component the platform cannot report is DROPPED and the weights renormalized', 'a missing number is never read as a zero', 'hedged by design, never a claimed cause', and 'an id that is not yours... answers an error rather than a quietly shorter report'. No contradiction with annotations.

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 description is front-loaded with purpose and is very comprehensive, but it is extremely long and duplicates schema content (e.g., the sections parameter description is essentially repeated in the prose). While every sentence carries useful information, the overlap with the schema and the wall-of-text format keep it from being concise.

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 the tool's complexity and the absence of an output schema, the description covers all necessary context: platform coverage, section-by-section semantics, limitations (e.g., Facebook/TikTok geo not available), edge cases (unconnected platforms, invalid instance ids), auth requirements, and the distinction from audience_360. Nothing an agent needs to select and invoke this tool correctly is missing.

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% – every parameter has a detailed description, including enums. The tool description does not add significant new parameter-level meaning; it largely repeats the schema's section definitions. Since the schema does the heavy lifting, a baseline 3 is appropriate.

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 opens with a specific verb+resource: 'the caller's OWN deterministic social performance report over their connected Facebook Page, Instagram, TikTok, YouTube and LinkedIn data, computed server-side'. It explicitly distinguishes itself from a sibling: 'Deeper than audience_360 (which answers "who comes from where")'. This makes the tool's role unmistakable.

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 provides concrete trigger questions ('how are my social accounts doing', 'is my account growing', 'which post worked best') and says 'Call it when a user asks...'. It also names the alternative audience_360 and explains the difference in scope. Auth requirements and connector prerequisites are also stated.

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