Enables sending, editing, and deleting messages on Discord using webhooks, with support for rich embeds, text content, and threads.
Click on "Install 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 Webhook MCP Send 'Build successful' to Discord with a green status embed"
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 Webhook を使用してメッセージの送信、編集、削除を行う Model Context Protocol (MCP) サーバーです。
メッセージ送信 - テキスト、Embed、スレッド対応
メッセージ編集 - 送信済みメッセージの内容を更新
メッセージ削除 - 送信済みメッセージを削除
Zod バリデーション - 入力パラメータの厳密な検証
Related MCP server: MCP-Discord
MCP対応クライアント（例: Gemini CLI）の設定ファイルに以下を追加:
{
"mcpServers": {
"discord-mcp": {
"command": "npx",
"args": ["-y", "@kongyo2/discord-webhook-mcp"],
"env": {
"DISCORD_WEBHOOK_URL": "https://discord.com/api/webhooks/YOUR_WEBHOOK_ID/YOUR_WEBHOOK_TOKEN"
}
}
}
}変数名 | 必須 | 説明 |
| ✅ | Discord Webhook URL |
discord_send_messageメッセージを送信します。
{
"content": "Hello, Discord!",
"embeds": [
{
"title": "タイトル",
"description": "説明文",
"color": 65280
}
]
}discord_edit_message送信済みメッセージを編集します。
{
"message_id": "123456789",
"content": "更新後のメッセージ"
}discord_delete_message送信済みメッセージを削除します。
{
"message_id": "123456789"
}レート制限: 30メッセージ/分/チャンネル
メッセージ本文: 最大2000文字
Embed: 最大10個、合計6000文字以内
# 依存関係のインストール
npm install
# 開発モード
npm run dev
# ビルド
npm run build
# Lint
npm run lintMIT
Webhookで送信したメッセージを削除します。
環境変数DISCORD_WEBHOOK_URLに設定されたWebhookを使用します。
⚠️ レート制限: 30リクエスト/分/チャンネル ⚠️ この操作は取り消せません。
Args:
message_id (string, required): 削除するメッセージID
Returns: { "success": boolean, // 削除が成功したか "message_id": string // 削除されたメッセージのID }
Examples:
メッセージ削除: { "message_id": "123456789" }
Error Handling:
"Discord Webhook error: 404 Not Found - Message not found"
"Discord Webhook error: 400 Bad Request - Invalid message ID"
"Discord Webhook error: レート制限に達しました" - 429エラー時、retry-after秒後に再試行
| Name | Required | Description | Default |
|---|---|---|---|
| message_id | Yes | 削除するメッセージID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint and idempotentHint, but description adds rate limits (30 req/min/channel), irreversibility, and specific error messages, enhancing transparency beyond annotations.
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?
Concise yet comprehensive, with clear sections for args, returns, examples, and error handling. No superfluous content.
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?
Covers all necessary aspects for a simple delete tool: environment dependency, rate limits, irreversibility, return format, examples, and error handling. No gaps.
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 coverage is 100%, so baseline is 3. The description repeats the parameter info without adding new semantics about format or validation.
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 tool deletes a message sent via webhook, specifies the use of DISCORD_WEBHOOK_URL environment variable, and distinguishes from sibling tools (edit, send).
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 implicitly differentiates from siblings by specifying deletion context, but lacks an explicit 'when to use vs. alternatives' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Webhookで送信したメッセージを編集します。
content、embedsのいずれか最低1つが必要です。 環境変数DISCORD_WEBHOOK_URLに設定されたWebhookを使用します。
⚠️ レート制限: 30リクエスト/分/チャンネル
Args:
message_id (string, required): 編集するメッセージID
content (string, optional): 新しいメッセージ内容（1-2000文字）
embeds (array, optional): 新しいEmbedの配列（最大10個、合計6000文字以内）
allowed_mentions (object, optional): 許可されたメンション設定
Returns: { "success": boolean, // 編集が成功したか "message_id": string, // 編集されたメッセージのID "timestamp": string // 編集日時 (ISO 8601形式) }
Examples:
テキストを編集: { "message_id": "123456789", "content": "更新後のメッセージ" }
Embedを編集: { "message_id": "123456789", "embeds": [{ "title": "新しいタイトル", "color": 0xFF0000 }] }
Error Handling:
"Validation error: content/embeds - content、embeds のうち最低1つを指定してください"
"Discord Webhook error: 404 Not Found - Message not found"
"Discord Webhook error: 400 Bad Request - Invalid message ID"
"Discord Webhook error: レート制限に達しました" - 429エラー時、retry-after秒後に再試行
| Name | Required | Description | Default |
|---|---|---|---|
| message_id | Yes | 編集するメッセージID | |
| content | No | 新しいメッセージ内容 (最大2000文字) | |
| embeds | No | 新しいEmbedの配列 (最大10個) | |
| allowed_mentions | No | 許可されたメンション設定 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds rate limit (30 req/min/channel) and error handling details beyond the annotations. It does not contradict annotations, though openWorldHint=true might imply side effects not fully explained.
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 well-structured with sections (requirements, examples, errors) and uses bullet points. It is concise yet comprehensive, with no wasted words.
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?
Despite no output schema, the description provides a clear return structure, error handling examples, and rate limit details. It covers all necessary aspects for an agent to use the tool correctly.
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 coverage is 100%, but the description adds the requirement of at least one of content/embeds and provides examples. It adds value beyond the schema, hence above baseline.
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 tool edits messages sent via webhook. It distinguishes from sibling tools (delete, send) by focusing on editing existing messages.
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 specifies that at least one of content or embeds is required and mentions the webhook URL environment variable. However, it does not explicitly contrast with siblings or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discordチャンネルにメッセージを送信します。
content、embedsのいずれか最低1つが必要です。 環境変数DISCORD_WEBHOOK_URLに設定されたWebhookを使用します。
⚠️ レート制限: 30メッセージ/分/チャンネル
Args:
content (string, optional): メッセージ内容（1-2000文字）
username (string, optional): Webhookのユーザー名を上書き（最大80文字）
avatar_url (string, optional): Webhookのアバター画像をURLで指定
tts (boolean, optional): テキスト読み上げ（TTS）メッセージとして送信（デフォルト: false）
embeds (array, optional): Embedの配列（最大10個、合計6000文字以内）
allowed_mentions (object, optional): 許可されたメンション設定
thread_id (string, optional): 送信先スレッドID（指定したスレッドに送信、スレッドは自動アーカイブ解除）
thread_name (string, optional): 作成するスレッド名（フォーラム/メディアチャンネルのみで新しいスレッドを作成、最大100文字）
Returns: { "success": boolean, // 送信が成功したか "message_id": string, // 送信されたメッセージのID "channel_id": string, // 送信先チャンネルID "timestamp": string // 送信日時 (ISO 8601形式) }
Examples:
シンプルなテキスト送信: { "content": "Hello, Discord!" }
Embed付き送信: { "embeds": [{ "title": "タイトル", "description": "説明", "color": 0x00FF00 }] }
スレッドに送信: { "content": "スレッドメッセージ", "thread_id": "123456789" }
Error Handling:
"Validation error: content/embeds - content、embeds のうち最低1つを指定してください"
"Discord Webhook error: 400 Bad Request - Invalid webhook URL"
"Discord Webhook error: 404 Not Found - Webhook not found"
"Discord Webhook error: レート制限に達しました" - 429エラー時、retry-after秒後に再試行
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | メッセージ内容 (最大2000文字) | |
| username | No | Webhookのユーザー名を上書き | |
| avatar_url | No | WebhookのアバターURLを上書き | |
| tts | No | テキスト読み上げ (TTS) | |
| embeds | No | Embedの配列 (最大10個) | |
| allowed_mentions | No | 許可されたメンション設定 | |
| thread_id | No | 送信先スレッドID (自動アーカイブ解除) | |
| thread_name | No | 作成するスレッド名 (フォーラム/メディアチャンネルのみ) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: uses a configured webhook, rate limit of 30 messages/minute/channel, triggers thread auto-archive revoke when thread_id is provided, and thread creation only on forum/media channels. Error handling examples clarify expected responses. Annotations (readOnlyHint=false, etc.) are consistent and the description adds substantial 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 well-organized with sections for summary, requirements, rate limits, arguments, return value, examples, and error handling. It is concise yet comprehensive, with no superfluous content. The most critical information is front-loaded.
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 complexity (8 parameters, nested embeds, no output schema), the description covers all necessary aspects: parameter constraints, return object structure, multiple examples, and error handling. It provides enough detail for an agent to use the tool correctly.
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 coverage is 100%, but the description adds meaningful context beyond schema, such as the requirement for at least one of content/embeds, thread_id's auto-archive revoke effect, and thread_name's channel type restriction. It also explains the allowed_mentions structure and embed limits (10 max, 6000 chars total).
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 explicitly states 'Discordチャンネルにメッセージを送信します' (send a message to a Discord channel), clearly defining the verb and resource. It distinguishes from sibling tools discord_delete_message and discord_edit_message.
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 specifies that either content or embeds is required, uses an environment variable for the webhook URL, and notes rate limits. It provides error handling guidance but does not explicitly contrast with sibling tools; however, the context makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.4discord_delete_messagediscord_edit_messagediscord_send_messageThe three tools have clearly distinct purposes: send, edit, and delete. There is no overlap or ambiguity.
All tool names follow a consistent pattern: 'discord_verb_noun' (discord_send_message, discord_edit_message, discord_delete_message).
Three tools cover the essential lifecycle for webhook messages (send, edit, delete) without unnecessary extras. The scope is well-scoped.
Covers all core operations for webhook messages. Minor gap: no tool to retrieve or list messages, but webhooks typically don't support listing, so it's acceptable.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Control your Discord community: send/read messages, manage channels and forums, and handle webhook…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kongyo2/discord-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server