GuildControl MCP

GuildControl MCP is a local stdio Model Context Protocol server for safe Discord guild and separately allowlisted one-to-one access through an operator-owned bot. It combines broad typed coverage with exact scope, privacy-minimized results, reviewed writes, content-free evidence, and explicit ambiguity handling.

Least privilege. Review before mutation. Verifiable outcomes. No Discord-content persistence.

GuildControl is an independent project and is not affiliated with or endorsed by Discord Inc. Discord is used only to identify the platform that GuildControl connects to.

Why this connector

Concern	Enforced behavior
Discord reach	One strict non-secret policy file with verified application and bot identities, exact guild and channel scope, a separate exact-user private-message scope, risk-separated toolsets, and read-only setup presets
Exact targeting	Canonical Discord jump links and official typed mentions convert locally into exact IDs without name lookup, Discord contact, input echo, persistence, or downstream authority
Read safety	Bounded requests, lossless whole-result byte budgets, strict response validation, privacy-tiered projections, untrusted-content handling, caller-retained multi-channel catch-up with loss-resistant cursor advancement, exact native attachment reads without local-file persistence, and no private-channel discovery or scope inheritance
Write safety	Exact-ID requests, keyed fresh plans, signed interactive approval, a final fresh-plan match, and action-specific Discord permission proof
Outcome integrity	Pending content-free evidence, non-retried writes, exact readback, durable coordination, ambiguity quarantine, and bounded local invalid-request pressure
Privacy	Tokens stay in a caller-owned secret source; Discord content, profiles, URLs, audit reasons, and raw operation keys are not persisted
Plan review	Complete evidence, MCP App display, and local authority-free blueprint preview
Release integrity	Exact dependency and base-image pins, credential-free contract fingerprints, reproducible npm and MCPB artifacts, hardened OCI checks, embedded and external SPDX evidence, signed-release automation, and source-bound public documentation

Use the first verified read guide for one linear setup and recovery path. Read product boundaries and host compatibility to decide whether the custody, privacy, approval, and recovery model fits. The complete reference documents every tool family, policy gate, permission boundary, privacy tier, resource, prompt, Gateway mode, operator command, and workflow-specific limitation.

Quick start

The fastest supported outcome is an operator-owned read-only bot, one non-secret policy file, a private host activation guide, and a successful host-side channel inventory. The first inventory response is a compact bounded directory page, with an authenticated continuation for larger guilds and exact metadata available only when requested. Follow the complete getting-started guide if this is your first installation; the commands below are the condensed operator path.

Every command and nested action supports credential-independent -h and --help; use guildcontrol FAMILY ACTION --help or the equivalent guildcontrol help FAMILY ACTION for exact syntax and the action's authority, privacy, and side-effect boundary before supplying values.

Requirements:

Node.js 22 or newer
A Discord application with a bot user
One strict non-secret JSON policy file
The bot token available through an environment variable or protected file
A local stdio MCP host, with one-click MCPB import available in compatible hosts
Only the Discord permissions needed for the selected read or reviewed-write scope

Each deployment uses a Discord application and bot controlled by that operator. GuildControl MCP does not provide a shared bot, hosted relay, or shared token: create your own application, invite its bot only to guilds you control, and keep its credential in the local launcher or secret store.

Do not grant the bot Administrator. Generate the exact initial permission grant from a read-only preset, then narrow the installed bot role with category or channel overrides. The bot setup guide explains bot ownership, optional intents, and later feature-specific permissions.

Optional preflight: inspect without credentials

Inspect an exact release and its read-only preset without a token or Discord request:

npx --yes guildcontrol@0.1.2 catalog --check
npx --yes guildcontrol@0.1.2 catalog --html ./guildcontrol-contract.html
npx --yes guildcontrol@0.1.2 preset show server-observer

catalog --check verifies the credential-free, execution-disabled production contract, including complete per-tool setup and readiness metadata. catalog --html FILE renders it as a release-exact guided, searchable offline explorer with no external asset, runtime request, credential, or configured completion ID.

Switch from another Discord MCP

Generate a complete release-exact outcome map before creating policy or changing the old deployment:

npx --yes guildcontrol@0.1.2 migrate list
npx --yes guildcontrol@0.1.2 migrate plan cappyeo@0.25.0 --html ./guildcontrol-migration.html

