Skip to main content
Glama

Show what works: best posts, times and patterns

get_post_performance
Read-onlyIdempotent

Returns what the account's own numbers say works, over the last 90 days, computed from the numbers each network reports (no estimates): the published posts ranked against the median of the same social account on the same network, each with its network, brand, link, excerpt, metric (views where the network reports them, otherwise likes + reposts + replies), value, that median, n (posts in the median), a verdict (winner at 2x the median or more, under at half or less) and what the post had (format, first-line type, question, emoji, number up front, day and time, length, hashtags); best_times: the time of day and day of week whose posts did best, with the size of the effect and both sample sizes, or — below 8 measured posts or without a clear difference — two hours to post at to learn it; streak: weeks in a row with at least one post; headline_pattern: the strongest pattern, as a sentence with its numbers; next: three concrete suggestions for the next post, each with the numbers behind it; competitors: public accounts the user watches (YouTube, Bluesky, Mastodon; TikTok captions only), their posts against their own median and what their best posts share; measurable: what each network lets PostWire read, and why the rest is not measurable. Posts younger than 24 hours are not ranked; patterns need at least 10 measured posts and 3 per group. Depending on the account's plan it also returns every pattern, the per-network detail and which formats to double down on or rethink; on a plan without them, locked.patterns_preview says which further patterns are ready and how large each effect is, without the winning value. Read-only; nothing here uses AI.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
brand_idNoOnly this brand's posts. Omit for all brands.
platformNoOnly posts on this network.
timezoneNoIANA timezone for the day and time patterns, e.g. "America/Lima". Default UTC.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / platform / enum
      Previous value: -[
      -  "telegram",
      -  "bluesky",
      -  "mastodon",
      -  "discord",
      -  "tiktok",
      -  "youtube",
      -  "reddit",
      -  "linkedin",
      -  "facebook",
      -  "instagram",
      -  "x"
      -]New value: +[
      +  "telegram",
      +  "bluesky",
      +  "mastodon",
      +  "discord",
      +  "wordpress",
      +  "devto",
      +  "hashnode",
      +  "slack",
      +  "nostr",
      +  "tiktok",
      +  "youtube",
      +  "reddit",
      +  "linkedin",
      +  "facebook",
      +  "instagram",
      +  "x"
      +]
  2. Changed1 schema field changed
    • changedInput schema / properties / platform / enum
      Previous value: -[
      -  "telegram",
      -  "bluesky",
      -  "mastodon",
      -  "discord",
      -  "tiktok",
      -  "youtube",
      -  "reddit",
      -  "linkedin",
      -  "facebook",
      -  "instagram"
      -]New value: +[
      +  "telegram",
      +  "bluesky",
      +  "mastodon",
      +  "discord",
      +  "tiktok",
      +  "youtube",
      +  "reddit",
      +  "linkedin",
      +  "facebook",
      +  "instagram",
      +  "x"
      +]
  3. Added

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only assert readOnly/idempotent/non-destructive; the description goes far beyond them with the 90-day window, the 24-hour ranking floor, minimum sample thresholds, plan-gated output (locked.patterns_preview revealing effect sizes but withholding winning values), per-network measurability limits, and the 'no estimates, no AI' computation basis. That is exactly the behavioral context an agent needs before promising results to a user.

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 opening clause is well front-loaded and the field inventory is genuinely needed since there is no output schema, but the whole thing is delivered as one ~330-word semicolon-chained sentence with no visual hierarchy. Dense and information-earning, yet structurally unscannable for an agent skimming before a call.

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 read-only analytics tool with no output schema, three optional filter params and rich annotations, the description covers what is returned, the computation basis, the gating rules and the fallback behavior ('below 8 measured posts ... two hours to post at to learn it'). Nothing an agent needs to invoke it correctly or set expectations 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?

Schema description coverage is 100%, so brand_id, platform and timezone (with its IANA example) are already fully documented in the schema. The description only indirectly touches timezone via 'day and time patterns' and never adds filter syntax beyond what the schema provides — baseline 3 is correct here.

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 return (ranked posts, best times, streaks, patterns, suggestions, competitor benchmarks) computed from the account's own reported numbers over a fixed 90-day window. An agent can distinguish it immediately from every sibling, none of which produce analytics — the nearest relatives (replicate_top_post, plan_week) consume this kind of data rather than produce it.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: the description names qualifying conditions ('patterns need at least 10 measured posts and 3 per group', 'posts younger than 24 hours are not ranked') and closes with 'Read-only; nothing here uses AI.' However, it never says when to prefer this over list_scheduled_posts or get_post_status, nor that replicate_top_post is the natural follow-up.

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.