BulkPublish

Get post metrics

get_post_metrics

Read-onlyIdempotent

Get engagement metrics for a published post. Returns likes, comments, shares, impressions, and other platform-specific metrics. IMPORTANT: every platform entry carries metricsSupported and supportedMetrics — a metric key NOT in supportedMetrics is stored as 0 because that platform's API has no such field, so report it as unavailable rather than as zero. X reports impressions/likes/comments/shares/saves (bookmarks); Bluesky and Mastodon report no impressions; Pinterest reports no reach; YouTube reports no shares or reach; Reddit reports likes (score), comments and shares (crossposts); Discord reports likes (reaction counts) and comments (thread replies); TikTok reports reach, saves and clicks only for accounts that have granted TikTok insights. An Instagram story reports only impressions, reach and comments (story replies). Google Business, Telegram, Tumblr and LinkedIn personal profiles report nothing readable at all, and an X post comes back with metricsSupported: false until its channel turns on X metrics sync. Each platform entry also carries linkClicks (summed in totals.linkClicks): clicks on bulkpubli.sh short links in this post, measured by BulkPublish rather than reported by the platform. It sits OUTSIDE latest and is distinct from the platform's own clicks — one visit can register in both, so never add them together. It is therefore available even for the platforms that report nothing, and supportedMetrics always includes it. Bot and link-preview traffic is excluded; it is 0 for organizations without Link Tracking enabled. Use this when the user asks how a specific post performed (likes, views, engagement).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`postId`	Yes	The post ID to get metrics for.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`postId`	No
`totals`	No
`platforms`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 9, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "platforms": {
+      "anyOf": [
+        {
+          "items": {
+            "additionalProperties": {},
+            "properties": {
+              "platform": {
+                "anyOf": [
+                  {
+                    "type": "string"
+                  },
+                  {
+                    "type": "null"
+                  }
+                ]
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "postId": {
+      "anyOf": [
+        {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "string"
+            }
+          ]
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "totals": {
+      "anyOf": [
+        {
+          "additionalProperties": {},
+          "properties": {},
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    }
+  },
+  "type": "object"
+}

First observedSep 3, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly/idempotent/non-destructive); the description goes far beyond them. It explains that a metric absent from `supportedMetrics` is stored as 0 and must be reported as unavailable, enumerates per-platform coverage gaps, discloses that `linkClicks` is measured by BulkPublish and must never be summed with platform `clicks`, and notes bot/link-preview exclusion plus the TikTok-insights and X-sync gating. This is exactly the interpretive context an agent needs to avoid reporting wrong numbers.

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 first sentence front-loads purpose and return shape well, but the body is a dense run-on covering every platform's metric coverage. With an output schema present, much of that return-value enumeration is redundant with structured documentation, and the linkClicks passage is longer than the decision it supports.

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 single-parameter read tool whose real complexity lies in interpreting per-platform metric availability, the description covers the edge cases (zero vs. unavailable, platform gaps, linkClicks double-counting, insight/sync gating) that the schema and annotations cannot express. Nothing an agent needs to report results correctly is missing.

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?

There is a single parameter and schema description coverage is 100%, so the schema already fully documents `postId`. The description adds no format, range, or sourcing detail about the ID, which is the expected baseline when the schema does the work.

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 engagement metrics for a published post') and enumerates the returned metric families, so the agent immediately knows this is per-post performance data rather than an account-level rollup. The scope word 'published post' cleanly separates it from the analytics/view_analytics siblings without needing their schemas.

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?

The closing sentence gives an explicit trigger: 'Use this when the user asks how a specific post performed (likes, views, engagement).' That is clear context, but it never names an alternative (e.g., get_analytics for aggregate reporting) or states an exclusion, so the agent must infer the boundary itself.

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

All BulkPublish 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?