Skip to main content
Glama

Get post stats

get_post_stats
Read-onlyIdempotent

Recipients, opens, open rate, views, likes, restacks and subscribers gained.

Input Schema

NameRequiredDescriptionDefault
post_idYesPost ID from list_posts.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description's only added value is enumerating the returned metrics, which is modest but real given there is no output schema; it says nothing about time window, aggregation, permissions, or whether unpublished posts are supported.

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?

It is short and wastes no words, but it is a fragment rather than a front-loaded sentence, so the reader spends the whole line figuring out that this is a retrieval operation. Brevity comes at the cost of a lead clause stating what the tool does.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a stats tool with no output schema, the metric enumeration is genuinely helpful, but crucial context is absent: no time range, no granularity, no indication whether values are cumulative or periodic, and no contrast with the four other stats tools. An agent cannot confidently pick this over get_daily_stats or get_post_engagement.

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 description coverage is 100% — post_id is documented as coming from list_posts — so the schema does the heavy lifting. The description adds no parameter detail beyond the metric list, which is the expected baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description is a bare list of metrics ("Recipients, opens, open rate, views, likes, restacks and subscribers gained") with no verb or resource; the reader has to infer from the name 'get_post_stats' that this retrieves per-post statistics. It is distinguishable from siblings in spirit but never states the action or scope explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus get_post_engagement, get_post_traffic, get_daily_stats, or get_publication_stats — a crowded cluster of stats siblings where routing guidance is most needed. The only hint is inside the schema (post_id from list_posts), which is not the description's job.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.