Skip to main content
Glama
TheStreamCode

Discord Management MCP

Delete Discord channel

discord_delete_channel
Destructive

Delete a Discord guild channel after confirmation and backup acknowledgement to prevent accidental removals during guild management.

Instructions

Delete a Discord guild channel after confirmation and backup acknowledgement.

Input Schema

NameRequiredDescriptionDefault
reasonNo
confirmNo
backupIdNo
channelIdYes
allowWithoutBackupNo

Output Schema

NameRequiredDescriptionDefault
okYes
nameNo
noteNo
typeNo
errorNo
actionYes
statusNo
clearedNo
guildIdNo
updatedNo
targetIdNo
channelIdNo
positionsNo
targetTypeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the danger profile is covered structurally. The description adds real value by disclosing the confirmation and backup-acknowledgement gate, but omits what the deletion destroys (messages, threads), what allowWithoutBackup does, and whether permissions are required.

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 no filler, and the safety precondition is placed before any other detail. It is efficient, though the terseness comes partly at the cost of information the agent needs.

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?

This is a destructive, irreversible mutation with five undocumented parameters. The output schema removes the need to describe return values, but the description still leaves the confirm/backupId/allowWithoutBackup interaction and the destruction scope unexplained, which is a serious gap for a delete tool.

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

Parameters2/5

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

Schema description coverage is 0% across five parameters, so the description carries the full burden. It only hints at 'confirm' and 'backup acknowledgement' (backupId / allowWithoutBackup) and says nothing about channelId format or the purpose of the optional 'reason' audit 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?

Names a specific verb and resource ('Delete a Discord guild channel'), which clearly separates it from sibling mutations like discord_delete_role or discord_update_channel. However, it doesn't explicitly contrast with alternatives or state the scope of the deletion (messages, threads, permissions).

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

Usage Guidelines3/5

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

The phrase 'after confirmation and backup acknowledgement' implies prerequisites but never states when to use this tool versus discord_backup_create / discord_backup_restore_plan or discord_update_channel. The agent must infer the workflow rather than being routed to it.

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