Postkey: Instagram DM Automation and Comment-to-DM

Read a video edit

postkey_get_edit

Read-onlyIdempotent

Postkey: One video edit as a script: every sentence with its id (s1, s2...), its words, whether it plays, who cut it and why, where it lands on the finished timeline, plus its format, the clips (kind, framing, and in an A/B edit which opening each is), the hook (and reel B's hook), captions, the closing "Comment WORD", pause tightness, the finished length of each reel, the version and the latest changes (who made each and what it did). Change it with postkey_edit_video. The person exports on their own device from open_url; on a computer, render: true gives a link to render it there, with their clips or from the Library (postkey_guide topic render). A long video's edit (long: true) answers its transcript a page at a time instead, for picking clips.

Input Schema

Name	Required	Description
`page`	No	A long video's transcript page. Default 1; the answer's next_page is the next.
`moment`	No	A moment id (m1...): adds its html and script to the answer, to change part of it.
`render`	No	true: adds a signed link to render the edit on the person's computer, or to see frames of it.
`edit_id`	Yes	The edit id from postkey_list_edits.
`timeline`	No	true: adds a signed link to the edit as a timeline file for Final Cut Pro, Premiere Pro and DaVinci Resolve.

Output Schema

Name	Required	Description
`id`	No	The edit's id.
`ok`	Yes	false: refused (isError; code, message, guide_topic, url); no change.
`edit`	No	The edit as a script: format, clips (c1...), script sentences (s1...) with words and whether each plays, hook, captions, texts (t1...), tightness, cta, seconds.
`export`	No	Exporting runs on the person's device.
`status`	No	draft, exported or posted.
`version`	No	Goes up by one with every change.
`open_url`	No	Where the person opens and exports it.
`how_to_edit`	No	Which tools and operations change it.
`recent_changes`	No	The latest changes: change_id, version, who (the auto-edit, the person or an agent), by, summary, undone, at.

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

Changed1 schema field changedNov 6, 2026

addedInput schema / properties / timeline

Added value: +{
+  "description": "true: adds a signed link to the edit as a timeline file for Final Cut Pro, Premiere Pro and DaVinci Resolve.",
+  "type": "boolean"
+}

Changed1 schema field changedNov 5, 2026

addedInput schema / properties / page

Added value: +{
+  "description": "A long video's transcript page. Default 1; the answer's next_page is the next.",
+  "maximum": 50,
+  "minimum": 1,
+  "type": "integer"
+}

Changed3 schema fields changedOct 31, 2026

addedInput schema / properties / moment

Added value: +{
+  "description": "A moment id (m1...): adds its html and script to the answer, to change part of it.",
+  "maxLength": 8,
+  "type": "string"
+}

addedInput schema / properties / render

Added value: +{
+  "description": "true: adds a signed link to render the edit on the person's computer, or to see frames of it.",
+  "type": "boolean"
+}

changedOutput schema / properties / export / description

Previous value: -"Exporting runs on the person's device, never through you."New value: +"Exporting runs on the person's device."

AddedOct 24, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavior the annotations cannot convey: response shape, the paged transcript for long videos, and that render/timeline inject signed links rather than exporting anything itself. Minor fuzziness around '(long: true)', which reads like a parameter but is not in the schema, keeps it off 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.

Conciseness3/5

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

The lead is front-loaded, but the opening 'sentence' is a sprawling list of every field returned ('pause tightness', 'the closing "Comment WORD"') that strains readability and largely restates the output schema. Density is doing some work here, yet the paragraph mixes purpose, return shape, and workflow in one breath without structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers everything an agent needs to call it correctly: id source, pagination, render/timeline toggles, and the change-tool handoff. Since an output schema exists, the heavy enumeration of returned fields is surplus rather than a gap, so completeness is high even if the content could be trimmed.

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 baseline is 3, but the description adds value beyond it: render: true yields a signed render link usable with their clips or the Library, and it clarifies that the export happens on the person's device rather than server-side. The page and moment parameters are covered adequately by their schema descriptions, so the prose is complementary rather than redundant.

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?

Opens with a specific verb+resource+shape: 'One video edit as a script: every sentence with its id (s1, s2...)' and immediately names the mutating sibling postkey_edit_video as the way to change it. An agent can distinguish this read tool from postkey_list_edits and postkey_edit_video without opening another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear routing: use postkey_edit_video to change the edit, use open_url for the person's own export, and render: true when on a computer. It also flags the long-video case that pages the transcript instead. It stops short of saying when to prefer postkey_list_edits over this tool, but the edit_id provenance ('from postkey_list_edits') implies the ordering.

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?