PostRite

Get a post's engagement metrics

get_post_analytics

Read-only

Fetch per-platform engagement metrics for a post (views, likes, comments, shares, saves, clicks, impressions — whatever each platform exposes), including the daily snapshot series. Instagram posts, and Pinterest standard pins (follows and profileVisits only), may also carry detail, built field by field from the latest snapshots that reported each one (detail.asOf is the newest such day) and NOT part of engagement: follows, profileVisits, profileActivity, replies, totalInteractions, linkClicks, reelsAvgWatchTimeMs, reelsTotalWatchTimeMs, reelsSkipRate (Reels watch times are in milliseconds, reelsSkipRate is a percentage, 0-100) and, for Stories, storyNavigation (tapForward, tapBack, tapExit, swipeForward). A null or missing detail value means the platform did not report it, never zero — a Story with fewer than 5 viewers reports nothing. A Story's replies is null, not 0, when Instagram returns 0 (it does so for every Story created in Europe or Japan, whatever happened), so a null replies does not mean nobody replied. final: true on a platform means no more snapshots will be collected (an Instagram Story past 24 hours), so latest is its last word. metricsState (OFF or PAUSED) on a platform means that account's metrics are not being collected by its owner's choice or because the platform refused the read — X metrics are billed to the customer's own X developer account, so they run only when turned on in the app's Platforms page; tell the user that rather than reading it as zero engagement. Find post IDs with list_posts.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "postId": "<postId>"
    },
    "name": "get_post_analytics"
  }
}

Input Schema

Name	Required	Description	Default
`postId`	Yes	The post ID
`organizationId`	No	Organization to act in — an id from list_organizations. Required when this connection was authorized for more than one organization; omit it when there is only one.

Output Schema

Name	Required	Description
`postId`	No
`benchmark`	No	This post vs the org average; absent when there is too little history
`platforms`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 5, 2026

addedOutput schema / properties / platforms / items / properties / metricsState

Added value: +{
+  "description": "An X account whose metrics are not collected: OFF (never turned on, or turned off) or PAUSED (X refused the read — no credit or no read access). Changed in the app's Platforms page; absent when metrics are on",
+  "enum": [
+    "OFF",
+    "PAUSED"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / platforms / items / properties / supported / description

Previous value: -"False when the platform exposes no metrics"New value: +"False when no metrics are collected for this post on this account: the platform exposes none, or `metricsState` says why"

First observedNov 5, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations only declare it a safe, open-world read; the description goes far beyond by explaining that null/missing means unreported rather than zero, that 'final: true' means no more snapshots will arrive, and that metricsState OFF/PAUSED means metrics are not being collected (including the X developer-account billing explanation) and should be reported as such rather than read as zero. It also clarifies that detail fields are explicitly excluded from engagement and gives units for watch times and skip rates. That is exactly the interpretive context an agent cannot get from annotations.

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

Conciseness3/5

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

The core definition is front-loaded in the first sentence, and every clause carries real semantic content, so little is pure waste. But the description is a dense ~250-word run-on with long comma-separated field lists (detail fields, Reels fields, storyNavigation fields) that would read far better as structured bullets, making it harder to scan mid-task.

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?

An output schema exists, so the return shape need not be explained, yet the description still supplies the interpretation layer the schema cannot (null vs zero, finality, paused state). It covers discovery of postId as well. Remaining gaps are minor: nothing on what happens for a missing/unauthorized post, or on snapshot granularity and date-range behavior.

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%: postId and organizationId are both documented, including the multi-org rule. The description adds only the hint that post IDs come from list_posts, which is modest value over the schema. Baseline 3 is appropriate.

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: 'Fetch per-platform engagement metrics for a post', and enumerates the metric families (views, likes, comments, shares, saves, clicks, impressions) plus the daily snapshot series. This clearly separates it from siblings like get_account_insights or get_analytics_summary, and it names list_posts as the source of post IDs.

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 closing line 'Find post IDs with list_posts' gives one concrete prerequisite, which is useful routing. However, there is no explicit guidance on when to choose this tool over get_post, get_top_posts, get_account_insights, or get_analytics_insights — the agent must infer that this is the per-post drill-down.

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

All PostRite 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.

Resources

Need Help?