Social MCP

Overview Schema Source Related Servers Discussions Admin

threads_list_publications

Read-only

List recent saved publication states for a Threads account to check status after an interruption or timeout. Use the saved publication_id to resume preparing posts safely.

Instructions

List recent saved publication states for an account, without captions or tokens.

Use after interruption, processing timeout, or before resuming. preparing can continue with threads_resume_publication using the saved publication_id. publishing means a publish request may have been sent: do not retry or create another post; check threads_list_posts (or replies for reply_to_id) first. published includes the confirmed post_id. failed cannot be resumed. Returns the latest limit local records; this is not a list of Meta drafts.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "account_id": "<account_id>"
    },
    "name": "threads_list_publications"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No
`account_id`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.2Nov 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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

readOnlyHint=true is consistent with a list operation, and the description adds substantial context beyond annotations: it defines the four publication states, warns that 'publishing' may mean a publish request was already sent (a duplicate-post hazard), and clarifies the records are local rather than Meta drafts. It stops short of stating ordering or retention behavior beyond 'latest limit', which keeps it from a 5.

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?

Front-loaded with the core action, then a compact state-to-action mapping; nearly every clause carries operational weight. The line-broken state guidance is slightly telegraphic ('preparing can continue with...'), but there is no filler.

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?

An output schema exists, so return-value details needn't be described, and the description still covers the state machine, retry hazards, and sibling routing. For a two-parameter read tool, nothing an agent needs to call it correctly 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 0% for two parameters, so the description must compensate. It does clarify `limit` as 'the latest `limit` local records', but says nothing about `account_id` beyond the schema's numeric pattern, leaving the account identifier's expected form to inference.

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 verb and resource ('List recent saved publication states for an account') and immediately bounds the scope ('without captions or tokens'). It also explicitly distinguishes itself from the nearest confusable thing by noting 'this is not a list of Meta drafts' and pointing at threads_list_posts for actual posts.

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?

Gives explicit when-to-use triggers ('after interruption, processing timeout, or before resuming') and then per-state routing: preparing -> threads_resume_publication, publishing -> check threads_list_posts first and do not retry, published -> has post_id, failed -> cannot be resumed. Alternatives are named and the conditions selecting them are spelled out.

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