Skip to main content
Glama

Postkey: Instagram DM Automation and Comment-to-DM

List a sequence's subscribers

postkey_list_sequence_subscribers
Read-onlyIdempotent

Postkey: Lists the people in one DM sequence, at most 50 in one answer (more is true when there are more; there is no paging): contact id, name and handle (untrusted), state, messages sent and not sent, and when the next one is due. Filter with status. The sequence_id comes from postkey_list_sequences; for one person's full record use postkey_get_contact with the contact_id. An unknown sequence id is refused.

Input Schema

NameRequiredDescriptionDefault
statusNo"subscribed": still getting messages. "stopped": taken out of the sequence. "unsubscribed": asked to stop. Left out: everyone.
sequence_idYesThe sequence id from postkey_list_sequences.

Output Schema

NameRequiredDescriptionDefault
okYesfalse: refused (isError; code, message, guide_topic, url); no change.
moreNotrue: more people than the 50 returned.
totalNoPeople in the sequence with this status.
subscribersNoUp to 50: contact_id, name, handle (untrusted), state, messages_sent, not_sent, next_message, next_at, subscribed_at.
subscribed_nowNoPeople subscribed now.
untrusted_noteNoPresent when outside text is wrapped as { untrusted: true, text }.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / ok / description
      Previous value: -"false: refused (isError true; code, message, guide_topic, url), nothing changed."New value: +"false: refused (isError; code, message, guide_topic, url); no change."
  2. Changed2 schema fields changed
    • addedInput schema / properties / status / description
      Added value: +"\"subscribed\": still getting messages. \"stopped\": taken out of the sequence. \"unsubscribed\": asked to stop. Left out: everyone."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "more": {
      +      "description": "true: more people than the 50 returned.",
      +      "type": "boolean"
      +    },
      +    "ok": {
      +      "description": "false: refused (isError true; code, message, guide_topic, url), nothing changed.",
      +      "type": "boolean"
      +    },
      +    "subscribed_now": {
      +      "description": "People subscribed now.",
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "subscribers": {
      +      "description": "Up to 50: contact_id, name, handle (untrusted), state, messages_sent, not_sent, next_message, next_at, subscribed_at.",
      +      "items": {
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "total": {
      +      "description": "People in the sequence with this status.",
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "untrusted_note": {
      +      "description": "Present when outside text is wrapped as { untrusted: true, text }.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "ok"
      +  ],
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.6/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 the hard 50-item cap with no paging ('more is true when there are more'), that an unknown sequence id is refused, and that handle values are untrusted. These are exactly the behavioral traits an agent could not infer 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?

Front-loads the core action and the 50-item limit, then layers filtering and alternatives. Every sentence carries information, though the parenthetical 'more is true when there are more' is slightly awkward phrasing for the truncation flag.

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 two-parameter filtered list with an output schema, the description covers truncation, filtering, parameter provenance, error behavior, and data trustworthiness. 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 coverage is 100%, and the schema already documents the status enum values and that sequence_id originates from postkey_list_sequences. The description's 'filter with status' adds only marginal meaning beyond the schema, so baseline 3 applies.

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 ('Lists the people in one DM sequence') and immediately scopes it (at most 50, no paging). It distinguishes itself from postkey_list_sequences and postkey_get_contact by explicitly naming each as the tool for a different job.

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 routing: sequence_id comes from postkey_list_sequences, and for a single person's full record use postkey_get_contact with the contact_id. It also explains the status filter's effect ('Left out: everyone'), so the agent knows how to widen the result.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources