Skip to main content
Glama

Add or change a Proactive Messages rule

save_proactive_message
Destructive

Add a Proactive Messages rule, or change one (pass rule_id from list_proactive_messages; fields you leave out keep their value). The chatbot then writes first, live for every visitor at once, when the trigger happens. For a general greeting bubble shown to everyone, use update_widget_settings instead. Pro and Enterprise only. A fixed text shows at once and costs nothing; an AI rule spends one AI reply each time it shows. On phones the message always shows in a bubble. For trigger_type event, the website must send the event in its code: window.Asyntai = window.Asyntai || {}; (window.Asyntai.events = window.Asyntai.events || []).push({ name: 'added_to_cart', data: { product: 'Running shoes' } });

Input Schema

NameRequiredDescriptionDefault
nameNoName only the owner sees, to find the rule in the list.
displayNobubble: a bubble above the chat button. open: the chat opens with the message (on phones it is always a bubble).
enabledNoWhether the rule is on. New rules are on.
rule_idNoId of the rule to change, from list_proactive_messages. Omit to add a new rule.
frequencyNosession: once per visit. visitor: once per visitor. always: every time (never twice within 30 seconds).
website_idNoNumeric id of the website, from list_websites. Omit to use the account's primary website.
message_modeNofixed: the visitor sees message_text exactly. ai: message_text is an instruction and the AI writes the message in the visitor's language.
message_textNoThe fixed text, or the instruction for the AI.
translationsNoFixed text only: language code to translated text, for example {"de": "...", "cs": "..."}. Each visitor sees the text of their browser language, and the main text when there is none. Replaces the whole set.
trigger_typeNoWhen the chatbot writes: event (the website code sends an event name), click (a click on a CSS selector), url (the page address contains a text) or time (seconds on the page).
trigger_valueNoThe event name (for example added_to_cart), the CSS selector (for example #copy-code), the text in the page address (for example /pricing) or the number of seconds (for example 30).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing partial-update semantics ('fields you leave out keep their value'), the AI-credit cost of ai mode, mobile forced-bubble behavior, and the client-side code the site must ship for event triggers. It does not state reversibility or whether an omitted display/enabled resets anything on update, so not quite a 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?

Front-loaded with purpose and the add-vs-update rule, then cost/plan facts, then the code sample. The JavaScript snippet is long but is the only way to convey the event contract; a few clauses (mobile bubble, fixed-vs-AI cost) sit slightly awkwardly mid-paragraph.

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 11-parameter mutation with no output schema, the description covers plan gating, partial-update behavior, cost model, platform rendering differences, and the event-trigger integration requirement. Everything an agent needs before calling is present, with the field-level detail delegated to a fully documented 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 baseline is 3; the description earns extra by explaining the rule_id/omission convention and by giving a concrete event-trigger code sample that defines what trigger_value must contain for trigger_type=event. Other parameter meanings (frequency, display) are left to the schema's own enum docs.

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?

The opening sentence names a specific verb pair (add/change) and the resource (Proactive Messages rule), and immediately differentiates from update_widget_settings for the general-greeting case. An agent can distinguish it from list_proactive_messages and delete_proactive_message 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 routing rules: pass rule_id to change an existing rule, omit it to add a new one (both sourced from list_proactive_messages), and use update_widget_settings instead for a general greeting bubble. It also states the Pro/Enterprise plan prerequisite, which is a hard gate an agent must check.

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