MCP tool surface

The catalog command is a separate credential-free trust boundary. It must build the full production registration surface from fixed internal configuration without consulting ambient credentials, policy, activity paths, attachment roots, Gateway settings, or telemetry settings. It must not construct a Discord client or operational service. Replace low-level tool dispatch before the transport connects so listed tools, invalid arguments, discovery, disabled capabilities, and unknown names all return the same fixed CATALOG_ONLY result without reaching a registered handler.

Keep catalog checks self-contained and content-free. They may negotiate the four MCP catalogs, inspect schemas and annotations, render validated prompts, and read static safety or fixed policy guidance. Live Discord, activity, Gateway-event, and operational observability reads must remain unavailable. The check report may contain only fixed safety claims, package identity, schema version, and catalog counts. Pack verification must exercise the installed check without providing a bot token.

Publish one deterministic machine-readable access contract for every canonical tool and the local discovery tool. Classify each as local, live read, reviewed plan, reviewed execution, receipt verification, or guarded write; identify every exact reviewed workflow companion; and bind the manifest into credential-free catalog evidence. Treat this metadata only as an explanation of the authorization lifecycle. It must never grant authority, claim target readiness, replace tool annotations, expose an excluded tool through progressive discovery, or bypass the operation's exact identity, policy, scope, permission, hierarchy, intent, approval, freshness, coordination, recovery, and verification checks.

Keep tools.surface set to full for clients that already defer tools natively. This retains each canonical tool's exact name, schema, annotations, and approval identity while the client controls context loading. The portable progressive mode may hide a canonical tool only by disabling its registration through the MCP SDK. discover_discord_tools must reveal and enable those same registrations through standard tool-list change notifications; do not replace exact tools with a generic read, write, or destructive dispatcher.

Tool discovery is local and bounded. It must never contact Discord, return its query, log tool arguments or results, or reveal a tool excluded by tools.toolsets. Exact-name results may return the canonical input contract. Broader results must remain bounded, and an already enabled result must not create another list-change notification.

Treat toolsets as a reduction in callable surface, never as authorization. Discord permissions, capability gates, exact allowlists, protected targets, reviewed plans, approvals, signed confirmation, freshness checks, operation-key reservation, and pending activity records remain authoritative even when a tool is selected. Keep guild audit logs, permission diagnostics, channel metadata changes, channel-order audit and changes, forum-tag audit and changes, message pins, reaction lifecycle, component messages, exact-recipient direct messages, announcement crossposts, message forwarding, announcement subscriptions, native polls, credential-safe webhook administration and its private message lifecycle, guild integration audit and deletion, invite and vanity URL audit and invite revocation, native Guild Templates, guild onboarding, Welcome Screens, authenticated widget settings, application-owned emojis, guild expressions, scheduled events, Stage instances, member voice moderation, thread governance, attachments, forum posts, guild scaffolds, channel creation, role creation, role configuration, role deletion, role ordering, message deletion, and moderation in their deliberately selected toolsets. Reveal every private-message read, plan, verification, and execution tool together, reveal the component preview, plan, and execution tools together, and reveal every other reviewed plan-plus-execute pair together, so clients cannot discover an incomplete reviewed workflow. Keep audit_channel_order, channel-deletion readiness, and audit_role_deletion independently discoverable because audit and mutation have separate policy gates.

Keep both single-member and bulk member-role planners and executors in member-roles, while preserving independent capability and scope checks inside each service.

Keep named guild-settings audit and changes in the dedicated guild-settings toolset, keep guild incident-action audit and changes in the dedicated guild-incidents toolset, and reveal each planning and execution pair together.

Canonical source: SECURITY.md