Skip to main content
Glama

posterly

by ly.poster
OverviewDiscussionsAdmin

list_posts

Read-onlyIdempotent

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, 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). 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).list
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, 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, post_group_id.
platformNo
timezoneNoIANA time zone such as Europe/London for reading plain dates and showing times. Default UTC.
account_idNo
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_idNo
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. Changed4 schema fields changed
    • addedInput schema / properties / group_id
      Added value: +{
+  "description": "Caller group id. Matches api_group_id, group_id, post_group_id.",
+  "type": "string"
+}
    • addedInput schema / properties / release_id
      Added value: +{
+  "description": "Caller release id. Matches release_id only.",
+  "type": "string"
+}
    • addedInput schema / properties / status / description
      Added value: +"Stored post status, 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."
    • changedInput schema / properties / status / enum
      Previous value: -[
-  "scheduled",
-  "published",
-  "failed",
-  "draft"
-]New value: +[
+  "draft",
+  "scheduled",
+  "publishing",
+  "processing",
+  "awaiting_tiktok_publish",
+  "awaiting_manual",
+  "published",
+  "failed",
+  "paused",
+  "paused_due_to_token",
+  "paused_due_to_billing",
+  "missed"
+]
  2. Changed2 schema fields changed
    • changedInput schema / properties / offset / description
      Previous value: -"How many matching posts to skip. Use the offset the previous page gives to get the next page. Ignored by view=counts."New value: +"Matching posts to skip; use the offset the previous page gives. Ignored by view=counts."
    • changedInput schema / properties / view / description
      Previous value: -"list (default): the posts themselves, one page at a time. counts: exact totals per day, status, account, and brand (needs scheduled_from and scheduled_to)."New value: +"list (default): the posts. counts: totals (needs scheduled_from and scheduled_to)."
  3. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses pagination semantics, that the response always reports whether the full result set was shown, timezone handling for reads and display, date-boundary inclusivity/exclusivity, the 366-day cap on counts, and that limit/offset/order are ignored in counts. That is exactly the kind of behavioral context annotations cannot express.

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?

It is a single dense paragraph that front-loads scope and then the view decision, and nearly every clause carries operational meaning. Minor waste comes from restating schema facts verbatim (limit default 20 / max 200, order='asc|desc'), which makes it read as a run-on.

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

Completeness4/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 pagination, completeness signals, timezone behavior, and even one return field (approval.pending_client_approval). The main residual gap is that the shape of each returned post is not described, which matters given the absent output schema.

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 already 81%, so the baseline is 3; the description adds real meaning on top by explaining that counts requires scheduled_from/scheduled_to (with a 366-day ceiling) and how plain dates are read versus ISO date-times. Some parameters (platform, account_id, workspace_id) get no semantic treatment in either place.

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

Purpose4/5

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

The description names the resource (posts), the scope (workspaces you belong to, teammates' posts, brand-locked seat visibility), and the two operating modes (list vs counts). It is specific enough that an agent can distinguish it from get_post or list_analytics without reading the schema, though it never explicitly names those siblings.

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 an explicit decision rule between the two views ('use it for "how many" or "is this month full" questions') and instructs the agent to keep paging until the output says everything was shown before drawing conclusions about totals. It stops short of stating when to prefer a different tool (get_post, list_analytics) for adjacent tasks.

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

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