Safety model

Getting started and first verified read | Migration from another Discord MCP | Product boundaries and host compatibility | Privacy policy | Project overview

GuildControl MCP is a local stdio Model Context Protocol server that lets compatible MCP clients inspect Discord guilds, exact allowlisted one-to-one private messages, current-application command exposure, privacy-bounded guild profiles, complete obfuscation-safe channel layouts, named guild settings, time-bounded guild incident actions, exact channel metadata and transient voice-channel status, complete ordered forum tags, roles, threads, forums, message pins, exact-message direct replies, directed coordination notes, privacy-safe reaction aggregates, native polls, privacy-safe guild integrations, application-owned emojis, guild emojis, stickers, soundboard sounds, AutoMod rules, scheduled events, active Stage instances, exact member voice state, guild onboarding, Welcome Screens, authenticated widget settings, guild bans, and guild vanity URL state, credential-redacted webhooks and announcement subscriptions, capability-safe guild invites and native Guild Templates, channel permission overwrites, effective permissions, privacy-minimized members and guild audit history, and indexed message history through a dedicated bot. It includes exact member and role permission diagnostics, bounded channel-role access audits, exact-tool progressive discovery, risk-separated toolsets, portable non-secret multi-bot profiles, an optional privacy-safe real-time Gateway feed, optional exact-scope native Discord Interaction ingress with authenticated request Buttons, privacy-safe local and OpenTelemetry observability, privacy-tiered MCP resources, validated read-only and plan-only prompts, a credential-safe operator CLI, compact bounded search, a model-neutral exact-message and directed-note coordination playbook, safe idempotent message interactions, reviewed exact-recipient private-message plain-text or static Components V2 send, reply, same-format edit, deletion, and receipt verification, reviewed Components V2 and remote-free rich-embed creation and editing, opt-in reaction-user and scheduled-event-subscriber audits, reviewed reaction moderation, reviewed native command management, reviewed policy-justified privileged-intent enablement, reviewed test-entitlement creation and receipt-proven deletion, reviewed externally fulfilled consumable-entitlement consumption, reviewed native poll creation and irreversible ending, reviewed exact announcement crossposts, reviewed immutable message forwarding, reviewed announcement subscribe and exact-ID unsubscribe operations, reviewed Guild Template lifecycle, guild-integration deletion, sparse guild-profile text, named guild-settings changes, time-bounded guild incident-action changes, forum-tag, application-emoji, guild-expression, soundboard, AutoMod, scheduled-event, Stage-instance, complete onboarding, complete ordered Welcome Screen, authenticated widget-settings, member nickname, member verification-bypass, member-role, member voice, and exact thread lifecycle and membership administration, reviewed credential-safe webhook creation, rename, move, and deletion, credential-private webhook message reads, idempotent plain-text delivery and editing, and signed exact-message deletion, capability-safe invite revocation, reviewed message pin, channel metadata, voice-channel status, channel ordering, exact channel and standard-role retirement, atomic same-guild channel cloning, channel permission overwrite, exact standard-role configuration, and exact relative role-order changes, reviewed local-file attachment messages, reviewed forum posts, reviewed message-anchored and standalone public or private thread creation, caller-retained declarative guild blueprints, resumable additive guild scaffolds, reviewed additive channel and role creation, exact reviewed message deletion, exact reviewed member moderation, reviewed native bulk guild bans, bounded reviewed non-exact guild pruning, and content-free local activity records.

Live guild-blueprint capture adds a privacy-minimized two-pass authoring and same-guild recovery aid without creating a connector-side snapshot or backup journal.

Reviewed exact guild departure is independently disabled, separately allowlisted, and isolated in its own toolset. It verifies complete membership and non-ownership evidence, requires explicit consequence and quiescence acknowledgments, and accepts success only after complete target-absence readback.

The connector treats Discord permissions as its outer boundary and adds local policy inside that boundary.

