このMCPサーバーは、単一の柔軟なツールを通じて、生のDiscord APIアクセスを提供します。REST API呼び出しとスラッシュコマンド構文の両方をサポートしています。
Smithery経由で Claude Desktop 用の Discord Raw API を自動的にインストールするには:
npx -y @smithery/cli install @hanweg/mcp-discord-raw --client claudeDiscord ボットを設定します。
Discord開発者ポータルで新しいアプリケーションを作成する
ボットを作成し、トークンをコピーする
必要な特権インテントを有効にします。
メッセージ内容の意図
プレゼンスインテント
サーバーメンバーの意図
OAuth2 URLジェネレータを使用してボットをサーバーに招待する
パッケージをクローンしてインストールします。
# Clone the repository
git clone https://github.com/hanweg/mcp-discord-raw.git
cd mcp-discord-raw
# Create and activate virtual environment
uv venv
.venv\Scripts\activate
### If using Python 3.13+ - install audioop library: `uv pip install audioop-lts`
# Install the package
uv pip install -e .Related MCP server: Discord MCP Server
これをclaude_desktop_config.jsonに追加します
"discord-raw": {
"command": "uv",
"args": [
"--directory",
"PATH/TO/mcp-discord-raw",
"run",
"discord-raw-mcp"
],
"env": {
"DISCORD_TOKEN": "YOUR-BOT-TOKEN"
}
}{
"method": "POST",
"endpoint": "guilds/123456789/roles",
"payload": {
"name": "Bot Master",
"permissions": "8",
"color": 3447003,
"mentionable": true
}
}{
"method": "POST",
"endpoint": "/role create name:Bot_Master color:blue permissions:8 mentionable:true guild_id:123456789"
}ロールを作成します。
{
"method": "POST",
"endpoint": "/role create name:Moderator color:red permissions:moderate_members guild_id:123456789"
}メッセージを送信:
{
"method": "POST",
"endpoint": "channels/123456789/messages",
"payload": {
"content": "Hello from the API!"
}
}サーバー情報を取得します:
{
"method": "GET",
"endpoint": "guilds/123456789"
}サーバー、チャネル、ユーザー ID といくつかの例をプロジェクト ナレッジに入れて、モデルにそれらを思い出させる必要がないようにします。また、開始するには次のような内容も入れます。
Discord の生の API ツールを効果的に使用する方法は次のとおりです。このツールは discord_api と呼ばれ、3 つのパラメータを取ります。
メソッド: HTTP メソッド ("GET"、"POST"、"PUT"、"PATCH"、"DELETE")
エンドポイント: Discord API エンドポイント (例: "guilds/{guild.id}/roles")
ペイロード: リクエスト本文のオプションの JSON オブジェクト 私が使用した主な例:
ロールの作成:
discord_api
method: POST
endpoint: guilds/{server_id}/roles
payload: {
"name": "Role Name",
"color": 3447003, // Blue color in decimal
"mentionable": true
}カテゴリとチャネルの作成:
// Category
discord_api
method: POST
endpoint: guilds/{server_id}/channels
payload: {
"name": "Category Name",
"type": 4 // 4 = category
}
// Text channel in category
discord_api
method: POST
endpoint: guilds/{server_id}/channels
payload: {
"name": "channel-name",
"type": 0, // 0 = text channel
"parent_id": "category_id",
"topic": "Channel description"
}チャンネルをカテゴリに移動する:
discord_api
method: PATCH
endpoint: channels/{channel_id}
payload: {
"parent_id": "category_id"
}メッセージを送信:
discord_api
method: POST
endpoint: channels/{channel_id}/messages
payload: {
"content": "Message text with emojis \ud83d\ude04"
}役割の割り当て:
discord_api
method: PUT
endpoint: guilds/{server_id}/members/{user_id}/roles/{role_id}
payload: {}このツールはDiscord APIを完全にサポートしているため、Discord APIドキュメントを参照して、より多くのエンドポイントや機能を確認できます。レスポンスには、後続のリクエストで使用できるIDやその他のメタデータが含まれます。プロのヒント：
作成リクエストから返された ID を保存して、後続のリクエストで使用します。
~~Unicode 絵文字をメッセージ コンテンツに直接含めることができます~~ ? モデルに :champagne_glass: のような discord 絵文字を使用するように指示します - Unicode 絵文字を含むメッセージは Claude Desktop をハングさせますか?
チャンネルの種類: 0 = テキスト、2 = 音声、4 = カテゴリ、13 = ステージ
ロールの色は10進数形式（16進数ではない）です
ほとんどの変更エンドポイントはPATCHメソッドを使用します
空のペイロードは null ではなく {} である必要があります
MITライセンス
Execute raw Discord API commands. Supports both REST API calls and application commands.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | HTTP method (GET, POST, PUT, PATCH, DELETE) | |
| endpoint | Yes | Discord API endpoint (e.g., 'guilds/{guild.id}/roles' or command like '/role create') | |
| payload | No | Optional request payload/body |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Executes raw Discord API commands' which implies it performs operations, but it doesn't disclose critical traits like authentication requirements, rate limits, error handling, or whether it's read-only or destructive. The mention of 'Supports both REST API calls and application commands' adds some context but is insufficient for a mutation-capable tool.
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 with two sentences that directly state the tool's function and scope. Every word earns its place, with no redundant or vague language. It is front-loaded and efficiently communicates the essential information without waste.
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 raw API execution tool with no annotations and no output schema, the description is incomplete. It lacks details on authentication, rate limits, error responses, and the nature of operations (e.g., whether it can perform destructive actions). For a tool that handles both REST and application commands with potential mutations, more context is needed to guide 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?
The schema description coverage is 100%, with clear descriptions for all parameters (method, endpoint, payload). The description adds no additional meaning beyond what the schema provides—it doesn't explain parameter interactions, format specifics, or examples. Baseline 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate with extra insights.
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's purpose: 'Execute raw Discord API commands' with the verb 'Execute' and resource 'Discord API commands'. It distinguishes between REST API calls and application commands, providing specific scope. However, without sibling tools, differentiation from alternatives is not applicable, preventing 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 or any prerequisites. It mentions support for 'both REST API calls and application commands', but this is part of the purpose statement rather than usage instructions. There are no explicit when/when-not scenarios or context for selection.
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.
v1.0.0discord_apiScored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'discord_api' has a clearly distinct purpose that covers all Discord API interactions.
Since there is only one tool, naming consistency is inherently perfect. The tool name 'discord_api' follows a clear and appropriate pattern for its function.
A single tool for a Discord API server is too few for the apparent scope, as Discord's API typically involves multiple resources and operations (e.g., channels, messages, users). This forces all functionality through one generic tool, which is a mismatch for the domain's complexity.
The tool surface is severely incomplete for a Discord API server. While the single tool can execute any raw API command, there are no specific tools for common Discord operations (e.g., send_message, get_channel, list_members), leaving significant gaps that will likely cause agent failures due to lack of structured guidance.
Build, validate, deploy — HTTP APIs, cron jobs, webhooks and MCP tools — from your AI client.
Official MCP server for twitterapis.com. Read and write Twitter/X: search, users, tweets, DMs.
Any REST/SOAP/GraphQL/OData/SQL API as MCP tools for Claude & ChatGPT. 325 connectors: SAP, ERP.
Discover MCP servers and A2A agents; verify, message, post, follow, react, and receive webhooks.