Postkey: Instagram DM Automation and Comment-to-DM

List video templates

postkey_list_video_templates

Read-onlyIdempotent

Postkey: Lists the profile's video templates: reusable recipes for a kind of video, each with a name, a description, the blanks it asks for and how often it was used. Read only. An agent cannot start a video from a template, and video editing (Studio) is switched off unless this server turns it on, so do not offer to make a video from one or send the person to Studio. DM automation templates are postkey_list_automation_templates.

Input Schema

Name	Required	Description	Default
`limit`	No	How many to return, 1 to 50. Default 20.
`status`	No	"active" (default): in use. "draft": not finished. "retired": no longer used. "all": every one.

Output Schema

Name	Required	Description
`ok`	Yes	false: refused (isError; code, message, guide_topic, url); no change.
`total`	No	Templates matching the status.
`templates`	No	id, name, description, status, blanks, used, shared_across_accounts.

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

Changed3 schema fields changedOct 24, 2026

changedInput schema / properties / limit / description

Previous value: -"How many to return (1 to 50). Default 20."New value: +"How many to return, 1 to 50. Default 20."

changedInput schema / properties / status / description

Previous value: -"Default active."New value: +"\"active\" (default): in use. \"draft\": not finished. \"retired\": no longer used. \"all\": every one."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "ok": {
+      "description": "false: refused (isError true; code, message, guide_topic, url), nothing changed.",
+      "type": "boolean"
+    },
+    "templates": {
+      "description": "id, name, description, status, blanks, used, shared_across_accounts.",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total": {
+      "description": "Templates matching the status.",
+      "type": "number"
+    }
+  },
+  "required": [
+    "ok"
+  ],
+  "type": "object"
+}

First observedOct 23, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so "Read only" is largely redundant. The description does add genuinely new behavioral context beyond annotations: a template cannot be used to start a video, and Studio/editing is disabled unless the server enables it, which constrains what the agent may promise the user afterwards.

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-loads what the tool returns, then the read-only constraint, then the sibling pointer — a sensible order. Slightly redundant repetition of read-only status already carried by annotations 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?

For a two-parameter, zero-required list tool with annotations and an output schema, nothing material is missing: purpose, contents of each item, disabling conditions, and the sibling alternative are all covered, and return values need not be spelled out because the output schema exists.

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%, with both limit and status fully documented including enum meanings, so the structured data carries the semantics. The description adds nothing about paging or status filtering, which is acceptable at this coverage level but not additive.

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 ("Lists the profile's video templates") and then defines the object as "reusable recipes for a kind of video" with the fields returned (name, description, blanks, usage count). An agent can distinguish this from postkey_list_edit_templates and postkey_list_automation_templates 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?

Explicitly names the alternative for the adjacent use case ("DM automation templates are postkey_list_automation_templates") and adds a clear when-not: do not offer to make a video from a template or route the person to Studio because editing is switched off. That is exactly the routing information an agent needs.

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?