Skip to main content
Glama
posterly-mcp-server

posterly-mcp-server

by awpthorp

list_posts

Read-onlyIdempotent

Retrieve and filter social posts across workspaces by status, platform, account, brand, group, release, approval, and scheduled date range; get paginated results or exact daily counts.

Instructions

Posts in your workspaces, teammates' too, per your role there (brand-locked seats only see their assigned brands). If workspace_id is omitted, this searches every workspace you belong to. view=list (default): posts filtered by status (draft, scheduled, publishing, processing, awaiting_tiktok_publish, awaiting_manual, published, failed, paused, paused_due_to_token, paused_due_to_billing, or missed), platform, account_id, workspace_id, brand_id, group_id, release_id, approval_status, approval_waiting_on, and a scheduled date range: scheduled_from (inclusive) and scheduled_to (a plain date includes that whole day), read in timezone (IANA, default UTC; also the zone times are shown in). status=missed is posts that failed, scheduled posts whose scheduled time is already past, and posts a publishing pause held past their time. group_id matches the caller group (including post_group_id). release_id matches that release only. Returns limit posts (default 20, max 200) starting at offset; with a date range the order defaults to oldest first (order=asc|desc). The output always says whether every matching post was shown. If it says more are available, call again with the offset it gives and keep paging until all are shown before drawing any conclusion about totals, gaps, or how busy a client is. view=counts (scheduled_from and scheduled_to required, up to 366 days): exact totals per day, status, account, and brand for the same filters (limit, offset, and order are ignored); use it for "how many" or "is this month full" questions. Each post includes approval.pending_client_approval.

Input Schema

NameRequiredDescriptionDefault
viewNolist (default): the posts. counts: totals (needs scheduled_from and scheduled_to).
limitNoPosts per page (default 20, max 200). Ignored by view=counts.
orderNoasc (oldest first) or desc (newest first). Default asc with a date range, otherwise desc. Ignored by view=counts.
offsetNoMatching posts to skip; use the offset the previous page gives. Ignored by view=counts.
statusNoStored post status (draft, scheduled, publishing, processing, awaiting_tiktok_publish, awaiting_manual, published, failed, paused, paused_due_to_token, paused_due_to_billing, or missed). paused_due_to_token is a reconnect pause and paused_due_to_billing is a billing pause. missed: failed, still scheduled after the scheduled time, or held by a publishing pause past it.
brand_idNoFilter to posts assigned to a specific brand/client (the id from list_brands).
group_idNoCaller group id. Matches api_group_id, group_id, and post_group_id.
platformNoFilter by platform: instagram, facebook, tiktok, twitter, linkedin, youtube, pinterest, threads, google_business, telegram, bluesky, discord, slack, mastodon, devto, hashnode, wordpress, lemmy.
timezoneNoIANA time zone such as Europe/London for reading plain dates and showing times. Default UTC.
account_idNoFilter to a specific social account ID (from list_accounts).
release_idNoCaller release id. Matches release_id only.
scheduled_toNoEnd of the scheduled range: a plain date (2026-10-31) includes that whole day; an ISO date-time is exclusive.
workspace_idNoFilter to posts in a specific workspace (get IDs via whoami).
scheduled_fromNoStart of the scheduled range, inclusive: a date (2026-10-01) or an ISO date-time. Plain dates and times without an offset are read in timezone.
approval_statusNoFilter by client review approval status. pending_client means the post is waiting on the client.
approval_waiting_onNoclient: approval_status pending_client. team: changes_requested or rejected. Conflicts with a non-overlapping approval_status.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.55.1

TDQS

A4.3/5.0
Behavior5/5

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

Goes well past the readOnly/idempotent annotations: it explains role-based visibility, that omitting workspace_id searches every workspace, the semantics of status=missed, the multi-field group_id match, the date-range-dependent default ordering, and the 366-day cap on counts. It also states that the output always reports whether all matching posts were shown, which is essential for correct paging behavior.

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?

Content is dense and mostly earns its place, but it is delivered as one long unbroken paragraph mixing filtering, paging, and the counts mode. Sectioning or front-loading the two-view distinction would make it far easier to scan for a 16-parameter tool.

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 16-parameter read tool with no output schema, it covers everything an agent needs: filter semantics, defaults, paging loop, timezone handling, the dual-mode contract, and the one field worth surfacing (approval.pending_client_approval). Nothing material is left to inference.

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 the baseline is 3 and the description largely restates the same facts (group_id matching, timezone behavior, scheduled_to inclusivity). It does add modest value by tying ordering to the presence of a date range and by clarifying that limit/offset/order are ignored under view=counts.

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 concrete verb+resource+scope: posts across your workspaces and teammates', constrained by role and brand-locked seats. It also separates the two modes (view=list vs view=counts) inline, so an agent can distinguish this from get_post or list_analytics 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?

Explicit guidance for the counts view ("use it for 'how many' or 'is this month full' questions") and a mandatory paging directive (keep calling until everything is shown before drawing conclusions). It never names sibling alternatives like get_post or list_analytics, so routing between tools is left implicit.

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