The Discord Raw API MCP Server provides raw access to Discord's API, allowing you to:
Execute REST API Calls: Send GET, POST, PUT, PATCH, DELETE requests to Discord API endpoints
Use Slash Command Syntax: Interact with the API using simplified slash command-style syntax (e.g., /role create)
Manage Roles: Create, modify, assign, and delete roles
Operate Channels: Create, move, and manage various channel types
Handle Messages: Send and interact with message content
Manage Servers: Retrieve and manage guild information, members, and permissions
Include JSON Payloads: Provide optional data for complex requests
Access Full API: Use the complete range of Discord API endpoints for comprehensive server management
Provides raw Discord API access through a flexible tool, supporting both REST API calls and slash command syntax, allowing users to interact with Discord servers, create roles, send messages, and access server information.
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 Raw API MCP Server create a new role called 'Moderator' with blue color in my server"
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.
This MCP server provides raw Discord API access through a single flexible tool. It supports both REST API calls and slash command syntax.
To install Discord Raw API for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @hanweg/mcp-discord-raw --client claudeSet up your Discord bot:
Create a new application at Discord Developer Portal
Create a bot and copy the token
Enable required privileged intents:
MESSAGE CONTENT INTENT
PRESENCE INTENT
SERVER MEMBERS INTENT
Invite the bot to your server using OAuth2 URL Generator
Clone and install the package:
# 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
Add this to your 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"
}Create a role:
{
"method": "POST",
"endpoint": "/role create name:Moderator color:red permissions:moderate_members guild_id:123456789"
}Send a message:
{
"method": "POST",
"endpoint": "channels/123456789/messages",
"payload": {
"content": "Hello from the API!"
}
}Get server information:
{
"method": "GET",
"endpoint": "guilds/123456789"
}Put server, channel and user IDs and some examples in project knowledge to avoid having to remind the model of those, along with something like this to get it started:
"Here's how to effectively use the Discord raw API tool: The tool is called discord_api and takes three parameters:
method: HTTP method ("GET", "POST", "PUT", "PATCH", "DELETE")
endpoint: Discord API endpoint (e.g., "guilds/{guild.id}/roles")
payload: Optional JSON object for the request body Key examples I've used:
Creating roles:
discord_api
method: POST
endpoint: guilds/{server_id}/roles
payload: {
"name": "Role Name",
"color": 3447003, // Blue color in decimal
"mentionable": true
}Creating categories and channels:
// 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"
}Moving channels to categories:
discord_api
method: PATCH
endpoint: channels/{channel_id}
payload: {
"parent_id": "category_id"
}Sending messages:
discord_api
method: POST
endpoint: channels/{channel_id}/messages
payload: {
"content": "Message text with emojis \ud83d\ude04"
}Assigning roles:
discord_api
method: PUT
endpoint: guilds/{server_id}/members/{user_id}/roles/{role_id}
payload: {}The tool supports the full Discord API, so you can reference the Discord API documentation for more endpoints and features. The responses include IDs and other metadata you can use for subsequent requests. Pro tips:
Save IDs returned from creation requests to use in follow-up requests
Unicode emojis can be included directly in message content ? Tell the model to use discord emoji like :champagne_glass: - Messages with unicode emoji hangs Claude Desktop?
Channel types: 0 = text, 2 = voice, 4 = category, 13 = stage
Role colors are in decimal format (not hex)
Most modification endpoints use PATCH method
Empty payloads should be {} not null"
MIT License
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Build, validate, deploy — HTTP APIs, cron jobs, webhooks and MCP tools — from your AI client.
Build and deploy websites, Telegram and Discord bots from chat via the DreamAgent platform.
Discover and call 10,000+ production APIs from one MCP server. Pay-per-call billing for AI agents.
The Canva MCP server connects AI assistants (like Claude, ChatGPT, and Cursor) to Canva's API, enabling them to create and manage designs directly within chat conversations. Key capabilities include generating new designs from prompts, autofilling templates, searching and resizing existing designs, importing files from URLs, exporting designs as PDFs or images, and managing folders and comments without switching between tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hanweg/mcp-discord-raw'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
