Discord MCP - Discord server management MCP for AI agents

Set channel permissions

set_channel_permissions

Set a channel permission overwrite for a role or member, specifying allowed and denied permissions. Replaces the existing overwrite, and previews sensitive changes until you confirm them with a token.

Instructions

Set a permission overwrite on a channel for one role or member: which permissions are explicitly allowed and which are denied. It replaces that role's or member's whole overwrite on the channel, so list every permission it should keep, not only the new one; get_channel_permissions shows the current one. Permission names like manage_messages or send_messages. On a category, Discord also makes the same change in every channel inside whose permissions match the category's exactly (synced), as the Discord app does; the result names them. To keep such a channel as it is, change that channel first, which stops it matching. get_channel_permissions says whether a channel is synced. A change that would let someone see a channel they cannot see now, or give them moderator or admin powers (such as banning, kicking, or timing out members, deleting other people's messages, or managing the server, roles, or channels) there, needs confirming: the first call changes nothing and returns a preview and a confirm_token, and repeating the call with the token makes the change.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "channel": "<channel>",
      "target": "<target>"
    },
    "name": "set_channel_permissions"
  }
}

Input Schema

Name	Required	Description
`deny`	No	Permissions to deny.
`allow`	No	Permissions to allow.
`guild`	No	Guild (server) name or ID. Omit to use the default guild.
`target`	Yes	Role or member name or ID.
`channel`	Yes	Channel name or ID.
`confirm_token`	No	The token from this exact action's preview. Where the app can show a confirmation dialog, calling with it asks the user there, and it happens only if they agree.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.4.2Nov 12, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / properties / confirm_token

Added value: +{
+  "description": "The token from this exact action's preview. Where the app can show a confirmation dialog, calling with it asks the user there, and it happens only if they agree.",
+  "type": "string"
+}

Changed1 schema field changedv1.3.0Aug 12, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
First observedv1.0.2Jun 14, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnly=false and destructive=false, so the description must carry the burden of the replacement semantics and it does: overwrite replacement, category-level propagation to exactly-matching synced channels with results naming them, and a two-phase confirm_token flow where the first call changes nothing. It also enumerates which classes of permission change require confirmation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the operation and its replacement semantics, followed by the sync caveat and then the confirmation flow. It is dense and long, but nearly every clause carries decision-relevant information; a slight trim would help readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, replacement semantics, category sync side effects, permission-name format, and the confirmation protocol, and even notes that the result names the affected channels, so the absence of an output schema is not a gap. Nothing needed to call this tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds real meaning by explaining that allow/deny are exhaustive replacement lists rather than incremental edits, giving permission-name examples like manage_messages or send_messages. It also clarifies that the confirm_token comes from an exact action preview, which the schema describes only briefly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Set a permission overwrite on a channel for one role or member', and immediately clarifies it covers both allow and deny lists. This is clearly distinguishable from get_channel_permissions (which it names as the read counterpart) and clear_channel_permissions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit guidance: it replaces the whole overwrite, so 'list every permission it should keep, not only the new one'; get_channel_permissions shows the current one; to preserve a synced channel, 'change that channel first'. It also names the trigger condition for the confirmation flow rather than leaving the agent to discover it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server