Postkey: Instagram DM Automation and Comment-to-DM

Pause a DM automation

postkey_pause_automation

Idempotent

Postkey: Switches a live DM automation off on every Instagram account it runs on, at once (no approval). It stops answering new people; conversations already under way finish. Nothing is deleted, and postkey_publish_automation turns it back on. Only when the person asks: never to make room under a plan limit.

Input Schema

Name	Required	Description	Default
`automation_id`	Yes	The automation id (a UUID) from postkey_list_automations or postkey_create_automation.

Output Schema

Name	Required	Description
`ok`	Yes	false: refused (isError; code, message, guide_topic, url); no change.
`note`	No	Present when it did not pause on every account.
`paused`	No	true: it is off.
`status`	No	The automation's status now.
`accounts`	No	Present when an account could not be paused: ok, message.
`automation_id`	No	The automation id.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

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."

Changed2 schema fields changedOct 24, 2026

changedInput schema / properties / automation_id / description

Previous value: -"The automation id."New value: +"The automation id (a UUID) from postkey_list_automations or postkey_create_automation."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "accounts": {
+      "description": "Present when an account could not be paused: ok, message.",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "automation_id": {
+      "description": "The automation id.",
+      "type": "string"
+    },
+    "note": {
+      "description": "Present when it did not pause on every account.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "false: refused (isError true; code, message, guide_topic, url), nothing changed.",
+      "type": "boolean"
+    },
+    "paused": {
+      "description": "true: it is off.",
+      "type": "boolean"
+    },
+    "status": {
+      "description": "The automation's status now.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "ok"
+  ],
+  "type": "object"
+}

First observedOct 23, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description explains the blast radius (all Instagram accounts at once, no approval gate), the runtime effect on in-flight state ("stops answering new people; conversations already under way finish"), and that nothing is deleted. It also confirms reversibility, which the annotations alone cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the action and scope, then effect, then reversibility, then the usage constraint. Every clause carries distinct information and nothing repeats the title or schema.

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 single-parameter, non-destructive, idempotent mutation with an output schema and full annotation coverage, the description supplies everything an agent still needs: scope, side effects, reversibility, and the approval-free nature of the call.

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 description coverage is 100% and the single automation_id parameter is fully documented in the schema, including its UUID pattern and where to obtain it. The description adds no further parameter meaning, but none is needed, so the 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 ("Switches a live DM automation off") plus scope ("on every Instagram account it runs on, at once"), and names the sibling that reverses it (postkey_publish_automation). An agent can distinguish this from postkey_update_automation or postkey_delete_post without opening any schema.

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 both the positive trigger ("Only when the person asks") and an explicit exclusion ("never to make room under a plan limit"), and points to postkey_publish_automation as the inverse action. This is exactly the when/when-not/alternative structure that prevents misuse.

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 tools Inspect

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

Need Help?