Skip to main content
Glama
Sign In

Postkey: Instagram DM Automation and Comment-to-DM

by pro.postkey
OverviewDiscussionsAdmin

List DM automations

postkey_list_automations
Read-onlyIdempotent

Postkey: Lists the profile's DM automations (for example "comment GUIDE, get the link by DM") one page at a time (next_cursor; null: the last page): id, name, status (draft, live, paused, error), made_with (Quick form, Flow Builder, or Postkey (a built-in automation)), unpublished changes, and what starts each one with its keywords. Without search, newest edits first. With search, names AND keywords are matched, each result with match: "keyword" (a keyword is exactly the search), "name" (a whole word of its name) or "partial". When some automation has the search as a keyword, only those are listed unless include_partial is true. For a keyword ("the LIST automation"), act only on results with match "keyword": "name" and "partial" are other automations. match_note says which to act on. Use it to find an automation id; use postkey_get_automation for one automation's messages and settings, postkey_get_automation_stats for results, and postkey_list_automation_templates to make a new one.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many to return, 1 to 50. Default 20.
cursorNoThe next_cursor of the previous answer, as it was. Leave out for the first page.
searchNoA keyword or words of the name, at most 120 characters, case-insensitive: "GUIDE" finds the automation whose keyword is GUIDE (match "keyword"); when none has it, names with that word ("name") or containing it ("partial").
statusNo"all" (default). "draft": never switched on. "live": answering people. "paused": switched off. "error": has a problem to fix in Postkey.
include_partialNoWith search: true also lists the "name" and "partial" matches when some automation has the search as a keyword. false (default): only the keyword matches then. Use true only when the person asks about names, not a keyword.

Output Schema

NameRequiredDescriptionDefault
okYesfalse: refused (isError; code, message, guide_topic, url); no change.
noteNoPresent when more matched than were returned.
totalNoAutomations matching the filter.
match_noteNoWith search, when not every result is a keyword match or others were left out: which one to act on.
automationsNoid, name, status, made_with (Quick form, Flow Builder, or Postkey (a built-in automation)), has_unpublished_changes, ever_published, problem, starts (starts_on, on, keywords, scope), updated_at; with search, match (keyword, name or partial).
next_cursorNoPass as cursor for the next page; null on the last page.
hidden_matchesNoWith search and include_partial false: how many name or partial matches were left out because some automation has the search as a keyword. Missing when none was.

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. Changed4 schema fields changed
    • addedInput schema / properties / include_partial
      Added value: +{
+  "description": "With search: true also lists the \"name\" and \"partial\" matches when some automation has the search as a keyword. false (default): only the keyword matches then. Use true only when the person asks about names, not a keyword.",
+  "type": "boolean"
+}
    • changedInput schema / properties / search / description
      Previous value: -"A keyword or words of the name, at most 120 characters, case-insensitive: \"GUIDE\" finds the automation whose keyword is GUIDE first (match \"keyword\"), then names with that word (\"name\") or containing it (\"partial\")."New value: +"A keyword or words of the name, at most 120 characters, case-insensitive: \"GUIDE\" finds the automation whose keyword is GUIDE (match \"keyword\"); when none has it, names with that word (\"name\") or containing it (\"partial\")."
    • addedOutput schema / properties / hidden_matches
      Added value: +{
+  "description": "With search and include_partial false: how many name or partial matches were left out because some automation has the search as a keyword. Missing when none was.",
+  "type": "number"
+}
    • changedOutput schema / properties / match_note / description
      Previous value: -"With search, when not every result is a keyword match: which one to act on."New value: +"With search, when not every result is a keyword match or others were left out: which one to act on."
  3. Changed5 schema fields changed
    • changedInput schema / properties / cursor / description
      Previous value: -"The next_cursor of the page before. Leave out for the first page."New value: +"The next_cursor of the previous answer, as it was. Leave out for the first page."
    • changedInput schema / properties / limit / description
      Previous value: -"How many to return (1 to 50). Default 20."New value: +"How many to return, 1 to 50. Default 20."
    • changedInput schema / properties / search / description
      Previous value: -"Words in the name."New value: +"A keyword or words of the name, at most 120 characters, case-insensitive: \"GUIDE\" finds the automation whose keyword is GUIDE first (match \"keyword\"), then names with that word (\"name\") or containing it (\"partial\")."
    • changedInput schema / properties / status / description
      Previous value: -"Default all."New value: +"\"all\" (default). \"draft\": never switched on. \"live\": answering people. \"paused\": switched off. \"error\": has a problem to fix in Postkey."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "automations": {
+      "description": "id, name, status, made_with (Quick form, Flow Builder, or Postkey (a built-in automation)), has_unpublished_changes, ever_published, problem, starts (starts_on, on, keywords, scope), updated_at; with search, match (keyword, name or partial).",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "match_note": {
+      "description": "With search, when not every result is a keyword match: which one to act on.",
+      "type": "string"
+    },
+    "next_cursor": {
+      "description": "Pass as cursor for the next page; null on the last page.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "note": {
+      "description": "Present when more matched than were returned.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "false: refused (isError true; code, message, guide_topic, url), nothing changed.",
+      "type": "boolean"
+    },
+    "total": {
+      "description": "Automations matching the filter.",
+      "type": "number"
+    }
+  },
+  "required": [
+    "ok"
+  ],
+  "type": "object"
+}
  4. Changed1 schema field changed
    • addedInput schema / properties / cursor
      Added value: +{
+  "description": "The next_cursor of the page before. Leave out for the first page.",
+  "maxLength": 400,
+  "type": "string"
+}
  5. First observed

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile needs no restating. The description still adds real behavior beyond that: one-page-at-a-time paging with a null next_cursor meaning last page, newest-edits-first default ordering, and that match_note tells the agent which results are safe to act on. It stops short of describing error conditions or rate limits, which is acceptable for a read-only listing.

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 block that front-loads the core action before the matching rules and alternatives, and nearly every sentence carries operational information. It is slightly overlong for a list tool, with the paging aside and field enumeration partly duplicating the output schema, but nothing is superfluous enough to obscure the main instruction.

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 five-parameter, read-only, paged listing with an output schema, the description covers what an agent needs: what is returned, how paging terminates, ordering, search/match semantics, and which sibling to call for adjacent needs. Return-value detail need not be repeated given the output schema exists.

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 description coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema does not: the interaction between search and include_partial (only keyword matches listed when one exists unless include_partial is true) and the interpretation of the returned match values. It also clarifies intent for include_partial (use true only when the person asks about names, not a keyword).

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 first sentence gives a specific verb and resource (lists the profile's DM automations), an example of what an automation is, and the pagination model. It is clearly separable from siblings it names (postkey_get_automation, postkey_get_automation_stats, postkey_list_automation_templates), so an agent can pick it without opening other schemas.

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 the primary use case (find an automation id) and explicitly routes the agent elsewhere for messages/settings, stats, and templates. It also gives conditional usage rules: how search matches, that only keyword matches are returned when any exist unless include_partial is true, and that only results with match "keyword" should be acted on for a keyword request.

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

All Postkey: Instagram DM Automation and Comment-to-DM 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