Discord MCP: Bots, Channels and Caution

As of September 30, 2026, Discord does not publish an official MCP server. When people say “Discord MCP” they mean a community-built server that wraps the Discord API and signs in with a bot token: you create a bot in the Discord Developer Portal, invite it to your server, and hand its token to the MCP server, which exposes tools such as reading a channel, sending a message or creating a thread. The assistant can then do whatever that bot can do, in every server the bot has joined. That makes the bot’s permissions, its intents and where its token lives the whole security story. Start with a bot that can read one channel, keep posting and moderation behind a person, and treat every message it reads as untrusted.

If MCP is new to you, what MCP is covers the basics. This guide is about Discord specifically.

Is there an official Discord MCP server?

No. Discord’s developer documentation covers bots, OAuth2, webhooks and the Gateway, but not an MCP server of its own. The servers you will find are open source projects run by individuals, and none of them is reviewed or endorsed by Discord. Three that come up most often, described from their own READMEs:

• SaseQ/discord-mcp↗ (opens in a new tab): written in Java, run as a Docker container, with an HTTP mode the README recommends. It lists more than 50 tools, among them sending, editing and deleting messages, creating and deleting channels, managing roles and webhooks, and kicking, banning and timing out members.
• barryyip0625/mcp-discord: a Node.js server started with npx mcp-discord or Docker, over stdio or Streamable HTTP. Its README asks for the Message Content, Server Members and Presence intents and a long list of permissions including Manage Roles, Manage Channels and Manage Webhooks, or Administrator for full access.
• The mcp-discord entry in Docker’s MCP Catalog↗ (opens in a new tab), built from the slimslenderslacks/mcp-discord project, with 20 tools and one secret, DISCORD_TOKEN.

Notice what they have in common: broad tool lists that include destructive actions, and one long-lived token. That is not a flaw in any one project; it is what a Discord bot is. How to weigh a third-party server before you install it is covered in MCP security risks.

How a Discord bot with MCP works

There are three pieces. The Discord application and its bot user, which you create in the Developer Portal. The bot token, which authenticates every API call the bot makes. And the servers (guilds, in the API) the bot has been installed into, each with the permissions it was granted there.

Discord’s getting started guide↗ (opens in a new tab) is blunt about the token: it authorizes API requests and carries your app’s permissions, and the guide calls tokens “highly sensitive.” It tells you never to share it or commit it to version control, and to reset it on the Bot page if you suspect it has leaked. Installing the bot into a server means choosing the bot scope and a set of permissions, and the person installing it needs the Manage Server permission there.

The MCP server holds that token and translates tool calls into API calls. It does not know who in your team asked for an action. Every message it sends, every channel it deletes, shows up in Discord as the bot, no matter which person or assistant was driving. Unlike Slack’s official server, which signs in as each person with OAuth scopes (see Slack MCP server), a Discord bot is one shared identity.

Setting one up in Claude Code

1. Create a private test server in Discord. Do the first run there, not in your community.
2. In the Developer Portal, create an application, open the Bot page, and reset the token to reveal it. Store it in a password manager; you cannot view it again without resetting.
3. Under Privileged Gateway Intents, turn on only what you need. For reading channel text that is Message Content; leave Server Members and Presence off unless a tool you use requires them.
4. Generate an install link with the bot scope and the smallest set of permissions: View Channels and Read Message History to read, Send Messages only if it must post.
5. Start the MCP server with the token in an environment variable, then add it to your client.

With SaseQ’s server in HTTP mode, the README’s commands look like this. Binding the port to 127.0.0.1 is an addition worth making: without an address, Docker publishes the port on every network interface, and anything that can reach it can drive your bot.

export DISCORD_TOKEN=...        # from the Bot page, never committed
export DISCORD_GUILD_ID=...     # your test server's ID

docker run -d -i --name discord-mcp --restart unless-stopped \
  -p 127.0.0.1:8085:8085 \
  -e SPRING_PROFILES_ACTIVE=http \
  -e DISCORD_TOKEN -e DISCORD_GUILD_ID \
  saseq/discord-mcp:latest

claude mcp add discord-mcp --transport http http://localhost:8085/mcp