The migration guide covers every scored peer release. Planning scans no checkout, reads no configuration, host setting, environment value, or credential, contacts no network or Discord endpoint, and changes nothing. It maps every audited source tool into supported, review-required, or intentionally excluded outcomes and validates target routes against the negotiated production catalog. It does not rewrite prompts, arguments, configuration, credentials, or host settings.

Install your owner-managed bot

Create a Discord application and bot in the Developer Portal, copy the public Application ID and target Server ID, and generate a callback-free install link whose guild and least-privilege permission grant come from the recommended preset:

npx --yes guildcontrol@0.1.2 preset install server-observer \
  --application-id YOUR_APPLICATION_ID \
  --guild-id YOUR_GUILD_ID \
  --html ./guildcontrol-onboarding.html

Open the printed URL while signed in as a member allowed to manage that server. It requests only View Channel for server-observer, locks the server selector to the supplied ID, requests no user token, and never sends the bot token to the connector command. Keep Public Bot disabled unless other people should be able to install your application. Use channel-reader instead to request View Channel plus Read Message History; its plan also identifies Message Content as the recommended Developer Portal intent.

Optional --html FILE adds a deterministic standalone checklist, copy controls, explicit Discord navigation, pinned follow-up commands, and exact plan evidence without a token, external asset, background request, persisted browser state, automatic browser launch, or overwrite. The terminal plan remains complete without HTML.

Create the safest first configuration

From a canonical process-owned private directory, keep the token in a secret-capable launching environment, verify one exact guild, save the complete non-secret policy in one file, and test the full MCP path:

export DISCORD_BOT_TOKEN
printf 'Discord bot token: '
read -r -s DISCORD_BOT_TOKEN
printf '\n'
npx --yes guildcontrol@0.1.2 setup \
  --npx \
  --config ./guildcontrol.json \
  --preset server-observer \
  --guild-id YOUR_GUILD_ID
npx --yes guildcontrol@0.1.2 host --npx --config ./guildcontrol.json --html ./guildcontrol-host-activation.html

On PowerShell 7.1 or newer, read the token into the current process without displaying it or placing its value in command history, then run the same commands:

$env:DISCORD_BOT_TOKEN = Read-Host "Discord bot token" -MaskInput

Enter each displayed multi-line shell command on one line in PowerShell; the npx arguments remain the same. With older Windows PowerShell, use an MCP host secret facility or protected token file instead of a token literal in command history.

If the launcher, container runtime, or orchestrator mounts the token as a file, select that input instead. The path must be absolute, the file must already exist for verified setup, and --token-file cannot be combined with --token-env or an ambient DISCORD_BOT_TOKEN:

npx --yes guildcontrol@0.1.2 setup \
  --npx \
  --config ./guildcontrol.json \
  --preset server-observer \
  --guild-id YOUR_GUILD_ID \
  --token-file /run/secrets/discord_bot_token

The server-observer preset exposes guild metadata, roles, permission diagnostics, connector health, content-free activity, and tool discovery without enabling writes, the Gateway, telemetry, persistence, or Message Content access. Setup is the first-run readiness gate: it validates the strict policy, verifies the application and bot, audits the exact guild installation, stores public IDs and a credential reference but never the token, and prints the launch descriptor. A ready setup exits successfully even when it reports non-blocking warnings for deliberate review. route_discord_goal safely routes later discovery, reads, and reviewed planning, never mutation; it creates bookkeeping keys itself instead of asking the operator to invent them.

The versioned file is the only policy boundary. It covers identity, read scope, tools, capabilities, feature scopes, limits, local storage paths, Gateway behavior, runtime settings, and privacy-safe observability. A typical deployment has two inputs: one JSON policy file and one external bot-token secret. The bot token may be referenced through an environment variable or a strictly validated file; optional authenticated-collector headers remain environment references. The checked-in JSON Schema supports editor validation, while config show and config explain provide secret-free inspection. Managed profiles use the same document when private per-user storage is preferable.

Operational commands require --config FILE, --profile NAME, or the non-secret GUILDCONTROL_CONFIG_FILE selector. Ambient policy variables are rejected and there is no alternate environment-policy or automatic import mode. The offline migrate planner never becomes a runtime policy source. Running setup without a preset verifies an existing policy without rewriting it, while a preset explicitly creates or replaces the selected target.

