Skip to main content
Glama
Sign In

Postkey: Instagram DM Automation and Comment-to-DM

by pro.postkey
OverviewDiscussionsAdmin

Preview a send

postkey_preview_action
Read-onlyIdempotent

Postkey: Shows exactly what postkey_schedule_post, postkey_publish_automation or postkey_send_reply would do with these arguments, without doing it: the time it understood, the accounts or the person it reaches, the words, the limits after it, issues, and whether it would wait for approval. Changes nothing and sends nothing. Call it before every send and show the person the result; then call that send tool with the same arguments and the preview_id it returns. A preview is refused when the send could not happen at all (not_found, outside_24h_window, the plan's limit on automations switched on): fix that first. Anything else the send would meet, a full weekly post limit included, is listed in issues and the preview is still ok. At most 500 preview calls a day per connection.

Input Schema

NameRequiredDescriptionDefault
argsYesThe exact arguments you would pass to that tool, checked against its own input schema (a preview_id in them is ignored).
toolYesThe send tool to preview.

Output Schema

NameRequiredDescriptionDefault
okYesfalse: refused (isError; code, message, guide_topic, url); no change.
nextNoWhat to do next.
sentNoAlways false.
toolNoThe send tool previewed.
wouldNoWhat it would do: the post's time (understood_as), targets (each with send_refuses: the code the send would refuse it with) and weekly count; the automation's approval text and limit; or the reply's recipient, text and window.
issuesNoProblems that would make it fail or surprise the person.
previewNoAlways true: this was a preview.
preview_idNoPass it to the send tool with the same arguments (valid for the same UTC day).
send_policyNoReplies and automations: held_in_postkey or confirm_in_chat.
held_becauseNoWhy it would wait even on a direct connection.
publish_policyNoFor a post: held_in_postkey or confirm_in_chat.
untrusted_noteNoPresent when outside text is wrapped as { untrusted: true, text }.
nothing_changedNoAlways true.
would_wait_for_approvalNotrue: the send would wait in Approvals.

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
    • addedOutput schema / properties / publish_policy
      Added value: +{
+  "description": "For a post: held_in_postkey or confirm_in_chat.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • changedOutput schema / properties / send_policy / description
      Previous value: -"held_in_postkey or confirm_in_chat."New value: +"Replies and automations: held_in_postkey or confirm_in_chat."
  3. Changed2 schema fields changed
    • changedInput schema / properties / args / description
      Previous value: -"The arguments you would pass to that tool."New value: +"The exact arguments you would pass to that tool, checked against its own input schema (a preview_id in them is ignored)."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "held_because": {
+      "description": "Why it would wait even on a direct connection.",
+      "type": "string"
+    },
+    "issues": {
+      "description": "Problems that would make it fail or surprise the person.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "next": {
+      "description": "What to do next.",
+      "type": "string"
+    },
+    "nothing_changed": {
+      "description": "Always true.",
+      "type": "boolean"
+    },
+    "ok": {
+      "description": "false: refused (isError true; code, message, guide_topic, url), nothing changed.",
+      "type": "boolean"
+    },
+    "preview": {
+      "description": "Always true: this was a preview.",
+      "type": "boolean"
+    },
+    "preview_id": {
+      "description": "Pass it to the send tool with the same arguments (valid for the same UTC day).",
+      "type": "string"
+    },
+    "send_policy": {
+      "description": "held_in_postkey or confirm_in_chat.",
+      "type": "string"
+    },
+    "sent": {
+      "description": "Always false.",
+      "type": "boolean"
+    },
+    "tool": {
+      "description": "The send tool previewed.",
+      "type": "string"
+    },
+    "untrusted_note": {
+      "description": "Present when outside text is wrapped as { untrusted: true, text }.",
+      "type": "string"
+    },
+    "would": {
+      "description": "What it would do: the post's time (understood_as), targets (each with send_refuses: the code the send would refuse it with) and weekly count; the automation's approval text and limit; or the reply's recipient, text and window.",
+      "type": "object"
+    },
+    "would_wait_for_approval": {
+      "description": "true: the send would wait in Approvals.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "ok"
+  ],
+  "type": "object"
+}
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/idempotentHint true and destructiveHint false, and the description reinforces this with 'Changes nothing and sends nothing.' Beyond that it discloses non-obvious behavior: the 500-calls-per-day-per-connection rate limit, the fact that a preview returns a preview_id that must be reused, and that approval-waiting status is reported.

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 purpose in the first clause, then workflow, failure modes, and limits in descending priority. Dense but nearly every sentence carries operational information; the enumeration of previewed fields is slightly redundant given an output schema exists, which keeps it from a 5.

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?

Covers the full picture for a two-parameter, nested-args, cross-tool preview: what it returns, what it does not do, the required follow-up call, the refusal-versus-issue split, and a rate limit. With an output schema present it does not need to enumerate return fields in detail, and it doesn't over-explain them.

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; the description earns extra by explaining the cross-tool contract — args are the exact arguments for the target send tool and are validated against its schema, and an embedded preview_id is ignored. It adds workflow meaning (the returned preview_id feeds the subsequent send call) that the schema alone does not 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 ('Shows exactly what ... would do ... without doing it') and names the three sibling send tools it previews (postkey_schedule_post, postkey_publish_automation, postkey_send_reply). This makes it unmistakable against the ~50 siblings, including the real send tools it shadows.

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 prescription: 'Call it before every send and show the person the result; then call that send tool with the same arguments and the preview_id it returns.' It also distinguishes refusal cases (not_found, outside_24h_window, automation limit switched on) from advisory issues that still yield an ok preview, so the agent knows both when to call and how to react.

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