Skip to main content
Glama
Upload-Post

Upload-Post

Official

Manage automatic DM monitoring

manage_autodms
Destructive

Start, pause, resume, or stop AutoDM monitors that reply to post comments on Instagram, TikTok, YouTube, Facebook, Threads, and Bluesky, with preview and approval before sending.

Instructions

Control AutoDM monitors, which answer every comment on a post (or only those containing trigger_keywords). Instagram answers with a private DM; TikTok, YouTube, Facebook, Threads and Bluesky answer with a public reply under the comment. For action='start', provide profile_username, reply_message and the post (post_url on Instagram; post_id or post_url elsewhere, plus platform). For stop/pause/resume/delete/logs, provide monitor_id. For status, optionally set include_inactive=true. Needs the user's approval: call it first without confirmed to get a preview (nothing is sent), show the user exactly what will go out, and repeat the call with confirmed: true only after they approve.

Input Schema

NameRequiredDescriptionDefault
actionYes
buttonsNoInstagram only, for action='start': up to 3 web_url buttons ({ title, url }) added to each auto-DM.
post_idNoPost to watch on tiktok/youtube/facebook/threads/bluesky (instead of post_url): TikTok video id, YouTube video id, Facebook post id ('{pageId}_{postId}'), Threads post id, Bluesky at:// URI. A TikTok or YouTube URL is also accepted.
platformNoNetwork of the post. Default instagram, which answers with a private DM. tiktok, youtube, facebook, threads and bluesky have no private reply to a comment, so matching comments get a PUBLIC reply under the comment instead.
post_urlNoPost URL to monitor. Required on Instagram when action='start'.
confirmedNoSet to true only after the user has seen the preview this tool returns without it and approved it. Without it nothing is sent.
monitor_idNoAutoDM monitor ID. Required for stop, pause, resume, delete, and logs.
reply_messageNoText sent to matching commenters (a DM on Instagram, a public reply elsewhere). Required when action='start'.
reply_messagesNoPublic replies only: up to 5 alternative texts, rotated across comments so TikTok and YouTube do not see the same reply over and over.
include_inactiveNoFor action='status', include stopped and expired monitors when true.
profile_usernameNoUpload-Post profile name. Required when action='start'.
trigger_keywordsNoOptional keyword or keywords; only comments containing these terms are answered (case and accents ignored).
monitoring_intervalNoMinutes between comment checks for action='start'. Minimum is 15. Instagram and TikTok answer within seconds, so there it only paces a backup check.

Output Schema

NameRequiredDescriptionDefault
resultNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.17.2
    • changedInput schema / properties / buttons / description
      Previous value: -"For action='start': up to 3 web_url buttons ({ title, url }) added to each auto-DM."New value: +"Instagram only, for action='start': up to 3 web_url buttons ({ title, url }) added to each auto-DM."
    • addedInput schema / properties / confirmed
      Added value: +{
      +  "description": "Set to true only after the user has seen the preview this tool returns without it and approved it. Without it nothing is sent.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / monitoring_interval / description
      Previous value: -"Polling interval in minutes for action='start'. Minimum is 15."New value: +"Minutes between comment checks for action='start'. Minimum is 15. Instagram and TikTok answer within seconds, so there it only paces a backup check."
    • addedInput schema / properties / platform
      Added value: +{
      +  "description": "Network of the post. Default instagram, which answers with a private DM. tiktok, youtube, facebook, threads and bluesky have no private reply to a comment, so matching comments get a PUBLIC reply under the comment instead.",
      +  "enum": [
      +    "instagram",
      +    "tiktok",
      +    "youtube",
      +    "facebook",
      +    "threads",
      +    "bluesky"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / post_id
      Added value: +{
      +  "description": "Post to watch on tiktok/youtube/facebook/threads/bluesky (instead of post_url): TikTok video id, YouTube video id, Facebook post id ('{pageId}_{postId}'), Threads post id, Bluesky at:// URI. A TikTok or YouTube URL is also accepted.",
      +  "type": "string"
      +}
    • changedInput schema / properties / post_url / description
      Previous value: -"Instagram post URL to monitor. Required when action='start'."New value: +"Post URL to monitor. Required on Instagram when action='start'."
    • changedInput schema / properties / reply_message / description
      Previous value: -"DM text sent to matching commenters. Required when action='start'."New value: +"Text sent to matching commenters (a DM on Instagram, a public reply elsewhere). Required when action='start'."
    • addedInput schema / properties / reply_messages
      Added value: +{
      +  "description": "Public replies only: up to 5 alternative texts, rotated across comments so TikTok and YouTube do not see the same reply over and over.",
      +  "items": {
      +    "minLength": 1,
      +    "type": "string"
      +  },
      +  "maxItems": 5,
      +  "type": "array"
      +}
    • changedInput schema / properties / trigger_keywords / description
      Previous value: -"Optional keyword or keywords; only comments containing these terms receive a DM."New value: +"Optional keyword or keywords; only comments containing these terms are answered (case and accents ignored)."
  2. Changed2 schema fields changedv0.11.1
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedOutput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  3. Changed1 schema field changedv0.7.0
    • addedInput schema / properties / buttons
      Added value: +{
      +  "description": "For action='start': up to 3 web_url buttons ({ title, url }) added to each auto-DM.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "title": {
      +        "type": "string"
      +      },
      +      "url": {
      +        "format": "uri",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "title",
      +      "url"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 3,
      +  "type": "array"
      +}
  4. First observedv0.4.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only say destructiveHint=true and openWorldHint=true; the description adds the crucial, non-obvious safety mechanism that nothing is sent without confirmed:true and that an unconfirmed call returns a preview. It also discloses a behavior no annotation could convey — Instagram sends a private DM while TikTok, YouTube, Facebook, Threads and Bluesky send a public reply under the comment, which is a materially different side effect per platform.

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

Conciseness5/5

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

Four sentences, each carrying distinct load: what the tool does, platform-specific side effects, per-action parameter requirements, and the approval workflow. The approval rule — the highest-stakes information — is placed last but is short and unambiguous, and no sentence restates the schema or title.

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 13 parameters across seven actions, an output schema already handling return values, and destructive annotations, this description covers everything an agent uniquely needs: the action taxonomy, conditional requirements, platform divergence, and the two-step confirmation gate. No gap remains that would cause a misinvocation.

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 already 92%, so the schema does most of the heavy lifting. The description still adds genuinely new semantics the schema cannot express: conditional, action-dependent required fields (profile_username, reply_message and a post identifier for start; monitor_id for stop/pause/resume/delete/logs) and the platform-specific post identifier rule.

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

Purpose4/5

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

The description gives a concrete verb-plus-resource ('Control AutoDM monitors') and immediately explains the mechanism: answering comments with a DM on Instagram or a public reply elsewhere. That distinguishes it semantically from generic comment tools like reply_to_comment. However, it never acknowledges the many overlapping siblings (start_autodm, pause_autodm, stop_autodm, delete_autodm, get_autodm_logs), so an agent cannot tell from the description alone whether this consolidated tool or those single-action tools should be used.

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?

The per-action parameter contract is explicit: which fields action='start' needs per platform, which actions need monitor_id, and that status accepts include_inactive. The confirmation protocol is spelled out as a concrete sequence (preview first, show the user, re-call with confirmed:true). What's missing is routing guidance against the single-purpose autodm siblings.

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