Skip to main content
Glama

Manage scheduled messages

manage_scheduled_messages
Destructive

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"

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultNoThe JSON-compatible result returned by the Kaption extension

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (destructive=true, openWorld=true, non-idempotent), it discloses rate limits ('a few messages an hour and a day, minutes apart'), group eligibility (posted within 30 days), 800/2000 char caps, offline-miss behavior, retention ('stays on this device'), and refusal reason codes like '(reason: per-day)'. This is unusually rich operational context.

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?

It is long but front-loads the two modes before the action list and examples, and every section is functional. There is some redundancy between the prose mode description and the repeated per-action notes, but given the 8-action/9-param complexity it stays mostly disciplined.

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 prose. With modes, per-action requirements, limits, failure semantics, and worked examples all covered, an agent has everything needed to select an action and construct a valid call.

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 the baseline is 3, but the description adds value beyond the schema by showing concrete example payloads and mapping mode requirements to specific actions (local needed for groups, delete vs cancel vs remove vs send_now distinctions). It largely restates schema-documented field semantics, hence not a 5.

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 (schedule WhatsApp messages to be sent automatically) and enumerates the eight actions the tool dispatches. No sibling among the listed tools covers scheduled messaging, so it is cleanly distinguishable.

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 contrasts bot vs local mode, states the prerequisites for local mode ('must first be turned on by the user... an assistant cannot turn it on'), and ties each action to a mode constraint via per-action notes. When-to-use and when-not-to-use are both spelled out.

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