Reviewed thread creation

General thread creation has no immediate-call path. Set capabilities.threadCreation: true and list every eligible parent by its own exact ID in scopes.threadParentIds. The parent allowlist must be a subset of readScope.channelIds when the read allowlist is present. Parent inheritance, guild scope, forum-post scope, and interaction scope never grant this authority.

The strict mode union supports from-message in text or announcement parents and standalone-public or standalone-private in text parents. Every request carries an exact name, audit reason, one-shot operation key, optional supported auto-archive duration, and optional bounded slowmode. Anchored requests require one exact source-message ID and reject invitable; standalone requests reject a source ID; public requests reject invitable; private requests default it to false. Forum and media parents, starter messages, files, tags, notification settings, membership changes, locks, archives, edits, deletion, rollback, and reconciliation are excluded.

Grant the bot View Channel and the mode-specific Create Public Threads or Create Private Threads permission in each selected parent. Message-anchored creation additionally requires Read Message History. Planning validates the exact parent type and guild, source-message identity when applicable, complete bounded guild-role inventory and parent overwrite evidence, verified bot membership, effective permissions, resolved parent defaults, and any already-existing anchored thread.

1. Call plan_thread_creation with one exact mode-specific request.
2. Review the exact guild, parent, source preview when present, existing-thread state, settings, complete permission evidence, warnings, hashed operation key, and keyed digest.
3. Call execute_thread_creation with identical inputs plus the digest.
4. Approve the signed MCP confirmation only if every displayed field and warning remains intended.
5. Review the returned exact thread ID, jump URL, fixed drift fields, readback status, activity ID, and ambiguity-recovery state before any follow-up.

If a source message already owns a valid thread, the plan reports source-already-threaded; execution returns that exact thread without approval, reservation, activity, or mutation, and does not apply the requested name or settings. Otherwise the process-keyed digest binds the application and bot IDs, source snapshot, exact guild, parent, member, roles, overwrites, permissions, resolved settings, audit reason, and domain-separated operation-key hash. The raw key is omitted from the plan and signed request state. A connector restart invalidates the digest.

Before the one and only POST, the connector passes the shared interaction limiter, atomically reserves the key in a private durable receipt, and appends pending content-free activity. A known Discord 4xx rejection before a valid result is recorded as failed. Transport failure, Discord 5xx, malformed success, or readback failure is uncertain. A reserved key remains spent after every outcome, and the connector never automatically retries, edits, deletes, or compensates.

Message-anchored threads have the same ID as their source message. After an ambiguous anchored response, the connector may recover only by fetching that deterministic ID and finding an active, unlocked, exact-setting thread in the exact guild and parent with the verified bot as owner. Standalone threads have no safe deterministic rediscovery key, so an ambiguous outcome permanently blocks the same normalized parent, mode, and logical name in the direct service instance. The production facade also acquires a durable exact parent-channel claim, so connector processes sharing the activity-state root serialize overlapping thread creation and retain the claim after an uncertain outcome.

The reviewed plan may transiently show untrusted guild, parent, thread, and source-message data. Activity and operation receipts contain only fixed outcomes, exact guild, parent, optional source, and created thread IDs, timestamps, activity ID, digest, and operation-key hash. They never contain thread or parent names, source content or profiles, attachment metadata, audit reasons, roles, overwrites, or the raw operation key. See Discord's message-anchored and standalone thread references.

Canonical source: docs/reference.md