Connect with the one-click bundle or a generated adapter

After setup reports ready, compatible MCPB hosts can import guildcontrol-0.1.2.mcpb from the immutable GitHub Release or MCP Registry. Select the strict config and enter only the token through the sensitive prompt. The verified bundle supports macOS, Windows, and Linux, duplicates no policy field, embeds privacy and dependency evidence, and completes a real unpacked MCP handshake.

For a file-backed token or another host, host emits deterministic adapters for common MCP JSON, Cursor, VS Code, and Gemini CLI. host plan and host apply review and install one static JSON projection without resolving credentials or replacing unrelated entries; --inspect-host-file reports exact drift without returning observed values. The connection guide covers setup and verification.

Once the host is connected, the first useful request can stay natural and narrow:

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

config validate, doctor, and smoke are optional assurance and recovery tools rather than mandatory repetitions after successful setup. Offline doctor remains useful before a secret is mounted or when its referenced file is unavailable. Its default human output shows totals plus actionable warnings and failures; add --verbose for every check or --json for complete machine-readable evidence. doctor --online contacts Discord only when the real selected credential is available, while smoke launches a child server and verifies the MCP handshake. Doctor exits 1 when warnings need review even though it describes that state as ready with warnings.

npx --yes guildcontrol@0.1.2 config validate ./guildcontrol.json
npx --yes guildcontrol@0.1.2 doctor --config ./guildcontrol.json --online
npx --yes guildcontrol@0.1.2 smoke --config ./guildcontrol.json

Review any policy replacement

Keep the active policy unchanged while editing a separate candidate, then review and apply only an exact fresh plan:

npx --yes guildcontrol@0.1.2 config workbench \
  ./guildcontrol.json \
  --html ./guildcontrol-workbench.html
npx --yes guildcontrol@0.1.2 config plan \
  ./guildcontrol.json \
  ./guildcontrol.candidate.json
npx --yes guildcontrol@0.1.2 config apply \
  ./guildcontrol.json \
  ./guildcontrol.candidate.json \
  --plan-digest SHA256_FROM_THE_PLAN \
  --confirm ACTIVE_POLICY_NAME

The private workbench keeps edits in memory until explicit candidate download and has no secret, network, persistence, Discord, active-file write, or approval authority. Application rereads both files, requires the fresh digest and policy-name confirmation, rejects identity or file drift, and preserves a recoverable backup. The active document remains the only policy source.

Review recent write outcomes and durable cross-process claims from the same selected policy without making a Discord request or resolving its credential:

npx --yes guildcontrol@0.1.2 activity \
  --config ./guildcontrol.json \
  --html ./guildcontrol-activity.html

The bounded review collapses each activity into its newest outcome, retains superseded history, joins durable claims only through content-free digests, and warns on every unsettled state. Its optional private explorer adds search and filters but cannot contact Discord, resolve a claim, retry an operation, or persist browser state. Use coordination resolve only after stopping the owner and checking the exact Discord state and audit log.

Feature policy uses the same document shape. Reviewed features retain separate capabilities, exact scopes, bounded limits, and documented toolsets; single-member authority never grants batch authority. No environment-policy interface, legacy alias, fallback parser, or automatic migration layer exists.

Use channel-reader only when bounded message history, caller-retained channel catch-up, and native search are needed. It requires at least one exact channel:

npx --yes guildcontrol@0.1.2 setup \
  --npx \
  --config ./discord-reader.json \
  --preset channel-reader \
  --guild-id YOUR_GUILD_ID \
  --channel-id YOUR_CHANNEL_ID

Expand the policy through review

Keep first setup read-only, then plan one additive recipe. message-channel is the narrowest first write: plain sends, replies, connector-owned edits, and typing acknowledgement in exact channels, with no privileged intent or message-history, reaction, component, or embed tools. Actual messages need ordinary host write approval, not a plan and signed confirmation. coordination-channel adds directed notes, channel-publisher adds the broader read, reaction, Components V2, and remote-free embed surface, guild-starter adds reviewed public layouts with nonprivileged GUILDS evidence, and guild-builder adds the broader blueprint lifecycle. incident-response adds reviewed lockdown, while direct-messenger adds reviewed exact-user private messaging. Every recipe reports permissions, intents, scopes, risks, and exclusions before policy changes.

