Skip to main content
Glama

Get Analytics Overview

get_analytics_overview
Read-only

Workspace-wide performance for a date window: views, likes, comments, shares, followers, posts published, average views per post and engagement rate, each as { value, previousValue, deltaPercent } against the window of the same length just before it. Use this for "how did we do this month" questions and for follower counts. Metrics are summed over the selected platforms; partialMetrics names metrics some selected platform cannot report, and a metric no platform reports is null. Analytics cover Facebook, Instagram, Threads, TikTok, Pinterest, Bluesky, LinkedIn, YouTube, X and Google Business Profile (location impressions only, no per-post numbers); Mastodon, Telegram and Tumblr have none. Connecting an account imports its posts from the last 180 days, and analytics are kept from then on while the account stays connected, so any date range in that history can be queried. Analytics refresh every few hours (lastSyncedAt says when); if the user just published, call trigger_analytics_sync first. Use get_analytics_timeseries for a trend, get_platform_breakdown to compare platforms, and list_post_analytics for individual posts.

Input Schema

NameRequiredDescriptionDefault
toYesEnd of the reporting window (ISO 8601). Must not be earlier than from
fromYesStart of the reporting window as an ISO 8601 date or instant (e.g. "2026-08-01"). Metrics cover posts published between from and to; the comparison window is the same length immediately before from
platformsNoRestrict to these platforms; omit for every platform with analytics. MASTODON, TELEGRAM and TUMBLR have no analytics and are ignored. GOOGLE_BUSINESS reports location impressions only, with no per-post numbers
workspaceIdNoWorkspace to act in: an id from list_workspaces. Omit to act in the workspace list_workspaces marks current. Use the same workspaceId for every call about the same workspace, since ids from one workspace (accounts, posts, uploads) do not exist in another
connectionIdsNoRestrict to these accounts, by the account id from list_accounts; omit for every account

Output Schema