Run /mcp in Claude Code to confirm it is connected. For a stdio server, the Claude Code MCP docs show the pattern: claude mcp add --env KEY=value --transport stdio <name> -- <command>. If it lists the server but will not connect, Claude Code MCP not working walks through the checks. Pin an image tag or package version once it works, so an update does not change the tools under you.

Intents and permissions: what the bot can actually see

Discord’s Gateway documentation↗ (opens in a new tab) names three privileged intents: GUILD_PRESENCES, GUILD_MEMBERS and MESSAGE_CONTENT. Without Message Content, the bot still receives message events, but content, embeds, attachments, components and poll arrive empty, except in messages the bot sent, direct messages to the bot, messages that mention it, and messages targeted by its context menu commands. Apps with fewer than 10,000 users can switch privileged intents on in the portal; past that, Discord reviews the use case. Discord also asks apps to enable only the intents they need.

Permissions are the other half. Discord’s permissions reference↗ (opens in a new tab) says Administrator “allows all permissions and bypasses channel permission overwrites,” so a bot with it ignores every private-channel rule you have set. Some community READMEs offer Administrator as the easy path. Do not take it. Grant permissions per channel with overwrites instead, so the bot can read #bug-reports and nothing else, and leave Manage Roles, Manage Channels, Manage Webhooks, Kick Members and Ban Members off unless a person has decided the bot should moderate.

The risks, in order of likelihood

• Prompt injection from members. In a community server, anyone who can post can write text the assistant will read, including instructions aimed at it. A bot that reads a public channel and can also send, delete or ban is the classic setup for indirect prompt injection.
• A leaked token. The token is the bot. It sits in an environment variable, a .env file or an MCP config, and one careless commit hands the bot to whoever finds it. Reset it the moment you suspect exposure.
• Actions nobody meant. A model that misreads “clean up the thread” can delete messages, and deletes are not undone. Moderation tools at a model’s discretion are the fastest way to lose a community’s trust.
• Mass notifications. A message with @everyone or @here, or a DM sent to many members, cannot be pulled back from people’s notifications.
• Third-party code. The server runs with your token. Read the tool list, check how recently it was maintained, and prefer one you can run in a container with nothing else mounted.
• Mixing servers. A bot connected alongside other MCP servers can carry what it read in Discord into them. Connect Discord on its own until you trust the setup.

Safer patterns

• Read-only first. A bot that can only view and read history in one or two channels covers the most useful jobs: summarizing a support channel, finding what the community said about a release, pulling bug reports.
• Post through a webhook, not the bot. Discord’s webhook documentation↗ (opens in a new tab) says webhooks post to a channel and “do not require a bot user or authentication to use.” A webhook URL reaches one channel only, which is a much smaller thing to lose than a bot token, but it is still a secret.
• Keep writes on ask. In Claude Code, do not pre-approve the send, delete, channel or member tools; auto-approve in Claude Code explains the settings. The assistant drafts, a person sends.
• Remove what you do not need. If the server lets you disable tools or categories, turn off moderation and role tools entirely.
• Separate bots for separate jobs. A reader bot and a poster bot, each with its own token, can be revoked one at a time.

Choosing the best Discord MCP server for you

There is no best server in general, only the one that matches the job with the least power. Check that it authenticates with a bot token, not your personal account; that it lists its tools and the intents it needs; that you can switch off the tools you will not use; that it runs over the transport your client supports; and that it has had recent commits. A server with 20 tools that you understand is a better choice than one with 50 you have not read.

From a community report to a task

Discord is where a community reports problems, not where the fixes are tracked. A good first job for a read-only bot is to read a #bug-reports or #feature-requests channel each morning and turn what is new into tasks, without posting anything back. With fenbs connected as a second MCP server at https://fenbs.ai/api/mcp, the assistant can search the board for an existing task, then file a bug, a feature or an enhancement with the message link and a short summary in the note, and a priority from 1 to 10. It lands in To Do, and a person decides what moves to Next Up. History records that the assistant filed it, and you can give the assistant its own role on the board, so it can add and comment while only your team moves work between lanes. fenbs does not read Discord itself, and it has no due dates or settable assignee; the assistant carries the report across, and people decide who does the work. The pattern for mixed inboxes is in how to track bugs and feature requests in one board.