Skip to main content
Glama
Upload-Post

Upload-Post

Official
by Upload-Post
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Manage automatic DM monitoring

manage_autodms
Destructive

Manage Instagram AutoDM monitors: start, stop, pause, resume, delete, and check status or logs for automated direct messages.

Instructions

Control Instagram AutoDM monitors. For action='start', provide post_url, reply_message, and profile_username. For stop/pause/resume/delete/logs, provide monitor_id. For status, optionally set include_inactive=true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYes
buttonsNoFor action='start': up to 3 web_url buttons ({ title, url }) added to each auto-DM.
post_urlNoInstagram post URL to monitor. Required when action='start'.
monitor_idNoAutoDM monitor ID. Required for stop, pause, resume, delete, and logs.
reply_messageNoDM text sent to matching commenters. Required when action='start'.
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 receive a DM.
monitoring_intervalNoPolling interval in minutes for action='start'. Minimum is 15.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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#"
  2. 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"
+}
  3. First observedv0.4.0

TDQS

A4/5.0
Behavior4/5

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

Annotations indicate destructiveHint=true slash readOnlyHint=false, which suggests state-changing behavior, but the description does not contradict that. It adds value by specifying that some actions (delete) are destructive and others (pause, resume) are state changesholistic. It does not detail the response format, but output schema exists, and the annotations already signal non-read-only nature. However, it could have warned that 'delete' is irreversible, so it's not a full 5.

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 description is compact and front-loaded with the main purpose. The action-to-parameter mapping is useful and in one sentence. It could be slightly more structured (e.g., bullet points) for scanning, but it is efficient and clear.

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?

Given the tool's complexity (9 params, multiple actions, output schema exists), the description covers the critical action-parameter relationships. However, it omits information about the operation's side effects (e.g., whether starting a monitor immediately begins polling, or how logs are returned). It is adequate for basic usage but leaves gaps for an agent to infer.

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 high (89%), meaning most parameters already have descriptions. The tool description adds a small amount of value by mapping actions to required parametersholistically, but it largely restates what the schema already says. No new parameter semantics or examples are given, so this is a baseline 3.

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 clearly identifies the tool as controlling Instagram AutoDM monitors and enumerates the possible actions. It differentiates from sibling tools by focusing on DM automation rather than post management or user management. However, it does not explicitly name a sibling to distinguish from, so it loses a point.

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 provides clear action-specific parameter requirements: for 'start' you need post_url, reply_message, profile_username; for stop/pause/resume/delete/logs you need monitor_id; for status you may set include_inactive. This is explicit and practical, guiding the agent directly on which parameters to supply for each action.

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

Deploy Server

Other Tools