Privacy-minimized guild incident actions and reviewed lockdown changes

get_guild_incident_actions returns one separately allowlisted guild's current invite and direct-message disable-until values plus privacy-minimized detection evidence. Set capabilities.guildIncidentAudit: true and list every eligible guild in scopes.guildIncidentGuildIds. This allowlist must be a subset of readScope.guildIds. The equivalent discord://guilds/{guildId}/incident-actions resource applies the same scope and projection. The deterministic incident-response recipe adds this audit, the separately gated change workflow, the exact guild scope, and the guild-incidents toolset without adding a Gateway connection or privileged intent.

Every audit verifies the configured application and bot identities, exact guild and owner, current connector membership, a complete bounded role inventory, and complete effective guild permissions. The result retains exact action deadlines but reduces Discord's raid-detected and direct-message-spam-detected timestamps to booleans. Guild and role names, raw detection timestamps, raw payloads, and unknown values are omitted; future fields appear only as a count. An absent incidents_data source is reported explicitly instead of being interpreted as an all-clear state.

Changes have no immediate-call path. Set capabilities.guildIncidentChanges: true in addition to the audit gate and exact scope. A strict sparse request must include invitesDisabledUntil, directMessagesDisabledUntil, or both, plus a bounded local review reason and a unique one-shot operation key. An omitted action is preserved. null deliberately clears one action before its existing deadline. A non-null value must be an exact ISO 8601 timestamp with an offset, must still be in the future, and must be no more than 24 hours ahead during every planning pass. The endpoint does not document X-Audit-Log-Reason, so auditReason is bound into the local review digest but is not sent to Discord.

Planning requires an available exact incident object with no unknown fields, complete known permission bits, and either exact guild ownership or effective MANAGE_GUILD. It reports the complete current and desired action state, requested and changed field names, presence-only detection evidence, disable, extend, shorten, or clear effects, privacy and verification boundaries, risks, warnings, the operation-key hash, and a process-keyed digest. Imposing a guild-wide communication restriction and clearing protection early are both high-impact destructive changes. Detection evidence, authority, roles, permissions, action deadlines, intent, local reason, or operation-key drift invalidates the review.

1. Call get_guild_incident_actions to inspect current deadlines, detection-presence signals, authority, schema-drift count, privacy projection, and verification limits.
2. Call plan_guild_incident_action_change with only the intended action fields, the local review reason, and a unique one-shot operation key.
3. Review the verified application and bot IDs, exact guild, complete current and desired action state, requested and changed fields, effects, authority, risks, warnings, local reason, operation-key hash, and keyed digest.
4. If the plan reports already-current, no confirmation, reservation, activity record, or Discord write is needed.
5. Call execute_guild_incident_action_change with identical inputs plus the digest.
6. Approve the signed MCP confirmation only if every displayed identity, deadline, effect, authority decision, risk, warning, local reason, operation-key hash, and digest remains intended, then inspect the exact verification result.

Execution rebuilds the plan before approval and again immediately before mutation. The production facade acquires a durable exact guild incident-actions collection claim, then the service atomically reserves the operation-key hash and appends a pending content-free activity record. It sends exactly one non-retried sparse PUT containing only changed action fields and no undocumented audit header. Discord's returned Incidents Data object must contain exact known action fields, and a fresh guild, member, role, permission, and incident-state read independently verifies both controlled fields. This catches changes to an unrequested action as well as divergence in the requested action.

Exact response and readback agreement is completed. Valid response or readback divergence is completed-with-drift and reports only controlled field names. A definite Discord client refusal is failed. Rate limiting, transport failure, Discord server error, malformed success, unknown response fields, failed response validation, failed readback, or failed receipt finalization is uncertain and may have completed. Every reserved key remains spent, the connector never retries, rolls back, or compensates automatically, and an uncertain result retains the durable guild claim until an operator inspects Discord and resolves the content-free coordination record.

Activity and operation records contain only the exact guild ID, plan digest, operation-key hash, record timestamps, fixed verification and outcome values, activity ID, sanitized error category, and sorted requested field names where applicable. Action deadlines, detection timestamps, local review reasons, guild and role names, permission evidence, raw operation keys, raw payloads, and transport causes never enter durable records, diagnostics, or telemetry. Discord automatically expires each non-null action deadline; the connector does not schedule a second write. See Discord's Incidents Data object and Modify Guild Incident Actions endpoint and permission flags.

Canonical source: docs/reference.md