Skip to main content
Glama
Sign In

Acrium

by com.acriumautomated
OverviewDiscussionsAdmin

Get post stats

get_post_stats
Read-onlyIdempotent

How published posts performed. With post_id: that post (the post_id publish_post returned, or a scheduled post's number from list_scheduled_posts). Without: the most recent published posts, newest first. Each has its caption (shortened), published time, and per account the platform, its post id and link where known, views, impressions, reach, likes, comments, shares, saves and engagement rate (null where the platform doesn't report one), the platform's own figures under raw, and totals across accounts. Posts sent through Outstand have stats, and so can YouTube videos published through Acrium (post_id "yt:": views, likes and comments, where Acrium can read them; otherwise the item says so); a post that isn't published or can't be reported on says so. Paid or boosted copies (ads) of a post aren't counted: their results are in Meta Ads Manager or the app.

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_post_stats"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoHow many recent posts (default 10).
post_idNoOne post. Leave out for the recent ones.
project_idNoWorkspace to work in (from list_projects). Leave out for the default one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare a safe, idempotent read; the description adds real behavioral context on top: nulls for metrics a platform doesn't report, a raw block for platform-native figures, per-account plus aggregate totals, an explicit exclusion for paid/boosted copies (which live in Ads Manager), and the YouTube-via-Acrium edge case with its own post_id format.

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?

Front-loaded and information-dense with no filler, but the middle 'Each has its caption...totals across accounts' is a single sprawling run-on that would scan better as a list. Every clause carries real information, so the length is defensible.

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?

There is no output schema, so the description must describe return shape itself, and it does: caption (shortened), published time, per-account platform/id/link/metrics, raw figures, and totals. It also covers the negative cases ('a post that isn't published or can't be reported on says so'), leaving nothing an agent needs unknown.

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 the baseline is 3; the description earns above that by explaining post_id's origin and the 'yt:<video id>' form, which the schema's terse 'One post' does not convey. project_id and limit add nothing beyond the schema, which is acceptable.

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?

Opens with a specific verb+resource statement ('How published posts performed') and immediately splits into the two modes (single post vs. recent posts), which is enough to separate it from list_scheduled_posts and get_overview_stats 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?

Explicitly states when to supply post_id versus omit it, and tells the agent where a valid post_id comes from (publish_post's return value or list_scheduled_posts' number). It does not contrast itself with get_overview_stats, so the sibling routing is implied rather than stated.

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

All Acrium 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