Skip to main content
Glama
Sign In
Discord MCP - Discord server management MCP for AI agents

Discord MCP - Discord server management MCP for AI agents

by OrygnsCode
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Delete channel

delete_channel
Destructive

Deletes a Discord channel or category after returning a preview and confirm token for approval; removing a category leaves its channels uncategorized.

Instructions

Delete a channel or category. Safe to call directly: the first call deletes nothing and returns a preview plus a confirm_token, and the deletion only happens when the call is repeated with that token. When the user asks to delete something, call this and relay the preview for their go-ahead instead of sending them to do it manually in Discord; the gate exists exactly so deletion can be approved through the conversation. Deleting a category leaves its channels in place, uncategorized.

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": "delete_channel"
  }
}

Input Schema

NameRequiredDescriptionDefault
guildNoGuild (server) name or ID. Omit to use the default guild.
reasonNo
channelYesChannel or category name or ID.
dry_runNo
confirm_tokenNoThe 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.

  1. Changed2 schema fields changedv1.4.2
    • 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 / description
      Added value: +"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."
  2. Changed1 schema field changedv1.3.0
    • removedInput schema / additionalProperties
      Removed value: -false
  3. First observedv1.0.2

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true, and the description adds the genuinely useful fact that the first call is a no-op that returns a preview plus confirm_token, so deletion requires a second call. It also discloses that category deletion leaves child channels uncategorized. It does not cover permission requirements or what the preview contains.

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

Conciseness3/5

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

It is front-loaded with the purpose and the safety gate, which is good. The clause about the gate existing "exactly so deletion can be approved through the conversation" restates the preceding point and could be cut without losing information.

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

Completeness4/5

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

For a destructive tool with no output schema, the definition covers the confirmation workflow, the category side effect, and the user-facing approval step well. Remaining gaps are permission requirements and the unexplained dry_run and reason parameters.

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?

Schema coverage is 60%, so the schema documents most parameters. The description's best contribution is the inline explanation of the confirm_token two-step flow, but it leaves dry_run and reason entirely unexplained, and the token explanation largely duplicates the schema's own description of that field.

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?

"Delete a channel or category" gives a specific verb and resource, and the category note clarifies scope. It does not name a sibling to distinguish itself from (e.g. delete_thread, delete_forum_post), so differentiation is only partial.

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

Usage Guidelines4/5

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

It explicitly tells the agent to call this rather than instruct the user to act manually in Discord, which is clear situational guidance. What is missing is any exclusion: a thread, forum post, or role has its own delete sibling, and nothing here says to route those elsewhere.

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

Deploy Server

Other Tools