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; 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

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

Output 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.1/5.0

Behavior5/5

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

Annotations already declare a safe, idempotent, closed read, so the description is free to add interpretation-critical behavior: the metricsSupported/supportedMetrics contract, per-platform reporting quirks (Bluesky/Mastodon no impressions, TikTok insights gating, X metrics sync), the linkClicks-vs-clicks distinction and the explicit warning never to sum them, and bot/link-preview exclusion. This is exactly the extra context annotations cannot carry.

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?

Purpose is front-loaded and every sentence carries non-obvious operational detail, but at ~230 words for a one-parameter read it is long, and much of the per-platform metric inventory overlaps with what the output schema could document.

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 tool whose risk is misinterpreting cross-platform metrics, the description covers the value contract, per-platform support matrix, link-click semantics, and traffic exclusions. With an output schema present it does not need to explain return shape, so nothing essential 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?

Only one parameter (postId) with 100% schema description coverage, so the schema already documents it. The description adds no syntax, format, or sourcing detail for postId, leaving the baseline 3 appropriate.

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?

States a specific verb and resource ('Get engagement metrics for a published post') and enumerates what comes back (likes, comments, shares, impressions). The 'for a published post' scoping implicitly separates it from the aggregate get_analytics/view_analytics siblings, but no sibling is named explicitly.

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 explicit when-to-use guidance: 'Use this when the user asks how a specific post performed (likes, views, engagement).' That is a clear selection trigger, though it names no alternative tool and gives no when-not boundary against get_analytics or get_post.

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?