Discord MCP - Discord server management MCP for AI agents

Undo change

undo_change

Destructive

Revert a Discord server change made through this server, such as a channel, role, permission, or settings edit, from its exact saved copy. Preview first, then confirm to apply.

Instructions

Undo changes made through discord-mcp, from their records: builds, and any single create, edit, or delete of a channel or role, permission edit, role given or taken, server settings edit. Use this rather than redoing things by hand: it has an exact copy of what was there. It deletes what a change created, puts back what it changed, and recreates what it deleted. A setting goes back only if it still holds the value the change set; anything changed since stays and is reported. Recreated items get new ids, and a deleted channel's messages cannot come back. Pass change_id for one change, since (a time) to undo every change made from then on, such as everything today, or change_ids for several; they are undone newest first. With none, the latest change not yet undone. The first call changes nothing and returns every step plus a confirm_token; repeat with the token to run it. If a step fails (a rate limit, say), calling it again finishes the rest.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "undo_change"
  }
}

Input Schema

Name	Required	Description
`guild`	No	Guild (server) name or ID. Omit to use the default guild.
`since`	No	ISO date-time: undo every change made at or after it.
`dry_run`	No
`change_id`	No	One change, from list_changes or the tool that made it.
`change_ids`	No	Several changes.
`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.

Addedv1.4.2Nov 12, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the destructiveHint annotation it discloses the exact revert semantics (delete what was created, restore what was changed, recreate what was deleted), the guard that a setting only reverts if it still holds the value the change set, that newer edits are preserved and reported, that recreated items get new ids, and that deleted channel messages are unrecoverable. It also discloses the two-phase preview/confirm_token flow and the retry-to-finish behavior on partial failure — far more than the annotations convey.

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?

Purpose and irreversibility risks are front-loaded, and every sentence carries information. The parameter sentence ('Pass change_id for one change, since (a time) to undo every change made from then on... or change_ids for several') is tangled enough to slow comprehension slightly, but nothing is redundant.

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, six-paramutation-style tool with no output schema, the description covers confirm flow, partial failure, irreversibility, and scope selection — nearly everything an agent needs before invoking. The unexplained dry_run parameter and the absence of any permission/prerequisite note are the remaining minor gaps.

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?

With 83% schema coverage the baseline is 3, and the description adds real meaning: it explains the semantics of change_id versus change_ids versus since versus omitting all three, and describes the ordering of multi-change undos (newest first) and the confirm_token's role. The one gap is dry_run, which carries no schema description and is never explained in prose.

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?

The description names the exact resource (records of changes made through discord-mcp) and enumerates the operation types it covers: builds, create/edit/delete of channels and roles, permission edits, role grants, server settings edits. It also contrasts itself with the alternative of manual redoing, so an agent can tell this is a targeted rollback tool rather than a generic mutation.

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 gives concrete selection rules for scope: change_id for one change, since for everything from a time onward, change_ids for several, and none for the latest not-yet-undone change. It does not state prerequisites such as required permissions or when undoing is inappropriate (for example, after out-of-band changes), which keeps it short of a full when/when-not statement.

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

Deploy Server