discord-server-mcp

edit_channel

Change a Discord channel, category, or thread's name, topic, category, position, slowmode, NSFW, voice, or forum settings to organize and moderate servers.

Instructions

Change a channel, category or thread: name, topic, category, position, slowmode, NSFW, voice settings, forum settings.

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>"
    },
    "name": "edit_channel"
  }
}

Input Schema

Name	Required	Description
`bot`	No	Use this bot (name or id) instead of choosing automatically
`name`	No
`nsfw`	No
`topic`	No
`reason`	No	Reason shown in the server's audit log
`server`	No	Server name or id. Optional when the bot is in one server or DISCORD_GUILD_ID is set.
`bitrate`	No
`channel`	Yes	Channel or thread name, id, or message link
`dry_run`	No	Show the requests that would be made without changing anything
`category`	No	Category name/id, or "none" to take it out of its category
`position`	No
`forum_sort`	No
`user_limit`	No
`forum_layout`	No
`slowmode_seconds`	No
`sync_permissions`	No	With category: copy the category's permissions
`forum_default_reaction`	No	Unicode emoji, or "none"

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 12, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations provide only readOnlyHint=false, so the description must carry the behavioral burden and it does not: it never states that this is a partial mutation (unspecified fields untouched), says nothing about audit-log or permission requirements for renaming, and never mentions the dry_run preview path that the schema exposes. For a destructive-ish 17-parameter mutation this leaves significant gaps.

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?

A single front-loaded sentence with zero filler; the colon-plus-list structure is easy to scan. It is dense but appropriate in size for the number of fields, though the list reads as an inventory rather than prioritized guidance.

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

Completeness2/5

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

A 17-parameter mutation tool with no output schema, minimal annotations, and 47% schema coverage needs more than a field inventory. Nothing explains dry_run, reason, sync_permissions, server/bot selection, or partial-update semantics, so an agent still has to infer critical behavior from the schema alone.

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

Parameters3/5

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

The field enumeration groups parameters meaningfully ("voice settings" covers bitrate/user_limit, "forum settings" covers forum_sort/forum_layout/default_reaction), which helps orient the reader. But with schema coverage at 47%, undocumented-in-schema params like position, nsfw, bitrate and user_limit get no added semantics beyond their names, and the category+sync_permissions interaction is unexplained.

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

Purpose4/5

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

Names a specific verb ("Change") and the objects it applies to (channel, category, thread) and enumerates the editable fields, which separates it cleanly from create_channel and delete_channel. It stops short of naming a sibling for contrast, but the verb+resource pair is unambiguous.

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

Usage Guidelines2/5

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

There is no when-to-use guidance: nothing says to use dry_run first, nothing says when to use create_channel or edit_server instead, and no prerequisites (permissions, bot availability) are given. The only usage signal is implicit in the field list.

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