Privacy-safe application-owned emojis and reviewed changes

list_application_emojis, get_application_emoji, and discord://application/emojis expose the verified current application's complete bounded emoji inventory or one exact inventory member. Enable reads with capabilities.applicationEmojiAudit: true and include the application-emojis toolset when selecting toolsets. This feature requires pinned application and bot identities but no guild allowlist, caller-selected application ID, guild permission, or privileged intent.

Every response is projected at the REST boundary to the emoji ID, normalized name, animation, availability, managed state, colon requirement, uploader-projection proof, and unknown-field counts. The client requires the application-specific empty role array and a valid uploader object, then discards both before the data reaches MCP. Image bytes, CDN URLs, uploader IDs and profiles, raw Discord objects, role IDs, and unknown-field values are omitted and never persisted.

Enable reviewed create, rename, and delete with capabilities.applicationEmojiChanges: true in addition to audit. Creation also requires at least one absolute canonical owned directory in storage.applicationEmojiRoots. Creation accepts one JPEG, PNG, GIF, WebP, or AVIF file up to Discord's application-emoji byte limit. It never accepts a remote URL, data URL, base64 payload, arbitrary bytes, directory, or relative path. Rename and delete identify one exact emoji ID; delete additionally requires acknowledgeGlobalImpact: true because an application emoji can be used across every installation of the application.

Planning requires a complete known unmanaged inventory. Unknown response or emoji fields, managed or non-colon emoji state, duplicate IDs, absent rename targets, exact-name collisions, capacity exhaustion, malformed evidence, and unsafe local files fail closed. The plan binds the verified application and bot, complete sorted inventory digest, current and desired metadata, action-specific request, domain-separated operation-key hash, and a stable owned-file byte snapshot when creating. Because Discord does not expose stored image bytes for readback, creation verification proves exact returned and freshly read metadata but explicitly does not claim stored-byte equality. Discord's application-owned emoji reference documents the application-wide endpoints, supported upload formats, size boundary, and bot-token authentication; it does not document an audit-log reason parameter, so this workflow accepts and sends no audit reason.

Use the workflow in this order:

1. Call list_application_emojis or read discord://application/emojis when an inventory review is useful.
2. Call plan_application_emoji_change with exactly one create, rename, or delete request and a unique operation key.
3. Review the identity, application-wide impact, complete inventory evidence, current and desired metadata, local file evidence when present, privacy omissions, risks, warnings, verification boundary, and keyed digest.
4. Call execute_application_emoji_change with the identical request and digest. A compatible MCP host must grant write approval and return the signed interactive confirmation requested by the server.
5. The connector rebuilds the complete plan immediately before mutation and rejects any identity, inventory, file, target, name, capacity, or intent drift.
6. After the pending content-free activity record succeeds, the connector issues one non-retried mutation and requires exact metadata or complete-inventory absence readback.

An already-current rename or already-absent delete is an operation-record-free no-op: it requests no confirmation, reserves no key, writes no activity, and calls no mutation route. The production facade may briefly serialize the application collection while rechecking that no-op. Every real change acquires one application-wide collection claim, so connector processes sharing the activity-state root cannot overlap changes under different operation keys. A reserved key stays spent after every outcome. A known pre-response Discord client rejection is failed; transport ambiguity, rate limiting, server failure, malformed mutation evidence, post-write readback failure, or failed durable receipt finalization is uncertain and may have completed. Uncertain outcomes retain the application-wide claim and quarantine queued same-application work until an operator inspects Discord and resolves the durable evidence. The connector never retries, compensates, restores, or rolls back automatically.

Application-emoji activity and operation records contain only application and emoji IDs, action, plan digest, operation-key hash, timestamps, fixed verification and outcome values, activity ID, and sanitized error category. Names, local paths, file metadata, image bytes, content digests, uploader data, raw operation keys, raw responses, and private evidence remain absent.

Canonical source: docs/reference.md