Getting started: first verified Discord read

This is the shortest supported route from no installation to a useful Discord read. It creates one owner-managed bot, one exact-guild read-only policy, and one private host handoff. It enables no write surface.

Before you run it

You need Node.js 22 or newer, Manage Server authority in a Discord server you control, and Discord Developer Mode enabled so you can copy the Server ID.

In the Discord Developer Portal, create an application and bot, copy the public Application ID, and create or reset its token. Keep the token in a protected secret source or enter it only when GuildControl shows the hidden prompt. Do not place it in a command argument, policy file, issue, or screenshot.

Run one command

npx guildctl

A bare interactive launch enters onboarding. guildctl onboard remains the explicit equivalent, while MCP hosts and scripts use guildctl serve or a non-interactive zero-argument launch.

If host choice is the only uncertainty, run npx guildctl host detect or opt in with npx guildctl onboard --detect-host. Detection checks only the existence and type of documented marker paths. It reads no candidate configuration content or credential and changes nothing. Exactly one candidate may be selected; ambiguity returns to an explicit choice.

1. Choose the MCP host you want to use first, or accept one unambiguous opt-in metadata detection result.

2. Enter the public Application ID and exact Server ID.

3. Review the generated server-observer grant and let GuildControl open the guild-locked Discord installation page if you want it to.

4. After installation, type the same Server ID exactly and provide the token through the selected protected route.

5. Wait for GuildControl to verify the application, bot, guild installation, strict policy, and a real child-process MCP handshake.

6. Open the private activation guide it creates and follow the selected host instructions.

If an exact onboarding policy already exists, rerun the same interactive command. GuildControl derives the public IDs from that policy, skips the repeated installation ceremony, then revalidates the live bot, policy, credential custody, stdio path, and host handoff. Policy drift fails closed instead of replacing the file.

The generated policy states its read modes directly, uses progressive discovery, suppresses user notifications, and permits documented message reads to follow verified child threads while keeping message writes exact. Those choices are visible policy, not hidden defaults.

The guide does not retain a prompted token

A hidden token is used only for setup and the smoke test. Your MCP host still needs the token through its own sensitive-input facility, protected environment, keychain, or supported credential file. GuildControl does not search for or silently edit host configuration.

Complete the first read

Reload the MCP host after activation, then send this request with your Server ID:

Show me the channels in Discord server YOUR_GUILD_ID using GuildControl MCP. Do not make changes.

Success proves that the host launched the selected package, delivered the referenced credential, loaded the exact policy, negotiated the MCP tools, and completed an in-scope Discord read. It does not authorize a later write or prove access beyond the configured and Discord-effective scope.

Need more control or recovery detail?

Use the advanced manual routeInspect the release first, choose another preset or credential mode, capture each proof separately, and use the complete recovery ladder.

Troubleshoot initializationSeparate policy, credential, Discord, stdio, and host failures without widening authority.

Check fit and boundariesReview custody, privacy, host compatibility, and deliberately unsupported behavior.

Review safety tradeoffsSee why each restriction was retained, internalized, made optional, or relaxed.

Migrate from another MCPMap the old release's outcomes and authority before changing either installation.