이 MCP 서버는 단일의 유연한 도구를 통해 원시 Discord API 액세스를 제공합니다. REST API 호출과 슬래시 명령 구문을 모두 지원합니다.
Smithery 를 통해 Claude Desktop용 Discord Raw API를 자동으로 설치하는 방법:
지엑스피1
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")
payload: 요청 본문에 대한 선택적 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를 저장합니다.
~~유니코드 이모티콘을 메시지 내용에 직접 포함할 수 있나요~~? 모델에게 :champagne_glass:와 같은 디스코드 이모티콘을 사용하라고 알려주세요. - 유니코드 이모티콘이 포함된 메시지는 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.