此 MCP 服务器通过单一灵活的工具提供原始 Discord API 访问。它支持 REST API 调用和斜线命令语法。
要通过Smithery自动为 Claude Desktop 安装 Discord Raw API：
npx -y @smithery/cli install @hanweg/mcp-discord-raw --client claude设置你的 Discord 机器人：
在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 并采用三个参数：
方法：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 表情符号可以直接包含在消息内容中~~ ? 告诉模型使用 discord 表情符号，例如 :champagne_glass: - 带有 unicode 表情符号的消息会挂起 Claude Desktop？
频道类型：0 = 文本、2 = 语音、4 = 类别、13 = 舞台
角色颜色采用十进制格式（不是十六进制）
大多数修改端点使用 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.