Reviewed member verification-bypass changes

Member verification-bypass changes have no immediate-call path and inherit no authority from member reads, nickname changes, role changes, moderation, or voice administration. Set capabilities.memberVerificationChanges: true, configure a non-empty exact scopes.memberVerificationGuildIds, keep that allowlist inside readScope.guildIds, select the independent member-verification toolset, and list every ineligible operator, service account, and break-glass identity in scopes.protectedUserIds. Configuration rejects an enabled capability with no exact guild scope.

Each request contains exactly one guild ID, one member user ID, the desired bypassesVerification boolean, a Discord audit-log reason, and one unique one-shot operation key. Arbitrary flags, numeric bitmasks, display names, member searches, bulk targets, full-member payloads, and additional fields are rejected before service access. The public plan and result expose only the named current, desired, and observed BYPASSES_VERIFICATION boolean; raw flags never cross MCP.

1. Call plan_member_verification_change with the exact boolean intent and one-shot key.
2. Review the pinned identities; exact guild and member IDs; transient untrusted guild name and username; pending Membership Screening state; current and desired named state; documented authorization path; complete effective permission and unknown-bit evidence; protected and special-member boundaries; strict hierarchy; privacy projection; risks; warnings; audit reason; operation-key hash; creation time; write requirement; and keyed digest.
3. Call execute_member_verification_change with the identical intent and digest.
4. Approve the signed MCP confirmation only if every exact ID, boolean, permission alternative, hierarchy result, reason, warning, risk, hash, and digest remains intended.
5. Review the exact named-state readback, activity ID, verification state, and outcome before any related operation.

Planning verifies the exact guild and owner, pinned connector-bot membership, exact target membership, and complete bounded role inventory. Bot and target evidence must contain a nonnegative safe-integer flags value, exact identities, well-formed transient names, unique known roles, and one unambiguous highest role. The target cannot be the connector bot, another bot account, the guild owner, a configured protected user, an administrator, or a member at or above the connector bot's unique highest role. A target still pending Membership Screening is deliberately allowed and surfaced because that is the primary use of the bypass.

A verified guild owner is authoritative; otherwise Discord documents three permission alternatives: MANAGE_GUILD, MANAGE_ROLES, or the complete combination of MODERATE_MEMBERS, KICK_MEMBERS, and BAN_MEMBERS. The plan names the path actually proven and warns when the connector has ADMINISTRATOR or guild ownership because either is broader than this workflow. Missing or incomplete permission evidence, ambiguous hierarchy, unknown member role references, malformed flags, a spent operation key, or a prior quarantined same-member outcome fails closed.

The process-keyed plan digest binds the current raw flags, the exact desired raw value, every unrelated preserved bit, complete identity, guild, member, role, permission, hierarchy, policy, request, privacy, risk, and warning evidence, and the domain-separated operation-key hash. Those raw values remain private internal freshness evidence. An already matching named state is a verified no-op that requires no elicitation, reservation, activity record, or Discord mutation.

A real execution rebuilds the complete plan, durably coordinates the exact member and guild member collection across connector processes sharing the activity-state root, reserves the one-shot key, and appends pending content-free activity before Discord contact. It performs one non-retried PATCH to /guilds/{guild.id}/members/{user.id} with an internally derived flags value that changes only the named bit. It strictly validates the exact returned member identity, raw flags, and named state, then performs one exact member readback and independently verifies the named state plus preservation of every unrelated reviewed bit. The workflow never retries, rolls back, reconciles, or rewrites another member field.

Exact response and readback agreement produces completed; a valid response or readback with a different named state or unrelated-bit drift produces completed-with-drift. A known non-rate-limited Discord 4xx refusal before a valid response is failed. Rate limiting, transport or server failure, malformed or mismatched success evidence, readback failure, or any other indeterminate post-reservation state is uncertain and potentially completed. Every reserved key remains spent. Uncertainty retains the durable exact-member claim for operator review and blocks later overlapping same-member work across reviewed workflows.

Durable activity and operation records contain only the desired named boolean, exact guild and member IDs, plan digest, domain-separated operation-key hash, timestamps, fixed status and verification values, activity ID, and sanitized error category. Raw member flags, usernames, guild and role names, permission and hierarchy evidence, audit reasons, raw operation keys, request and response bodies, routes, and transport causes never enter persistent records or telemetry. Use review_member_verification_change for a locally validated plan-only prompt, and inspect the exact member plus Discord audit log before forming a new intent after uncertainty. See Discord's Guild Member Flags and Modify Guild Member contracts.

Canonical source: docs/reference.md