LetsBot

list_store_automations

Read-onlyIdempotent

List every automatic WhatsApp message this workspace sends to its store customers, and whether each one is ON or OFF: order/store event notifications (kind notification_template — e.g. order created, shipped, delivered, per store platform), abandoned-cart reminders (kind cart_reminder, plus older per-store ones as legacy_cart_reminder, read-only) and automation reminders (kind behavioral_reminder — e.g. product viewed, checkout started, ask for a rating after delivery). Each row has id, kind, platform, event, delay (for reminders), template info (type, languages, Meta category and approval status on an official number), active, can_toggle, last_sent_at and warnings explaining why an active message might not actually send. Also returns which stores are connected. Use it before set_store_automation_active (which needs kind + id) and to answer "which automatic messages are on?". It does NOT change anything, show message text, edit templates or send test messages.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_store_automations"
  }
}

Input Schema

Name	Required	Description
`kind`	No	Optional: only this kind of automation.
`active`	No	Optional: true = only those switched ON, false = only those switched OFF.
`platform`	No	Optional: only automations for this store platform (e.g. salla, zid, shopify, woocommerce).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover read-only, idempotent, non-destructive behavior, but the description adds substantial context: each row includes warnings explaining why an active message might not actually send, can_toggle, last_sent_at, template approval status, and connected stores. It also clarifies legacy cart reminders are read-only.

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 description is front-loaded and appropriately detailed for a complex list tool with no output schema. It is slightly dense with parenthetical examples and field enumeration, but nearly every sentence earns its place by clarifying scope, output contents, or usage.

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?

Given the tool has no output schema and three optional filters, the description is complete enough: it explains the returned row fields, connected stores, warnings, and read-only limitations. An agent has what it needs to call it correctly and understand the result shape.

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 the schema already documents kind, active, and platform. The description adds useful meaning to the kind enum by naming notification_template, cart_reminder, legacy_cart_reminder, and behavioral_reminder with examples and a read-only note for legacy cart reminders.

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 states a specific verb and resource: listing every automatic WhatsApp message a workspace sends to store customers, including whether each is ON or OFF. It distinguishes itself from siblings like set_store_automation_active by clarifying it only reads and never changes anything.

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?

It explicitly says to use this before set_store_automation_active, which needs kind + id, and to answer 'which automatic messages are on?'. It also names exclusions: it does not change anything, show message text, edit templates, or send test messages.

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

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

Resources

Need Help?