Skip to main content
Glama
tensakulabs

discord-mcp

by tensakulabs
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

discord-mcp

Discord selfbot MCP server — read & send Discord messages from Claude Code or OpenClaw.

⚠️ Selfbot Warning: This uses your Discord user token, which violates Discord's ToS. Your account may be banned. Use at your own risk.

What it does

Exposes 6 Discord tools via MCP (Model Context Protocol):

Tool

Description

discord_list_guilds

List all servers you're in

discord_list_channels

List text channels in a server

discord_get_messages

Fetch recent messages from a channel

discord_get_dms

List your open DM conversations

discord_send_message

Send a message (channel or DM)

discord_get_unread

Get messages you haven't seen yet

A background daemon maintains a persistent WebSocket to the Discord Gateway, ingesting messages into a local SQLite database so discord_get_unread works even while Claude isn't running.

Related MCP server: Discord MCP Server

Setup

1. Install & configure

npx @tensakulabs/discord-mcp setup

This will:

  1. Show you how to extract your Discord token from the desktop app

  2. Save it securely to your OS keychain (macOS: uses built-in security CLI — no native module required)

  3. Start the background daemon via launchd (macOS) or systemd (Linux)

  4. Auto-register the MCP server in Claude's config

2. Token extraction (step shown during setup)

Open Discord desktop app → Press Ctrl+Shift+I (or Cmd+Option+I on Mac) → Network tab → Send any message in Discord → filter requests by messages → click any request → Headers tab → find the Authorization header → copy its value.

3. Restart Claude

Restart Claude Code. You'll see Discord tools available.

Verify it's working

npx @tensakulabs/discord-mcp status
# ✅ Connected as: yourname#0

Manual MCP config (if auto-config fails)

Add to ~/.claude/settings.json:

{
  "mcpServers": {
    "discord": {
      "command": "npx",
      "args": ["-y", "@tensakulabs/discord-mcp"]
    }
  }
}

Usage with Claude

Once registered, Claude can use Discord tools directly:

"What did I miss in the #general channel of the Tensaku server?"
→ Claude calls discord_list_guilds, discord_list_channels, discord_get_unread

"Reply to Alex saying I'll be there at 5pm"
→ Claude calls discord_send_message with replyToMessageId

Hooks

Fire shell commands or HTTP webhooks when Discord events occur. Configure in ~/.config/discord-mcp/config.json:

{
  "hooks": {
    "on_mention": [
      {
        "type": "command",
        "enabled": true,
        "command": "osascript -e 'display notification \"{content}\" with title \"Mention from {author}\"'"
      }
    ],
    "on_everyone": [],
    "on_here": [],
    "on_message": []
  }
}

Hook types

Hook

Fires when

on_mention

Someone directly @username mentions you

on_everyone

Someone uses @everyone in a server you're in

on_here

Someone uses @here in a server you're in

on_message

Any non-bot message (use sparingly — fires a lot)

Hook config fields

Field

Values

Description

type

"command" | "http"

Shell command or HTTP POST

enabled

true | false

Toggle without removing

command

string

Shell command (type: command)

url

string

Endpoint to POST to (type: http)

Template variables

Available in command strings and HTTP POST body:

Variable

Value

{author}

Username of message sender

{content}

Message text

{channel}

Channel ID

{guild}

Guild/server ID (or "dm" for DMs)

{is_dm}

true or false

HTTP hook payload

{
  "author": "username",
  "content": "message text",
  "channel": "channel-id",
  "guild": "guild-id",
  "is_dm": false
}

OpenClaw integration

Add to OpenClaw's MCP config:

{
  "mcp": {
    "servers": [{
      "name": "discord",
      "transport": "stdio",
      "command": "npx",
      "args": ["-y", "@tensakulabs/discord-mcp"]
    }]
  }
}

Security

  • Token stored in OS keychain (macOS: security CLI — no native module compilation needed; Linux: keytar; fallback: AES-256-CBC encrypted file)

  • Token never written to config files or logs

  • Local files at ~/.config/discord-mcp/: messages.db, config.json, token.enc (fallback only), daemon.log

Architecture

discord-mcp/
├── src/
│   ├── index.ts          MCP server entry — registers 6 tools
│   ├── cli.ts            setup + status commands
│   ├── daemon.ts         Discord Gateway WebSocket → SQLite ingestion + hooks
│   ├── auth.ts           keychain token storage (macOS security CLI / keytar / encrypted file)
│   ├── hooks.ts          hook runner — shell commands and HTTP webhooks
│   ├── config.ts         config loader (~/.config/discord-mcp/config.json)
│   ├── db.ts             SQLite schema + queries
│   ├── ratelimit.ts      429 backoff + Discord headers
│   ├── state.ts          per-channel last-seen state
│   ├── purge.ts          scheduled message retention cleanup
│   └── tools/
│       ├── list_guilds.ts
│       ├── list_channels.ts
│       ├── get_messages.ts
│       ├── get_dms.ts
│       ├── send_message.ts
│       └── get_unread.ts

