Skip to main content
Glama

Autario Data Analytics Platform

social_360

Read-onlyIdempotent

Social 360 | the caller's OWN deterministic social performance report over their connected Facebook Page, Instagram, TikTok and YouTube 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.

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 discloses numerous behavioral nuances: server-side deterministic computation, missing platform metrics are dropped and weights renormalized ('never counted as zero'), spikes are 'hedged by design, never a claimed cause', financial revenue/ROAS only appears when the ad platform itself reports it, and unconnected platforms show an 'honest not-connected state' rather than zeros. This is exceptionally transparent.

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 long but information-dense, structured as a clear purpose statement followed by a section-by-section breakdown. It is front-loaded and each section earns its place, though there is some redundancy in emphasizing 'honest', 'never zero', and hedging, which could be slightly tightened.

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 high complexity (9 sections, multiple platforms, caveats) and the absence of an output schema, the description fully covers what is returned for each section, platform-specific limitations, connector freshness, edge cases, and authentication requirements (pointing to get_app_context('social-360')). It leaves no significant gap.

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 description coverage is 100%, so baseline is 3. The description adds valuable meaning by explaining each report section (score, explorer, posts, geo, spikes, peers, findings, financials, health) and how the sort option affects the top-post list. However, it does not add semantics for 'format' or 'days' beyond what the schema provides, preventing a 5.

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: 'Social 360 | the caller's OWN deterministic social performance report over their connected Facebook Page, Instagram, TikTok and YouTube data'. It explicitly enumerates the questions it answers ('is my account growing', 'which post worked best') and contrasts itself with audience_360 ('Deeper than audience_360...'), clearly distinguishing purpose from siblings.

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 gives explicit 'Call it when a user asks...' with a list of representative queries, states prerequisites ('Requires the caller's own autario account... with at least one social connector'), and names an alternative (audience_360) with a differentiation note. This fully guides when to use the tool.

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.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools are strongly domain-specific with clear boundaries, especially the 360 reports and dataset/chart CRUD tools. Some overlap exists around driver analysis (find_drivers, what_matters, decompose_drivers) and dataset discovery (search_datasets, discover_by_topic, list_indicators), but the descriptions make the intended use cases mostly distinguishable.

Naming Consistency4/5

The vast majority of tools follow a clear snake_case verb_noun or get_noun pattern, e.g. list_connectors, refresh_connector, query_dataset, delete_dataset. Minor deviations such as calculate, describe, bubble_or_not, what_matters, and the 360-style report names keep it from being perfectly uniform.

Tool Count2/5

48 tools is far beyond the 3-15 range and even beyond the 25-tool threshold for a heavy surface. The platform is broad and the tools are organized into domains, but the sheer number creates a high selection burden for an agent and suggests the server is trying to cover too many workflows in one toolset.

Completeness4/5

The toolset covers dataset lifecycle, chart lifecycle, data discovery, querying, statistics, app context, connectors, and admin reports remarkably well. Notable gaps are the lack of a delete_chart tool and no row-level update/delete for datasets, but agents can generally work around these or treat them as intentional platform constraints.

Resources