Skip to main content
Glama

posterly

by ly.poster
OverviewDiscussionsAdmin

list_conversations

Read-onlyIdempotent

Social inbox DM conversations for Instagram and Facebook Page inboxes (Threads has no DMs; Pro plan or higher plus posts:read). Without conversation_id: list conversations filtered by account, platform, unread/starred/archived, search, or since/until dates, with limit/offset paging. With conversation_id: one conversation and its messages; there limit is the number of messages (default 50, max 100) and only workspace_id may be added. When a sync has stored it, each conversation includes the Meta reply window (open until a UTC time, or closed). A reply does not extend that window, and it is not guessed from the messages loaded in the thread.

Input Schema

NameRequiredDescriptionDefault
limitNoRows (messages with conversation_id). Default 50.
sinceNoISO date/time, inclusive.
untilNoISO date/time, inclusive.
filterNoDefault all (excludes archived).
offsetNoRows to skip.
searchNoSearch participant username or last message preview.
platformNoInstagram or Facebook. Threads has comments, not DMs.
account_idNoFrom list_accounts.
workspace_idNoOmit to search all your workspaces, or pass an ID from whoami.
conversation_idNoOne conversation and its messages.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / platform / description
      Added value: +"Instagram or Facebook. Threads has comments, not DMs."
    • changedInput schema / properties / platform / enum
      Previous value: -[
-  "instagram",
-  "facebook",
-  "threads"
-]New value: +[
+  "instagram",
+  "facebook"
+]
  2. Changed9 schema fields changed
    • changedInput schema / properties / account_id / description
      Previous value: -"Social account ID from list_accounts."New value: +"From list_accounts."
    • changedInput schema / properties / conversation_id / description
      Previous value: -"One conversation (from a list call) with its messages."New value: +"One conversation and its messages."
    • changedInput schema / properties / filter / description
      Previous value: -"Conversation filter. Defaults to all (excludes archived)."New value: +"Default all (excludes archived)."
    • changedInput schema / properties / limit / description
      Previous value: -"Conversations to return, or messages with conversation_id. Default 50, max 100."New value: +"Rows (messages with conversation_id). Default 50."
    • changedInput schema / properties / offset / description
      Previous value: -"Skip this many conversations before returning results."New value: +"Rows to skip."
    • removedInput schema / properties / platform / description
      Removed value: -"instagram or facebook. Threads has no DMs."
    • addedInput schema / properties / since
      Added value: +{
+  "description": "ISO date/time, inclusive.",
+  "type": "string"
+}
    • addedInput schema / properties / until
      Added value: +{
+  "description": "ISO date/time, inclusive.",
+  "type": "string"
+}
    • changedInput schema / properties / workspace_id / description
      Previous value: -"Optional. Omit to search every workspace you belong to; pass a workspace ID from whoami to limit to one."New value: +"Omit to search all your workspaces, or pass an ID from whoami."
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context on top: the required plan and posts:read scope, mode-dependent limit semantics with default 50 and max 100, and the Meta reply-window model including the caveats that a reply does not extend the window and the window is not inferred from loaded messages. Those domain constraints are exactly the kind of thing an agent cannot get from structured fields.

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 is front-loaded in the first sentence, followed by the two-mode branch and then the reply-window nuance — a logical order. Four dense sentences with no filler, though the reply-window paragraph is long enough that it could be trimmed slightly.

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 10-parameter read tool with no output schema, the description covers the critical gaps: mode branching, pagination semantics per mode, auth/plan requirements, and one important returned field (reply window). It doesn't describe the shape of returned conversation objects beyond that, and pagination metadata (totals/has_more) is unmentioned, but the essentials for correct invocation are present.

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 100%, so the per-parameter baseline is 3; the description earns above that by explaining that limit/offset mean rows in list mode but message count in single-conversation mode, and that filters only apply when conversation_id is absent. It also reinforces the Threads exclusion for platform. The remaining filter interplay (e.g., that 'all' excludes archived) is left to the schema.

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 description names a specific verb and resource ('Social inbox DM conversations for Instagram and Facebook Page inboxes') and immediately splits the tool's two operating modes by presence of conversation_id. It also scopes out a false friend ('Threads has no DMs'), so an agent can distinguish it from comment-related siblings like list_comments.

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?

Clear conditional usage is spelled out: omit conversation_id to list with filters, include it to fetch one thread and its messages, and only workspace_id may be combined in that mode. It also states the plan and scope prerequisite ('Pro plan or higher plus posts:read'). It stops short of naming manage_conversation as the tool to use for replying or mutating a thread, though the reply-window sentence implies it.

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