• Production requests always target Discord API v10 at a fixed origin
• Direct-message channels are rejected
• Discord names, topics, forum tags, thread names, message bodies, embeds, components, filenames, and URLs are treated as untrusted data rather than instructions
• The leading MCP instruction preamble keeps exact scope, untrusted-data, exact-ID targeting, direct-write boundaries, reviewed approval, no-retry, and policy-refusal rules together before domain detail, so clients that present only a bounded prefix retain the cross-tool contract
• Resource discovery is content-free; live resource templates require exact IDs and never enumerate messages
• Prompt rendering validates literal inputs without contacting Discord or invoking a service method, and reviewed write prompts stop after read-only planning
• Credential-free catalog mode advertises the exact production tools, prompts, resources, and templates while a fixed guard rejects every tool call before argument validation or execution
• Full mode advertises every configured canonical tool so clients with native deferred-tool search retain exact tool identity, schemas, annotations, and approvals
• Progressive mode starts with one local discovery tool and reveals matching canonical tools through standard notifications/tools/list_changed events; it never uses a generic execution dispatcher
• Operational tool calls with a client-provided MCP progress token emit only fixed request-round start and finish progress; notifications contain no tool name, input, result, status, error, identifier, count, timing, credential, or plan data, while calls without a token emit no progress
• MCP request cancellation propagates through canonical handlers into abortable connector service, REST, and Gateway work; an aborted round emits no finish progress and the protocol sends no later tool response
• Every canonical plan_* tool remains model-visible and links to one optional display-only MCP App resource; the app exposes no app-callable tool, approval action, execution action, or alternate write path
• Toolsets separate plain-message writes, reactions and static Components V2, directed coordination routing, the member directory, guild ban audit, native bulk bans, guild prunes, member nickname changes, member verification-bypass changes, member-role changes, member voice moderation, thread governance, guild audit logs, permission diagnostics, guild profiles, named guild settings, guild Community state, guild incident actions, application privileged-intent enablement, channel metadata and voice-channel status changes, channel-order audit and changes, channel-clone audit and changes, forum-tag audit and changes, channel permission overwrites, message pins, announcement crossposts, message forwarding, static rich-embed messages, announcement subscriptions, native polls, native Interaction ingress and command management, Guild Templates, guild integrations, application-owned emojis, guild expressions, soundboard sounds, AutoMod rules, scheduled events, Stage instances, guild onboarding, Welcome Screens, authenticated widget settings, credential-safe webhook administration and private webhook messages, invite and vanity URL audit and invite revocation, attachments, forum posts, guild blueprints, guild scaffolds, channel creation, role creation, role configuration, role deletion, role ordering, message deletion, and moderation from ordinary reads, cannot expand Discord policy, and remove unavailable tools from both direct calls and discovery results
• Canonical registration checks toolset membership before invoking the MCP SDK and materializes each selected schema graph on demand; excluded tools retain no callable or discoverable handle and avoid eager schema-conversion cost without changing the full catalog contract
• The linked-roles toolset exposes only the complete application linked-role schema plan and execute pair; it grants no audit, guild-role, user-value, or other application authority
• The application-monetization toolset exposes only exact-beneficiary entitlement and exact-user subscription-lifecycle reads; it grants no purchaser enumeration, commerce mutation, SKU mutation, or access authority
• Every redacted application read result has one lossless UTF-8 byte budget; an oversized value is withheld whole without a partial JSON fragment, preview, spill file, result cache, digest, or measured-size disclosure, while every final mutation-capable result remains visible
• An exact guild allowlist forms the required outer read boundary, and an optional channel allowlist can narrow access inside it
• Portable profiles store the same complete policy as standalone configuration files while referring to a caller-owned environment or file credential without storing its value
• Deterministic setup presets resolve common read-only intents into exact guild and channel scope plus catalog-verified read-only tools; they cannot enable writes, Gateway access, telemetry export, or activity persistence
• Profile activation loads the complete saved document directly as the exclusive policy boundary, resolves only its exact secret references, and rejects ambient connector or telemetry policy
• Profile files are private, bounded, canonical, single-link records written atomically; removal moves one exact profile to recoverable private trash instead of deleting it
• Threads inherit local read scope from an allowlisted parent, while native search requests are attenuated to exact allowlisted channel IDs
• Gateway access is disabled by default. Real-time events require expected application and bot IDs plus an exact guild or channel read allowlist; channel ordering, channel cloning, Guild Template audit, guild-settings audit, guild Community audit, onboarding audit, and member-role changes can independently activate a layout-only connection for their exact guild scopes
• Startup resolves channel-only and voice-status scope to exact guilds before any socket opens, derives the unique required shard IDs under Discord's recommended total, and opens no shard solely for non-guild traffic. Readiness requires every selected shard, while status exposes only aggregate topology counts
• The Gateway requests only the nonprivileged GUILDS, GUILD_MESSAGES, GUILD_MESSAGE_REACTIONS, and GUILD_MESSAGE_POLLS intents for its event feed, adds the standard GUILD_VOICE_STATES intent only for exact-scope soundboard playback corroboration, uses no content-bearing Discord client cache, and immediately reduces event-feed dispatches, including soundboard and Stage-instance lifecycle events, to scoped identifiers and fixed event kinds
• The Gateway keeps an atomic process-local direct-channel layout for the exact union of event-feed, channel-ordering, channel-deletion, role-deletion, channel-cloning, Guild Template, guild-settings, guild Community, onboarding, and member-role guild scopes, containing only ID, type, raw position, parent ID, and the explicit obfuscation bit; channel-only read scope never activates complete-layout retention
• Channel-completeness consumers bracket one bounded HTTP inventory pass with identical complete Gateway layouts, accept only a complete HTTP inventory or its exact non-obfuscated subset, discard metadata for obfuscated channels, and expose only count-based completeness evidence
• Gateway events and layouts remain process-local; content, names, topics, permission overwrites, profile data, emoji, URLs, raw payloads, session IDs, sequence numbers, and resume URLs are never returned through the layout source or persisted
• Native Discord Interaction ingress is independently disabled by default and requires pinned application and bot IDs plus non-empty exact guild, channel, and user allowlists; it accepts only the managed slash-command contract and authenticated request Buttons published by this connector
• The managed guild command is guild-only, administrator-only by default, accepts one bounded request string, and can be installed or removed only through a keyed reviewed workflow with signed confirmation, one non-retried mutation, and exact full-inventory readback; request-button clicks create no Discord mutation and therefore require the exact user scope but not Administrator
• Interaction-only Gateway connections request zero intents. Startup rejects an application with an outgoing HTTP Interaction endpoint or any selected guild whose managed command is absent, duplicated, or contract-drifted
• Accepted requests are deferred ephemerally before slower verification, then held only in a bounded process-local queue with a strict lifetime and per-user capacity. Slash-command text or the authenticated clicked-button label remains untrusted and transient; Interaction tokens never cross MCP or enter persistent state
• Initial responses discard the Interaction token by default. An explicit keepOpen choice can retain it only in process behind a rotating opaque one-shot continuation for at most three ephemeral plain-text follow-ups within the original expiry
• Every follow-up requires pending content-free activity, one non-retried write, exact direct response evidence, and an independent exact readback; refusal, uncertainty, drift, exhausted allowance, and shutdown return no new continuation
• Responses require an opaque one-shot reference and pending content-free activity, remain ephemeral and mention-free, and are never automatically retried after rejection, transport ambiguity, malformed evidence, or expiry
• Member-directory reads are disabled unless a separate feature gate and non-empty exact guild allowlist are both configured
• Exact member lookup, ascending cursor pages, and username-or-nickname prefix search return privacy-minimized records and never persist, cache, journal, or export member data or queries
• Member records omit avatars, decorations, presence, voice state, boost state, permissions, flags, and raw Discord payloads; display names never become write targets
• Guild ban audit is disabled unless a separate feature gate and non-empty exact guild allowlist are both configured
• Ban pages use bounded private lookahead and strict ascending user-ID validation, while exact lookup accepts only one guild and user ID; both prove verified identity and complete BAN_MEMBERS permission evidence without requiring the Guild Members privileged intent
• Ban results contain minimized profiles, omit reasons by default, discard avatars, discriminators, and unknown raw fields, and never cache, persist, journal, or export the response; an exact MCP resource always omits the reason
• Process-local observability stores only bounded aggregate counts and durations under fixed operation names plus a rolling connector-observed lower bound on Discord invalid-request pressure, and never persists telemetry
• The invalid-request aggregate counts 401, 403, and non-shared 429 responses, including intermediate retries; it excludes proven shared-scope rate limits and never claims to know other traffic sharing the egress IP
• Optional OTLP export and JSON stderr records contain no tool arguments, results, Discord identifiers, routes, URLs, bodies, headers, error messages, stacks, plan digests, or activity data
• OTLP export is disabled by default, requires its own exact feature gate, and permits plaintext HTTP only to a loopback collector
• Message interactions are disabled unless an explicit capability gate and exact interaction-channel allowlist are both present
• Interaction scope never inherits from a thread parent, mentions notify nobody by default, and roles, @everyone, and @here cannot be enabled
• Every actual interaction send, edit, or own-reaction write requires a pending content-free activity record and passes process-local anti-spam guards
• Reviewed Components V2 creation and editing require the same exact interaction scope and shared anti-spam budget, plus confirmed Message Content intent, complete read and send permission evidence, a keyed plan, signed approval, a durable one-shot receipt, pending content-free activity, one non-retried mutation, and exact response plus fresh readback
• Completed Components V2 operations can be verified after restart from the exact caller-retained request and a token-keyed content-free receipt; verification requires only read permission, fetches the receipt-bound exact message without scanning history, and performs no write, reservation, activity append, or rate-budget consumption
• Component layouts use a strict local text, separator, callback-free link-row, authenticated request-row, and container DSL with recursive and aggregate bounds; every HTTPS destination has exact transient review and separate origin policy, while request Buttons require ready exact native Interaction ingress and connector-generated HMAC IDs, and raw Discord component JSON, caller-selected IDs, selects, modals, sections, files, remote media, and remote templates are rejected
• Components V2 conversion is never implicit: edits target only exact already-V2 default messages owned by the verified bot, while exact layout matches with empty parsed user-mention state are notification-free no-ops requiring no confirmation, claim, receipt, activity record, rate budget, or Discord write
• Static rich-embed creation and editing have an independent capability, exact channel or thread scope, and embed-messages toolset; they require confirmed Message Content intent, complete read, send, and EMBED_LINKS permission evidence, signed review, one-shot coordination, one non-retried mutation, and exact response plus fresh readback
• Rich-embed layouts accept only bounded text, integer color, timestamp, and ordered field presentation; embed URL and remote-asset fields, providers, attachments, arbitrary types, unknown fields, and raw Discord JSON are rejected, and the connector never fetches an embed asset
• Completed rich-embed operations use the caller-retained request and token-keyed content-free receipt for restart-safe exact-message verification, while an exact notification-free edit is a record-free no-op
• Aggregate reaction reads use ordinary readable-channel scope and return strict normal and burst counts plus only the bot's own reaction flags; message content, authors, profiles, burst colors, raw payloads, and unknown fields are excluded
• Reaction user pages require a separate disabled-by-default gate and exact channel allowlist, return only bounded user IDs and bot flags, and persist nothing
• Reaction moderation requires a separate disabled-by-default gate, pinned identity, an exact channel allowlist, complete message-read plus MANAGE_MESSAGES evidence, a fresh keyed plan, signed approval, exact-message coordination, a one-shot receipt, pending content-free activity, one non-retried deletion, and target-absence plus exact aggregate readback
• Raw emoji text never enters durable activity or operation records; custom emoji IDs and a keyed emoji fingerprint may be retained for review, while uncertain same-message outcomes remain quarantined
• Sends require caller-provided idempotency keys, coalesce concurrent retries, and use deterministic Discord nonces with uniqueness enforcement
• Only non-webhook messages owned by the verified bot can be edited
• Every receipt-backed reviewed write acquires a durable content-free claim over its exact channel, message, member, role, webhook, integration, or guild collection targets before the final fresh plan can advance to reservation or mutation; resumable scaffolds claim both guild role and channel collections, and separate connector processes coordinate when they share the same local activity-state root
• Claims never expire by age. A dead owner is reclaimed automatically only when its immutable receipt proves that no matching reservation exists or that the result is terminal; pending, uncertain, unreadable, or malformed state remains quarantined for operator review
• Coordination state uses private atomically published records and stores only exact Discord identifiers, bounded target kinds, operation kind, operation-key hash, plan digest, PID, timestamp, and random claim ID. It never stores Discord content, names, audit reasons, payloads, URLs, local file paths, raw operation keys, or credentials
• Durable coordination requires one shared local state root on a local filesystem. A normally paused scaffold releases its matching pending claim only after the callback returns successfully; interruption or uncertain execution leaves it quarantined. Message deletion participates through exact message targets. Member moderation claims its exact member and the guild member collection, while bulk guild bans claim the complete exact member target set and that collection. Guild pruning claims the member collection plus every exact included role, and other member, role, integration, or structural workflows sharing those targets cannot race past review. Ordinary message interactions retain their documented specialized semantics outside this boundary
• Pin listing uses Discord's current timestamp-paginated endpoint under ordinary read scope and never persists returned messages
• Pin and unpin changes are disabled unless a separate toggle and non-empty exact channel allowlist are both configured; thread-parent scope never grants mutation authority
• A content-bound keyed plan, signed MCP elicitation, host write approval, a final fresh plan, dedicated PIN_MESSAGES evidence, a durable one-shot receipt, pending content-free activity, one non-retried mutation, and exact state plus review-snapshot readback surround every pin change
• Message content, attachment metadata, names, audit reasons, and raw operation keys are never persisted; uncertain pin outcomes spend the key and retain the durable exact channel-and-message claim across connector processes sharing the activity-state root
• Announcement crossposts are disabled unless a separate toggle and non-empty exact direct announcement-channel allowlist are configured, and planning additionally requires confirmed Message Content intent
• Crosspost planning accepts only exact default non-poll non-forwarded messages, proves VIEW_CHANNEL, READ_MESSAGE_HISTORY, SEND_MESSAGES, and authorship-sensitive MANAGE_MESSAGES, and exposes that follower destinations and counts are unavailable
• Signed approval, a final fresh plan, a durable one-shot receipt, pending content-free activity, one non-retried POST, the exact CROSSPOSTED flag transition, and a fresh exact readback surround every crosspost; uncertain outcomes retain durable exact channel-and-message claims for operator review
• Message content, attachments, embeds, components, profiles, names, follower data, raw operation keys, raw responses, and transport causes are never persisted or exported by the crosspost workflow
• Native message forwarding is disabled unless a separate toggle, non-empty exact source and target direct-channel allowlists, pinned application and bot identities, and confirmed Message Content intent are configured; cross-guild forwarding requires an additional independent toggle
• Forward planning accepts only one exact eligible non-poll, non-call, non-nested source message, blocks age-restriction downgrades before reading source content, and proves complete source VIEW_CHANNEL plus READ_MESSAGE_HISTORY and target VIEW_CHANNEL, READ_MESSAGE_HISTORY, plus SEND_MESSAGES evidence including unknown permission bits
• Signed approval, a final fresh plan, durable exact source-message and target-channel coordination, a one-shot receipt, pending content-free activity, one non-retried nonce-enforced POST with empty allowed mentions and suppressed notifications, strict response validation, and independent exact readback surround every forward
• Forwarded snapshot content and rich message data remain transient; the plan returns only a bounded review preview and counts, the complete validated evidence enters the process-keyed digest, and durable records retain only content-free identifiers and outcomes. Any indeterminate result spends the key and preserves the known target message ID when available
• Announcement-subscription audit and changes have independent disabled-by-default gates and exact target text-channel scope; creation additionally requires an exact announcement-source allowlist
• Subscription inventory privately validates a complete bounded target webhook collection, exposes only aggregate capacity plus exact Channel Follower IDs, types, locally derived timestamps, in-scope available follower-source IDs, complete target permission evidence, and explicit omissions, and never reads messages or returns unrelated webhook IDs, credentials, URLs, webhook or follower-source names, avatars, or profiles
• Subscribe planning proves source VIEW_CHANNEL, target VIEW_CHANNEL plus MANAGE_WEBHOOKS, source and target channel types, complete guild evidence, target capacity, and duplicate absence; an exact existing subscription is a record-free no-op, while any follower with unavailable or policy-redacted source identity blocks creation
• Exact-ID unsubscription remains possible when Discord no longer exposes the source identity, but only for a Channel Follower webhook in the complete separately allowlisted target inventory
• Every actual subscription change requires a process-keyed plan, signed approval, final fresh-plan equality, durable target and webhook-collection coordination, a one-shot receipt, pending content-free activity, one non-retried mutation, and exact complete-inventory readback; an uncertain result spends the key and retains its claims
• Subscription records contain only exact Discord IDs, plan and key digests, timestamps, fixed outcomes, verification state, activity ID, and sanitized error category; names, credentials, URLs, audit reasons, raw keys, responses, and message data are never persisted
• Webhook inventory is disabled unless a separate audit toggle and non-empty exact direct-channel allowlist are both configured
• The Discord REST response is projected immediately to exact IDs, type, creation time, name, application ID, and creator user ID; webhook credentials, execution URLs, avatars, creator profiles, source objects, and unknown raw fields never enter the MCP result or content-free lifecycle state
• Incoming-webhook creation, rename, and same-guild move each require an independent action gate in addition to audit scope, complete source and destination inventory and permission evidence, a keyed plan, signed MCP elicitation, host write approval, a final fresh plan, one-shot records, pending content-free activity, one non-retried mutation, and exact response plus inventory readback
• A created Incoming webhook credential is validated and written exclusively under its exact webhook ID in a configured private process-owned root; credential files are fsynced stable single-link regular files with exact 0600 mode and never enter MCP data, diagnostics, observability, activity records, operation receipts, or configuration
• A no-op rename or move returns verified already-current state without confirmation, reservation, activity, or a Discord write; an actual move preserves the external bearer credential and redirects future deliveries to the reviewed destination
• Webhook message reads, delivery, edits, and deletion each require a separate disabled-by-default capability and an exact direct text or announcement channel allowlist; the connector resolves the credential privately from the exact webhook ID and rejects credential, token, and execution-URL fields at the MCP schema boundary
• Webhook delivery and editing accept only bounded plain text, suppress embeds, parse no role or everyone mentions, notify only exact separately allowlisted users, share channel anti-spam limits, require one-shot operation keys, dispatch at most once, and verify the exact response plus credential-authenticated readback
• Webhook message deletion additionally requires a content-bound keyed plan, signed MCP elicitation, host write approval, a final fresh plan, durable exact webhook-and-message coordination, a pending content-free activity record, one non-retried DELETE, and exact absence readback
• Webhook message content is transient and never enters activity, receipt, diagnostic, or observability state; deletion's local review reason is bound into the plan but is neither sent to Discord nor persisted because the token-authenticated route accepts no Discord audit-log reason
• Incoming-webhook deletion requires an independent toggle in addition to audit scope, then uses verified application and bot identity, complete channel inventory and permission evidence, a keyed plan, signed MCP elicitation, host write approval, a final fresh plan, one-shot receipt, pending content-free activity, one non-retried DELETE, and exact absence readback before removing only the inspected exact-ID private credential file when one exists
• Webhook names, execution URLs, credential paths, avatars, creator profiles, source objects, audit reasons, raw operation keys, and raw Discord responses are never persisted; credentials persist only in their dedicated exact-ID private files, while uncertain creation outcomes retain exact channel and guild-webhook-collection claims and uncertain changes or deletions retain exact source, destination when applicable, webhook, and collection claims across connector processes sharing the activity-state root
• Guild integration inventory is disabled unless a separate audit toggle and non-empty exact guild allowlist are both configured
• Every integration read verifies pinned application and bot identities, exact guild ownership, connector membership, complete bounded roles, guild-level MANAGE_GUILD, and a strict privacy projection; integration, external account, application, user, and bot names or profiles never enter results or persistent state
• Discord caps the guild integration endpoint at a documented maximum without pagination, so a response at that boundary is explicitly ambiguous and blocks every deletion
• Integration deletion requires an independent toggle and exact integration allowlist, rejects unknown types, OAuth scopes, and fields, protects the connector's own application and bot plus configured protected bots, and keeps guild subscription integrations audit-only
• Every deletion binds the complete inventory and associated-bot membership into a keyed plan, requires explicit acknowledgment that associated webhooks are removed and that an associated bot can be kicked, then uses signed confirmation, host write approval, final fresh planning, durable collection and side-effect claims, one-shot records, pending content-free activity, one non-retried DELETE, and a complete readback proving the target absent and every survivor unchanged
• Integration, external account, application, user, and bot names, external account IDs, descriptions, icons, profiles, OAuth values unknown to the connector, audit reasons, raw operation keys, raw responses, and transport causes are never persisted; content-free records may retain the exact Discord IDs needed for review, and an uncertain result spends the key and quarantines the guild for operator review
• Guild departure is disabled unless a dedicated capability, toolset, and nonempty exact guild allowlist are configured; no generic administration gate or Discord permission implies it
• Planning verifies pinned identity, exact connector membership, non-ownership, and a complete privacy-projected current-guild inventory, then binds explicit access-loss, re-entry, and stopped-work acknowledgments plus a transient local reason into the keyed plan
• Execution requires signed confirmation, host approval, repeated freshness checks, every modeled guild collection claim, one-shot reservation, pending content-free activity, one non-retried leave request, and complete membership-absence readback; the quiescence acknowledgment covers resource-only workflows and external actors outside collection coordination
• Guild invite inventory is disabled unless a separate audit toggle and non-empty exact guild allowlist are both configured
• Invite codes and URLs are bearer capabilities, so the REST response is projected to process-keyed opaque references and bounded security metadata before any MCP result is formed; raw codes, URLs, profiles, role names, and unknown Discord fields are omitted
• Every invite read verifies the exact application, bot, guild, owner, connector membership, complete bounded roles, visibility-bounded channels, and guild-level MANAGE_GUILD; authenticated cursors bind every page to one complete fresh invite inventory and reject drift or tampering
• Finite private-file invite creation has an independent direct-channel gate; optional role assignment adds another capability, an exact role allowlist, complete unobfuscated Gateway channel evidence, MANAGE_ROLES, strict hierarchy and permission-subset checks, minimum new-member impact review, and explicit acknowledgement that accepted roles persist
• Invite revocation requires an independent deletion toggle, a keyed full-inventory plan, signed MCP elicitation, host write approval, a final fresh plan, durable one-shot reservation, pending content-free activity, one non-retried DELETE, returned-target validation, and complete fresh absence readback
• Invite codes, URLs, profiles, role names, audit reasons, raw operation keys, raw Discord responses, and transport causes from code-bearing routes are never persisted or returned by the connector; uncertain outcomes spend the key, preserve the service-instance reference barrier, and retain the durable exact guild invite-collection claim across connector processes sharing the activity-state root
• Guild Template inventory is disabled unless a separate audit toggle and non-empty exact guild allowlist are both configured
• Template codes and use URLs are bearer capabilities, so every raw code is replaced with a process-keyed opaque reference before an MCP result is built; names, descriptions, creator profiles, source snapshots, role and channel names, topics, icon hashes, and raw payloads are omitted
• Every Template audit returns continuity-stable channel evidence and labels live structure and drift complete or visibility-bounded; create and synchronize require complete live channel metadata, while exact metadata-update and delete actions remain available with visibility-bounded drift
• Create, synchronize, metadata-update, and delete actions require an independent change toggle, complete MANAGE_GUILD evidence, a keyed full-inventory plan, signed MCP elicitation, host write approval, a final fresh plan, durable one-shot reservation, pending content-free activity, one non-retried mutation, strict response validation, and exact complete-inventory readback
• Template codes, URLs, source content, metadata, audit reasons, raw operation keys, raw Discord responses, and permission evidence never enter persistent records, diagnostics, or telemetry; uncertain outcomes spend the key, preserve a service-instance target barrier, and retain the durable exact guild template-collection claim across connector processes sharing the activity-state root
• Guild onboarding inspection is disabled unless a separate audit toggle and non-empty exact guild allowlist are both configured; prompt titles, option titles, descriptions, and Unicode emoji are omitted by default and included only transiently through explicit tool opt-in
• Every onboarding read verifies the exact application, bot, guild, owner, connector membership, complete bounded onboarding, role, emoji, and permission evidence, plus continuity-stable complete or visibility-bounded channel evidence; unknown fields and enums are reported only as counts
• Onboarding replacement requires an independent change toggle, complete MANAGE_GUILD and MANAGE_ROLES authority, zero-authority standard roles below the connector, directly visible referenced channels, and conservative enablement proof; any obfuscated channel makes role references unsafe because hidden overwrites are unavailable, while role-free replacements remain reviewable, and enabling also requires fresh COMMUNITY guild-feature evidence
• Every replacement is an exact complete-state operation where omitted prompts, options, assignments, and default channels are deletions; existing IDs must be owned by the current configuration and omitted IDs request creation through transport-only placeholders
• A full-state keyed plan, signed MCP elicitation, host write approval, a final fresh plan, durable one-shot reservation, pending content-free activity, one non-retried PUT, authoritative response-ID validation, and a complete fresh readback surround every onboarding change
• Onboarding text, names, Unicode emoji, audit reasons, raw operation keys, and raw payloads are never persisted; uncertain outcomes spend the key and retain the durable exact guild onboarding-collection claim across connector processes sharing the activity-state root
• API readback verifies the controlled server state but cannot prove the fresh-member client experience, so enabled onboarding plans require a separate non-staff client check after execution
• Welcome Screen inspection is disabled unless a separate audit toggle and non-empty exact guild allowlist are both configured; descriptions and Unicode emoji are omitted by default and included only transiently through explicit tool opt-in
• Every Welcome Screen read verifies the exact application, bot, guild, owner, connector membership, complete bounded guild-feature, role, emoji, permission, and Welcome Screen evidence, plus visible channels and their overwrites; a configured or desired channel omitted by Discord fails closed, unknown fields are reported only as counts, and disabled state without MANAGE_GUILD is reported as unavailable rather than guessed
• Welcome Screen replacement requires an independent change toggle, complete MANAGE_GUILD authority, the COMMUNITY guild feature, directly supported channels visible to @everyone, and exact available public custom emoji or one validated Unicode grapheme
• Every replacement is one complete ordered state where omitted channel entries are deletions; a full-state keyed plan, signed MCP elicitation, host write approval, final fresh plan, durable one-shot reservation, pending content-free activity, one non-retried PATCH, authoritative response validation, and complete fresh readback surround the write
• Welcome Screen descriptions, Unicode emoji, guild and channel names, channel IDs, audit reasons, raw operation keys, and raw payloads are never persisted; uncertain outcomes spend the key and retain the durable exact guild Welcome Screen collection claim across connector processes sharing the activity-state root
• API readback verifies the controlled server state but cannot prove the member client experience, so enabled Welcome Screen plans recommend a separate fresh non-staff client check after execution
• Authenticated widget-settings inspection is disabled unless a separate audit toggle and non-empty exact guild allowlist are both configured; every read verifies exact identity, guild ownership, connector membership, complete bounded roles, visible channels and their overwrites, MANAGE_GUILD, the exact authenticated settings object, and any guild-object cross-check fields, while a selected channel omitted by Discord fails closed
• Public widget JSON and image routes are deliberately never called because they can disclose public channel, presence-oriented, invite, and profile information; widget audits omit channel names, member and presence data, invite codes and URLs, raw payloads, and unknown-field values
• Widget-settings changes require an independent change toggle, one exact complete desired state, a supported direct channel visible to @everyone when selected, complete permission evidence, and a separate public-exposure gate when enabling the widget or selecting a different non-null channel
• A keyed plan, signed MCP elicitation, host write approval, final fresh plan, durable one-shot reservation, pending content-free activity, one non-retried PATCH, strict authoritative-response validation, and complete fresh authenticated readback surround every real widget-settings change
• Widget-setting values, channel names and IDs, permission evidence, audit reasons, raw operation keys, and raw payloads are never persisted; uncertain outcomes spend the key and retain the durable exact guild widget-settings collection claim across connector processes sharing the activity-state root
• Enabling the widget makes the Server Profile public outside the guild and may permit anonymous invite generation; disabling it does not restore Private Profile, so the connector reports the manual Server Settings follow-up without claiming to verify it
• Application-owned emoji inventory is disabled unless a separate audit toggle and pinned application and bot identities are configured; callers cannot select another application ID
• Inventory projects uploader identity and every private or unrecognized raw value out immediately, requires exact application-emoji structure, reports unknown fields only as counts, and never returns image bytes or CDN URLs
• Create, rename, and delete require an independent change toggle, a complete known unmanaged inventory, exact-name collision and capacity checks, and the same signed fresh-plan, approval, one-shot reservation, pending content-free activity, non-retried write, and exact metadata or absence-readback gates used by other reviewed changes
• Creation accepts only one bounded canonical owned JPEG, PNG, GIF, WebP, or AVIF file inside dedicated application-emoji roots, never a URL or transported base64 payload; deletion additionally requires explicit acknowledgement of its global impact across every application installation
• Application emoji changes acquire one durable application-wide collection claim, retain that claim after uncertainty, and never persist names, local paths, image bytes, digests, uploader profiles, raw keys, or raw payloads; the endpoints do not document Discord audit-log reason support
• Application entitlement writes are absent unless the independent application-entitlement-changes toolset and the matching disabled-by-default test-change or consumption capability are both selected; read-only monetization audit, SKU audit, guild scope, and one write capability never grant the other write authority
• Test-entitlement creation accepts only one exact configured guild or user and one exact current-application subscription SKU whose documented purchase scope matches that beneficiary; deletion additionally requires the exact entitlement ID and a matching completed connector creation receipt, so arbitrary or externally created entitlement deletion is unavailable
• Consumable-entitlement consumption accepts only one exact configured user, current-application consumable SKU, and exact active entitlement after the caller explicitly acknowledges completed application-specific fulfillment and supplies a caller-owned durable fulfillment reference; the connector cannot verify the fulfillment itself and persists only its domain-separated hash
• Both workflows use fresh identity, complete SKU, exact lifecycle, keyed-plan, signed confirmation, host write approval, application-wide coordination, one-shot reservation, pending content-free activity, one non-retried mutation, and exact readback gates; no-op plans write nothing, while ambiguous outcomes spend the key and retain the application claim
• Global application-command changes are disabled unless capabilities.globalApplicationCommandChanges is true and the dedicated application-commands toolset is selected; this authority remains independent of guild command changes, command exposure audit, and native Interaction management
• Global definitions require explicit complete interaction contexts and installation types, full localizations, named default member permissions, strict type-specific fields, and an explicit global-exposure acknowledgement; Primary Entry Point commands additionally require fresh EMBEDDED application evidence
• Planning binds the complete application installation evidence and full localized global inventory, separate type capacities, exact target and complete definitions, collision and no-op state, cross-guild permission-reset effects, one-shot operation-key hash, risks, warnings, and verification contract into a keyed digest
• Signed MCP elicitation, host write approval, final fresh planning, an exact durable global-command collection claim, one-shot reservation, pending content-free activity, one non-retried exact-ID mutation, strict response validation, and exact complete survivor readback surround every real change; uncertain outcomes quarantine the application-wide collection and no command text enters durable records
• Application linked-role metadata changes are disabled unless capabilities.applicationRoleConnectionMetadataChanges is true and the dedicated linked-roles toolset is selected
• The workflow accepts only an explicitly acknowledged complete non-empty canonical replacement or an explicitly acknowledged complete clearance for the verified pinned application; partial updates, caller-selected applications, guild-role configuration, and user role-connection values are unavailable
• Planning binds the authoritative complete current and desired schemas, ordering, count-only diff, endpoint presence, acknowledgements, one-shot operation-key hash, risks, and warnings while keeping metadata text transient and signed request state label-free
• Signed MCP elicitation, host write approval, final fresh planning, an exact durable application schema-collection claim, one-shot reservation, pending content-free activity, one non-retried PUT, strict complete response validation, and independent exact readback surround every real replacement; uncertain outcomes retain the claim and no schema text enters durable records
• Application privileged-intent enablement is disabled unless capabilities.applicationIntentChanges is true and the dedicated application-security toolset is selected
• Guild Members is eligible only when the member directory is enabled for at least one exact guild; Message Content is eligible only when selected tools require it for reviewed content-dependent writes or recommend it for ordinary message access
• The workflow accepts only additive Guild Members or Message Content limited-flag enablement; Presence, disabling, full-authorization requests, generic application metadata, caller-selected application IDs, and automatic remediation are unavailable
• Planning binds pinned application and bot identities, authoritative flags_new evidence or Discord's validated numeric flags response fallback, named current state, policy requirement, every preserved non-target flag, an ephemeral rationale, a one-shot operation-key hash, and a keyed digest without exposing raw flag values
• Signed MCP elicitation, host write approval, a final fresh plan, an exact durable application privileged-intents claim, one-shot reservation, pending content-free activity, one non-retried current-application PATCH, strict exact response validation, and independent exact readback surround every real enablement
• Application-intent activity and operation records contain only application and bot IDs, the named intent, hashes, timestamps, verification, outcome, activity ID, and sanitized error category; rationale, application text, raw flags, raw operation keys, credentials, and raw payloads are never persisted
• Guild emoji and sticker inventory is disabled unless a separate audit toggle and non-empty exact guild allowlist are both configured
• Inventory projects Discord responses immediately to stable expression metadata and complete ownership-aware permission evidence; CDN URLs, image bytes, uploader profiles, and unknown raw fields never enter MCP results or persistent state
• Creation requires an independent change toggle, exact verified guild scope, normalized-name collision checks, complete roles and permissions, and CREATE_GUILD_EXPRESSIONS; update and delete additionally require either exact bot ownership with that permission or MANAGE_GUILD_EXPRESSIONS
• Creation accepts only one bounded canonical owned local file inside dedicated roots, never a URL or base64 payload, detects the actual container format and animation state, records dimensions where encoded, enforces byte limits plus sticker dimensions and duration, and binds the stable file snapshot into a keyed plan
• Signed MCP elicitation, host write approval, a final fresh plan, durable one-shot reservation, pending content-free activity, one non-retried mutation, and exact metadata or absence readback surround every guild-expression change; managed emojis, missing role references, insufficient ownership, and uncertain same-guild predecessors fail closed
• Expression names, descriptions, tags, role names, local paths, image bytes, uploader profiles, audit reasons, and raw operation keys are never persisted; reserved keys are never retried or rolled back automatically
• AutoMod inventory is disabled unless a separate audit toggle and non-empty exact guild allowlist are both configured; full policy strings are returned only for an exact rule read, while inventory returns rule identity, action and trigger types, counts, and reference health
• AutoMod changes require an independent toggle, exact guild scope, MANAGE_GUILD, complete guild, role, channel, and bot-member evidence, and MODERATE_MEMBERS when creating, updating, or enabling a timeout-bearing rule
• Create always produces a disabled rule, enabling and disabling are separate reviewed actions, enabled rules cannot be edited or deleted, and Discord's immutable trigger type requires disabled delete and recreate instead of implicit conversion
• Alert destinations require their own exact local allowlist, an existing text or announcement channel, and effective VIEW_CHANNEL; every exempt role and channel must exist, and incompatible trigger, action, exemption, or capacity combinations fail closed
• Signed MCP elicitation, host write approval, a final fresh plan, durable one-shot reservation, pending content-free activity, one non-retried mutation, and exact state or absence readback surround every AutoMod change; uncertain same-guild predecessors fail closed
• Rule names, trigger strings, custom responses, role and channel names, audit reasons, and raw operation keys are never persisted; AutoMod execution-event content and matched content are deliberately absent from the Gateway feed
• Scheduled-event inventory is disabled unless a separate audit toggle and non-empty exact guild allowlist are both configured
• Ordinary event reads project Discord responses immediately to bounded metadata and complete entity-specific permission evidence; subscriber identities, creator profiles, cover URLs and hashes, and unknown raw fields are never returned or persisted, while aggregate subscriber counts require explicit opt-in
• Subscriber-user audit requires a second opt-in, inherits the exact event guild scope, verifies the exact event and complete read permissions before fetching identities, sends with_member=false, and returns only bounded ascending user IDs and bot flags; usernames, display names, avatars, member data, raw payloads, and all persistence are excluded
• Event changes require an independent change toggle, exact guild scope, future and internally consistent timing, documented recurrence shapes, valid lifecycle transitions, complete channel or guild permissions, and either MANAGE_EVENTS or exact bot ownership with CREATE_EVENTS
• Cover changes accept only one bounded canonical owned local JPEG or non-animated PNG file inside dedicated roots, never a URL or base64 payload, and bind its stable bytes and provenance into the reviewed plan
• Signed MCP elicitation, host write approval, a final fresh plan, durable one-shot reservation, pending content-free activity, one non-retried mutation, and exact state or absence readback surround every scheduled-event change; uncertain same-guild predecessors fail closed
• Event names, descriptions, locations, recurrence details, subscriber counts and user IDs, local paths, image bytes and digests, audit reasons, and raw operation keys are never persisted; reserved keys are never retried or rolled back automatically
• Stage-instance inventory is disabled unless a separate audit toggle and non-empty exact Stage-channel allowlist are both configured; inactive channels remain explicit inventory entries
• Stage reads require exact channel and guild identity, the Stage channel type, verified application and bot identity, complete roles and overwrites, and effective VIEW_CHANNEL; results omit speaker state, audience state, scheduled-event objects, and raw Discord payloads
• Stage start, topic update, and end require an independent change toggle, guild-only privacy, no scheduled-event association, zero unknown fields, complete VIEW_CHANNEL, CONNECT, MANAGE_CHANNELS, MUTE_MEMBERS, and MOVE_MEMBERS evidence, and strict lifecycle-specific input
• Guild-wide Stage start notification is disabled behind a third toggle, requires fresh MENTION_EVERYONE, and consumes the shared interaction rate budget; update and end can never request it
• Signed MCP elicitation, host write approval, a final fresh plan, durable one-shot reservation, pending content-free activity, one non-retried mutation, and exact state or absence readback surround every Stage change; ambiguous outcomes retain the durable exact channel claim across connector processes sharing the activity-state root
• Stage topics, guild and channel names, speaker and audience identities, audit reasons, raw operation keys, raw payloads, and scheduled-event objects are never persisted; completed drift is reported without retry or rollback
• Permission-overwrite listing is a bounded ordinary read that reports exact role and member targets, known and unknown bits, and the inherited parent source for threads without persisting the result
• Exact channel metadata reads return a strict transient projection for one permitted guild channel, including type-applicable voice settings; names, topics, and RTC region IDs may be returned to the caller but are never cached, journaled, or persisted, while unknown fields are represented only by a count
• Global and exact-guild voice-region reads return complete bounded deterministic inventories with transient untrusted names, deprecation and availability flags, and count-only unknown fields; raw payloads are omitted and nothing is persisted
• Channel metadata changes are disabled unless a separate toggle and non-empty exact direct-channel allowlist are both configured; ordinary read scope and parent-thread inheritance never grant mutation authority
• Reviewed changes support only type-applicable name, topic, NSFW, slowmode, default thread slowmode, default auto-archive, bitrate, user limit, RTC region, and semantic video-quality fields while preserving every omitted field; deletion, type conversion, moves, positions, overwrite replacement, forum-tag replacement, flags, and thread edits are unavailable
• Every metadata change binds verified application and bot identity, exact guild ownership, connector membership, complete roles, complete overwrites, effective VIEW_CHANNEL plus MANAGE_CHANNELS authority, type-required CONNECT authority for voice and Stage targets, current and desired metadata, requested fields, audit reason, and one-shot key hash into the plan; voice plans additionally bind the guild boost tier, VIP_REGIONS capability, applicable bitrate and user limits, and a keyed exact guild-region inventory when an explicit region is selected
• Signed MCP elicitation, host write approval, a final fresh plan, durable one-shot reservation, pending content-free activity, one non-retried PATCH, exact response validation, and a complete fresh GET surround every channel metadata change; ambiguous outcomes spend the key and retain the durable exact channel and guild channel-collection claims across connector processes sharing the activity-state root
• Exact voice-channel status access reuses the channel-metadata gate and exact allowlist, adds no policy or environment setting, accepts ordinary voice channels only, and obtains fresh transient state through a projection-only Gateway connection using the nonprivileged GUILDS intent
• Each status read or plan first proves the exact HTTP channel type and scope, then sends one exact Gateway channel-info query; non-target status values are discarded before projection and only counts describe the broader guild response
• Status authority requires complete effective VIEW_CHANNEL and SET_VOICE_CHANNEL_STATUS; it conditionally requires MANAGE_CHANNELS when the connector is not connected to the exact target, while the returned connection class never exposes another channel ID
• Status changes require explicit text or null, a one-shot key, signed MCP elicitation, host write approval, a final fresh plan, durable coordination, pending content-free activity, one non-retried PUT, event-assisted settling, and a fresh authoritative Gateway query; valid mismatch completes with drift and ambiguous outcomes remain uncertain and quarantined
• Voice status text, status hashes, audit reasons, names, non-target channel IDs, raw Gateway payloads, and event values never enter durable records, diagnostics, logs, metrics, or traces; Stage support, enumeration, history, fuzzy lookup, bulk actions, retry, and rollback are unavailable
• Channel-order audit is disabled unless a separate toggle and non-empty exact guild allowlist are configured; reviewed relative changes require a second independent toggle and never inherit authority from reads, metadata changes, channel creation, scaffolds, forum tags, or permission overwrites
• Audit joins an atomic complete Gateway layout containing only channel ID, direct-channel type, raw position, nullable parent ID, and explicit obfuscation state with one bounded HTTP guild-channel snapshot. Complete legacy HTTP evidence and the exact visible HTTP subset after Discord's channel-obfuscation transition are both accepted, while metadata for every Gateway-obfuscated channel is discarded even if HTTP still returns it
• Canonical order uses ascending raw position followed by ascending snowflake ID and groups only categories, text-like channels, and voice-like channels within the same parent. Unsupported siblings, incomplete topology, cross-family placement, arbitrary numeric positions, arbitrary parents, permission synchronization, and any permission, flag, or metadata change fail closed; a different-parent same-family anchor may select one reviewed destination with capacity, target authority, overwrite preservation, and complete readback
• Planning binds verified identity, the complete coherent layout, visibility-bounded HTTP evidence, exact target and anchor, source and destination parents and capacities, full normalized affected-group payload, exact overwrite preservation, complete source and destination MANAGE_CHANNELS authority, cross-parent target VIEW_CHANNEL plus MANAGE_CHANNELS, audit reason, risks, warnings, and one-shot key hash into a process-keyed digest
• Signed MCP elicitation, host write approval, a final fresh plan, durable claims on the target, anchor, applicable parent categories, and whole guild channel collection, a one-shot receipt, pending content-free activity, a verification subscription armed before one non-retried complete position PATCH, a newer complete matching Gateway layout, and coherent overwrite-preserving HTTP readback surround every real change. Timeout, continuity loss, mismatch, or post-acceptance failure is uncertain and quarantines the guild channel collection without retry or rollback
• Channel-clone audit is disabled unless a separate toggle plus non-empty exact guild and source-channel allowlists are configured; mutation requires an independent toggle and never inherits authority from reads, channel creation, metadata changes, ordering, scaffolds, forum tags, or permission overwrites
• Cloning supports exact same-guild and same-parent copies of text, voice, category, announcement, Stage, forum, and media channels only when one create request can preserve every supported setting and overwrite; threads, directory channels, child resources, source placement, type conversion, edits, deletion, retry, rollback, and reconciliation are unavailable
• Planning joins complete continuity-stable Gateway and HTTP evidence, requires a visible exact source, guild-level MANAGE_CHANNELS, source VIEW_CHANNEL, complete roles and overwrite targets, sufficient guild and parent capacity, and authority for every copied permission bit; MANAGE_ROLES overwrites require ADMINISTRATOR because Discord imposes that create-time rule
• A process-keyed digest, signed MCP elicitation, host write approval, final fresh-plan equality, durable source plus guild-collection coordination, one-shot reservation, pending content-free activity, a pre-armed Gateway watch, one non-retried create, exact readback, complete post-create evidence, unchanged source semantics, and preserved relative order of every existing sortable group surround each clone
• Forum and media tag IDs are intentionally regenerated and returned as an exact source-to-created mapping after verification. An ambiguous acceptance, missing or contradictory proof, source drift, existing-channel reorder, or terminal operation-record failure quarantines the guild without retry, deletion, rollback, or position repair
• Forum-tag audit is disabled unless a separate audit toggle and non-empty exact stable-forum allowlist are both configured; it returns the complete bounded ordered inventory transiently, reports unknown fields only as counts, never scans posts or threads, and never persists tag text
• Forum-tag changes require an independent toggle and support only exact create, exact-ID metadata update, and exact-ID deletion while preserving tag IDs, order, omitted fields, and untouched custom emoji IDs; media channels, custom emoji introduction, fuzzy names, raw-array replacement, and reordering are unavailable
• Planning binds verified identity, the exact guild and forum, complete roles and overwrites, effective VIEW_CHANNEL plus MANAGE_CHANNELS, the complete current and desired ordered inventories, deletion's unavailable usage impact, audit reason, and one-shot key hash into a process-keyed digest
• Signed MCP elicitation, host write approval, a final fresh plan, durable exact channel coordination and one-shot reservation, pending content-free activity, one non-retried full available_tags PATCH, strict response validation, and a fresh complete readback surround every change; uncertain outcomes remain quarantined without retry or rollback
• Forum-tag names, emoji, audit reasons, raw operation keys, and raw Discord payloads are never persisted; activity and receipts contain only bounded identifiers, action, digest, timestamp, outcome, and verification
• Permission-overwrite changes are disabled unless a separate toggle and non-empty exact channel allowlist are both configured; only direct guild channels can be mutation targets and thread-parent scope never grants mutation authority
• Updates accept named allow, deny, or inherit deltas for one exact role or member and preserve unspecified bits; explicit deletion is a separate reviewed action, while raw bitfields, bulk reset, arbitrary copy, synchronization through this single-target workflow, and thread mutation are unavailable
• Planning binds the complete overwrite set, complete role inventory, exact target identity, parent-category synchronization, effective-access impact, connector authority, lockout checks, and one-shot operation-key hash into a process-keyed digest
• Every update proves the connector holds each outgoing permission and retains VIEW_CHANNEL plus MANAGE_ROLES; unknown or non-channel bits fail updates closed, while explicit deletion surfaces their removal as a warning
• Signed MCP elicitation, host write approval, a final fresh plan, a durable one-shot receipt, pending content-free activity, one non-retried PUT or DELETE, and full overwrite-set readback surround every permission-overwrite change
• Permission names, bitfields, role and member names, audit reasons, and raw operation keys are never persisted; uncertain outcomes spend the key and retain the durable exact channel-and-target claims across connector processes sharing the activity-state root
• Parent-category permission synchronization is independently disabled unless its own capability and non-empty exact direct-child allowlist are configured; ordinary read, parent, category, metadata, ordering, creation, clone, and single-overwrite authority never grant it
• Synchronization accepts only one supported direct child and its live exact parent category, requires literal complete-replacement, future-parent-propagation, and stopped-concurrent-change acknowledgments, and rejects arbitrary sources, categories, threads, direct messages, caller-supplied bitfields, and best-effort batches
• Planning binds complete child and parent overwrite sets, every referenced role, changed structural targets, protected-member boundaries, and current-child, parent, and prospective-child connector authority without fetching member profiles or claiming exhaustive member-effective access analysis
• Signed MCP elicitation, host write approval, repeated fresh plans, durable claims on both exact channels, a one-shot receipt, pending content-free activity, one non-retried complete overwrite replacement, exact response validation, and fresh synchronized-state readback surround every real synchronization; an already-synchronized child is a record-free no-op
• Permission-sync records omit changed overwrite targets, permission bits, names, reasons, and raw keys; uncertainty spends the key, retains both channel claims, and blocks overlapping same-channel work without retry or rollback
• Attachment messages are disabled unless a separate toggle, non-empty exact channel allowlist, and one or more existing owned canonical directory roots are configured
• Attachment planning accepts one exact absolute local path only, rejects URL and base64 inputs, reads no more than the configured 10 MiB ceiling, and rejects path escapes, symlinks, hardlinks, non-regular files, foreign-owned files, empty files, and files that change while being read
• A keyed plan binds the stable file identity and bytes, exact channel and optional reply, message fields, explicit notification users, complete bot permission evidence, and a one-shot operation-key hash
• MCP host write approval, signed MCP elicitation, two fresh byte-matching plans, the shared interaction limiter, a durable one-shot receipt, pending content-free activity, one non-retried multipart POST, and exact message readback all surround attachment execution
• Attachment URLs, local paths, file properties, byte digests, message content, descriptions, filenames, notification user IDs, and raw operation keys are never persisted; uncertain sends are never retried or rolled back automatically
• Channel creation is disabled unless a separate toggle and non-empty exact guild allowlist are both configured
• Creation is additive-only and supports categories, text channels, and forum channels without permission overwrites, positioning, edits, deletion, rollback, or broad blueprint reconciliation
• A keyed plan binds the exact request, bot identity, guild and optional parent permission evidence, logical-name collision candidates, relevant role state, visible capacity, and one-shot operation key hash
• MCP host write approval, signed MCP elicitation, a final fresh plan match, a durable one-shot content-free receipt, pending activity journaling, and exact post-write readback all surround channel creation
• Visible channel inventory is explicitly treated as visibility-bounded, and a reserved operation key cannot be reused after a failed or uncertain attempt
• Guild scaffolds are disabled unless a separate toggle and non-empty exact guild allowlist are both configured
• Guild blueprints add no authority of their own: additive structure, exact-ID role configuration, exact-ID channel metadata, profile, settings, Community, Welcome Screen, onboarding, AutoMod, and static publication frontiers each require their corresponding existing capability, exact scope, permission, intent, and interaction controls
• The exact blueprint manifest remains caller-retained; only keyed request and process-bound plan digests enter signed confirmation state, and no blueprint content or master operation key is persisted
• One blueprint execution can dispatch only one fresh fixed-order domain frontier, preserving that domain's existing approval, reservation, pending-audit, non-retry, readback, conflict, and uncertainty-quarantine behavior
• A scaffold accepts only additive roles, categories, text channels, and forum channels in one bounded symbolic graph; it never edits, assigns, moves, reorders, deletes, rolls back, or creates permission overwrites
• One keyed plan binds the verified application and bot, exact guild and requested graph, complete role and visible channel inventories, permissions, hierarchy, capacities, durable checkpoints, execution limit, and ready dependency frontier
• Signed MCP elicitation, host write approval, a final fresh plan, persistent request binding, per-step one-shot receipts, pending activity, non-retried writes, and exact readbacks surround every frontier
• A newly created category always forces a fresh plan before any requested child can be created; resumes use the same scaffold operation key and fail closed on pending, failed, uncertain, or drifting checkpoints
• Forum-post creation is disabled unless a separate toggle and non-empty exact forum-channel allowlist are both configured
• The forum surface targets stable public forum channels only and accepts one exact title, one plain-text starter message, at most five exact available tag IDs, optional exact notification users, and bounded thread archive and slowmode settings
• A keyed plan binds the exact request, bot identity, full guild role and forum overwrite evidence, required and moderated tag rules, effective View Channel, Read Message History, Send Messages, and conditional Manage Threads permissions, and a one-shot operation-key hash
• MCP host write approval, signed MCP elicitation, a final fresh plan match, the shared interaction limiter, a durable one-shot receipt, pending content-free activity, one non-retried POST, and exact thread plus starter-message readback all surround forum-post execution
• Forum-post titles, content, tag IDs and names, notification user IDs, audit reasons, and raw operation keys are never persisted; uncertain outcomes are never retried, deleted, or rolled back automatically
• General thread creation is disabled unless a separate toggle and non-empty exact parent-channel allowlist are both configured; ordinary parent read scope alone grants no creation authority
• The thread surface accepts message-anchored threads in text or announcement channels and explicit standalone public or private threads in text channels; forum and media posts, starter messages, lifecycle edits, membership changes, and files are separate workflows
• A process-keyed plan binds the exact parent, optional source-message snapshot, mode, settings, audit reason, identity, complete roles and overwrites, effective creation permissions, and one-shot operation-key hash
• MCP host write approval, signed MCP elicitation, a final fresh plan match, the shared interaction limiter, a durable one-shot receipt, pending content-free activity, one non-retried POST, and exact thread readback surround every creation; an already-threaded source is a record-free no-op
• Thread names, parent names, source content and profiles, audit reasons, raw operation keys, roles, and overwrites are never persisted; anchored ambiguity can recover only through the deterministic source-message ID, while standalone ambiguity preserves the direct-service logical barrier and retains the production facade's durable exact parent-channel claim
• Exact thread-state audit is disabled unless a separate toggle plus non-empty exact guild and thread allowlists are configured; it returns only pinned identity, exact minimized guild, parent, lifecycle, connector-membership, inherited permission, privacy, and unknown-field evidence without listing members or returning messages
• Thread changes require an independent toggle and accept exactly one rename, archive, unarchive, lock, unlock, auto-archive, slowmode, invitation-policy, connector-targeted join or leave, member-add, or member-remove action; every targeted member also needs an exact dedicated user-allowlist entry
• Planning verifies supported thread-parent relationships, complete guild roles and parent overwrites, exact connector and optional target membership, known lifecycle metadata, action-specific MANAGE_THREADS, self-membership, ownership, membership, and SEND_MESSAGES_IN_THREADS authority, protected removals, target parent access, and retained private-thread readback access
• A process-keyed plan, signed MCP elicitation, host write approval, final fresh-plan match, durable one-shot reservation, pending content-free activity, one non-retried single-field PATCH, exact connector @me membership PUT or DELETE, or exact member PUT or DELETE, and exact state or membership readback surround every real thread change
• Thread and member names, lifecycle values, parent IDs, permission evidence, audit reasons, raw operation keys, and Discord payloads never enter durable records; already-current requests are record-free no-ops, and uncertainty retains the durable exact thread-and-member claims across connector processes sharing the activity-state root
• Role creation is disabled unless a separate toggle and non-empty exact guild allowlist are both configured
• Role reads normalize current solid colors, hierarchy, managed-role provenance, known permission names, and unknown future permission bits from a complete bounded inventory or one exact role endpoint
• Principal permission diagnostics fetch exact member or role identities and a complete bounded role inventory without listing guild members, then evaluate named permissions, channel actions, timeouts, thread access, and strict role hierarchy without writing or persisting profile data
• Channel-role audits evaluate every role against a bounded action set, page compact rows with exact role cursors, report full-inventory totals, and distinguish standalone role baselines from member-specific overwrites
• Guild audit-log reads use exact guild scope, bounded lookahead pagination, exact actor and action filters, strict response-order validation, and an exact-entry lookup that cannot substitute a neighboring entry
• Guild audit summaries omit Discord's embedded objects plus all change and option values, redact polymorphic non-snowflake targets, include reasons only by explicit opt-in, and are never cached, logged, journaled, or persisted
• Role creation is additive-only, accepts exact named permissions, forbids ADMINISTRATOR, and never edits, moves, assigns, deletes, rolls back, or creates role icons, emoji, or gradients
• A keyed plan binds the complete role inventory, exact request without the raw operation key, operation-key hash, bot identity, effective permissions, hierarchy, capacity, and logical-name collision candidates
• MCP host write approval, signed MCP elicitation, a final fresh plan match, a durable one-shot content-free receipt, pending activity journaling, a single non-retried POST, and exact post-write readback all surround role creation
• Role configuration is disabled unless a separate toggle and non-empty exact standard-role allowlist are both configured; guild scope and role-creation, role-assignment, and permission-overwrite authority do not grant it
• Exact partial changes support name, modern role colors, hoist, mentionability, named permission grant or revoke deltas, and one tagged role-icon intent; omitted properties and unrelated permission bits are preserved, while @everyone, managed roles, ADMINISTRATOR grants, deletion, reordering, assignment, and creation are unavailable
• Role-icon intent is exactly one clear, NFC Unicode emoji grapheme, or exact owned local 64 by 64 PNG or JPEG image under storage.guildExpressionRoots; URLs, transported base64, custom emoji IDs, animation, other formats, and images above 256 KiB are rejected
• A keyed plan binds the exact role, affected-member count, complete inventory, current and desired state, bot identity, effective and post-change permissions, hierarchy, grantability, logical-name collisions, local-file identity and exact bytes when present, risks, and one-shot operation-key hash; unknown target fields and unknown permission bits during permission changes fail closed
• MCP host write approval, signed MCP elicitation, a final fresh plan match and file reread, a durable one-shot content-free receipt, pending activity journaling, one non-retried partial PATCH, strict response validation, and exact role, complete inventory, and role-holder-count readback all surround role configuration; local images bind Discord's response-assigned hash as the exact readback target
• Role-deletion readiness is disabled unless independent audit policy and an exact role allowlist are configured; execution requires a second gate and never inherits authority from role reads, creation, configuration, assignment, ordering, scaffolds, or channel overwrites
• Only one exact unheld standard role below the connector is eligible, and complete role, holder-count, hierarchy, channel-overwrite, invite role-grant, emoji restriction, onboarding option, AutoMod exemption, integration-role, this-application command-permission, and unobfuscated channel-layout evidence must contain no blocker or unknown field
• A keyed plan binds literal irreversible-role-loss acknowledgement, complete transient evidence, verified identities, audit reason, risks, warnings, and a one-shot operation-key hash; historical role mentions, Guild Template snapshot internals, and other applications' command permissions remain explicit operator review obligations because Discord does not expose complete bounded inventories for them
• MCP host write approval, signed MCP elicitation, a final fresh plan match, durable exact-role and evidence-collection coordination, a one-shot content-free receipt, pending activity journaling, one non-retried exact-ID DELETE, and fresh absence plus surviving-role and dependency preservation proof surround every role deletion; uncertainty quarantines guild role changes
• Role-order audit is disabled unless its own toggle and non-empty exact guild allowlist are configured; reviewed changes require a second independent toggle and never inherit authority from role reads, creation, configuration, assignment, scaffolds, or channel overwrites
• Role-order changes accept only one exact standard unmanaged target, one distinct exact standard unmanaged anchor, and above or below; arbitrary numeric positions, fuzzy names, bulk arrays, metadata changes, assignment changes, retry, rollback, and reconciliation are unavailable
• A keyed plan binds the complete canonical hierarchy, verified connector identity and membership, MANAGE_ROLES, exact target and anchor, affected segment, aggregate holder counts, hierarchy-sensitive permissions, unknown-field evidence, risks, and one-shot operation-key hash; unsafe or connector-held affected roles fail closed
• MCP host write approval, signed MCP elicitation, a final fresh plan match, durable whole-guild role-collection coordination, a one-shot content-free receipt, pending activity journaling, one non-retried exact-position PATCH, complete response validation, and full hierarchy plus holder-count readback surround every real role-order change
• Member nickname changes are disabled unless a base toggle and non-empty exact guild allowlist are configured; the base gate exposes only the narrow current-bot route and requires pinned application and bot identities plus complete CHANGE_NICKNAME evidence
• A second explicit gate permits another exact member only after protected-user, connector-bot, guild-owner, pending-member, administrator, complete MANAGE_NICKNAMES, and strict bot-above-target hierarchy checks; member-directory, moderation, role, and voice scopes grant no nickname authority
• Nickname intent is an exact string of 1 to 32 Unicode scalar values or explicit null for clearing; controls, formatting code points, malformed Unicode, surrounding whitespace, repeated whitespace, fuzzy lookup, normalization, retry, rollback, and full-member replacement are unavailable
• A process-keyed plan, signed MCP elicitation, host write approval, final fresh-plan match, durable exact-member coordination, one-shot content-free reservation, pending activity, one non-retried target-specific PATCH, strict response validation, and exact member readback surround every real nickname change; a matching nickname is a record-free no-op
• Nicknames, usernames, guild names, role names, permission evidence, audit reasons, raw operation keys, and Discord payloads never enter durable records or telemetry; uncertainty spends the key, retains the durable member claim, and quarantines later same-member nickname writes in that process
• Member verification-bypass changes are disabled unless their independent capability, exact non-empty guild allowlist, and member-verification toolset are configured; member-directory, nickname, role, moderation, and voice authority never grant this surface
• Requests accept only one exact member ID and the named bypassesVerification boolean; arbitrary raw flag values, bitmasks, full-member replacement, fuzzy identity, bulk changes, immediate writes, retry, and rollback are unavailable
• Planning preserves every unrelated member flag bit internally, hides raw flags from MCP and persistence, binds them into the keyed digest, verifies one documented permission alternative, rejects protected and special members, and requires the connector's unique highest role above the target; pending Membership Screening is allowed and shown explicitly
• Signed MCP elicitation, host write approval, a final fresh matching plan, durable exact-member coordination, one-shot receipt reservation, pending content-free activity, one non-retried exact member PATCH, strict response validation, and exact readback surround every real verification-bypass change; an already matching named state is a record-free no-op
• Member flags, usernames, guild and role names, permission and hierarchy evidence, audit reasons, raw operation keys, and Discord payloads never enter durable records or telemetry; uncertainty spends the key and retains the exact-member claim for operator review
• Member-role changes are disabled unless a separate toggle, non-empty exact guild allowlist, and non-empty exact role allowlist are all configured; protected users, the connector bot, guild owners, pending members, and actively timed-out members cannot be targeted
• Each plan verifies the complete guild role inventory, continuity-stable complete direct-channel metadata, MANAGE_ROLES, strict bot and target hierarchy, the selected role's management state and permissions, exact before-and-after guild permission sets and deltas, and exact named permission impact for every supported direct guild channel; any obfuscated channel blocks both add and remove
• Additions reject ADMINISTRATOR, unknown selected-role or overwrite bits, selected-role guild permissions outside the connector bot's effective guild set, and selected-role channel overwrite allowances or effective gains the bot does not itself hold in that channel; removals may de-escalate high-risk or unknown selected-role permissions and disclose them for review
• MCP host write approval, signed MCP elicitation, a final fresh plan match, a durable one-shot content-free receipt, pending activity journaling, one exact non-retried PUT or DELETE, and exact member readback surround every member-role change
• Member and role names, channel names, permission evidence, audit reasons, and raw operation keys are never persisted; active threads remain outside the direct-channel impact proof, and uncertain outcomes spend the key and retain the durable exact member-and-role claims across connector processes sharing the activity-state root
• Exact member voice-state audit is disabled unless a separate toggle plus non-empty exact guild and voice-channel allowlists are configured; it performs no occupant enumeration and returns a bounded projection containing verified identities, untrusted display names, connection state, scoped source channel, server mute and deafen state, complete VIEW_CHANNEL plus CONNECT evidence, and discarded unknown-field count
• Voice-state results omit session IDs, embedded member objects, self mute and deafen state, stream and camera state, Stage suppression and request-to-speak state, and every unknown-field value; reads are never cached, journaled, exported, or persisted
• Member voice changes require an independent toggle and support only exact move, disconnect, server mute or unmute, and server deafen or undeafen actions in ordinary voice channels; Stage participants remain read-only
• Every change rejects protected users, the connector bot, the guild owner, pending members, administrators, and targets at or above the connector's unique highest role, then proves action-specific source permissions plus exact destination access for both the connector and target when moving
• A process-keyed plan, signed MCP elicitation, host write approval, final fresh-plan match, durable one-shot reservation, pending content-free activity, one non-retried one-field member PATCH, strict response validation, and exact voice-state readback surround every real change; uncertain outcomes spend the key and retain the durable exact member claim across connector processes sharing the activity-state root without persisting voice-channel IDs
• Voice channel IDs, state booleans, member and channel names, permission evidence, audit reasons, raw operation keys, and Discord payloads never enter activity or operation records; an already-current request is a record-free no-op
• Deletion is disabled unless an explicit capability gate and deletion-channel allowlist are both present
• Deletion accepts exact message IDs rather than free-form filters
• A keyed snapshot digest detects message edits or replacements
• MCP host write approval and signed MCP elicitation both precede deletion
• The connector re-reads the plan immediately before writing
• A content-free pending activity record must succeed before deletion starts
• Member administration is disabled unless a separate toggle and non-empty exact guild allowlist are both configured
• Kick, ban, timeout, timeout removal, and unban accept exact guild and user IDs only, reject the bot, guild owner, and configured protected users, and fail closed on incomplete permission or role-hierarchy evidence
• Every moderation write is bound to a keyed snapshot of the exact action, target state, permission evidence, action parameters, and Discord audit-log reason
• MCP host write approval, signed MCP elicitation, a final fresh plan match, durable exact-member coordination, one-shot receipt reservation, and a content-free pending activity record all precede member moderation; each mutation dispatches once without automatic retry and ends with exact fresh readback
• Native bulk guild bans are disabled unless separate audit and execution gates, a non-empty exact guild allowlist, and the independent bulk-bans toolset are configured
• Bulk planning accepts only a unique exact target set from 2 through Discord's endpoint maximum, rejects every protected, self, owner, bot, already-banned, or hierarchy-ineligible target, and requires complete BAN_MEMBERS plus MANAGE_GUILD evidence
• Signed approval, complete-set durable exact-member coordination, one non-retried native batch request, strict response partitioning, and fresh exact ban readback for every target surround execution; partial success is explicit, successful bans are never rolled back, and failed subsets are never retried automatically
• Guild pruning is disabled unless separate audit and execution gates, a non-empty exact guild allowlist, an independent configured member-count ceiling, and the guild-prunes toolset are configured
• Prune planning requires explicit acknowledgement that Discord exposes no exact candidate IDs, an inactivity window, a request-specific member-count ceiling, protected-identity evidence, complete KICK_MEMBERS plus MANAGE_GUILD evidence, and a fresh native count estimate under both ceilings
• Optional prune include roles require a separate exact role allowlist and must be non-managed, below the connector, and free of hazardous permissions; every protected present member and the connector must retain an assigned role outside the widened cohort
• Signed approval, guild-member-collection and exact-role coordination, one non-retried native prune request, and a strict returned count surround execution; zero estimates are record-free no-ops, exact removed identities and readback are unavailable, and ambiguous outcomes remain quarantined
• The bot token, webhook credentials and URLs, invite codes and URLs, Discord profiles, message content, content hashes, embeds, components, attachment URLs, emoji, application-emoji, guild-expression, scheduled-event, Stage-instance, widget-setting, and channel-layout values, names, descriptions, locations, topics, tags, recurrence details, subscriber counts, speaker or audience identities, local paths, image bytes and digests, uploader profiles, notification user IDs, raw idempotency or operation keys, forum titles or tags, channel names or topics, scaffold symbols, Discord audit-log reasons, profile names, role names, and Discord Interaction public key are never written to the activity log or operation receipts

Treat application privileged-intent enablement, forum-tag changes, application-emoji changes, guild-expression changes, scheduled-event changes, Stage-instance changes, onboarding replacement, Welcome Screen replacement, authenticated widget-settings replacement, webhook deletion, webhook message delivery, editing, and deletion, invite creation and revocation, attachment messages, Components V2 messages, static rich-embed messages, forum posts, message-pin changes, channel metadata changes, voice-channel status changes, channel-order changes, channel deletion, channel permission-overwrite changes, member nickname changes, member verification-bypass changes, member-role changes, member voice changes, guild blueprints, guild scaffolds, channel creation, role creation, role configuration, role deletion, role ordering, message deletion, member moderation, bulk guild bans, and guild pruning as consequential even though the connector records only bounded identifiers and outcomes.

Canonical source: docs/reference.md