npx --yes guildcontrol@0.1.2 recipe list
npx --yes guildcontrol@0.1.2 recipe plan guild-starter ./guildcontrol.json \
  --guild-id YOUR_GUILD_ID
npx --yes guildcontrol@0.1.2 recipe apply guild-starter ./guildcontrol.json \
  --guild-id YOUR_GUILD_ID \
  --plan-digest SHA256_FROM_THE_PLAN \
  --confirm guild-starter
npx --yes guildcontrol@0.1.2 recipe plan message-channel ./guildcontrol.json \
  --channel-id YOUR_MESSAGE_CHANNEL_ID
npx --yes guildcontrol@0.1.2 recipe apply message-channel ./guildcontrol.json \
  --channel-id YOUR_MESSAGE_CHANNEL_ID \
  --plan-digest SHA256_FROM_THE_PLAN \
  --confirm message-channel
npx --yes guildcontrol@0.1.2 recipe plan direct-messenger ./guildcontrol.json \
  --user-id EXPECTED_RECIPIENT_USER_ID
npx --yes guildcontrol@0.1.2 recipe apply direct-messenger ./guildcontrol.json \
  --user-id EXPECTED_RECIPIENT_USER_ID \
  --plan-digest SHA256_FROM_THE_PLAN \
  --confirm direct-messenger

Planning prints the complete proposed document, exact changes, requirements, risks, warnings, and path-bound digest without a secret or Discord request. Application recomputes the plan, requires exact digest and name confirmation, rejects source drift, and preserves a backup. Recipes add policy only and grant no Discord authority.

Online doctor verifies identity, complete ID-only installation drift, and application posture. Smoke launches serve, negotiates stable MCP over stdio, validates catalogs and read-only status, writes nothing to Discord, and shuts down configured runtimes. See the operator reference.

Build from source

git clone https://github.com/j-256/guildcontrol.git
cd guildcontrol
npm run deps:locked
npm run build
node dist/bin.js catalog --check

The exact installation, operator CLI, and configuration references cover standalone configuration, managed profiles, OCI bind mounts, progressive discovery, toolsets, allowlists, optional Gateway modes, observability, and every independently gated feature.

Capability map

Area	Selected capabilities
Discovery and reads	Scoped guild, channel, message, thread, forum, member, moderation, audit, application, event, voice, and configuration reads; exact-ID parsing and attachment access; caller-retained multi-channel catch-up, native search, bounded recall, aggregate activity, and privacy-minimized outputs
Messages and communities	Idempotent delivery; authority-free directed notes and exact-message task coordination; reviewed private messages; Components V2, remote-free embeds, attachments, reactions, polls, crossposts, forwarding, threads, pins, and exact deletion
Guild structure	Deterministic starters and caller-retained blueprints; additive channels, roles, forums, permissions, onboarding, AutoMod, and publications; reviewed cloning, ordering, metadata, synchronization, and retirement
Members and moderation	Privacy-minimized directories and ban audits; reviewed exact-member moderation, roles, nicknames, verification, voice, and thread membership; resumable batches, native bulk bans, and protected guild pruning
Community configuration	Application, command, linked-role, monetization, webhook, integration, invite, template, profile, settings, Community, expression, soundboard, event, Stage, and AutoMod audits and reviewed lifecycles
Operations	Progressive discovery, resources, and prompts; model-neutral playbooks; strict configuration, profiles, host guides, presets, and recipes; content-free audit and coordination; bounded Gateway and native Interaction runtimes; OpenTelemetry diagnostics

Capabilities are exposed only when their toolset and policy gates are selected. A toolset narrows the callable surface but never grants Discord or local write authority. Browse the exact tool reference, resources, and prompts.

Safety model

Discord permissions are the outer boundary. Connector policy narrows that authority further.

