MCP field guide / Discord
// mcp field guide · community
There's no official Discord MCP — the space is filled by community projects that expose the Discord bot API as tools. An agent driving one can post messages (irreversible once seen, like Slack), delete a channel (taking its whole history with it), and ban members. The real risk isn't any one tool — it's the bot token's scope. Here's the sourced read.
GUARD FIT · READS
PASS-THROUGHRead messages, list channels/members/roles, server info. No side effect — gating adds friction.
GUARD FIT · SEND + MODERATION
STRONGPosting is irreversible once seen; deleting a channel loses its history; ban/kick and role/permission edits are high-blast-radius.
Overall fit: STRONG on the send + destructive-moderation surface; weak on reads.
As of Aug 2026, Discord publishes no first-party MCP server. The ecosystem is fragmented across several independent, MIT-licensed community projects — the most prominent being SaseQ/discord-mcp (Java/JDA, ~65 tools spanning messaging, channels, roles, moderation, events, permissions, forums) with barryyip0625/mcp-discord (TypeScript) as an actively-developed alternative. Each runs self-hosted and authenticates as a Discord bot via a bot token — so everything it can do is bounded by that bot's granted permissions.12
Names below are verbatim from the SaseQ/discord-mcp README (the canonical server); the alternative uses its own discord_* naming.
| Tier | Tools |
|---|---|
| read-only | get_server_info, read_messages, list_channels, get_channel_info, list_roles, get_bans, list_invites, list_forum_posts, list_emojis |
| mutating | send_message*, edit_message, add_reaction, send_webhook_message*, create_text_channel, create_role, assign_role, create_webhook, timeout_member (reversible), set_nickname |
| destructive | delete_message, delete_channel/delete_category (takes history), ban_member/kick_member, delete_role, upsert_*_channel_permissions, delete_webhook, disconnect_member |
* Posting is "mutating" by API shape but irreversible in practice. send_message/send_webhook_message are delivered the instant they return; once a person, bot, or webhook consumer has seen the message, a later delete_message does not un-send it — the same property as Slack. And delete_channel removes the channel's entire message history, which is not recoverable via the API.
Community management assist. Read recent messages, summarize activity, draft or apply moderation (timeout, or a kick/ban queued for human approval).
Server automation / ops. Create channels, categories, roles, scheduled events and webhooks — e.g. spin up a per-incident channel and post release notes via webhook.
Feedback triage. Search and read forum posts and channels to cluster user feedback or route support.
Reads → pass through. get_server_info, list_*, read_messages change nothing.
Send → strong (irreversible once seen). A pre-post human checkpoint on send_message/send_webhook_message is meaningful precisely because after-the-fact deletion doesn't un-say what people and webhooks already received. A "compensation" of deleting the message must be reported honestly as partial — it does not undo delivery.
Destructive moderation & structure → strong. ban_member/kick_member are real access/social events; delete_channel/delete_category take message history with them; role and permission edits (delete_role, upsert_*_channel_permissions) change who can see and do what, server-wide. These deserve mandatory approval and an honest "irreversible" flag.
The core risk is the bot token itself. The server acts as a bot with whatever permissions it was granted — a broadly-scoped token (Administrator, Manage Channels, Ban Members, Manage Roles) hands an autonomous agent server-wide destructive reach. A guard on the send + destructive-moderation surface addresses the "over-permissioned community bot driven by an agent" threat model directly; it cannot shrink the token's scope, which stays a Discord-side permission-hygiene job. Compensation is not undo — decide before you post, ban, or delete.
ChronoMCP holds send_message, ban_member, delete_channel and permission edits for a human — reads flow through.
Profiles describe third-party software from its public sources. These are independent, unofficial community projects (there is no first-party Discord MCP); described factually without endorsement or disparagement. Tool names are from the canonical server's README; the alternative uses its own naming. The landscape is fragmented — "canonical" means most-prominent, not standard. Sources current as of Aug 2026 — check the source links.