Socialync

get_analytics

Read-only

Get analytics for a week, a month, or any number of days up to 365, the same numbers as the Socialync analytics page. Views, likes, comments, shares and saves count only what was gained during the window, so a quiet week can read 0 comments even when older posts have comments. For each post's lifetime totals, use get_top_posts or get_post_insights. Also returns the current follower count and its net change, plus percentage changes against the previous window of the same length. Saves come only from platforms whose API reports them (Instagram); the others show saves as "not available". YouTube is left out of cross-platform totals and has no comparisons, because YouTube's API policy does not allow metrics derived from its data. Set breakdown="by_platform" to get separate numbers for each connected platform, YouTube included. Set includeTimeseries=true to also get daily snapshots per platform, including each day's follower count.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_analytics"
  }
}

Input Schema

Name	Required	Description	Default
`days`	No	Optional window length in days, 1 to 365 (daily analytics are kept for 365 days). Overrides period. With includeTimeseries=true this gives the follower count for every day in the window; pass platform to keep a long timeseries small.
`period`	No	Aggregation window: week=7 days, month=30 days. Period-over-period changes compare against the previous window of the same length. Ignored when days is set.	week
`platform`	No	Filter by a single platform (e.g. "tiktok") or "all" for cross-platform results	all
`breakdown`	No	"total" returns one set of cross-platform numbers; "by_platform" additionally returns per-platform numbers (the analytics page comparison cards). Only meaningful when platform="all".	total
`profileId`	No	The Socialync profile to report on. Call list_profiles to see authorized profiles. Omit to use the single/default authorized profile.
`includeTimeseries`	No	When true, also returns daily snapshots per platform. Each value is a running total as of that day: subtract one day from the next to get a gain, and never add them together.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 7, 2026

addedInput schema / properties / days

Added value: +{
+  "description": "Optional window length in days, 1 to 365 (daily analytics are kept for 365 days). Overrides period. With includeTimeseries=true this gives the follower count for every day in the window; pass platform to keep a long timeseries small.",
+  "maximum": 365,
+  "minimum": 1,
+  "type": "integer"
+}

changedInput schema / properties / period / description

Previous value: -"Aggregation window: week=7 days, month=30 days. Period-over-period changes compare against the previous window of the same length."New value: +"Aggregation window: week=7 days, month=30 days. Period-over-period changes compare against the previous window of the same length. Ignored when days is set."

Changed2 schema fields changedNov 5, 2026

changedInput schema / properties / breakdown / description

Previous value: -"\"total\" returns one set of aggregate metrics; \"by_platform\" additionally returns per-platform metrics (matches the analytics page comparison cards). Only meaningful when platform=\"all\"."New value: +"\"total\" returns one set of cross-platform numbers; \"by_platform\" additionally returns per-platform numbers (the analytics page comparison cards). Only meaningful when platform=\"all\"."

changedInput schema / properties / includeTimeseries / description

Previous value: -"When true, also returns daily metric snapshots per platform (used to chart views/engagement trends over time)"New value: +"When true, also returns daily snapshots per platform. Each value is a running total as of that day: subtract one day from the next to get a gain, and never add them together."

First observedOct 12, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare this as a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the safety profile needs no restating. The description nonetheless adds genuinely non-obvious behavior: metrics count only gains inside the window, saves come only from Instagram, YouTube is excluded from cross-platform totals, and timeseries values are running totals that must be differenced rather than summed.

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?

Front-loaded with purpose, then caveats, then optional flags — a logical order with no filler. It is long for a single paragraph and a couple of clauses (the zero-comments example, the YouTube rationale) run slightly verbose, but each carries real information an agent needs.

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?

With no output schema, the description carries the full burden of explaining return values and it does so thoroughly: metric set, follower count and net change, period-over-period percentages, per-platform breakdown, and daily snapshots. Known data gaps (saves, YouTube) are disclosed so the agent will not misread zeros as missing data.

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 interpretive value beyond the schema: it explains the days-overrides-period precedence, what breakdown="by_platform" actually yields, and that timeseries returns each day's follower count. The overlap with the schema's own descriptions is substantial, so it does not earn 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?

States a specific verb and resource ('Get analytics') plus the exact scope (a week, a month, or up to 365 days) and names the sibling tools that serve a different need (get_top_posts, get_post_insights for lifetime totals). An agent can distinguish it from those siblings without opening any schema.

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?

Explicitly routes the agent: use get_top_posts or get_post_insights for per-post lifetime totals, set breakdown="by_platform" for per-platform numbers, and includeTimeseries=true for daily snapshots. It also flags the prerequisite that breakdown is only meaningful against the cross-platform total.

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

All Socialync tools Inspect

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.