Production traffic uses fixed Discord REST and vetted Gateway origins; runtime configuration cannot redirect credentials
Each Gateway shard counts every successful outbound event in one rolling connection budget, bounds caller-command pressure below reserved lifecycle capacity, and discards queued exact-ID requests on every connection boundary
Exact scopes cover guilds, channels, roles, members, features, and HTTPS link origins
Guild tools reject DMs. Private-message tools require an independent exact ordinary-user allowlist and caller-known one-to-one channel IDs, support only plain text or bounded static Components V2, suppress mentions, enforce fixed anti-spam limits, and provide no discovery, bulk targeting, callback-bearing components, arbitrary embed URLs, or Gateway feed
Components V2 links require exact HTTPS origins; the connector never fetches them or follows redirects
Components V2 request Buttons use connector-generated HMAC IDs, require ready exact native Interaction ingress, create only a private bounded request for an exact allowlisted user, and never run a Discord write or administration action automatically
Discord names, messages, embeds, components, filenames, URLs, and other remote text are treated as untrusted data rather than instructions
Discord content may be returned transiently when explicitly requested, but it is not cached, journaled, exported, or persisted by the connector
New invite codes and URLs are delivered only through a caller-selected exclusive private file; MCP results, lifecycle records, errors, logs, and telemetry remain bearer-capability-free
Incoming-webhook credentials remain in exclusive exact-ID private files; MCP accepts only webhook and message IDs, and persistent activity, receipts, errors, logs, and telemetry remain credential- and content-free
Entitlement writes are separately scoped; test deletion needs creation proof, and consumption stores only a fulfillment-reference hash
Every consequential write retains its domain-specific permission, freshness, approval, audit, readback, and uncertainty gates
Message deletion accepts exact message IDs only and preserves every independent deletion gate
Channel deletion requires exact scope, complete dependency and permission evidence, irreversible-loss acknowledgement, and an exact target-bound blueprint attestation or no-artifact choice before signed review and Gateway absence proof; it never reads messages
Role deletion requires exact scope, zero holders, complete hierarchy, permission, and dependency evidence, irreversible-loss acknowledgement, an exact target-bound blueprint attestation or no-artifact choice, signed review, and fresh absence plus survivor-preservation proof
Guild pruning requires a separate exact guild allowlist, optional exact include-role allowlist, explicit acknowledgement that Discord does not reveal the candidate IDs, protected-identity role shields, a fresh native estimate below both requested and configured ceilings, signed review, and one non-retried request with strict count-only outcome evidence
Guild incident actions require one exact allowlisted guild, complete known MANAGE_GUILD or owner evidence, future deadlines no more than 24 hours ahead, signed review, one non-retried sparse write, and exact response plus fresh readback; clearing protection early is treated as destructive
Privileged-intent enablement accepts only Guild Members or Message Content when the strict policy proves that intent is required or recommended, preserves every observed non-target application flag, and excludes Presence, disabling, generic application editing, and automatic remediation

The common reviewed-write sequence is:

exact request -> fresh keyed plan -> human review -> signed approval
             -> final fresh-plan match -> pending content-free evidence
             -> one non-retried write -> exact readback or quarantine

Already-current requests are record-free no-ops where the Discord operation permits that proof. A known client rejection settles as failed. A transport failure, server failure, malformed success response, or missing readback is uncertain and must not be retried blindly. Durable claims keep the affected exact targets quarantined across connector processes until safe receipt evidence or explicit operator resolution proves what may proceed.

Read the complete safety model and security policy before enabling a write surface.

Trust and verification

