Discord Bridge MCP Server
Provides tools for interacting with Discord, enabling capabilities such as sending and replying to messages, reading channel history, reacting with emojis, listing channels, and checking for mentions.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Discord Bridge MCP Serversend a message to #general saying the deployment is finished"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Discord Bridge MCP Server
An MCP (Model Context Protocol) server that gives Claude Code native Discord tools. Enables bidirectional communication between your local Claude Code session and remote AI agents (or humans) through Discord.
What it does
This server exposes 6 Discord tools to Claude Code:
Tool | Description |
| Send a message to any channel |
| Read recent messages (with pagination) |
| Reply to a specific message |
| React to a message with emoji |
| List all text channels |
| Find messages that @mention you |
Uses the Discord REST API directly -- no WebSocket gateway connection needed. Lightweight, stateless, ~250 lines of code.
Related MCP server: Discord MCP Server
Setup
1. Create a Discord bot
Go to Discord Developer Portal
Create a new application
Go to Bot settings, create a bot, copy the token
Enable "Message Content Intent" under Privileged Gateway Intents
Invite the bot to your server with
Send Messages+Read Message Historypermissions
2. Install
npm install3. Register with Claude Code
claude mcp add discord-bridge \
-e DISCORD_BOT_TOKEN=your-bot-token \
-e DISCORD_GUILD_ID=your-server-id \
-e DISCORD_DEFAULT_CHANNEL=general \
-- node /path/to/index.js4. Add the /talk command (optional)
Copy talk.md to ~/.claude/commands/talk.md. Then type /talk in Claude Code to check for new messages and respond.
How it works
┌─────────────────┐ stdio ┌─────────────────┐ REST API ┌─────────┐
│ Claude Code │◄──────────────►│ Discord Bridge │◄─────────────►│ Discord │
│ (local CLI) │ MCP │ (MCP Server) │ HTTPS │ API │
└─────────────────┘ └─────────────────┘ └─────────┘
│
┌─────┴─────┐
│ Discord │
│ Server │
│ (channels) │
└─────┬─────┘
│
┌───────┴───────┐
│ Remote Agents │
│ (or humans) │
└───────────────┘Claude Code communicates with the MCP server over stdio. The MCP server translates tool calls into Discord REST API requests. Remote agents (or humans) see messages in Discord and can respond. Claude Code picks up responses on the next /talk invocation.
Use cases
Multi-agent coordination: Local Claude Code delegates tasks to remote AI agents running on a server
Human-in-the-loop: Team members monitor and participate in agent conversations via Discord
Cross-machine communication: Bridge between your laptop and a remote server running AI agents
Async task management: Post tasks, check on progress, get notified of completions
Environment variables
Variable | Required | Description |
| Yes | Discord bot token |
| Yes | Discord server (guild) ID |
| No | Default channel name (defaults to "general") |
License
MIT
Available Tools
6 toolsdiscord_channelsB
List all text channels in the Discord server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't specify any constraints like rate limits, permissions required, or what data is returned (e.g., channel names, IDs, types). This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without any fluff or redundant information. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate but lacks completeness. It doesn't explain what the output looks like (e.g., list format, data fields) or any behavioral nuances, which could hinder an agent's ability to use it effectively without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description appropriately doesn't mention parameters, earning a baseline score of 4 for not adding unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and target resource ('all text channels in the Discord server'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'discord_read' or 'discord_check_mentions' which might also involve channel operations, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or compare it to sibling tools like 'discord_read' or 'discord_check_mentions', leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discord_check_mentionsC
Check for recent messages that mention the bot.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No | Channel to check. If omitted, checks all channels. | |
| limit | No | Number of recent messages to scan per channel (default: 50) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It doesn't disclose whether this is a read-only operation, if it requires specific permissions, how it handles rate limits, or what the output format looks like (e.g., list of messages). This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of checking mentions across channels, the lack of annotations, and no output schema, the description is incomplete. It doesn't explain what constitutes a 'mention', how results are returned, or error handling, making it insufficient for an agent to use the tool effectively without guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the input schema already documents both parameters (channel and limit) clearly. The description adds no additional meaning beyond what the schema provides, such as explaining how 'mention' is defined or the scanning process, but the baseline is 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check for recent messages') and the target ('that mention the bot'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like discord_read or discord_reply, which might also involve reading messages, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like discord_read (which reads messages without mention filtering) or discord_reply (which responds to messages). There's no mention of prerequisites, context, or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discord_reactC
Add a reaction emoji to a Discord message.
| Name | Required | Description | Default |
|---|---|---|---|
| message_id | Yes | ID of the message to react to | |
| channel | Yes | Channel name or ID | |
| emoji | Yes | Emoji to react with (e.g. "thumbsup", "check", or a unicode emoji) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't cover permissions needed, rate limits, whether reactions are reversible, or what happens on success/failure. For a mutation tool, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words, efficiently conveying the core purpose. It's appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, side effects, or response format, leaving the agent with insufficient context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints not in the schema. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a reaction emoji') and target ('to a Discord message'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like discord_reply or discord_send, which also interact with messages, so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like discord_reply or discord_send, nor does it mention any prerequisites or exclusions. It states what the tool does but not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discord_readC
Read recent messages from a Discord channel.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No | Channel name or ID. Uses default channel if omitted. | |
| limit | No | Number of messages to fetch (default: 20, max: 100) | |
| before | No | Fetch messages before this message ID (for pagination) | |
| after | No | Fetch messages after this message ID |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but lacks details on permissions required, rate limits, pagination behavior beyond parameters, or what 'recent' means (e.g., time-based vs. count-based). This leaves significant gaps for a read operation with multiple parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core purpose, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a read operation with four parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain return values (e.g., message format), error conditions, or how parameters interact, leaving the agent with incomplete context for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds no additional parameter semantics beyond implying 'recent' messages, which is vague and doesn't clarify the default behavior or interplay between parameters like limit and before/after.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Read') and resource ('recent messages from a Discord channel'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like discord_check_mentions or discord_channels, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose discord_read over discord_check_mentions (which might filter for mentions) or discord_channels (which might list channels), nor does it specify prerequisites like channel access.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discord_replyC
Reply to a specific Discord message.
| Name | Required | Description | Default |
|---|---|---|---|
| message_id | Yes | ID of the message to reply to | |
| channel | Yes | Channel name or ID where the message is | |
| message | Yes | Reply content |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It states the tool replies to messages, implying a write operation, but doesn't cover critical aspects like permissions required, rate limits, whether replies are editable/deletable, or how failures are handled. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that directly states the tool's function without any fluff. It's front-loaded with the core action and resource, making it efficient and easy to parse. Every word earns its place, achieving optimal brevity for the given information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a Discord reply operation (a mutation with potential side effects), the description is incomplete. With no annotations and no output schema, it fails to address key contextual elements like error handling, response format, or integration with sibling tools. The agent lacks sufficient information to use this tool effectively in real-world scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all three required parameters (message_id, channel, message). The description doesn't add any meaningful parameter semantics beyond what the schema already provides—it doesn't explain format details, constraints, or examples. This meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reply to') and resource ('a specific Discord message'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'discord_send' or 'discord_react' which also involve message interactions, missing the opportunity to clarify its specific role in the Discord toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'discord_reply' over 'discord_send' (for new messages) or 'discord_react' (for reactions), nor does it specify prerequisites like needing message and channel IDs. This lack of context leaves the agent to guess about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discord_sendC
Send a message to a Discord channel.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Message content to send | |
| channel | No | Channel name (e.g. "general") or ID. Uses default channel if omitted. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'send a message' implies a write operation, it doesn't address important behavioral aspects like permission requirements (e.g., does the bot need specific channel permissions?), rate limits, whether messages can be edited/deleted later, or what happens on failure. The description is minimal and lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential information immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after sending (success/failure indicators), doesn't mention any constraints or requirements, and provides minimal context for a tool that performs a potentially complex operation in a chat platform with permission systems and rate limiting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions 'message' and 'channel' generically but provides no additional context about format constraints, channel resolution logic, or message formatting options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('send') and resource ('message to a Discord channel'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like discord_reply (which also sends messages but as replies) or discord_react (which interacts with messages differently).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like discord_reply (for replying to existing messages) or discord_react (for adding reactions). The description only states what the tool does, not when it's appropriate compared to other messaging-related tools in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
6 tool updates
v1.0.0- First observed
discord_channels - First observed
discord_check_mentions - First observed
discord_react - First observed
discord_read - First observed
discord_reply - First observed
discord_send
TDQS
Scored across 6 tools
Each tool has a clearly distinct purpose targeting specific Discord actions: listing channels, checking mentions, reacting, reading messages, replying, and sending messages. There is no overlap or ambiguity between these functions, making tool selection straightforward for an agent.
All tool names follow a consistent 'discord_' prefix with descriptive verb_noun patterns (e.g., discord_channels, discord_react, discord_send). This uniformity enhances readability and predictability across the toolset.
With 6 tools, the server is well-scoped for a Discord bridge, covering essential messaging and interaction functions without being overly sparse or bloated. Each tool serves a clear and necessary role in the domain.
The toolset provides strong coverage for core Discord messaging workflows, including sending, reading, replying, and reacting. A minor gap exists in the lack of tools for managing channels (e.g., creating or deleting) or handling other Discord features like voice channels or user management, but agents can still perform key tasks effectively.
Maintenance
Related MCP Connectors
An MCP server that integrates with Discord to provide AI-powered features.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Related MCP Servers
- AlicenseAqualityDmaintenanceAn MCP server that allows Claude to interact with Discord by providing tools for sending/reading messages and managing server resources through Discord's API.1988 npmMIT
- FlicenseNot gradedqualityCmaintenanceAn MCP server that enables Claude Desktop to interact with Discord through a dedicated bot. It allows users to list channels, read message history, and send messages directly from the AI interface.2-
- AlicenseAqualityDmaintenanceAn MCP server providing 26 tools for Discord API interactions, enabling message management, moderation, channel operations, and server inspection through Claude Code, Paperclip agents, or other MCP-compatible clients.26MIT
- AlicenseNot gradedqualityBmaintenanceA Discord MCP server SDK that connects AI assistants like Claude and ChatGPT to Discord, providing over 100 tools for natural language control of Discord servers, including channel, message, member, and role management.54 npmMIT