Discord MCP - Discord server management MCP for AI agents

Update member

update_member

Change a Discord member's nickname or voice state; server mute/deafen, voice moves, and moderator overrides require confirmation before applying.

Instructions

Edit a member's nickname or voice state. Voice changes (server mute, server deafen, move to another voice channel) only apply while the member is connected to voice. Role changes go through assign_role and remove_role. Moving someone into a voice channel they cannot join themselves lets them hear it, and lifting a server mute or deafen undoes what a moderator did, so those need confirming: the first call changes nothing and returns a preview and a confirm_token, and repeating the call with the token makes the change. Everything else, muting and deafening included, happens at once.

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": {
      "member": "<member>"
    },
    "name": "update_member"
  }
}

Input Schema

Name	Required	Description
`guild`	No	Guild (server) name or ID. Omit to use the default guild.
`member`	Yes	Member name or user ID.
`reason`	No
`nickname`	No	New nickname, or empty string to clear it.
`server_mute`	No
`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.
`move_to_voice`	No	Voice channel name or ID to move the member into.
`server_deafen`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.4.2Nov 12, 2026

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

Added value: +{
+  "description": "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.",
+  "type": "string"
+}

Changed1 schema field changedv1.3.0Aug 12, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
First observedv1.0.2Jun 14, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Goes well beyond readOnlyHint=false/destructiveHint=false by disclosing the two-step preview/confirm_token protocol, which calls change nothing on first invocation, and why those calls are gated (moving someone into a channel they cannot join, undoing a moderator's mute/deafen). The remaining gap is permissions or audit-log behavior for the `reason` field, and it does not reconcile that an "undo a moderator action" edit is still flagged destructiveHint=false.

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?

Front-loaded with purpose and scope before the conditional mechanics, and each sentence carries distinct information. The final sentence is a long run-on that packs the mute/deafen exception in last, which slightly hurts scanability.

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 an 8-parameter mutation with no output schema, the description supplies the critical return-value information (first call returns a preview and confirm_token) and the semantics of the prerequisite-only fields. Missing only secondary context such as permission requirements and what gets returned on the non-confirming path.

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 63% schema coverage the description carries real weight: it groups server_mute/server_deafen/move_to_voice as voice-only operations, ties confirm_token to a preview from "this exact action," and notes that muting/deafening (as opposed to move/unmute) applies immediately. It does not elaborate on `reason` or `guild`, which the schema already documents.

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?

Opens with a specific verb+resource plus scope: "Edit a member's nickname or voice state." It immediately distinguishes itself from siblings by naming assign_role and remove_role as the path for role changes, so an agent can route without opening another schema.

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?

Explicitly carves out what this tool does not do (role changes) and names the alternatives. It also gives the condition governing each field group (voice changes only apply while the member is connected) and states which cases require the confirm flow versus which apply immediately.

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

Deploy Server