Postkey: Instagram DM Automation and Comment-to-DM

List video edit templates

postkey_list_edit_templates

Read-onlyIdempotent

Postkey: The formats a video edit can start from or switch to, each a reel structure that wins on Instagram, with what to film and the parts its clips are; the account's own saved templates; every caption style, hook style and font by id; the sound library (sounds, music); and logos. Pass find_pictures to search open libraries for real photos a person may publish instead: nouns a camera could photograph, each result with its license and credit, for op add_broll (guide topic broll). Apply a format with postkey_edit_video, op apply_template, or a single style with set_captions or set_hook.

Input Schema

Name	Required	Description	Default
`find_pictures`	No	What a real photo should show, in a few plain words. Answers pictures only.

Output Schema

Name	Required	Description
`ok`	Yes	false: refused (isError; code, message, guide_topic, url); no change.
`note`	No	How to apply them.
`fonts`	No	Fonts by id: name, feel.
`logos`	No	Logos a moment can show as src="logo:<id>".
`music`	No	Music beds by id: label, mood, energy, bpm, seconds, use, credit.
`saved`	No	The profile's own saved formats: id, name, values.
`sounds`	No	Sound effects by id: role, label, seconds, tone, use.
`styles`	No	Finished looks by id: name, blurb, palette, fonts, sounds, music, brief. Apply with op use_style.
`formats`	No	Popular reel formats: id, name, about, values, film (what to shoot), seen_on, parts (role, is).
`pictures`	No	With find_pictures, and nothing else: url, thumb, title, width, height, license, credit, page, source.
`hook_styles`	No	Hook (title) styles by id with their look fields.
`caption_styles`	No	Caption styles by id with their look fields.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 9, 2026

changedOutput schema / properties / music / description

Previous value: -"Music beds by id: label, mood, energy, bpm, seconds, use."New value: +"Music beds by id: label, mood, energy, bpm, seconds, use, credit."

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

Changed6 schema fields changedOct 31, 2026

addedInput schema / properties / find_pictures

Added value: +{
+  "description": "What a real photo should show, in a few plain words. Answers pictures only.",
+  "maxLength": 100,
+  "minLength": 2,
+  "type": "string"
+}

addedOutput schema / properties / logos

Added value: +{
+  "description": "Logos a moment can show as src=\"logo:<id>\".",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / music

Added value: +{
+  "description": "Music beds by id: label, mood, energy, bpm, seconds, use.",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / pictures

Added value: +{
+  "description": "With find_pictures, and nothing else: url, thumb, title, width, height, license, credit, page, source.",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / sounds

Added value: +{
+  "description": "Sound effects by id: role, label, seconds, tone, use.",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / styles

Added value: +{
+  "description": "Finished looks by id: name, blurb, palette, fonts, sounds, music, brief. Apply with op use_style.",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

AddedOct 24, 2026

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context by exposing the scope of returned resources, that find_pictures 'answers pictures only,' and that results carry license and credit. It does not disclose pagination, result limits, or what happens when find_pictures matches nothing.

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

Conciseness2/5

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

The entire definition is a single sprawling sentence that stacks inventory items, an alternate search mode, and follow-up tool routing without paragraph breaks or front-loading. Important framing (that find_pictures switches the tool into a different mode) is buried in the middle rather than led with.

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

Completeness3/5

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

An output schema exists, so the long listing of return values is partly redundant and the description should instead spend its budget on selection guidance. Given a single optional parameter and a two-mode behavior, the missing piece is clear routing versus postkey_list_video_templates and the limits of the picture search.

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 description meaningfully extends it by characterizing find_pictures as 'nouns a camera could photograph' and by noting results include license and credit. That adds interpretive meaning beyond the schema's plain 'What a real photo should show'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description enumerates what the tool surfaces (formats, saved templates, caption/hook styles, fonts, sounds, logos), which implies a list operation, but it never states the verb outright and never mentions the near-identical sibling postkey_list_video_templates or postkey_list_library, so an agent cannot cleanly tell these apart. The large find_pictures sub-mode is also introduced mid-sentence rather than as a distinct capability.

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

Usage Guidelines3/5

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

There is some conditional guidance: pass find_pictures 'to search open libraries for real photos a person may publish instead,' and follow-up routing to postkey_edit_video (op apply_template) or set_captions/set_hook. However, these are downstream actions rather than competing alternatives, and there is no guidance on when to choose this listing over sibling listing tools.

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?