Turn one request into a Discord outcome you can independently verify

The full lifecycle:

request -> dry-run plan -> human approval -> resumable apply -> Discord readback -> Activity Evidence

You're finished only when apply returns evidence.activity.evidence_id and a separate guild_blueprint_evidence call returns status: verified.

Use an empty, private test guild. This workflow creates roles, categories, channels, AutoMod rules, onboarding, and Components V2 messages. It never deletes existing resources, it blocks on conflicting names instead of guessing what may be overwritten.

Before you begin#

• Complete the quickstart first, with your bot connected and a verified read-only call.
• Use a dedicated test profile for this journey, don't reuse its write-enabled settings for a production guild.
• Keep every mutation inside one empty private test guild in ALLOWED_GUILDS.
• Enable Community manually in Discord before planning. Rename any default channel whose name would collide with your requested design, the planner preserves unrelated channels but fails closed on a same-name conflict.
• Put your bot's dedicated role above every role it may manage. Don't grant Administrator, the read-only plan reports the exact narrower permissions still missing.

Step 1: arm the confirmation gate for this profile#

guild_blueprint_apply requires both MCP_DRY_RUN=false in the server environment and __confirm:true in the approved call. Merge these into your existing discord-mcp entry, don't replace its command, arguments, or token forwarding:

{
  "mcpServers": {
    "discord-mcp": {
      "env": { "MCP_DRY_RUN": "false", "MCP_WRITE_MODE": "allow" }
    }
  }
}

Restart your MCP client once after merging this.

Step 2: ask for a read-only plan#

Ask your client to call build_discord_server (the progressive alias of guild_blueprint_plan) with your community request, and to show you the exact bot, guild, selected source evidence, operation summary, missing permissions, blockers, warnings, risks, and approval_id, without applying anything.

This reads your live guild and returns a target-bound dry run without changing Discord.

Step 3: resolve blockers, then review before approving#

A ready plan has status: ready, no blockers, an exact target, plan_id, approval_id, and normally a short caller-local plan_ref. If it reports MISSING_PERMISSIONS, grant only the listed names to the bot role and ask for a fresh plan. If it reports a resource conflict, rename the conflicting resource rather than asking the agent to overwrite it.

Before approving, confirm:

• The displayed bot ID and guild ID are yours.
• source.permission_policy is discard_source_and_regenerate.
• blueprint.safety.source_permissions_discarded: true and source_overwrites_discarded: true.
• blueprint.safety.severe_generated_role_permissions: 0.
• blueprint.bot_boundary.auto_grant_permissions: false.

Don't approve a blocked or surprising plan.

Step 4: approve and apply the exact plan#

Prefer the returned plan_ref. Approve the exact approval_id, then call guild_blueprint_apply with guild_id, expected_bot_id, approval_id, the unchanged plan_ref (or only plan_token when plan_ref is null, never both), and __confirm:true.

Apply checkpoints every successful operation and reconciles Discord before each resume. If it returns partial or busy, resume the same plan without changing any argument until it completes. A stale or blocked result with next_action: replan requires a fresh preview and approval, never fabricate a replacement reference.

Step 5: independently verify the outcome#

After apply returns complete or already_current, call guild_blueprint_evidence with the completed plan's exact guild_id, expected_bot_id, and plan_id. It does not change Discord.

The expected result is status: verified, readback: match, zero remaining operations, and no blockers. Repeat this read-only call later to detect drift after the MCP process restarts.

Activity Evidence is not the same thing as the CLI's discord-mcp activity local journal, that command shows a private, non-authenticated log of setup and smoke-test outcomes with no Discord IDs or content. guild_blueprint_evidence is the authenticated completion record.

Verified-outcome checklist#

• The plan named the exact caller-owned bot and allowlisted private guild.
• You reviewed a ready dry run and approved its exact approval_id.
• Apply completed, including any checkpointed resumes, with no unrelated tool calls.
• The result contained evidence.activity.evidence_id.
• A separate guild_blueprint_evidence call returned status: verified with no remaining operations or blockers.

Next steps#

Watch this exact lifecycle in action: the live gaming-server demo. Understand the mechanical guard behind __confirm and MCP_DRY_RUN: how it works. Back to the overview.