Kaption WhatsApp

send_message

Destructive

Queue a WhatsApp message from this computer for the earliest permitted delivery. Requires the owner-only MCP_LOCAL_SEND flag, Rust core, and user consent in Kaption. Supports an existing person chat or eligible group (@g.us) and one image, document, audio or video attachment (8 MiB max). Message is optional with an attachment; audio cannot have captions. Returns queued plus a schedule ID, not proof of delivery. Existing ask-first prompts, 8/hour, 20/day, group limits and delays apply. An assistant cannot accept consent or confirmation. Computer and WhatsApp must remain open. Use manage_scheduled_messages with mode local to inspect or cancel the returned ID.

Input Schema

Name	Required	Description
`message`	No	Message or attachment caption; omit for attachment-only sends
`attachment`	No	Exactly one attachment source: dataB64 or uploaded ref (paths are never accepted); max 8 MiB. Requires MCP_LOCAL_SEND and local delivery
`target_session`	No	Session ID for multi-account routing
`conversation_id`	Yes	Existing person chat ID or eligible group ID ending @g.us

Output Schema

Name	Required	Description	Default
`result`	No	The JSON-compatible result returned by the Kaption extension

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 13, 2026

removedInput schema / properties / attachment / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / attachment / anyOf

Added value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "dataB64": {
+        "description": "Standard padded base64 bytes, without a data URL prefix",
+        "maxLength": 11184812,
+        "minLength": 4,
+        "pattern": "^[A-Za-z0-9+/]*={0,2}$",
+        "type": "string"
+      },
+      "mime": {
+        "description": "MIME type, e.g. image/png, application/pdf, audio/ogg, video/mp4",
+        "maxLength": 200,
+        "minLength": 3,
+        "type": "string"
+      },
+      "name": {
+        "description": "Filename without a path",
+        "maxLength": 200,
+        "minLength": 1,
+        "pattern": "^[^\\\\/\\x00-\\x1f\\x7f]+$",
+        "type": "string"
+      },
+      "size": {
+        "description": "Decoded byte count (maximum 8 MiB)",
+        "maximum": 8388608,
+        "minimum": 1,
+        "type": "integer"
+      }
+    },
+    "required": [
+      "name",
+      "mime",
+      "size",
+      "dataB64"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "ref": {
+        "description": "One-time attachmentRef returned by create_attachment_upload after PUT of the bytes",
+        "pattern": "^[a-f0-9]{64}$",
+        "type": "string"
+      }
+    },
+    "required": [
+      "ref"
+    ],
+    "type": "object"
+  }
+]

changedInput schema / properties / attachment / description

Previous value: -"One inline attachment; requires the owner-only MCP_LOCAL_SEND flag and local delivery"New value: +"Exactly one attachment source: dataB64 or uploaded ref (paths are never accepted); max 8 MiB. Requires MCP_LOCAL_SEND and local delivery"

removedInput schema / properties / attachment / properties

Removed value: -{
-  "dataB64": {
-    "description": "Standard padded base64 bytes, without a data URL prefix",
-    "maxLength": 11184812,
-    "minLength": 4,
-    "pattern": "^[A-Za-z0-9+/]*={0,2}$",
-    "type": "string"
-  },
-  "mime": {
-    "description": "MIME type, e.g. image/png, application/pdf, audio/ogg, video/mp4",
-    "maxLength": 200,
-    "minLength": 3,
-    "type": "string"
-  },
-  "name": {
-    "description": "Filename without a path",
-    "maxLength": 200,
-    "minLength": 1,
-    "pattern": "^[^\\\\/\\x00-\\x1f\\x7f]+$",
-    "type": "string"
-  },
-  "size": {
-    "description": "Decoded byte count (maximum 8 MiB)",
-    "maximum": 8388608,
-    "minimum": 1,
-    "type": "integer"
-  }
-}

removedInput schema / properties / attachment / required

Removed value: -[
-  "name",
-  "mime",
-  "size",
-  "dataB64"
-]

removedInput schema / properties / attachment / type
```
Removed value: -"object"
```

AddedOct 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: 8/hour and 20/day throttles, group limits and delays, ask-first prompts, the fact that an assistant cannot accept consent or confirmation, and that a successful call returns 'queued plus a schedule ID, not proof of delivery.' These are exactly the operational facts (rate limits, auth/consent needs, delivery semantics) the destructiveHint/openWorldHint annotations cannot 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?

Front-loaded with the purpose first, then prerequisites, capabilities, limits, and the hand-off tool. It is dense and several sentences are run-ons, but nearly every clause carries a constraint an agent needs, so little is wasted.

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 a non-idempotent, destructive, open-world send operation, the description covers preconditions, consent boundaries, media limits, throttles, lifetime requirements (computer and WhatsApp stay open), and return semantics. With an output schema already present, nothing further is needed.

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 real constraints beyond the schema: exactly one attachment, the allowed media classes (image/document/audio/video), the 8 MiB ceiling, that message is optional when an attachment is present, and that audio cannot have captions. The attachmentRef flow is only described in the schema, which caps this at 4.

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?

States a specific verb and resource ('Queue a WhatsApp message from this computer for the earliest permitted delivery') and immediately scopes the supported targets (existing person chat or eligible @g.us group). An agent can distinguish this from every sibling without opening a schema, and the 'queue' framing is materially more precise than a generic 'send'.

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?

Gives concrete preconditions (owner-only MCP_LOCAL_SEND flag, Rust core, user consent in Kaption, computer and WhatsApp must remain open) and explicitly routes follow-up work to 'manage_scheduled_messages with mode local' for inspection or cancellation. It never states a when-not-to-use case, so it falls short of the explicit exclusion bar, but the routing and prerequisites are clear.

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

All Kaption WhatsApp 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?