Reviewed global application-command lifecycle

plan_global_application_command_change, execute_global_application_command_change, and review_global_application_command_change belong only to the application-commands toolset. Enable capabilities.globalApplicationCommandChanges; no guild allowlist, caller-selected application ID, guild permission, privileged intent, or user-authorized Bearer token participates. The workflow is bound to the same operator-owned application and bot identities pinned in policy and freshly verified from the external bot credential. Guild command changes, the fixed native Interaction command, command exposure audit, and another application's commands remain separate authorities.

Every create request includes acknowledgeGlobalExposure: true and one complete canonical chat-input, user, message, or Primary Entry Point definition. Every update includes the same exposure acknowledgement, one exact command ID, and one complete replacement definition with immutable type. A rename additionally requires acknowledgePermissionResetAcrossGuilds: true. Every deletion requires the exact command ID plus acknowledgeGlobalDeletion: true and acknowledgePermissionResetAcrossGuilds: true. Definitions use explicit nonempty canonical contexts and integrationTypes arrays rather than mutable application defaults, named default member permissions or null, explicit NSFW state, complete localizations, and strict type-specific fields. Private-channel context requires User Install, every requested installation type must be supported by fresh application configuration, and a Primary Entry Point additionally requires fresh EMBEDDED application evidence and one documented handler.

Planning re-verifies the pinned application and bot, requires complete known application installation configuration, and fetches the complete global command inventory with full localizations. Every command is projected into the same strict definition and checked for exact application ownership, unique ID, unique name-and-type identity, supported installation types, and documented type and total capacity. The keyed plan binds fresh application support, EMBEDDED state, the complete inventory and digest, exact command IDs and versions, transient names and definition digests, separate type capacities, complete current and desired definitions, collision and no-op decisions, global exposure and permission-reset consequences, privacy claims, risks, warnings, one-shot operation-key hash, and the exact readback contract. Malformed, duplicated, unknown, incomplete, unsupported, colliding, absent, type-mismatched, over-capacity, or changed evidence blocks the write. An already-current update or already-absent deletion returns without confirmation, coordination, reservation, activity, or mutation.

Discord's global create route can return 200 after overwriting an existing same-name and same-type command. The connector accepts only a newly created response, so this upsert behavior cannot silently replace a command. Update submits one non-retried complete definition to the exact-ID route, and delete sends one non-retried exact-ID request. Discord permanently clears a global command's permissions in every guild when it is renamed or deleted, but a bot token cannot enumerate or modify all such permission targets because permission writes require a user Bearer token. The plan therefore exposes this unbounded cross-guild consequence, requires the matching acknowledgement, and never claims to list affected guilds or permission targets. Global bulk overwrite, partial definitions, raw REST bodies, name-targeted writes, type changes, application-default inheritance, permission writes, propagation polling, retries, and rollback are unavailable.

Execution requires a fresh matching keyed plan, MCP host write approval, signed request state, explicit interactive confirmation, and another fresh exact match. The signed state contains only the action, exact command ID, canonical definition digest, acknowledgement booleans, operation-key hash, and plan digest, never command text or the raw operation key. The production facade durably claims the pinned application's global-command collection before atomically reserving the one-shot key and appending pending content-free activity. It sends exactly one mutation, validates the exact response when present, then rereads the complete localized inventory. Creation requires one exact new command and exact unrelated survivors. Update requires one exact replacement and exact unrelated survivors. Deletion requires target absence and exact survivors. Discord clients converge through documented read-repair after the authoritative API state changes; the connector does not poll user clients or claim immediate presentation everywhere.

A deterministic Discord client refusal other than timeout or rate limiting may settle as failed. Rate limiting, transport ambiguity, server failure, malformed success, response mismatch, complete readback failure, survivor drift, or completion-record failure is uncertain and may have changed Discord. Every reserved key remains spent, the application-wide global-command collection remains quarantined for the process lifetime, and the connector never retries, bulk reconciles, compensates, recreates, restores permissions, or rolls back automatically. Activity and operation records contain only exact application, bot, and command IDs; command type; definition, inventory, plan, and operation-key digests; timestamps; fixed status and verification values; activity ID; and sanitized error category. They never contain command, option, choice, or localization text, permission target IDs, application or bot profile text, raw requests or responses, raw keys, credentials, transport causes, or audit reasons. Discord's application-command contract and Primary Entry Point setup guide define the external behavior.

Canonical source: docs/reference.md