Deletion workflow

1. Use read_messages or get_message to identify exact message IDs.
2. Call plan_message_deletion with one channel, those exact IDs, a Discord audit-log reason, and a unique one-shot operation key.
3. Review the verified application, bot, guild, channel, optional thread parent and membership evidence, every author, message type, timestamp, content preview, attachment filename, complete permission decision, execution strategy, reason, operation-key hash, warning, and keyed plan digest.
4. Call delete_messages with the identical reason, channel, IDs, operation key, and digest.
5. Approve the signed MCP confirmation only if every displayed identity, message, permission, strategy, warning, reason, hash, and digest remains intended.
6. Review the exact absence evidence, activity ID, and outcome before any related write.

Planning fetches each exact message and fails closed on malformed, mismatched, unknown, or Discord-documented non-deletable message types. It proves VIEW_CHANNEL and READ_MESSAGE_HISTORY, plus CONNECT for voice and Stage channels and exact private-thread membership where applicable. A bot-owned ordinary message can be deleted individually without MANAGE_MESSAGES; another author's message, an AutoMod action message, or any bulk request requires MANAGE_MESSAGES. Outstanding plan digests expire with the MCP process and are invalid after a restart. A changed or missing message, author identity, permission source, permission decision, role snapshot, guild or channel name, Message Content intent state, reason, target set, or strategy also invalidates the plan.

The execute call verifies signed request state, rebuilds the complete plan, durably claims every exact message across connector processes sharing the state root, rebuilds the plan again inside that claim, atomically reserves the operation key, and appends pending content-free activity before mutation. Discord does not offer a conditional message-delete operation. The connector performs its final fresh read immediately before deletion, but a message can still be edited or removed in the narrow interval between that read and Discord processing the delete request. Exact IDs prevent a different message from being substituted at the target ID.

Discord's bulk deletion endpoint is used only for two to 100 unique messages safely inside its supported age window and only with complete MANAGE_MESSAGES evidence. The connector deletes every other reviewed message individually and stops bounded individual execution after a failure. Mutation requests are never retried. Exact GET readback must prove every target absent through a 404: an ambiguous mutation followed by complete absence is completed-with-drift, a known failure with some targets remaining is partial, and a failed readback or ambiguous mutation with a surviving target is uncertain. Every reserved key remains spent, and unresolved uncertain work retains its exact durable claims for operator review.

Durable receipts and activity contain only exact Discord identifiers, plan digest, operation-key hash, strategies, timestamps, fixed error codes, outcomes, and observed presence or absence. They never contain message content, attachment filenames or URLs, embeds, components, author profiles or names, guild or channel names, audit reasons, raw operation keys, response bodies, routes, or transport causes.

Canonical source: docs/reference.md