Forum posts

Do not add a forum-post shortcut that bypasses the capability gate, exact forum-channel allowlist, pinned bot identity, exact stable forum type, complete guild-role and forum-overwrite evidence, exact available and selected tag IDs, required and moderated tag checks, notification policy, process-keyed planning, signed interactive confirmation, write-aware client approval, final fresh-plan match, shared interaction limiter, atomic one-shot operation-key reservation, pending activity journaling, single POST, or exact thread and starter-message readback. If a client cannot support MCP elicitation, keep forum-post execution unavailable in that client.

Keep the surface to one public thread and one plain-text starter message in a stable GUILD_FORUM channel. Do not silently add media channels, files, embeds, components, stickers, fuzzy tag lookup, private or standalone threads, edits, locks, archive actions, pins, tag administration, deletion, retry, rollback, or reconciliation. Each excluded capability needs its own evidence, policy, confirmation, and recovery design.

Require complete VIEW_CHANNEL, READ_MESSAGE_HISTORY, and SEND_MESSAGES evidence on the exact parent forum. Discord ignores CREATE_PUBLIC_THREADS for this operation. Require MANAGE_THREADS whenever any selected exact tag is moderated. Validate the forum's complete bounded overwrite and available-tag arrays, unique IDs, guild identity, REQUIRE_TAG, setting bounds, bot member identity, and complete guild-role inventory before returning a plan.

Suppress every notification by default. Allow only exact user IDs already present as visible mentions in the starter content and separately configured in the notification allowlist. Never enable role, @everyone, or @here notification through this workflow.

Exclude the raw operation key from plan material, signed request state, activity, receipts, results, and errors while binding its domain-separated hash into the plan. The title, starter content, tag IDs and names, notification user IDs, forum name, audit reason, roles, and overwrites may appear in the reviewed plan but must never enter persistent records. Forum-post activity and receipts may contain only exact guild, parent forum, created thread and starter-message IDs, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category.

Discord supplies no nonce or idempotency token for a forum starter message. Keep the MCP execute tool non-idempotent, disable automatic REST retry, and make the key permanently spent once reserved. A transport failure, Discord 5xx response, malformed success, or failure after any valid thread ID is observed is uncertain and must be treated as potentially completed. Never delete a thread as compensation. Require operator inspection of the exact forum and Discord audit log before a new reviewed intent uses a new key.

Serialize the same exact forum and normalized logical title across operation keys inside one process as defense in depth. The production facade also acquires a durable exact forum-channel claim, so connector processes sharing the activity-state root exclude overlapping forum-post creation and retain the claim after uncertainty. Do not imply title uniqueness; Discord permits duplicate titles.

Validate the nested starter message in Discord's create response, then fetch the exact thread and starter message using the shared ID. Require the expected guild, parent, public-thread type, bot owner and author, regular message type, active unlocked state, no webhook, attachment, or component payload, and valid bounded settings. Return only fixed drift-field names when safe readback differs, never observed content.

Canonical source: SECURITY.md