Skip to main content
Glama
Sign In

Postkey: Instagram DM Automation and Comment-to-DM

by pro.postkey
OverviewDiscussionsAdmin

List posts

postkey_list_posts
Read-onlyIdempotent

Postkey: Lists the profile's posts, newest first, one page at a time: id, status, title, the start of the caption, type, keyword, time (time_means: posted, scheduled, planned, updated or created), the accounts each goes to, and can_edit (false: postkey_update_post would refuse it; for a draft, edit_note says why and what to do). Use it to find a post id; use postkey_get_post for one post's full caption, media and each account's outcome, postkey_list_waiting_for_approval for what waits for a person, and postkey_get_post_stats for views and likes. Pass next_cursor as cursor for the next page (null: the last page). Only the newest 1,000 posts are listed.

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.
statusNo"all" (default). "in_progress": ideas and unfinished posts. "draft": saved to Drafts, not sent. "ready": waiting for a person in Posts > Approvals. "scheduled": on the schedule. "posted": published. "failed": the posting service could not publish it.

Output Schema

NameRequiredDescriptionDefault
okYesfalse: refused (isError; code, message, guide_topic, url); no change.
noteNoPresent when older posts were left out.
postsNoNewest first: id, status, detail_status, can_edit, edit_note (drafts only), title, caption_start, type, keyword, time, time_means, media_files, goes_to, failed_accounts, link.
totalNoPosts matching the filter.
next_cursorNoPass as cursor for the next page; null on the last page.

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
    • 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 / status / description
      Previous value: -"Which posts. Default all."New value: +"\"all\" (default). \"in_progress\": ideas and unfinished posts. \"draft\": saved to Drafts, not sent. \"ready\": waiting for a person in Posts > Approvals. \"scheduled\": on the schedule. \"posted\": published. \"failed\": the posting service could not publish it."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "next_cursor": {
+      "description": "Pass as cursor for the next page; null on the last page.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "note": {
+      "description": "Present when older posts were left out.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "false: refused (isError true; code, message, guide_topic, url), nothing changed.",
+      "type": "boolean"
+    },
+    "posts": {
+      "description": "Newest first: id, status, detail_status, can_edit, edit_note (drafts only), title, caption_start, type, keyword, time, time_means, media_files, goes_to, failed_accounts, link.",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total": {
+      "description": "Posts matching the filter.",
+      "type": "number"
+    }
+  },
+  "required": [
+    "ok"
+  ],
+  "type": "object"
+}
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered; the description adds real behavioral context on top: newest-first ordering, the 1,000-post listing ceiling, cursor pagination with null meaning last page, and the meaning of can_edit plus edit_note for drafts. Some of the field enumeration overlaps with the output schema, 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?

Single dense paragraph, front-loaded with purpose, then alternatives, then pagination mechanics and the 1,000-post limit. Every sentence carries information, though the long returned-field enumeration is the least essential part since an output schema already exists.

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?

With rich annotations, an output schema, and fully documented parameters, the description covers the remaining gaps an agent needs: routing to siblings, ordering, pagination contract, and the listing ceiling. Nothing required 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.

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema cannot: 'Pass next_cursor as cursor for the next page (null: the last page)' links the response field to the request parameter. It also clarifies time semantics ('time_means: posted, scheduled, planned, updated or created') beyond what the raw field names convey.

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 profile's posts') plus scope and ordering ('newest first, one page at a time'), then enumerates the returned fields. It explicitly distinguishes itself from postkey_get_post, postkey_list_waiting_for_approval, and postkey_get_post_stats, so an agent can route without opening 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?

Gives an explicit primary use ('Use it to find a post id') and names three alternative tools with the condition each serves (full caption/media, human approval queue, engagement stats). The exclusion logic is stated rather than inferred.

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