Este servidor MCP proporciona acceso directo a la API de Discord mediante una única herramienta flexible. Admite llamadas a la API REST y la sintaxis de comandos slash.
Para instalar Discord Raw API para Claude Desktop automáticamente a través de Smithery :
npx -y @smithery/cli install @hanweg/mcp-discord-raw --client claudeConfigura tu bot de Discord:
Crea una nueva aplicación en el Portal para desarrolladores de Discord
Crea un bot y copia el token
Habilitar intenciones privilegiadas requeridas:
INTENCIÓN DEL CONTENIDO DEL MENSAJE
INTENCIÓN DE PRESENCIA
INTENCIÓN DE LOS MIEMBROS DEL SERVIDOR
Invita al bot a tu servidor usando el generador de URL OAuth2
Clonar e instalar el paquete:
# 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
Agregue esto a su 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"
}Crear un rol:
{
"method": "POST",
"endpoint": "/role create name:Moderator color:red permissions:moderate_members guild_id:123456789"
}Enviar un mensaje:
{
"method": "POST",
"endpoint": "channels/123456789/messages",
"payload": {
"content": "Hello from the API!"
}
}Obtener información del servidor:
{
"method": "GET",
"endpoint": "guilds/123456789"
}Coloque los identificadores de servidor, canal y usuario y algunos ejemplos en el conocimiento del proyecto para evitar tener que recordarle al modelo sobre ellos, junto con algo como esto para comenzar:
A continuación, se explica cómo usar eficazmente la herramienta Discord Raw API: La herramienta se llama discord_api y acepta tres parámetros:
método: método HTTP ("GET", "POST", "PUT", "PATCH", "DELETE")
punto final: punto final de la API de Discord (por ejemplo, "guilds/{guild.id}/roles")
carga útil: objeto JSON opcional para el cuerpo de la solicitud Ejemplos clave que he utilizado:
Creación de roles:
discord_api
method: POST
endpoint: guilds/{server_id}/roles
payload: {
"name": "Role Name",
"color": 3447003, // Blue color in decimal
"mentionable": true
}Creación de categorías y canales:
// 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"
}Mover canales a categorías:
discord_api
method: PATCH
endpoint: channels/{channel_id}
payload: {
"parent_id": "category_id"
}Envío de mensajes:
discord_api
method: POST
endpoint: channels/{channel_id}/messages
payload: {
"content": "Message text with emojis \ud83d\ude04"
}Asignación de roles:
discord_api
method: PUT
endpoint: guilds/{server_id}/members/{user_id}/roles/{role_id}
payload: {}La herramienta es compatible con la API de Discord completa, por lo que puedes consultar la documentación de la API de Discord para obtener más puntos de conexión y funciones. Las respuestas incluyen ID y otros metadatos que puedes usar en solicitudes posteriores. Consejos profesionales:
Guardar los ID devueltos de las solicitudes de creación para utilizarlos en solicitudes de seguimiento
¿Se pueden incluir emojis Unicode directamente en el contenido del mensaje? ¿Indicar al modelo que use emojis de Discord como :champagne_glass:? ¿Los mensajes con emojis Unicode bloquean Claude Desktop?
Tipos de canal: 0 = texto, 2 = voz, 4 = categoría, 13 = escenario
Los colores de los roles están en formato decimal (no hexadecimal)
La mayoría de los puntos finales de modificación utilizan el método PATCH
Las cargas útiles vacías deben ser {} y no nulas"
Licencia 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.