Antwork

list_posts

Read-only

List the workspace's posts, optionally filtered, or laid out by day.

Not needed to find duplicates before drafting: create_post answers similarRecent for that. Pages run newest scheduled time first; each is sorted scheduled (soonest first), then draft, published, failed. hasMore means more posts: pass nextCursor back as cursor. get_post(post_id) returns one in full. A draft whose approval.state is changes_requested carries the reviewer's note. group_by_day=true is the calendar view: calendar maps each date (YYYY-MM-DD) to that day's posts by time, calendarUrl is the calendar page, and the range defaults to the Monday of this week through 30 days ahead.

Args: status: "draft", "scheduled", "published", "failed", or "pending_approval" (waiting for a person to approve). query: Keyword matched against post text, case-insensitive. platform: e.g. "linkedin", "x". campaign_id: Only the versions of one post (its campaignId from create_post with posts). date_from: Scheduled on or after this date (ISO 8601, e.g. "2026-03-01"). date_to: Scheduled on or before this date (ISO 8601). limit: Max posts to return (default 50, max 50). Ignored by group_by_day. group_by_day: Group the posts by date instead of listing them. workspace_id: Workspace ID or name. Optional if user has only one workspace. recurring: Instead, the repeating and evergreen posts (set with update_post's repeat / evergreen): rule, next time, posts made, last skip. attention: Instead, what needs the user, in one call: failed (last three days, with advice), pendingApproval, drafts (stale, mediaRequired) and upcoming, five each, with attentionCounts. cursor: nextCursor from the previous page, with the same filters.

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": "list_posts"
  }
}

Input Schema

Name	Required	Description
`limit`	No
`query`	No
`cursor`	No
`status`	No
`context`	No	The user's underlying goal for this call, in one sentence without personal details. Used for product analytics only.
`date_to`	No
`platform`	No
`attention`	No
`date_from`	No
`llm_model`	No	The model identifier of the calling assistant, or "unknown". Used for product analytics only.
`recurring`	No
`campaign_id`	No
`group_by_day`	No
`workspace_id`	No
`conversation_id`	No	Pass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.

Output Schema

Name	Required	Description	Default
`_mcp_instructions`	No	Server-issued metadata for this conversation.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

addedInput schema / properties / cursor

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Cursor"
+}

Changed1 schema field changedNov 9, 2026

addedInput schema / properties / attention

Added value: +{
+  "default": false,
+  "title": "Attention",
+  "type": "boolean"
+}

Changed1 schema field changedNov 7, 2026

addedInput schema / properties / recurring

Added value: +{
+  "default": false,
+  "title": "Recurring",
+  "type": "boolean"
+}

Changed1 schema field changedOct 26, 2026

changedInput schema / required

Previous value: -[
-  "context",
-  "llm_model"
-]New value: +[]

First observedOct 22, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare readOnly/non-destructive/closed-world; the description goes well beyond by disclosing sort order (newest page first, then scheduled/draft/published/failed), pagination contract (`hasMore`, echo `nextCursor` as `cursor` with the same filters), that `limit` is capped at 50 and ignored by `group_by_day`, and the default calendar range (Monday of this week through 30 days ahead). It also flags that `changes_requested` drafts carry a reviewer `note`, which affects how results should be read.

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?

Purpose and the key routing exclusion are front-loaded, and the Args block makes scanning easy. It is long, and a few clauses (e.g. the nested description of the `attention` payload) are denser than strictly necessary, but nearly every line supplies decision-relevant detail.

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 15-parameter read tool with an output schema, the description covers mode selection, filtering semantics, pagination, ordering, and the shape of the `calendar`/`calendarUrl` result. Nothing an agent needs to invoke it correctly or interpret the response is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 20% schema coverage across 15 parameters, the description carries the burden and does: it enumerates valid `status` values and explains `pending_approval`, gives ISO 8601 examples for the date bounds, states `query` is case-insensitive, gives platform examples, defines `campaign_id` as the version group from create_post, and notes `workspace_id` is optional when the user has one workspace. The only undocumented params (`context`, `llm_model`, `conversation_id`) are already explained in the schema itself.

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?

The opening sentence names a specific verb and resource (list the workspace's posts) plus its two scoping modes: filtered listing and day-grouped calendar layout. It explicitly distinguishes itself from create_post (which handles duplicate checks via `similarRecent`) and get_post (which returns a single post in full), so an agent can route without opening any schema.

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

Usage Guidelines5/5

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

It states a when-not ('Not needed to find duplicates before drafting') and names the tool that covers that need, then explains the two alternate modes (`recurring` for repeating/evergreen posts, `attention` for what needs the user) with the exact payload each returns. Sibling delegation to get_post is also explicit.

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

All Antwork tools Inspect

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.