Discord MCP - Discord server management MCP for AI agents

Update onboarding

update_onboarding

Configure a Discord community's new-member onboarding flow, including prompt options that grant roles or channels, default channels, and enabled state, with a preview-and-confirm step before saving.

Instructions

Configure the new-member onboarding flow on a Community server: prompts with options that grant channels and roles, the default channels every member sees, and the enabled state. Discord's app asks for at least seven default channels when configuring this by hand; the API has been observed to accept fewer. Members pick these options themselves, so offering a role that gives moderator or admin powers, or opens channels hidden from everyone, needs confirming: the first call changes nothing and returns a preview and a confirm_token, and repeating the call with the token saves it.

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

Input Schema

Name	Required	Description
`mode`	No	default counts only default channels toward the constraints; advanced counts prompt option channels too.
`guild`	No	Guild (server) name or ID. Omit to use the default guild.
`enabled`	No
`prompts`	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.
`default_channels`	No	Channel names or IDs every new member gets.

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"
+}

Changed3 schema fields changedv1.3.0Aug 12, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / prompts / items / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / prompts / items / properties / options / items / additionalProperties
```
Removed value: -false
```
First observedv1.0.2Jun 14, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false, and the description adds genuinely useful behavior the annotations cannot convey: the first call is a no-op that returns a preview and confirm_token, and privileged roles or hidden channels require confirmation. However, the return shape beyond 'preview and confirm_token' and what happens to unspecified settings are left implicit, so the disclosure is good but not thorough.

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?

Three sentences, front-loaded with the resource and scope, then the constraint caveat, then the confirmation mechanics. Dense but each clause carries content; the seven-channel trivia is borderline but does warn about a real constraint mismatch.

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 zero-required-parameter mutation tool with no output schema, this covers the confirmation workflow, privileged-grant risk, and channel-count constraints. It does not state what the preview contains or what a no-op invocation does, which would be the last gaps for an agent.

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?

Schema coverage is 67%, and the description compensates by explaining why parameters matter: option roles grant privileges members pick themselves, and confirm_token is tied to 'this exact action's preview.' The mode enum is documented in the schema, not repeated, which is correct economy.

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?

Names a specific verb and resource ('Configure the new-member onboarding flow on a Community server') and enumerates the exact surface it controls: prompts with options granting channels and roles, default channels, and enabled state. Clearly distinguishable from the read-side sibling get_onboarding.

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?

Explains the operative context (members self-select options, so privileged grants need confirmation) and prescribes the two-step call pattern. It stops short of naming when to use get_onboarding or other siblings instead, so it is clear but not fully exclusionary.

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

Deploy Server