discord-mcp: a Java MCP server that puts a Discord bot behind an HTTP endpoint

What discord-mcp actually bridges

The project is an MCP server for the Discord API built on JDA, the Java Discord API library. It exists so that MCP-compatible clients (the README names Claude, ChatGPT, Cursor, Codex CLI, OpenClaw and n8n) can call Discord operations as tools instead of you writing bot code for each task. The README describes the scope as managing channels, sending messages, and retrieving server information. That is the whole surface. This is not a Discord client, not a moderation framework, and not a hosted service. It is a process you run next to your bot token, and it turns that token into a set of callable tools. The intended user is someone who already has a Discord bot and a guild, and who wants an assistant to act inside that guild without a custom integration per client. If you do not already have a bot application and token, the README points to the Discord.js guide's app setup page rather than walking through it, so the prerequisite is assumed.

One container, one MCP endpoint, many clients

The architecture is visible in the installation instructions. A Spring Boot application starts with SPRING_PROFILES_ACTIVE=http and listens on port 8085, exposing the MCP endpoint at http://localhost:8085/mcp and a health endpoint at http://localhost:8085/actuator/health. The Discord side is handled by JDA inside the same process, authenticated with DISCORD_TOKEN. The README's recommended connection pattern is what it calls HTTP singleton mode: one shared server container, referenced by URL from every client. The legacy pattern is stdio, where the client spawns a fresh docker run --rm -i process per session, passing the token through -e flags. That distinction matters more than it looks. In singleton mode the JDA connection is established once and reused, and every client that points at the URL shares the same bot identity. In stdio mode each client session gets its own container, its own JVM startup, and its own gateway connection. The README explicitly labels stdio as legacy and starts a new process or container per client session, which is a fair description of the cost. If you connect three assistants, the legacy path means three Discord gateway sessions for one bot.

Getting it running with Docker, Compose or a jar

The fastest path is Docker. Export three variables, DISCORD_TOKEN, DISCORD_GUILD_ID and SPRING_PROFILES_ACTIVE=http, then run the published image with port 8085 mapped and the variables forwarded: docker run -d -i --name discord-mcp --restart unless-stopped -p 8085:8085 -e SPRING_PROFILES_ACTIVE -e DISCORD_TOKEN -e DISCORD_GUILD_ID saseq/discord-mcp:latest. The Compose path clones the repository, writes a .env file containing those same three keys, runs docker compose up -d --build, and verifies with docker ps --filter name=discord-mcp plus curl -fsS http://localhost:8085/actuator/health. The manual path requires Maven: mvn clean package produces a jar in /target, and the README shows running it as discord-mcp-1.0.0.jar with the same environment variables. DISCORD_GUILD_ID is optional and, when set, lets any tool that accepts a guildId parameter omit it. That is a convenience default, not a security boundary, and it is worth being clear-eyed about: it removes a parameter from tool calls, nothing more. The README also notes that LOGGING_PATTERN_CONSOLE does not need to be set manually because logging is configured for both http and stdio modes. Client wiring is one line each in most cases, for example claude mcp add discord-mcp --transport http http://localhost:8085/mcp, codex mcp add discord-mcp --url http://localhost:8085/mcp, or an openclaw mcp set call with a streamable-http transport.

The token is the whole security model

There is no authentication layer described between an MCP client and the server. The HTTP endpoint is bound to port 8085 and the README's examples all use localhost, but nothing in the supplied material describes an auth header, a shared secret, or a token check on /mcp. The permission boundary is entirely the Discord bot token: whatever the bot can do, any client that reaches the endpoint can ask it to do. That is a reasonable default for a localhost developer tool and a poor one for anything reachable from a network. If you expose port 8085 beyond your machine, you are trusting every caller to behave. This is the clearest case where the project is the wrong tool: a shared or multi-user deployment where different people should have different Discord capabilities. The material gives no role model, no per-caller scoping, and no audit trail beyond whatever Discord itself records. Treat the endpoint as equivalent to the bot token and place it accordingly.

What the README does not pin down

The documentation is thin in places that matter for adoption. The exact tool list is never enumerated; the description says channels, messages and server information, but the names, parameters and return shapes of the individual MCP tools are not in the material, so you cannot plan an integration from the README alone. Required Discord permission scopes for the bot are not listed either, only a pointer to the Discord.js app setup guide. Error behaviour is unspecified: what happens when the token is invalid, when the bot lacks permission in a channel, or when a guild ID is wrong, is not described. The stdio example config carries a note about SSE in the client configuration, while the HTTP profile is the recommended transport, and the material does not reconcile the two, so if you are on an older client that expects SSE you should confirm which transport it speaks before copying a config block. None of this is fatal for a v1.0.0 released in March 2026, but it means the first hour is partly discovery rather than following a checklist.

Where it sits against writing your own bot

The realistic alternative is not another MCP server; it is a small JDA or discord.js bot that implements exactly the two or three operations you need, plus whatever glue your assistant uses to call it. The difference in approach is where the tool schema lives. With discord-mcp, the schema is fixed by the server and you adapt your prompts to it; with your own bot, you define the operations and their parameters and expose them however you like. The project wins when you want broad, generic Discord access from several different MCP clients without writing per-client code, which is precisely the situation the README's multi-client connection section addresses. Your own bot wins when your needs are narrow, when you want to enforce argument validation before anything reaches Discord, or when you want the Discord credentials to live somewhere the MCP client cannot reach at all. A middle option is running discord-mcp in stdio mode so the client spawns and owns the process, which limits exposure but reintroduces per-session startup, as the README notes.

Maintenance, upgrades and the MIT licence

The project is Java with Maven, so upgrades are either a new image tag or a rebuild: docker pull saseq/discord-mcp:latest, or git pull followed by mvn clean package and a restart of the jar or container. The README's Compose instructions use --build, which rebuilds locally rather than pulling, so a Compose user tracking upstream changes needs to pull the repository first or the rebuild is of stale source. There is one release in the material, v1.0.0, dated 2026-03-16, with a last push to main on 2026-04-25. That is a young project with a single tagged release, and the practical consequence is that you should expect the tool surface and the transport guidance to move. The licence is MIT, which is permissive and places few obligations on how you redistribute or modify it; it also means no warranty is offered, which for a component holding a live Discord token is worth reading as written rather than as a formality. This is not legal advice, and if you plan to ship the server inside a product you should have someone check how MIT interacts with your own distribution terms.

Editorial conclusion

Adopt discord-mcp if you already run a Discord bot, want its actions callable from an MCP client, and are comfortable giving that bot a token with real channel and message permissions. Skip it if you need a hosted multi-tenant service, or if you cannot run Docker or a JVM on the machine holding the token. Before wiring it into an assistant, verify three things yourself: which tool scopes the bot's token actually needs, whether SPRING_PROFILES_ACTIVE=http is set in every launch path, and whether the SSE-based stdio mode still matches your client's transport expectations after the HTTP profile became the recommended option.

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. SaseQ/discord-mcp on GitHub