Skip to main content
Glama

Get analytics

get_analytics
Read-onlyIdempotent

How a brand's posts did over the last days (default 7, up to 90), optionally on one platform: totals (posts, views, impressions, reach, likes, comments, shares, saves, clicks, engagement = likes + comments + shares + saves), top_posts by engagement with each one's numbers, permalink and over_time (its numbers day by day), what_worked (the best posts by engagement rate and how each platform and time of day did, with a plain summary for the person; engagement_rate is engagement per view, or per impression where a platform has no views), counts of posted, failed and needs-action targets, and freshness (when the numbers were last read; posts from the last 2 days are read every 2 hours, older ones once a day). engagement.available is false, with the reason, when numbers cannot be read: analytics is not available for the workspace yet, or it posts through its own apps. best_times has engagement by weekday and hour against the posting times (its grid). insights is what to plan next week from: patterns in the brand's own posts over the last 90 days (format: photo, carousel, video or text; platform; time of day; weekday), each with a plain summary, the sample behind it (best and other post counts), strength ('early' on a few posts, 'steady' on more), a caveat when something else was shared by most of the best posts, and try_next, one thing to do next week; note says why there is none yet and what to post. Say the sample and the strength when you repeat one, never call it a cause. vs_previous compares views, likes and posts with the same number of days before, overall and per platform (change is a share: 0.24 is 24% more; null when there was nothing before or no numbers yet this period; newer posts are still collecting views); vs_previous is null when since is given or days is over 45. since is still accepted instead of days.

Input Schema

NameRequiredDescriptionDefault
daysNo
brandNoBrand id from get_workspace. Optional when the workspace has one brand.
sinceNoISO 8601 with an offset, e.g. 2026-10-06T09:00:00-07:00 for 9am in Los Angeles. A time without an offset is read as UTC. The workspace's time zone is in get_workspace.
platformNo

Output Schema

NameRequiredDescriptionDefault
sinceYes
totalsYes
freshnessYes
top_postsYes
engagementYes
what_workedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / platform / enum
      Previous value: -[
      -  "instagram",
      -  "facebook",
      -  "threads",
      -  "tiktok",
      -  "linkedin",
      -  "youtube",
      -  "x",
      -  "bluesky",
      -  "pinterest"
      -]New value: +[
      +  "instagram",
      +  "facebook",
      +  "threads",
      +  "tiktok",
      +  "linkedin",
      +  "youtube",
      +  "x",
      +  "bluesky",
      +  "pinterest",
      +  "googlebusiness"
      +]
  2. First observed

TDQS

A3.7/5.0
Behavior5/5

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

Annotations already cover safety, but the description adds extensive behavioral context: data freshness cadence, reasons `engagement.available` can be false, when `vs_previous` is null, and cautions about interpreting insights as causes. This is exactly the kind of limitation disclosure an agent needs and goes well beyond the structured annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is a single extremely dense paragraph that enumerates nearly every return field in detail, despite the presence of an output schema. It is front-loaded with the core purpose, but the bulk is verbose and would be better placed in the output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex analytics tool, the description covers scope, optional filters, return semantics, and important edge cases. It omits explicit routing guidance against sibling tools, but with an output schema present, the extra return-value detail is more than sufficient for correct invocation.

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 50%. The description adds useful meaning for `days` (default 7, up to 90), `since` (still accepted instead of days), and `platform` (optional single platform), but it does not clarify the `brand` parameter. Baseline 3 is appropriate given the partial coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening phrase 'How a brand's posts did over the last `days`' clearly identifies the resource and scope. It does not explicitly distinguish this tool from sibling analytics tools like `best_times`, even though it nests similar output fields, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description gives parameter conditions (default 7 days, up to 90, optional platform, `since` accepted). It does not say when to choose this tool over alternatives such as `best_times` or `list_posts`, so usage is only implied.

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