OpenClaw on Discord: One Assistant, a Whole Community
Discord is the only one of the common OpenClaw integrations that is many-to-one. Telegram and WhatsApp give you a private assistant in your pocket; Discord gives an entire server access to the same one. That changes three things worth understanding before you paste a token.
Intents: why a new bot often reads nothing
Discord treats message content as a privileged intent. A freshly created bot can be invited, appear online and still see nothing except messages that mention it directly, which reads exactly like a broken integration. Enabling the Message Content Intent in the Developer Portal under the bot settings is the fix, and it is the single most common reason a Discord bot appears not to work.
It is also worth pausing on rather than clicking through. That intent is the difference between an assistant that answers when asked and one that reads everything said in the channels it can see.
Permissions: give it the smallest set that works
The invite URL you generate decides what the bot can do, and the defaults are usually more generous than you need. A read-and-reply assistant needs to view channels, read history and send messages. It does not need to manage roles, kick members or delete other people's posts. Channel-level permissions are the other half: put the bot in the channels it is meant to serve rather than giving it the whole server and hoping.
Cost: one key, many typists
On a personal assistant you are the only person spending tokens. On a Discord server you are paying for everyone, and a busy channel can produce a surprising bill from a model priced per token. Two things help: be deliberate about which channels the bot listens in, and consider a local model through Ollama, where a busy server costs you compute you have already paid for rather than per-message charges.
Setting it up
- Create the application and bot. In the Discord Developer Portal, then copy the bot token and keep it somewhere safe. It is a password.
- Enable the Message Content Intent if the bot should read messages it was not mentioned in.
- Invite it with an invite URL carrying only the permissions you intend to grant.
- Deploy OpenClaw. Launch your instance on Flux in about 30 seconds if you have not already.
- Paste the token into the Discord integration in your dashboard.
How people will actually invoke it
There are two ways an assistant gets used on Discord and they suit different servers. Mentions are the low-ceremony option: someone types the bot's name and asks a question in the flow of conversation, which works well in a small channel and becomes noisy in a busy one. Slash commands are the structured option: they appear in Discord's own command menu with descriptions and typed arguments, so people discover what the assistant can do without anyone writing a guide.
The practical advice is to offer both and expect a split. Regulars will mention the bot because it is faster; everyone else will find it through the slash menu, and a bot with no commands registered is effectively invisible to them. Registering a small, well-named set of commands is the cheapest thing you can do to make an assistant feel like part of the server rather than a thing somebody added.
Threads are where context belongs
A channel is a shared room and an assistant that treats it as one long conversation will confuse itself, because three people asking unrelated things in the same five minutes is not a thread of reasoning. Discord threads solve this properly: a thread is a bounded conversation with its own participants, which maps cleanly onto how an assistant holds context.
Encouraging longer exchanges into threads keeps the main channel readable and keeps the assistant coherent, and it has a cost benefit too. A conversation that stays in one thread does not carry the whole channel's history into every request.
Anyone in the channel is spending your money
This deserves stating plainly because it is the difference between Discord and every personal integration. The provider key is yours, the billing is yours, and every member who talks to the bot consumes it. That is fine and expected on a server of friends; it is a genuine consideration on a public one.
Three things keep it sane. Limit which channels the bot listens in, so the assistant is available where it is useful rather than everywhere. Consider whether the Message Content Intent is really needed: a bot that only responds to mentions and slash commands cannot be triggered accidentally by ordinary conversation. And on a busy server, a local model through Ollama changes the economics entirely, because a hundred messages cost you compute you have already paid for rather than a hundred billable requests.
Why self-hosted matters more here
With a shared bot service, a whole community's conversations pass through somebody else's infrastructure. Self-hosting means the messages your members send reach an instance you control, and the model behind it is your choice: a hosted model for capability, or a local LLM through Ollama so nothing leaves your server at all.
Get started
Discord is one of more than 20 OpenClaw integrations. If you want a personal assistant rather than a community one, Telegram is the simpler setup, and WhatsApp covers the phone-number route. The full self-host guide covers the instance itself. Ready now? Deploy from the homepage.