Skip to main content
Glama

Postkey: Instagram DM Automation and Comment-to-DM

DM automation results

postkey_get_automation_stats
Read-onlyIdempotent

Postkey: Reports how the profile's DM automations did: the profile's totals (people who started one, DMs sent, links tapped, click rate), how many automations have each status, and each keyword automation's own counts. The numbers are the DM dashboard's; there is no date filter. Use it for DM results; for post results use postkey_get_post_stats, and for an automation's setup use postkey_get_automation. x_replies lists each X reply automation's replies posted, refused, capped and removed, and x_status.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many keyword automations to list, 1 to 50. Default 20. The totals always cover all of them.

Output Schema

NameRequiredDescriptionDefault
okYesfalse: refused (isError; code, message, guide_topic, url); no change.
noteNoWhere the numbers come from.
totalsNoThe profile's DM totals as the DM service reports them, for example triggered, dms_sent, link_clicks, click_rate.
keyword_automationsNoid, keyword, status and each one's counts.
automations_by_statusNoHow many automations have each status.

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. Changed2 schema fields changed
    • changedInput schema / properties / limit / description
      Previous value: -"How many to return (1 to 50). Default 20."New value: +"How many keyword automations to list, 1 to 50. Default 20. The totals always cover all of them."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "automations_by_status": {
      +      "description": "How many automations have each status.",
      +      "type": "object"
      +    },
      +    "keyword_automations": {
      +      "description": "id, keyword, status and each one's counts.",
      +      "items": {
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "note": {
      +      "description": "Where the numbers come from.",
      +      "type": "string"
      +    },
      +    "ok": {
      +      "description": "false: refused (isError true; code, message, guide_topic, url), nothing changed.",
      +      "type": "boolean"
      +    },
      +    "totals": {
      +      "description": "The profile's DM totals as the DM service reports them, for example triggered, dms_sent, link_clicks, click_rate.",
      +      "type": "object"
      +    }
      +  },
      +  "required": [
      +    "ok"
      +  ],
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description is free to add the one behavior that matters: there is no date filter and the figures are lifetime dashboard totals rather than a queryable window. It goes on to sketch what x_replies and x_status contain, which is somewhat duplicative of the output schema but still useful orientation.

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?

The purpose is front-loaded and the sibling routing is packed tightly into one sentence. The closing sentence enumerating x_replies sub-fields is the weakest link, restating return-value detail the output schema already provides.

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?

With an output schema present, the description need not document return values, yet it does explain the shape of the three result groups and the no-date-filter caveat. Nothing an agent needs to call this correctly is missing, though the x_replies phrasing is slightly garbled and could cause hesitation.

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?

The single parameter has 100% schema coverage that already explains the 1-50 range, the default of 20, and that totals always cover all automations. The description adds nothing about limit or its interaction with the listed counts, so the baseline 3 for high coverage 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?

The first sentence names a specific verb and resource (reports DM automation performance) and enumerates the three result groups: profile totals, per-status automation counts, and per-keyword counts. It also explicitly separates itself from postkey_get_post_stats and postkey_get_automation, so an agent can pick the right sibling 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?

The description gives an explicit routing rule: DM results here, post results in postkey_get_post_stats, and setup details in postkey_get_automation. It also states a real usage constraint (no date filter, numbers come from the DM dashboard), which tells the agent when not to expect time-scoped data.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources