Skip to main content
Glama
Sign In

Octopost

by ink.octopost
OverviewDiscussionsAdmin

Get post analytics

get_analytics
Read-onlyIdempotent

How published posts did: likes, reposts, replies, quotes and (on X) views.

Two modes:

  • With post_id: that post's numbers per network, plus snapshots taken about 1 hour, 24 hours and 7 days after it went live.

  • Without post_id: a summary of posts published between from and to (default: the last 30 days): totals per network and the top posts by engagement (likes + reposts + replies + quotes).

Which networks report what: X gives likes, reposts, replies, quotes, bookmarks and views. Bluesky gives likes, reposts, replies and quotes. Mastodon gives likes (favourites), reposts (boosts) and replies. Threads and LinkedIn are not available yet. Octopost reads the numbers on its own for 30 days after a post goes live, so they can be a few hours old; each network's result says when it was read. Pass refresh: true to read fresh numbers first (allowed once every 10 minutes).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_analytics"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoOptional. Summary end, an ISO date. Default: now.
topNoOptional. How many top posts to list (0 to 50, default 5).
fromNoOptional. Summary start, an ISO date like 2026-11-01. Default: 30 days ago.
post_idNoOptional. One post's numbers. Leave out for a summary.
refreshNoOptional. Read fresh numbers from the networks before answering (once every 10 minutes).
platformNoOptional. Only count this network in the summary.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses per-network metric availability, that Threads and LinkedIn are unsupported, that data can be hours stale, that snapshots land at ~1h/24h/7d, and that refresh is rate-limited. It also defines engagement as likes + reposts + replies + quotes, which is behavioral detail an agent could not get from structured fields.

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 in one line, then modes, then a network capability list, so structure is easy to scan. The closing refresh sentence partially duplicates the schema's refresh description, which is the only real waste in an otherwise dense block.

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?

No output schema exists, so the description must describe returns itself, and it does: per-network numbers, snapshot timestamps, totals, and a ranked top-post list. For a 6-parameter read tool with an optional mode switch, nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so a 3 baseline is warranted, but the description adds real meaning: post_id acts as a mode switch, from/to define the summary window with a 30-day default, and top is tied to the engagement ranking formula. Only platform is essentially left to the schema's enum.

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?

The first line names a specific resource (published posts) and the exact metrics returned (likes, reposts, replies, quotes, views), and the two modes distinguish what the tool does with and without post_id. An agent can tell this apart from content-level siblings like get_post or list_posts without opening the 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?

It gives explicit mode selection (with post_id = one post, without = date-range summary), the default window of 30 days, and a clear condition for using refresh (throttled to once every 10 minutes). What it never does is name a sibling alternative, so an agent must still infer whether get_post or list_posts is the better fit for content versus metrics.

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

All Octopost toolsInspect
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