Privacy-safe guild integration audit and reviewed deletion

list_guild_integrations exposes one bounded privacy-safe inventory for a separately allowlisted guild. Set capabilities.integrationAudit: true and list every eligible guild in scopes.integrationGuildIds. The integration-guild allowlist must be a subset of readScope.guildIds when the outer read allowlist exists. Every read verifies the expected application and bot, exact guild and owner, connector membership, complete bounded roles, and effective guild-level MANAGE_GUILD. The equivalent discord://guilds/{guildId}/integrations resource applies the same checks and projection.

The REST client projects each raw integration before returning it to the service. Results expose the exact integration ID and normalized type; optional role, application, and associated bot IDs; lifecycle and synchronization state; safe numeric counts; sorted recognized OAuth scope names; count-only unknown scopes and fields; and an explicit privacy contract. Integration, external account, application, user, and bot names and profiles, external account IDs, descriptions, icon hashes, raw payloads, and unknown field values are omitted and never persisted. A future integration type is returned as unknown for audit rather than guessed.

Discord documents a hard endpoint maximum without pagination. A response at that boundary is therefore marked inventoryComplete: false; it remains readable but cannot support deletion. A shorter strictly validated inventory is treated as complete. The connector requires unique exact IDs and rejects malformed identities, timestamps, scope names, duplicate scopes, invalid optional fields, and any response above its safety limit.

Integration deletion has no immediate-call path. Set capabilities.integrationDeletions: true, keep audit enabled, and list every eligible exact integration ID in scopes.integrationIds. The target guild and integration must pass both dedicated allowlists. guild_subscription entries remain audit-only. Any unknown integration type, scope, or field anywhere in the complete inventory blocks change planning because a privacy-discarded value cannot be reviewed safely. The connector also rejects its own application integration, its own bot identity, and any associated bot in scopes.protectedUserIds.

1. Call list_guild_integrations and identify the exact target from its ID, type, application and bot IDs, lifecycle state, known scopes, future-field counts, access evidence, privacy omissions, and completeness verdict.
2. Call plan_guild_integration_deletion with the exact guild and integration IDs, both explicit side-effect acknowledgments, a bounded Discord audit-log reason, and a unique one-shot operation key.
3. Review the exact identity, complete inventory, target, current associated-bot membership, MANAGE_GUILD evidence, privacy projection, endpoint limitation, acknowledgments, warning set, operation-key hash, and keyed digest.
4. Call execute_guild_integration_deletion with identical inputs plus the digest.
5. Approve the signed MCP confirmation only if every exact identity, omission, side effect, permission, reason, operation-key hash, and digest remains intended.
6. Review the target-absence and non-target-unchanged verdicts, activity ID, and outcome before any follow-up.

Discord deletion permanently removes the integration, removes its associated webhooks, and can kick its associated bot. Discord does not expose the exact associated webhook impact set before deletion. The request must always acknowledge webhook removal, and it must separately acknowledge the bot kick when an associated bot ID exists. Planning checks that bot's exact current membership without enumerating members and binds the result into the digest. These acknowledgments document informed intent; they do not replace the other authorization or freshness gates.

The process-keyed digest binds the normalized request, one-shot operation-key hash, pinned identities, exact guild and owner, connector member and complete roles, effective permission evidence, complete projected integration inventory, associated-bot membership, privacy contract, acknowledgments, and warnings. The adapter rebuilds that plan before signed approval, and the service rebuilds it immediately before mutation. A connector restart or any reviewed state change invalidates the digest.

Execution durably coordinates the exact integration, guild integration collection, guild webhook collection, and associated bot member when one exists. It atomically reserves the operation-key hash, appends pending content-free activity, sends one non-retried bot-authenticated DELETE with the reviewed audit reason, and fetches a complete fresh inventory. Completion requires the target to be absent and every non-target entry to be byte-for-byte unchanged under the canonical projection. Discord supplies no conditional delete that atomically binds the prior inventory, so prevent concurrent integration or webhook administration during a high-risk change.

A known Discord client refusal other than request timeout or rate limiting may settle as failed. Transport failure, rate limiting, server failure, malformed evidence, incomplete or drifting readback, or any otherwise indeterminate post-reservation state is uncertain and may represent a completed deletion. Every reserved key remains permanently spent, and an uncertain outcome retains durable claims and a process-local same-guild quarantine for operator review. The connector never retries, compensates, reinstalls a bot, or recreates webhooks automatically.

Integration-deletion activity and operation records contain only exact guild, integration, target application, and associated bot IDs, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Names, external account identities, descriptions, icons, profiles, audit reasons, raw operation keys, OAuth values unknown to the connector, raw responses, and transport causes never enter persistent records, diagnostics, or telemetry. See Discord's guild integration resource, integration endpoints, OAuth2 scope reference, Social SDK scopes, and permission flags.

Canonical source: docs/reference.md