Skip to main content
Glama

manage_scheduled_messages

Destructive

Schedule WhatsApp messages to send automatically at a specific time, and manage them by listing, updating, canceling, or sending missed ones.

Instructions

Schedule WhatsApp messages to be sent automatically at a specific time, in one of two modes: bot (default) - sent from Kaption's WhatsApp number, not the user's own. Stored in Kaption's cloud and sent even when this computer is off. One-to-one chats only (no groups); one line, max 800 characters. local ("From this computer") - sent from the user's own WhatsApp number, as them, while this computer and WhatsApp are open. Stays on this device. Kaption keeps it within safe limits automatically (a few messages an hour and a day, minutes apart, only to chats where the other person has written, at most 3 a day to groups) and refuses what does not fit. The only mode that can send to groups (ones the user can post in and posted in within 30 days). Text only. A message whose time passes while this computer is off is missed, never sent late on its own. The local mode must first be turned on by the user in Kaption (its "From this computer" option, after reading the risks); an assistant cannot turn it on. A refused local request says why and ends with a reason code, e.g. "(reason: per-day)".

Actions: list - List scheduled messages of both modes (each has "mode"); pass mode to list only one get - Get a specific scheduled message by ID create - Schedule a new message (requires message + datetime + conversation_id) update - Change the message and/or datetime (requires id) delete - Cancel/delete a scheduled message (requires id); in local mode it cancels a waiting message and removes a finished one cancel - Local mode only: cancel a waiting, missed or failed message remove - Local mode only: remove a finished message from the list send_now - Local mode only: send a missed or failed message now (still within the limits) Pass mode "local" for every action on a local message.

Examples: List all: { action: "list" } Schedule (Kaption bot): { action: "create", message: "Hey, just following up!", datetime: "2026-03-07T09:00:00Z", conversation_id: "5491157390064@c.us" } Schedule from the user's own number: { action: "create", mode: "local", message: "Running 10 min late", datetime: "2026-03-07T09:00:00-03:00", conversation_id: "5491157390064@c.us" } Schedule to a group: { action: "create", mode: "local", message: "Standup moved to 10", datetime: "2026-03-07T09:00:00Z", conversation_id: "120363000000000000@g.us" } Cancel: { action: "delete", id: "msg_abc123" }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoScheduled message ID (required for get/update/delete/cancel/remove/send_now)
modeNo"bot" (default): sent from Kaption's WhatsApp number. "local": sent from the user's own WhatsApp number while this computer and WhatsApp are open, within safe limits kept automatically; needed for groups. For list, omit to get both modes
actionYesScheduled message action to perform (cancel, remove and send_now need mode "local")
filterNoFilter for list action. Default: "pending" (not sent yet; in local mode also missed or failed ones waiting for the user)
messageNoMessage text to send (required for create, optional for update). Bot: one line, max 800 characters. Local: text only, up to 2000 characters
datetimeNoISO 8601 datetime when the message should be sent (required for create, optional for update)
target_sessionNoSession ID for multi-account routing
conversation_idNoChat to send the message to (required for create): a person, or a group with mode "local"
notification_typeNoBot mode only. Notification type. Default: "automatic"

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.6

TDQS

A4.5/5.0
Behavior5/5

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

Despite annotations already flagging destructive/openWorld, the description adds substantial behavioral detail: local-mode rate limits, 'never sent late' semantics, missed/refused request behavior with reason codes, user-only enablement, and per-action cancel/remove distinctions. This is well beyond what annotations or schema convey.

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 text is long but justified for an 8-action, dual-mode tool. Purpose and mode trade-offs are front-loaded, and the action list plus examples each carry distinct information. Some overlap with schema parameter descriptions keeps it from a 5.

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?

With no output schema, the description still covers behavior thoroughly and hints at list/get return shape ('each has "mode"'), plus reason codes. Given the complexity (9 params, 4 enums, 2 modes), it is nearly complete, though it does not describe the structure of list/get results in detail.

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, but the description contributes extra meaning: which parameters each action requires, the mode-per-action constraint ('Pass mode local for every action on a local message'), and concrete example payloads with real values. It reinforces rather than merely repeats the schema.

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 gives a specific verb+resource+scope: scheduling WhatsApp messages for automatic send at a specific time, split into two named modes. An agent can immediately distinguish this from siblings like manage_reminders or manage_chat 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 Guidelines4/5

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

The description gives explicit when-to-use guidance for the bot vs local modes (privacy, off-computer delivery, group support) and states the prerequisite that local mode must be enabled by the user first. It does not, however, compare against sibling tools, so it stops short of a full alternative-routing treatment.

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