Skip to main content
Glama

Create a comment-to-DM automation

create_comment_to_dm
Destructive

Instagram and Facebook only: when someone comments a keyword on a post (or replies to a story), the connected account automatically sends that person one private reply with what they asked for. It is created ACTIVE and answers every matching comment from then on, so confirm with the user the accounts, the posts, the keyword and the messages first; turn it off with set_automation_active. Meta allows exactly ONE message after a comment (text plus up to 3 buttons, no media): media, a second message or asking for data need the person to reply first, which is what welcomeMessage/requireFollow are for. On Facebook only comments from personal profiles get a private reply (never ones made as a Page), so the user must test from a personal profile (on Instagram, from another account). Write it for THIS post: message says what they get and why it is worth it, each button names the thing ("Get the guide", never "Open" or "Click here") and its url is the exact page that delivers it (ask the user if you do not know it). Before creating one, read get_working_rules("comment-to-dm"): what a good one looks like, the scopes and post links.

Input Schema

NameRequiredDescriptionDefault
nameYes
tagsNoTags added to the contact, silently.
scopeNoWhich posts it watches: "any" = every post; "next" = the next post actually PUBLISHED (a draft or a scheduled post does not claim it); "existing" = the posts in `postIds`; "scheduled" = one unpublished Ignix post (`scheduledPostId`), answered once THAT post goes out. For a post not out yet, offer "scheduled" first (tie it to its draft, or create the draft now); only a post published outside Ignix needs "next" or "existing". Details: get_working_rules("comment-to-dm").
askKindNoAsk for an email or a phone before delivering (lead magnet pattern).
buttonsNoLink buttons on the delivered message, [{"title":"Get the guide","url":"…"}]: every URL goes here, never in `message`. Where buttons cannot render, Ignix appends them as text.
messageYesThe direct message they receive: text ONLY, never the URL (it goes in `buttons`; putting it in both shows it twice).
postIdsNoRequired for scope "existing": the post URLs (https://www.instagram.com/reel/ABC123/) or native ids; Ignix resolves them. Do not fetch the URL yourself (Instagram blocks it).
carouselNoA carousel instead of a message: [{title, subtitle, imageUrl, buttons:[{title,url}]}]. Not with mediaUrl.
keywordsNoWords that trigger it. Empty = any comment.
mediaUrlNoAttachment sent with the delivery.
mediaTypeNoimage
accountIdsYesInstagram/Facebook accounts it applies to.
askMessageNoHow you ask for it.
sequenceIdNoDrip sequence to enrol them in. From list_sequences.
varyWithAiNoAI-worded variants of every message (same meaning, links and codes) so each person gets a different copy. Needs AI on in the plan; otherwise ignored.
publicReplyNoOptional public reply to the comment ("check your DMs!").
triggerKindNo"story" reacts to story replies: they arrive as a DM, so the 24h window is open and nothing is restricted.comment
askFieldSlugNoContact field where it is stored. From list_custom_fields.
askRetryTextNoSent when what they typed is not valid.
followButtonsNoLink buttons on the gate, e.g. [{"title":"See profile","url":"…"}].
followMessageNoMessage of the follow gate.
oncePerPersonNoDefault true on comments: no second DM to the same person (repeats get accounts restricted by Meta). false only if the user asks.
requireFollowNoInstagram only: ask for a follow before delivering, again until they follow. Also opens the 24h window.
idempotencyKeyNoOptional. A unique id for this action (16-128 chars: letters, digits, _ : . -). If you are unsure whether a call went through (timeout, network error), repeat it with the SAME idempotencyKey and the same arguments: you get the original result and nothing is done twice.
welcomeButtonsNoButton labels for the welcome. Tapping one opens the window and moves on.
welcomeMessageNoOpening message with a button; it opens Meta's 24h window. Without it (or requireFollow), no media, carousel or asking for data on a comment trigger.
scheduledPostIdNoRequired for scope "scheduled": the Ignix id of the unpublished post (create_post `post.id` or list_posts). Its accounts must include accountIds; deleting the post deletes the automation.
followReplyLabelsNoLabels that trigger the follow check, e.g. ["I already follow you"].
publicReplyVariantsNo2-3 alternative wordings of the public reply; one is picked per comment.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changed
    • changedInput schema / properties / buttons / description
      Previous value: -"Link buttons on the delivered message, e.g. [{\"title\":\"Buy\",\"url\":\"…\"}]. THIS is where every URL goes — do not repeat it in `message`. On Instagram, Facebook, Telegram and WhatsApp they render as tappable buttons; everywhere else Ignix appends them as \"title: url\" text automatically, so the link always arrives either way."New value: +"Link buttons on the delivered message, [{\"title\":\"Get the guide\",\"url\":\"…\"}]: every URL goes here, never in `message`. Where buttons cannot render, Ignix appends them as text."
    • changedInput schema / properties / carousel / description
      Previous value: -"Deliver a carousel instead of a message: [{title, subtitle, imageUrl, buttons:[{title,url}]}]. Mutually exclusive with mediaUrl — a carousel IS the message."New value: +"A carousel instead of a message: [{title, subtitle, imageUrl, buttons:[{title,url}]}]. Not with mediaUrl."
    • changedInput schema / properties / message / description
      Previous value: -"The direct message they receive. Write the text ONLY — never paste the URL in here. The link belongs in `buttons`, and Ignix already appends it as text on the networks that cannot render buttons. Putting it in both shows it twice."New value: +"The direct message they receive: text ONLY, never the URL (it goes in `buttons`; putting it in both shows it twice)."
    • changedInput schema / properties / oncePerPerson / description
      Previous value: -"Default true on comment triggers: someone who comments the keyword again does not get another DM (repeating the same DM to the same person is what gets accounts restricted by Meta). Set false only if the user explicitly wants repeat DMs."New value: +"Default true on comments: no second DM to the same person (repeats get accounts restricted by Meta). false only if the user asks."
    • changedInput schema / properties / postIds / description
      Previous value: -"Required when scope is \"existing\": the posts it watches. Paste the post URL — https://www.instagram.com/reel/ABC123/ — and it is resolved against the account's real posts. A native post id works too. Do NOT try to fetch the URL yourself: Instagram blocks it, and the code in the link is not the id the webhook sends. list_posts only knows posts created from Ignix, so a Reel published from the phone will not be there."New value: +"Required for scope \"existing\": the post URLs (https://www.instagram.com/reel/ABC123/) or native ids; Ignix resolves them. Do not fetch the URL yourself (Instagram blocks it)."
    • changedInput schema / properties / publicReplyVariants / description
      Previous value: -"Alternative wordings for the public reply; one is picked per comment so the answers read naturally. They do not change platform permissions, messaging limits or who receives the message."New value: +"2-3 alternative wordings of the public reply; one is picked per comment."
    • changedInput schema / properties / requireFollow / description
      Previous value: -"Demand a follow before delivering. It loops: if they still do not follow, the message is sent again. Instagram only. Also opens the 24h window."New value: +"Instagram only: ask for a follow before delivering, again until they follow. Also opens the 24h window."
    • changedInput schema / properties / scheduledPostId / description
      Previous value: -"Required when scope is \"scheduled\": the Ignix id of the unpublished post (create_post's `post.id`, or the id list_posts shows for a draft). The automation accounts must be among that post's accounts. If the post is deleted, the automation is deleted with it."New value: +"Required for scope \"scheduled\": the Ignix id of the unpublished post (create_post `post.id` or list_posts). Its accounts must include accountIds; deleting the post deletes the automation."
    • changedInput schema / properties / scope / description
      Previous value: -"Which posts it watches. \"any\" = every post, present and future. \"next\" = the next post that gets PUBLISHED after this is saved (it waits for the publish event and then pins itself to that post — a draft or a scheduled post does NOT claim it, only actual publication does). \"existing\" = the specific posts in `postIds`. \"scheduled\" = ONE Ignix post that is not published yet (a draft or a scheduled post: one you create now with create_post, or one already in Ignix — saved by Ignix Creator or Editor, or found with list_posts), given in `scheduledPostId`: the automation starts answering when THAT post goes out, and no other post can claim it. For a post that is not out yet, offer \"scheduled\" FIRST: if it is already a draft in Ignix, tie the automation to that draft; if not, create it as a draft (create_post, no date) and tie it now — nothing else can take it and the person does not have to come back. Only when they will publish it outside Ignix (from the phone, for example to use a trending sound) does it need \"next\" or \"existing\" once they send the post link; say that publishing outside Ignix is what rules the draft out."New value: +"Which posts it watches: \"any\" = every post; \"next\" = the next post actually PUBLISHED (a draft or a scheduled post does not claim it); \"existing\" = the posts in `postIds`; \"scheduled\" = one unpublished Ignix post (`scheduledPostId`), answered once THAT post goes out. For a post not out yet, offer \"scheduled\" first (tie it to its draft, or create the draft now); only a post published outside Ignix needs \"next\" or \"existing\". Details: get_working_rules(\"comment-to-dm\")."
    • changedInput schema / properties / triggerKind / description
      Previous value: -"What starts it. \"story\" reacts to story replies instead of comments, and it already arrives as a direct message, so the 24h window is open from the start and nothing below is restricted."New value: +"\"story\" reacts to story replies: they arrive as a DM, so the 24h window is open and nothing is restricted."
    • changedInput schema / properties / varyWithAi / description
      Previous value: -"Generate AI variants of every message so each person receives a differently worded copy (same meaning, same links and codes). Needs AI enabled for this workspace in its plan (the account owner can turn it on by opening the Ignix app); otherwise it is silently ignored."New value: +"AI-worded variants of every message (same meaning, links and codes) so each person gets a different copy. Needs AI on in the plan; otherwise ignored."
    • changedInput schema / properties / welcomeMessage / description
      Previous value: -"Opening message with a button. THIS IS WHAT OPENS META'S 24h WINDOW: without it (or without requireFollow) media, carousel and asking for data are not allowed on a comment trigger."New value: +"Opening message with a button; it opens Meta's 24h window. Without it (or requireFollow), no media, carousel or asking for data on a comment trigger."
  2. Changed2 schema fields changed
    • changedInput schema / properties / publicReplyVariants / description
      Previous value: -"Extra public replies; one is picked at random per comment, so it does not look automated."New value: +"Alternative wordings for the public reply; one is picked per comment so the answers read naturally. They do not change platform permissions, messaging limits or who receives the message."
    • changedInput schema / properties / varyWithAi / description
      Previous value: -"Generate AI variants of every message so each person receives a differently worded copy (same meaning, same links and codes). Needs an AI seat in the workspace (Inferno or the AI add-on); otherwise it is silently ignored."New value: +"Generate AI variants of every message so each person receives a differently worded copy (same meaning, same links and codes). Needs AI enabled for this workspace in its plan (the account owner can turn it on by opening the Ignix app); otherwise it is silently ignored."
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations declare destructiveHint=true and idempotentHint=false, and the description goes well beyond them: it discloses that the automation is created active, Meta's one-message-per-comment limit (text plus up to 3 buttons, no media), the Facebook personal-profile vs Page caveat, and that media or data requests require a prior reply/welcomeMessage. It does not spell out required scopes or error modes itself, deferring those to get_working_rules, which leaves a small gap but no contradiction with the annotations.

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?

It is front-loaded with what the tool does and what to confirm before calling, which is right for a 29-parameter tool. It is dense but mostly earns its length; the only waste is repeating the get_working_rules pointer at the end after introducing it in the prior sentence.

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 high-stakes mutation with 29 parameters and no output schema, the description covers the creation lifecycle, platform constraints, the confirmation workflow, scope selection guidance, and where to look for deeper rules. An agent has everything needed to decide whether to call it and how to prepare the arguments correctly.

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 93%, so the schema already documents nearly every parameter, including the message/buttons URL split and the scope enum meanings. The description mainly echoes that guidance ('message says what they get', buttons name the thing and carry the exact url) rather than adding new parameter semantics, so the baseline of 3 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?

States a specific verb and resource ('comment-to-DM automation') plus the exact trigger and action: a keyword comment or story reply causes one private reply. It scopes the tool to Instagram and Facebook and distinguishes it from generic siblings like create_automation and create_welcome_message by describing the activation lifecycle ('created ACTIVE and answers every matching comment').

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?

Gives explicit preconditions ('confirm with the user the accounts, the posts, the keyword and the messages first'), an explicit alternative for switching off ('turn it off with set_automation_active'), and a required reading step ('Before creating one, read get_working_rules("comment-to-dm")'). It even routes the agent among scope choices by recommending 'scheduled' first for unpublished posts.

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