Discord MCP Ultimate

discord_architect_apply

Idempotent

Applies a Discord server structure plan by creating roles, categories, and channels with preview-by-default, idempotent skipping of existing names, and resumable per-step results.

Instructions

Build a plan against the live server. PREVIEWS BY DEFAULT: returns the step list without changing anything; re-call with confirm:true to apply. Idempotent by name: a role, category or channel that already exists with the planned name is skipped rather than duplicated, so a re-run after a failure repairs the server instead of doubling it. Steps run in order (roles, then categories, then channels) and one failing step does not stop the rest: per-step results are returned so the build can be resumed. Requires Manage Channels and Manage Roles. A duplicate-suppression window rejects an identical plan re-submitted within 60 seconds. This creates structure inside an existing server; it cannot create a new Discord server (see discord_architect_explain_limits).

Input Schema

Name	Required	Description
`plan`	Yes
`reason`	No	Optional reason recorded in the audit log.
`confirm`	No	Set true to actually create. Default false returns a preview.
`guild_id`	Yes	Discord server (guild) ID (snowflake).

Output Schema

Name	Required	Description	Default
`mode`	Yes
`failed`	Yes
`applied`	Yes
`created`	Yes
`skipped`	Yes
`next_steps`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.0.0Oct 31, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well past the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false): discloses name-based idempotency and skip semantics, execution ordering across the three plan sections, per-step failure isolation with resumability, required permissions, and a 60-second duplicate-suppression window. These are exactly the behaviors an agent needs before applying a mutation.

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?

Front-loads the preview-by-default behavior, which is the single most decision-relevant fact, then layers idempotency, ordering, failure handling, permissions, and scope boundary. Six dense sentences, none redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A destructive-capable mutation with a nested plan schema and an output schema; the description covers safety (preview default), reversibility (idempotent repair), failure semantics, auth prerequisites, and rate limiting. Return values are covered by the output schema, so no gap remains.

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 75% and the nested plan object is heavily documented, so the baseline is 3. The description adds real semantics the schema does not carry: that confirm gates preview vs. apply, that plan entries are matched by name for idempotent skipping, and that section order dictates execution order.

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: builds server structure against a live guild from a plan, distinguishing it from planning-only siblings by emphasizing that it applies to the live server. The final sentence explicitly bounds scope ('cannot create a new Discord server') and routes to discord_architect_explain_limits.

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 the exact invocation path: call once for a preview, re-call with confirm:true to apply. States the precondition (Manage Channels and Manage Roles) and names the sibling tool to use instead when the intent is out of scope. There is also guidance on re-running after failures.

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

Deploy Server