Skip to main content
Glama
jhammant

Discord Bridge MCP Server

by jhammant

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

discord_send

Send a message to any channel

discord_read

Read recent messages (with pagination)

discord_reply

Reply to a specific message

discord_react

React to a message with emoji

discord_channels

List all text channels

discord_check_mentions

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

  1. Go to Discord Developer Portal

  2. Create a new application

  3. Go to Bot settings, create a bot, copy the token

  4. Enable "Message Content Intent" under Privileged Gateway Intents

  5. Invite the bot to your server with Send Messages + Read Message History permissions

2. Install

npm install

3. 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.js

4. 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

DISCORD_BOT_TOKEN

Yes

Discord bot token

DISCORD_GUILD_ID

Yes

Discord server (guild) ID

DISCORD_DEFAULT_CHANNEL

No

Default channel name (defaults to "general")

License

MIT

Available Tools

6 tools
discord_channelsB

List all text channels in the Discord server.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
channelNoChannel to check. If omitted, checks all channels.
limitNoNumber of recent messages to scan per channel (default: 50)

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
message_idYesID of the message to react to
channelYesChannel name or ID
emojiYesEmoji to react with (e.g. "thumbsup", "check", or a unicode emoji)

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
channelNoChannel name or ID. Uses default channel if omitted.
limitNoNumber of messages to fetch (default: 20, max: 100)
beforeNoFetch messages before this message ID (for pagination)
afterNoFetch messages after this message ID

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
message_idYesID of the message to reply to
channelYesChannel name or ID where the message is
messageYesReply content

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYesMessage content to send
channelNoChannel name (e.g. "general") or ID. Uses default channel if omitted.

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

  1. 6 tool updatesv1.0.0
    • First observeddiscord_channels
    • First observeddiscord_check_mentions
    • First observeddiscord_react
    • First observeddiscord_read
    • First observeddiscord_reply
    • First observeddiscord_send

TDQS

A3.5/5.0

Scored across 6 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    An MCP server that allows Claude to interact with Discord by providing tools for sending/reading messages and managing server resources through Discord's API.
    19
    88 npm
    MIT
  • F
    license
    Not graded
    quality
    C
    maintenance
    An 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
    -
  • A
    license
    A
    quality
    D
    maintenance
    An 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.
    26
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    A 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 npm
    MIT