Skip to main content
Glama

Get post analytics

get_post_analytics

Returns the latest analytics snapshot for a single platform post (layer 1 of 3 — one post = one platform). Includes views, likes, comments, shares, plus platform-specific metrics like reach, saves, watch time. Instagram Reels may add platform_metrics.reels_skip_rate (percent of views that skipped in the first 3 seconds), and Instagram rows with Facebook Login may add platform_metrics.reposts. When the workspace has Facebook Login for the same account, Instagram likes, comments and views are all-surfaces totals including boosted media, and platform_metrics has total_likes, total_comments and total_views.

The provenance field says where a row of zeros comes from:

  • sync → the analytics pipeline actually fetched from the platform. Zeros here are real.

  • seed → placeholder row written at publish time (fetched_at ≈ published_at). No fetch has run yet; every metric is a stub 0.

  • unsupported_platform → the platform has no analytics (Telegram, Discord). The seed row stays at 0 forever and does not mean the platform reported zero engagement.

A row with fetch_status unavailable means the platform will never report on this post, and fetch_error says why (personal LinkedIn/Pinterest account, X without the workspace's own API key, Google Business Profile posts); its zeros are placeholders, not measured values.

Also returns platform_supports_analytics: boolean. Numeric fields may be null when the platform doesn't expose that metric (e.g. shares on YouTube) OR when no sync has run yet. For the same video summed across platforms use get_video_analytics; for a whole folder rolled up use get_folder_analytics.

Freshness: if the workspace's analytics were last synced over an hour ago (or never), this call also starts a background sync and reports it in the response's sync field (status started or in_progress, plus last_synced_at). The numbers in that response are from the previous sync; call again in a few minutes for fresh ones. sync.status of free_plan_limit or daily_limit means no sync could run, so the numbers may not be current.

Input Schema

NameRequiredDescriptionDefault
video_post_idYesThe video_posts.id to fetch analytics for. Only meaningful once the post is published.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

With readOnlyHint=false, the description supplies the missing reason: the call can kick off a background sync and returns sync.status of 'started'/'in_progress', with 'free_plan_limit'/'daily_limit' meaning no sync ran and numbers may be stale. It further discloses what zeros actually mean per provenance value and per fetch_status 'unavailable', which an agent cannot infer from any structured field.

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 the core purpose, then organized into clearly separated topics (metrics, provenance, fetch_status, freshness). It is long for a single-parameter tool and the provenance block partly overlaps the sibling explain_post_analytics_state, but nearly every sentence carries decision-relevant detail.

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?

There is no output schema, so the description must carry the return semantics, and it does: which metrics appear, platform-specific fields, nullability causes (unsupported metric vs. no sync yet), and stale-data behavior. An agent has enough to call this correctly and to interpret a zeros result.

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 coverage is 100% and the single parameter video_post_id is fully documented in the schema ('Only meaningful once the post is published'). The description adds no further syntax or format detail about the parameter, so this sits at the high-coverage baseline.

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?

Opens with a specific verb and resource: 'Returns the latest analytics snapshot for a single platform post', and immediately scopes it as 'layer 1 of 3 — one post = one platform'. That framing lets an agent distinguish it from get_video_analytics and get_folder_analytics 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes adjacent cases: 'For the same video summed across platforms use get_video_analytics; for a whole folder rolled up use get_folder_analytics.' It also implies the pre-publish restriction via the schema note. It does not tell the agent when to use the sibling explain_post_analytics_state instead of reading the provenance prose here.

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.