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 AutoMod rule

delete_automod_rule
Destructive

Deletes a Discord AutoMod rule by name or ID after a preview and confirmation token, stopping its protection immediately upon confirmed deletion.

Instructions

Delete an AutoMod rule; its protection stops immediately. Safe to call directly: the first call changes nothing and returns a preview plus a confirm_token; repeating the call with the token deletes it. Turning it off with update_automod_rule is the reversible alternative.

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": {
      "rule": "<rule>"
    },
    "name": "delete_automod_rule"
  }
}

Input Schema

NameRequiredDescriptionDefault
ruleYesRule name or ID.
guildNoGuild (server) name or ID. Omit to use the default guild.
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

A4.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description is consistent with them while adding real detail: the immediate loss of protection and the two-phase preview/confirm_token protocol. The only weakness is that it presents the preview as automatic while an undocumented dry_run flag also exists, leaving the exact precondition for the preview slightly ambiguous.

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

Conciseness5/5

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

Three tight sentences, each carrying distinct information: the effect, the safe invocation protocol, and the reversible alternative. The irreversible consequence is front-loaded ahead of the mechanics.

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, no-output-schema tool this covers what an agent needs: what is destroyed, when it takes effect, how to invoke safely, and what to use instead. The remaining gap is dry_run, whose role is left unclear relative to the described automatic preview.

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 75%, so the baseline is 3; the description usefully contextualizes confirm_token by describing the preview-then-confirm flow, which explains why the token must come from "this exact action's preview." However, dry_run is never mentioned and the description's claim that the first call always changes nothing blurs how dry_run relates to that preview.

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 ("Delete an AutoMod rule") and immediately adds the consequence ("its protection stops immediately"), which is exactly what distinguishes it from update_automod_rule. The named sibling makes the boundary between deletion and disabling unambiguous.

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 an explicit alternative: "Turning it off with update_automod_rule is the reversible alternative," which functions as both a when-to-use and a when-not-to-use signal. It also tells the agent the safe invocation path (a preview first, then a repeat call with confirm_token), so no inference is needed.

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