Privacy-minimized Discord Community lifecycle

audit_guild_community returns one bounded structural and permission audit for a separately allowlisted guild. Set capabilities.guildCommunityAudit: true, list every eligible guild in scopes.guildCommunityGuildIds, and include guild-community in tools.toolsets when selecting toolsets. The allowlist must be a subset of readScope.guildIds when that outer boundary is present. Audit activates the nonprivileged layout-only Gateway evidence connection and requires pinned application and bot IDs. The equivalent discord://guilds/{guildId}/community resource applies the same policy and privacy projection.

Every read verifies the expected application and bot, exact guild and owner, non-pending connector membership, complete bounded roles, known effective permissions, a complete guild feature list, and continuity-safe direct-channel evidence. It reports whether Community is enabled, exact routing IDs and trusted metadata for rules, public updates, and optional safety alerts, whether @everyone can view and send in the rules channel, bounded feature count and digest, a content-free state digest, minimized authority evidence, fixed warnings, privacy guarantees, and verification boundaries. Guild, channel, and role names, topics, member profiles, raw feature values, raw permission bits, and raw payloads are omitted. Unknown permission bits, malformed or incomplete guild evidence, duplicate feature values, an obfuscated selected channel, or an unsupported selected channel type fails closed. An invisible existing rules channel is reported as an issue, while an invisible desired rules channel blocks planning.

Changes have no immediate-call path. Set capabilities.guildCommunityChanges: true in addition to audit scope. The strict request is one complete monotonic target:

{
  "acknowledgeCommunityEnablement": true,
  "auditReason": "Reviewed Community routing",
  "guildId": "100000000000000001",
  "operationKey": "community-change-attempt-0001",
  "publicUpdatesChannelId": "200000000000000002",
  "rulesChannelId": "200000000000000001",
  "safetyAlertsChannelId": null
}

Rules and public-updates channels must be distinct direct text or announcement channels. The optional safety-alerts target may reuse another selected channel. The acknowledgement is always required because a fresh plan may discover that Community must be enabled even when an earlier read found it present. The request cannot disable Community, provide a feature array, infer a channel from its name, create or move a channel, grant a permission, or change any unrelated guild field.

Planning adds COMMUNITY to the complete observed feature set while preserving every existing feature. If Community is absent, the exact guild owner or complete ADMINISTRATOR authority is required and the plan warns that the broad grant should be removed after enablement. If Community is already present, an exact owner or complete MANAGE_GUILD authority is sufficient for routing-only changes, and an unnecessary Administrator grant is reported as a least-privilege warning. The connector never grants or removes a Discord permission. A rules target must be visible to @everyone; ordinary-member sendability is review evidence and a warning rather than an automatic overwrite change. Updates and safety targets need not be public.

1. Call audit_guild_community to inspect Community presence, exact routing, content-free feature and state digests, connector authority, trusted channel evidence, rules access, warnings, and verification limits.
2. Call plan_guild_community_change with the complete desired routing state, explicit enablement acknowledgement, Discord audit-log reason, and a unique one-shot operation key.
3. Review the exact application, bot, guild, current and desired state, preserved feature count and digest, changed fields, enablement requirement, dynamic permission requirement, channel and rules-access evidence, risks, warnings, operation-key hash, and keyed digest.
4. If the plan reports already-current, no confirmation, claim, reservation, activity record, or Discord write is needed.
5. Call execute_guild_community_change with identical inputs plus the digest.
6. Approve the signed MCP confirmation only if every identity, digest, routing ID, permission decision, acknowledgement, risk, warning, audit reason, operation-key hash, and plan digest remains intended, then inspect the exact verification result before removing any temporary Administrator grant.

The process-keyed plan digest binds the normalized complete target, verified identities, exact guild owner, connector membership and roles, complete permission evidence, continuity-safe channel evidence, current and desired state digests, every preserved feature through its content-free digest, routing references, rules access, acknowledgement, privacy boundary, risks, warnings, audit reason, and one-shot key hash. A connector restart invalidates outstanding plans. The MCP adapter rebuilds the plan before approval, and the domain service rebuilds and matches it again immediately before mutation. Any identity, feature, routing, permission, channel-layout, rules-access, request, reason, or key drift invalidates the reviewed plan.

Execution acquires a durable exact guild community collection claim, atomically reserves the one-shot key, and appends pending content-free activity before one non-retried Modify Guild request carrying the encoded audit-log reason. The request sends the complete preserved feature array with COMMUNITY present and the three exact routing values. A strict authoritative response and an independent fresh full readback must both retain every baseline feature, retain Community, and match every routing value. A definite Discord client refusal other than rate limiting is failed. Rate limiting, transport ambiguity, Discord server failure, malformed success, feature loss, routing mismatch, unreadable readback, or durable finalization failure is uncertain, spends the key, and quarantines later same-guild Community changes for operator review. The connector never retries, rolls back, compensates, or guesses whether the write landed.

Activity records contain only the exact guild and routing IDs, changed-field names, whether enablement was required, content-free state digest, plan and operation-key digests, timestamps, fixed outcome and verification values, activity ID, and a sanitized error category. Operation receipts use the existing content-free outcome shape. Feature values, names, topics, profiles, permission evidence, audit reasons, raw operation keys, raw requests or responses, credentials, and transport causes never enter durable records, diagnostics, or telemetry. See Discord's Modify Guild endpoint and permission flags.

Canonical source: docs/reference.md