Saypage

Update DM automation

update_automation

Destructive

Change an automation's post, link, keyword, messages or buttons; every omitted field is kept.

Same fields as create_automation. Live automations stay live and the next comment gets the change. To put an automation on another post, such as a new Reel, move it with provider_media_id: it keeps its history and stats, so never delete it and create another. When messages change, the wording is the user's to choose: consider asking them, or offering drafts they can edit. Confirm the new wording with them first, then make every change in one call: an automation can only be updated once every few seconds.

Input Schema

Name	Required	Description
`url`	No	Or a web address to link to
`keyword`	No	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	A published page to link to instead; or give `url`
`url_name`	No	With `url`: a short name for it, shown in the user's automations
`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.
`public_reply`	No	New public reply under the comment; an empty string stops it
`automation_id`	Yes	Automation id
`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.
`link_button_label`	No	The button that opens the page or address. Same language.
`provider_media_id`	No	Move it to this post (from list_instagram_posts)
`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. Replaces the current ones; [] removes them.
`opening_button_label`	No	The first DM's button: tapping it sends link_message. Same language.
`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_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.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 20, 2026

addedInput schema / properties / page_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "A published page to link to instead; or give `url`",
+  "title": "Page Id"
+}

addedInput schema / properties / provider_media_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Move it to this post (from list_instagram_posts)",
+  "title": "Provider Media Id"
+}

addedInput schema / properties / url

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 200,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Or a web address to link to",
+  "title": "Url"
+}

addedInput schema / properties / url_name

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 120,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "With `url`: a short name for it, shown in the user's automations",
+  "title": "Url Name"
+}

First observedOct 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare destructiveHint=true and openWorldHint=true, and the description adds real behavioral context on top: partial semantics (omitted fields retained), that live automations keep running and the next comment receives the change, a rate limit (once every few seconds), and the anti-pattern of deleting and recreating. No statement contradicts the destructive annotation; it clarifies that history and stats survive.

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-loads the core update semantics in the first sentence and stays on-task, but a few sentences drift into soft product advice ("consider asking them, or offering drafts they can edit"). Slightly longer than needed for an agent-facing spec.

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?

An output schema exists, so return values need no explanation. For a 15-parameter destructive mutation the description covers partial-update behavior, rate limiting, live-state effects, and the safe alternative to delete/recreate — everything an agent needs to call it correctly.

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 description coverage is 100%, so parameter meaning is already well documented and the baseline is 3. The description still adds cross-field semantics the schema cannot express: omitted fields are kept, the field set mirrors create_automation, and provider_media_id is a move-with-history operation rather than a plain reference.

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 (Change) and resource (an automation), enumerates the mutable facets (post, link, keyword, messages, buttons), and adds the partial-update rule (omitted fields are kept) that distinguishes it from create_automation/delete_automation. An agent can tell exactly what this does without opening the 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?

Explicitly routes away from the wrong siblings: to move an automation to another post, use provider_media_id rather than delete_automation + create_automation, with the reason given (history and stats are preserved). It also states when to batch changes (one call, because of the update rate) and how to handle message rewording.

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.