All Discord API calls go through rateLimitedFetch — automatic backoff on 429.

The daemon runs as a launchd service (com.discord-mcp.daemon) on macOS, connecting to wss://gateway.discord.gg and storing all messages locally for fast unread queries.

Available Tools

8 tools
discord_get_dmsA

List the user's open DM conversations.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description only states 'list,' which implies a read operation. It does not disclose return format, pagination, or any other behavioral traits.

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 sentence with no unnecessary words. It is appropriately sized for the tool's simplicity.

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 has no parameters and no output schema, the description is adequate but could mention what information is returned (e.g., user IDs, names).

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 zero parameters, so schema coverage is 100%. The description does not need to add parameter info, and the baseline is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List the user's open DM conversations' explicitly states the verb (list) and resource (DM conversations), clearly distinguishing it from siblings like discord_get_messages and discord_list_channels.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing DMs, but lacks explicit guidance on when to use this tool versus alternatives like discord_search or discord_resolve_dm_user.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

discord_get_messagesA

Get messages from a channel. Uses local cache if daemon is running, Discord API otherwise.

ParametersJSON Schema
NameRequiredDescriptionDefault
channelIdYes
limitNoMax messages (1-100)
sinceNoISO date or datetime e.g. '2026-02-25' or 'yesterday'
untilNoISO date or datetime upper bound

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses use of local cache vs. Discord API, which is important for performance and freshness. No annotations provided, so description does the job well.

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?

Extremely concise: two sentences that cover purpose and caching behavior, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Provides key context on caching vs API, but lacks details on error handling or return value format (no output schema). Still adequate for a straightforward get operation.

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 75%; the description does not add additional meaning beyond what the schema already provides for parameters like limit, since, and until.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Get messages from a channel' and is distinct from sibling tools like discord_get_dms or discord_search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies use for retrieving messages with optional time filters, but lacks explicit guidance on when to prefer this over discord_search or other alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

discord_get_unreadA

Get messages you haven't seen yet. Uses local cache when daemon is running.

ParametersJSON Schema
NameRequiredDescriptionDefault
channelsYesChannels to check.

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It mentions local cache usage but does not clarify whether the tool is read-only, if it marks messages as read, or what happens when the daemon is not running. This leaves significant behavioral gaps.

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 concise with two short sentences. No unnecessary information is included; every word adds value.

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 has one parameter and no output schema, the description covers purpose and a cache behavior note but lacks usage guidelines, error scenarios, or details about data freshness when using cache. For a simple tool, it could be more complete.

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 coverage is 100%, so baseline is 3. The description 'Channels to check' adds minimal meaning beyond the schema's structured definition. It does not explain how channels are specified or how multiple channels are handled.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves 'messages you haven't seen yet', which precisely conveys its purpose. It is distinct from sibling tools like discord_get_messages (all messages) and discord_get_dms (direct messages).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions using local cache when the daemon is running, which hints at performance considerations but does not explicitly state when to use this tool over alternatives or provide conditions when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

discord_list_channelsB

List text channels in a guild.

ParametersJSON Schema
NameRequiredDescriptionDefault
guildIdYesGuild ID from discord_list_guilds

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must carry the full burden. The description only says 'list text channels', omitting details like rate limits, permission requirements, or behavior on invalid guild IDs. It doesn't disclose whether it returns only channel names or full objects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, concise and front-loaded. It contains no unnecessary words, but could be slightly expanded to include usage hints without being verbose.

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 (one required parameter, list operation), the description is somewhat adequate. However, without an output schema, the agent lacks information about the return format (e.g., list of channel IDs, names, or objects), reducing completeness.

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%, with the parameter description 'Guild ID from discord_list_guilds' providing context. The tool description adds no extra meaning beyond the schema, meeting the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists text channels in a guild, using a specific verb and resource. It distinguishes from siblings like discord_list_guilds (lists guilds) and discord_get_dms (gets direct messages), so the purpose is unambiguous.

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 on when to use this tool versus alternatives (e.g., discord_search, discord_get_messages). The description only states what the tool does, without mentioning prerequisites or context where this tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

discord_list_guildsA

List all Discord servers (guilds) the user is a member of.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, so description carries full burden. States only that it lists guilds, implying a safe read operation. No mention of authentication requirements, rate limits, pagination, or output details. Transparency is basic but not misleading.

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?

