Skip to main content
Glama
Sign In

Postkey: Instagram DM Automation and Comment-to-DM

by pro.postkey
OverviewDiscussionsAdmin

Assign a conversation

postkey_assign_conversation
Idempotent

Postkey: Assigns a conversation to a team member (member_id from postkey_list_conversations (team) or postkey_get_started (detail full, inbox_team)), or to nobody with member_id null. Nothing is sent to the contact. Works only on a profile with a team. To mark a conversation for the team use postkey_label_conversation; to answer the contact use postkey_send_reply.

Input Schema

NameRequiredDescriptionDefault
member_idYesThe team member's id (a UUID), or null for Unassigned.
conversation_idYesThe conversation id from postkey_list_conversations (or conversation_id in postkey_get_contact), as it was given.

Output Schema

NameRequiredDescriptionDefault
okYesfalse: refused (isError; code, message, guide_topic, url); no change.
stateNoThe conversation's state.
conversation_idNoThe conversation id.
assigned_member_idNoThe member it is assigned to; null: nobody.

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. Changed3 schema fields changed
    • changedInput schema / properties / conversation_id / description
      Previous value: -"The conversation id from postkey_list_conversations."New value: +"The conversation id from postkey_list_conversations (or conversation_id in postkey_get_contact), as it was given."
    • changedInput schema / properties / member_id / description
      Previous value: -"The team member's id, or null for Unassigned."New value: +"The team member's id (a UUID), or null for Unassigned."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "assigned_member_id": {
+      "description": "The member it is assigned to; null: nobody.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "conversation_id": {
+      "description": "The conversation id.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "false: refused (isError true; code, message, guide_topic, url), nothing changed.",
+      "type": "boolean"
+    },
+    "state": {
+      "description": "The conversation's state.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "ok"
+  ],
+  "type": "object"
+}
  3. Changed1 schema field changed
    • changedInput schema / properties / conversation_id / pattern
      Previous value: -"^([0-9]{1,40}|[0-9a-f]{24})$"New value: +"^([0-9]{1,40}|[0-9a-f]{24}|[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12})$"
  4. 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 this is a non-destructive, idempotent mutation, so the bar is lower. The description still adds real value: 'Nothing is sent to the contact' discloses the side-effect profile, and the team-profile prerequisite is a gating condition an agent cannot get from annotations. It does not cover failure modes or permission requirements beyond team membership.

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 action and target, then prerequisites, then alternatives — a sensible ordering with no filler sentences. It is dense (nested parentheses around the id sources), which slightly hurts scanability for an otherwise short description.

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 only two required params, full schema coverage, an output schema, and complete annotations, an agent has everything it needs: what the tool does, where the ids come from, the unassign case, the profile prerequisite, and which siblings to use instead.

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 and the schema already documents both fields including the null-means-Unassigned semantics. The description goes beyond this by giving provenance for member_id (postkey_list_conversations team, or postkey_get_started with detail full/inbox_team), which the schema does not provide.

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 ('Assigns a conversation') plus the assignment target (a team member, or nobody via null). It also names the sibling tools it is NOT (postkey_label_conversation, postkey_send_reply), so an agent can distinguish it from adjacent conversation tools without opening either 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?

Explicit when-to-use vs alternatives: use postkey_label_conversation to mark a conversation for the team, postkey_send_reply to answer the contact. It also states the preconditions ('Works only on a profile with a team') and the unassign case, leaving nothing to inference.

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