Skip to main content
Glama

Reword an automation

configure_automation
Idempotent

Change a built-in automation message, specific reminder/review variant, or supported SMS/email channel. Read get_automation_overview for actual templates, variants and available_channels first. Omitted fields keep their current values. Changes to an active automation affect future real messages; SMS requires approved setup, active billing and recipient consent. Templates use {{first_name}} and {{business_name}}.

Input Schema

NameRequiredDescriptionDefault
enabledNoAlso switch it on (starts emailing matching customers) or off
messageNoNew message body
site_idYesThe site, from list_sites
subjectNoNew subject line, where it has one
send_viaNoUse only available_channels from the overview; order/return receipts retain email, so both adds SMS
user_goalNoOptional: the user's goal behind this call, in one short sentence of plain words (e.g. "add a page so customers can book tables"). No names, emails or other personal details.
automationYesWhich automation
message_variantNoExact template variant from get_automation_overview; selects the 24h/1h reminder or initial/follow-up review text

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / user_goal
      Added value: +{
      +  "description": "Optional: the user's goal behind this call, in one short sentence of plain words (e.g. \"add a page so customers can book tables\"). No names, emails or other personal details.",
      +  "type": "string"
      +}
  2. Changed2 schema fields changed
    • addedInput schema / properties / message_variant
      Added value: +{
      +  "description": "Exact template variant from get_automation_overview; selects the 24h/1h reminder or initial/follow-up review text",
      +  "enum": [
      +    "default",
      +    "review_initial",
      +    "review_followup",
      +    "reminder_24h",
      +    "reminder_1h"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / send_via
      Added value: +{
      +  "description": "Use only available_channels from the overview; order/return receipts retain email, so both adds SMS",
      +  "enum": [
      +    "email",
      +    "sms",
      +    "both"
      +  ],
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly=false, idempotent=true and destructive=false, so the description does not need to re-establish the safety profile. It still adds valuable context beyond them: changes affect future real messages, SMS requires approved setup, active billing and recipient consent, and unspecified fields are preserved. It does not state what happens to already-queued messages, but the gaps are minor.

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 prerequisite read is front-loaded, followed by the patch semantics and the sending constraints. It is slightly dense with four separate caveats in successive sentences, but every clause carries real information and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter mutation tool with no output schema, the description covers prerequisites, side effects on real customer messages, channel constraints and placeholder format. The main residual gap is response/rollback behaviour, which is not described but is a reasonable omission for an idempotent patch-style update.

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?

With 100% schema description coverage, the baseline is 3, and the description genuinely adds meaning on top of the schema by explaining the template placeholders ({{first_name}}, {{business_name}}) and that variants must come from the overview. These are operational details not fully captured in the parameter descriptions alone.

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 description opens with a specific verb and resource ('Change a built-in automation message, specific reminder/review variant, or supported SMS/email channel'), which lets an agent distinguish it from siblings such as set_automation_enabled or get_automation_overview. The scoping to messages/variants/channels rather than the on/off switch is explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear prerequisite ('Read get_automation_overview for actual templates, variants and available_channels first') and a key behavioural rule ('Omitted fields keep their current values'). It does not name the closest sibling (set_automation_enabled) as an alternative for toggling, leaving the enabled parameter overlap implicit.

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