NameRequiredDescriptionDefault
resultNoAn object with views, likes, comments, shares, followers, postsCount, avgViewsPerPost and engagementRate (each { value, previousValue, deltaPercent }), partialMetrics, and lastSyncedAt.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / connectionIds
      Added value: +{
      +  "description": "Restrict to these accounts, by the account id from list_accounts; omit for every account",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / platforms / description
      Previous value: -"Restrict to these platforms; omit for every platform with analytics. MASTODON and TELEGRAM have no analytics and are ignored. GOOGLE_BUSINESS reports location impressions only, with no per-post numbers"New value: +"Restrict to these platforms; omit for every platform with analytics. MASTODON, TELEGRAM and TUMBLR have no analytics and are ignored. GOOGLE_BUSINESS reports location impressions only, with no per-post numbers"
    • changedInput schema / properties / platforms / items / enum
      Previous value: -[
      -  "LINKEDIN",
      -  "YOUTUBE",
      -  "INSTAGRAM",
      -  "FACEBOOK",
      -  "TIKTOK",
      -  "PINTEREST",
      -  "THREADS",
      -  "BLUESKY",
      -  "TWITTER",
      -  "MASTODON",
      -  "GOOGLE_BUSINESS",
      -  "TELEGRAM"
      -]New value: +[
      +  "LINKEDIN",
      +  "YOUTUBE",
      +  "INSTAGRAM",
      +  "FACEBOOK",
      +  "TIKTOK",
      +  "PINTEREST",
      +  "THREADS",
      +  "BLUESKY",
      +  "TWITTER",
      +  "MASTODON",
      +  "GOOGLE_BUSINESS",
      +  "TUMBLR",
      +  "TELEGRAM"
      +]
  2. Changed2 schema fields changed
    • changedInput schema / properties / platforms / description
      Previous value: -"Restrict to these platforms; omit for every platform with analytics. X (TWITTER) and MASTODON have no analytics and are ignored; LinkedIn analytics are pending platform approval and return no data yet"New value: +"Restrict to these platforms; omit for every platform with analytics. MASTODON and TELEGRAM have no analytics and are ignored. GOOGLE_BUSINESS reports location impressions only, with no per-post numbers"
    • changedInput schema / properties / platforms / items / enum
      Previous value: -[
      -  "LINKEDIN",
      -  "YOUTUBE",
      -  "INSTAGRAM",
      -  "FACEBOOK",
      -  "TIKTOK",
      -  "PINTEREST",
      -  "THREADS",
      -  "BLUESKY",
      -  "TWITTER",
      -  "MASTODON"
      -]New value: +[
      +  "LINKEDIN",
      +  "YOUTUBE",
      +  "INSTAGRAM",
      +  "FACEBOOK",
      +  "TIKTOK",
      +  "PINTEREST",
      +  "THREADS",
      +  "BLUESKY",
      +  "TWITTER",
      +  "MASTODON",
      +  "GOOGLE_BUSINESS",
      +  "TELEGRAM"
      +]
  3. Changed2 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedOutput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  4. Changed1 schema field changed
    • changedInput schema / properties / workspaceId / description
      Previous value: -"Workspace to act in: an id from list_workspaces. Omit to use the default workspace. Use the same workspaceId for every call about the same workspace, since ids from one workspace (accounts, posts, uploads) do not exist in another"New value: +"Workspace to act in: an id from list_workspaces. Omit to act in the workspace list_workspaces marks current. Use the same workspaceId for every call about the same workspace, since ids from one workspace (accounts, posts, uploads) do not exist in another"
  5. Changed1 schema field changed
    • addedInput schema / properties / workspaceId
      Added value: +{
      +  "description": "Workspace to act in: an id from list_workspaces. Omit to use the default workspace. Use the same workspaceId for every call about the same workspace, since ids from one workspace (accounts, posts, uploads) do not exist in another",
      +  "type": "string"
      +}
  6. Changed2 schema fields changed
    • changedInput schema / properties / platforms / description
      Previous value: -"Restrict to these platforms; omit for every platform with analytics. X (TWITTER) has no analytics and is ignored; LinkedIn analytics are pending platform approval and return no data yet"New value: +"Restrict to these platforms; omit for every platform with analytics. X (TWITTER) and MASTODON have no analytics and are ignored; LinkedIn analytics are pending platform approval and return no data yet"
    • changedInput schema / properties / platforms / items / enum
      Previous value: -[
      -  "LINKEDIN",
      -  "YOUTUBE",
      -  "INSTAGRAM",
      -  "FACEBOOK",
      -  "TIKTOK",
      -  "PINTEREST",
      -  "THREADS",
      -  "BLUESKY",
      -  "TWITTER"
      -]New value: +[
      +  "LINKEDIN",
      +  "YOUTUBE",
      +  "INSTAGRAM",
      +  "FACEBOOK",
      +  "TIKTOK",
      +  "PINTEREST",
      +  "THREADS",
      +  "BLUESKY",
      +  "TWITTER",
      +  "MASTODON"
      +]
  7. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial context beyond that: per-platform coverage gaps, partialMetrics/null semantics, the 180-day import limitation, and a refresh cadence mediated by lastSyncedAt. Not a full 5 only because pagination/response-size behavior is unaddressed, though the existence of an output schema lowers that burden.

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 what the tool returns before any caveats, and every sentence carries relevant information. It is dense (a single long paragraph mixing return shape, coverage, retention and routing), so a small structural penalty is warranted, but nothing is genuinely filler.

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 read-only aggregate endpoint with five documented parameters and an output schema, the description covers what an agent needs: metric semantics, platform coverage limits, data freshness, and how to choose among the analytics siblings. Nothing material is missing.

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 still earns credit by explaining that the comparison window is the same length immediately before 'from' and that metrics are summed across selected platforms, which is derived behavior the schema alone does not convey. It does not add detail on connectionIds, but the schema already documents that fully.

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 (workspace-wide performance for a date window) and enumerates the exact metrics returned, including the { value, previousValue, deltaPercent } shape. It also names the siblings it is not (get_analytics_timeseries, get_platform_breakdown, list_post_analytics), so an agent can differentiate it without opening a 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?

Gives an explicit use case ("how did we do this month" questions, follower counts) and explicitly routes the agent to alternatives for trends, platform comparison and per-post data. It also names a precondition (call trigger_analytics_sync first if the user just published).

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