Saypage

Create DM automation

create_automation

Destructive

DM a link to followers who comment keyword on the post: a published page (page_id) or a web address the user gives (url).

These DMs speak in the user's name. Unless they already said what to write or asked you to handle it, consider asking how each message should read: their own words, or drafts you propose in their tone. Confirm the post, keyword and messages with the user before calling this.

The follower gets opening_message and its button, then link_message with the link's button and any extra_link_buttons; with follow_gate, non-followers get follow_request_message instead of the link; with email_gate, the link waits for a reply holding an email address (list_emails). Write every message and button label (20 characters) in the user's language: the defaults are English. Remind the user to put the keyword in the caption.

If activation fails, the automation stays a draft and the result says why: fix that, then activate_automation; never create a second one.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "account_id": "<account_id>",
      "keyword": "<keyword>"
    },
    "name": "create_automation"
  }
}

Input Schema

Name	Required	Description	Default
`url`	No	Or the web address the DM links to, instead of a page
`keyword`	Yes	The word or short phrase followers comment, e.g. GUIDE. Matched in any case, anywhere in the comment, as whole words: 'Recipes please 🙌' triggers RECIPES, 'myrecipes' does not. Accents and emoji must match exactly. Saved in lowercase. Replies count, the account's own comments never do, and the longest matching keyword on a post wins.
`page_id`	No	The published page the DM links to; or give `url` instead
`activate`	No	Turn it on right away
`url_name`	No	With `url`: a short name for it, shown in the user's automations
`account_id`	Yes	From get_account
`email_gate`	No	Ask for their email address before the link (after follow_gate)
`follow_gate`	No	Only send the link to followers of the account
`link_message`	No	The DM that carries the link, sent once the follower taps the first button. Same language and voice as opening_message.	Here it is!
`public_reply`	No	Optional public reply under the comment, e.g. 'Sent you a DM!', or up to 3 to rotate, one per comment
`opening_message`	No	The first DM, sent right after the comment, with a button asking for the link. In the user's language and voice: the wording is theirs to choose.	Thanks for your comment! Want the link?
`link_button_label`	No	The button that opens the page or address. Same language.	Open the page
`provider_media_id`	No	The post (from list_instagram_posts); omit to use the next post
`extra_link_buttons`	No	Up to 2 more buttons on the link message, after the page's button: each opens another published page of the user's site (page_id) or any web address (url), e.g. a shop or a YouTube channel. Same language as the other messages.
`opening_button_label`	No	The first DM's button: tapping it sends link_message. Same language.	Send me the link
`email_request_message`	No	Only used when email_gate is true: the DM asking for their email, which they type in reply. Say what they get and what the address is for. Same language.	Reply with your email address and I'll send you the link!
`follow_request_message`	No	Only used when follow_gate is true: the DM asking a non-follower to follow first. Same language as the other messages.	Follow me first, then tap the button below and I'll send it.
`follow_request_button_label`	No	Only used when follow_gate is true: the button the follower taps once they follow. Same language as the other messages.	I'm following

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 8, 2026

changedInput schema / properties / public_reply / anyOf

Previous value: -[
-  {
-    "maxLength": 400,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maxLength": 400,
+    "type": "string"
+  },
+  {
+    "items": {
+      "maxLength": 400,
+      "type": "string"
+    },
+    "maxItems": 3,
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / public_reply / description

Previous value: -"Optional public reply under the comment, e.g. 'Sent you a DM!'"New value: +"Optional public reply under the comment, e.g. 'Sent you a DM!', or up to 3 to rotate, one per comment"

Changed2 schema fields changedNov 1, 2026

addedInput schema / properties / email_gate

Added value: +{
+  "default": false,
+  "description": "Ask for their email address before the link (after follow_gate)",
+  "title": "Email Gate",
+  "type": "boolean"
+}

addedInput schema / properties / email_request_message

Added value: +{
+  "default": "Reply with your email address and I'll send you the link!",
+  "description": "Only used when email_gate is true: the DM asking for their email, which they type in reply. Say what they get and what the address is for. Same language.",
+  "maxLength": 400,
+  "minLength": 1,
+  "title": "Email Request Message",
+  "type": "string"
+}

First observedOct 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations (destructiveHint, openWorldHint), it discloses the emitted-send semantics ('These DMs speak in the user's name'), the exact message sequence and gating order (opening_message → button → link_message; follow_gate substitutes follow_request_message; email_gate defers the link), and the partial-failure behavior of leaving a draft. It also warns against duplicate creation, which is the practical risk behind destructiveHint.

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-loaded with the action and the link-target choice, then flows, then guardrails — good ordering with no filler sentences. Minor redundancy: the 'same language / defaults are English' instruction appears in the body and again in nearly every parameter description, and the 20-character limit is stated twice in effect.

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 an 18-parameter orchestration tool with an output schema, the description covers the trigger, the message flow, both gates, localization, confirmation etiquette and the failure/recovery path. Nothing an agent needs in order to call it correctly is missing, and return values are rightly left to the output schema.

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 100%, so the baseline is 3; the description still earns more by explaining cross-parameter relationships the schema states only in isolation — the send order of opening_message/link_message/extra_link_buttons and which messages follow_gate and email_gate swap in. The 20-character label limit and the English-default point are restated from the schema, hence not a 5.

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?

Opens with a specific verb, resource and trigger: 'DM a link to followers who comment `keyword` on the post', and immediately names the two link targets (page_id or url). An agent can distinguish this from update_automation, list_automations and activate_automation 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?

Explicit preconditions ('Confirm the post, keyword and messages with the user before calling this') and an explicit when-not path for the failure case: 'If activation fails... fix that, then activate_automation; never create a second one.' It even routes the agent to list_emails for the email gate, so alternatives are named rather than implied.

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

All Saypage 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.