Single sentence, no redundancy, perfectly concise.

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?

For a tool with no parameters and no output schema, description covers the basic purpose but lacks detail on what the output contains (e.g., guild IDs, names). Adequate but not fully comprehensive.

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?

No parameters exist, so baseline is 4. Description adds no param info, but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/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 the resource 'Discord servers (guilds)' with scope 'the user is a member of.' It distinguishes well from siblings like discord_get_dms (which lists DMs) and discord_list_channels.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the name and description, but no explicit guidance on when to use this tool versus alternatives like discord_search or discord_resolve_dm_user. No when-not-to-use or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

discord_resolve_dm_userA

Resolve a username or display name to a DM channel ID. Use this before discord_get_messages when you know who to DM but not the channel ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
usernameYesDisplay name or username to look up (case-insensitive, partial match supported)

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It discloses case-insensitive and partial match behavior, but does not mention potential error cases (e.g., user not found) or rate limits. Still, for a simple tool, it provides useful 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?

Two sentences, front-loaded with the core purpose, no wasted words. Very concise and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 parameter, no output schema), the description fully covers what an agent needs to know: purpose, usage context, and parameter behavior. No gaps.

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 coverage is 100% with a description for the only parameter. The tool's description does not add further parameter-level meaning beyond what is already in the schema, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool resolves a username or display name to a DM channel ID, using a specific verb and resource, and distinguishes itself from siblings by mentioning its use before discord_get_messages.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use this tool: before discord_get_messages when you know who to DM but not the channel ID, providing clear usage context and differentiation from alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

discord_send_messageA

Send a message to a channel or user (DM). Specify channelId OR userId.

ParametersJSON Schema
NameRequiredDescriptionDefault
channelIdNoGuild channel ID
userIdNoUser ID to DM
contentYesMessage text
replyToMessageIdNoOptional message ID to reply to

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It adds the exclusive OR constraint on channelId and userId, but does not disclose permissions, rate limits, success/error behavior, or what happens if both parameters are supplied. This is adequate but not rich.

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 short sentence that is front-loaded with the primary action. Every word contributes value; there is no wasted text.

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 4 parameters and no output schema, the description adequately states the tool's purpose and key parameter constraint. However, it lacks explanations of success/error responses, rate limits, or prerequisites (e.g., bot must share a guild for DMs). This leaves some gaps for an AI agent.

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?

Schema coverage is 100% (all parameters documented), so baseline is 3. The description adds meaning by explicitly stating the exclusive OR relationship between channelId and userId, which is not encoded in the schema. This improves parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool sends a message to a channel or user (DM). It uses a specific verb ('Send') and resource ('message'), and distinguishes from sibling tools (which are about reading messages, getting DMs, etc.).

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 only mentions that one must specify either channelId or userId, but provides no guidance on when to use this tool versus alternatives like discord_get_messages or discord_resolve_dm_user. No exclusions or context are given.

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. Dates show when Glama detected each change.

  1. 8 tool updatesv0.1.9
    • First observeddiscord_get_dms
    • First observeddiscord_get_messages
    • First observeddiscord_get_unread
    • First observeddiscord_list_channels
    • First observeddiscord_list_guilds
    • First observeddiscord_resolve_dm_user
    • First observeddiscord_search
    • First observeddiscord_send_message
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool targets a distinct operation: listing DMs, getting messages, getting unread, listing channels, listing guilds, resolving user to DM channel, searching, and sending. No two tools have overlapping purposes.

Naming Consistency5/5

All tools follow a consistent 'discord_verb_noun' pattern in snake_case, using imperative verbs (get, list, resolve, search, send). No mixing of conventions.

Tool Count5/5

8 tools is well-scoped for a Discord MCP, covering essential read operations (messages, channels, guilds) and sending. Not excessive nor too sparse.

Completeness4/5

Covers core reading and sending, but lacks update/delete message operations and guild management. Minor gaps that agents can work around.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Discord MCP Server

    v-3
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables LLMs to interact with Discord channels by sending and reading messages through Discord's API, with a focus on maintaining user control and security.
    32
    228
    MIT

  • Discord MCP Server

    Kaleemullah-Younas
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables LLMs to send and read messages in Discord channels, manage servers, channels, and roles via Discord's API.
    32
    2
    MIT

  • Discord MCP Server

    elyxlz
    F
    license
    A
    quality
    D
    maintenance
    Enables LLMs to read messages, discover channels, send messages, and monitor Discord communities using web scraping without requiring bot permissions or API tokens.
    4
    14
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tensakulabs/discord-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server