Command	What it proves	Discord access
`guildcontrol catalog --check --json`	Exact production MCP inventories, access lifecycles, schemas, annotations, zero-value policy-completion proof, plan-review app authority, execution guard, and stable contract and resource digests	None
`guildcontrol catalog --html FILE`	Guided product tour and searchable rendering of the exact negotiated contract, including schemas, filters, completions, app source, resources, and safety guidance	None
`guildcontrol preset show server-observer --json`	Exact read-only tools, scope requirements, intents, and zero-write boundary for the recommended preset	None
`guildcontrol preset install server-observer --application-id ID --guild-id ID [--html FILE]`	Fixed-origin, guild-locked bot authorization plan plus an optional credential-free standalone checklist with exact digests and post-install commands	None
`guildcontrol config workbench ACTIVE --html FILE`	Private offline in-memory editor and explicit candidate download for one validated schema-v2 policy, with no active-file write or approval authority	None
`guildcontrol config plan ACTIVE CANDIDATE --json`	Complete candidate policy, exact semantic changes, authority impacts, tool exposure, warnings, identity lock, and fresh path-bound digest	None
`guildcontrol config apply ACTIVE CANDIDATE --plan-digest DIGEST --confirm ACTIVE_NAME`	Exact fresh local policy replacement with stale-file rejection, atomic publication, and a recoverable prior version	None
`guildcontrol recipe show guild-starter --json`	Exact additive capability, scope, toolset, permission, intent, Gateway-evidence, and risk contract	None
`guildcontrol recipe plan guild-starter FILE --guild-id ID --json`	Complete proposed policy, exact changes, requirements, warnings, and source-, path-, request-, and contract-bound digest	None
`guildcontrol migrate plan SOURCE [--html FILE] [--json]`	Complete release-exact source-tool accounting, safer target routes, staged switching commands, and deterministic plan evidence without reading or changing either deployment	None
`guildcontrol activity --config FILE [--html FILE] [--json]`	Bounded current write lifecycles, superseded history, exact content-free evidence, and correlated durable claims with warning status when operator attention is required	None
`guildcontrol doctor --config FILE`	Local Node.js, credential availability, identity pins, policy, scope, tool surface, lossless read-response budget, Gateway, observability, and write-gate diagnostics, even before a secret is available	None
`guildcontrol doctor --config FILE --online`	Strict policy, pinned application and bot identity, intent flags, complete bounded ID-only installed-guild inventory, and exact configured-scope drift	Read-only
`guildcontrol smoke --config FILE`	Spawned stdio negotiation, discovery, annotations, and connector identity through the selected policy	Read-only
`guildcontrol host`; `host plan`; `host apply`	Credential-free adapters, reviewed freshness-bound static JSON installation with a recoverable backup and rollback, and value-free drift inspection	None
`npm run container:verify`	Pinned-base build, non-root filesystem and process restrictions, secret-free metadata, deterministic catalog identity, MCP behavior, and safe credential failure	None
`npm run container:index:verify`	Exact multi-architecture index, platform configurations and blobs, and per-platform provenance plus SBOM records	Public image registries only
`npm run pack:verify`	Reproducible archives, exact package contents, isolated install, installed CLI, deterministic catalog evidence and HTML, and content-free MCP handshake	None
`npm run mcpb:verify`	Byte-identical cross-platform bundles, strict ZIP metadata and contents, embedded evidence, Registry hash binding, isolated token mapping, and a real unpacked MCP handshake	None
`npm run security:check`	Dependency vulnerabilities, registry signatures, and attestations	Public package registry only

catalog --check --json is designed for independent comparison. It needs no credential, ignores ambient connector authority, returns no configured completion identifiers, executes no Discord operation, opens no Gateway, exports no telemetry, and creates no activity record. Matching contract digests identify matching normalized MCP instructions, server capabilities, tool access lifecycles, policy-completion bindings, tool schemas and annotations, prompts, resources, templates, safety response, review app, and execution guard.

Release automation verifies reproducible npm and MCPB artifacts, a hardened multi-architecture OCI image, SPDX inventories, and signed provenance, then publishes an immutable GitHub Release before registering the exact public MCPB digest. Provenance is a build receipt, an SBOM a parts list, and an attestation their exact artifact-and-issuer binding; none certifies security or completeness. See the evidence boundaries and release runbook.

Architecture

The stdio transport, Discord REST client, scope policy, domain services, reviewed planning, durable coordination, activity log, observability, Gateway, and MCP adapter remain separate. Production uses native fetch, TypeScript ESM, exact dependencies, and lazy schemas that skip registration cost for excluded tools.

This keeps transport, permission evidence, local authority, reviewed writes, persistence, and MCP presentation independently testable. New capabilities must fit those boundaries rather than add a generic Discord dispatcher.

Documentation

Development

See CONTRIBUTING.md for changes and SUPPORT.md for setup and operator questions. Default tests use injected transports and do not contact Discord:

npm run metadata:check
npm run config:schema:check
npm run typecheck
npm test
npm run test:coverage
npm run build
npm run pack:verify
npm run mcpb:verify
npm run container:verify
npm run container:index:verify
npm run security:check

Live probes are explicit and read-only by default. No default verification command fetches message content or performs a Discord mutation.

License

AGPL-3.0-only

Canonical source: README.md

Documentation generated for guildcontrol@0.0.0. Canonical source and edit history remain in the public repository. GuildControl is an independent project and is not affiliated with or endorsed by Discord Inc. Discord is used only to identify the platform that GuildControl connects to.