Safety model

GuildControl MCP treats every layer as a narrowing boundary. Discord permissions, local policy, negotiated tool discovery, exact identifiers, interactive approval, and operation evidence serve different purposes. One gate never substitutes for another.

The authority stack

1. Discord grant

The bot receives only the application scopes, guild permissions, channel visibility, role position, and privileged intents required by the selected capability.

2. Local policy

One strict versioned file binds the verified application and bot identities to explicit read modes, typed exact-ID groups, notification and thread policy, selected toolsets, and feature gates.

3. MCP discovery

The server advertises only configured tools. Progressive discovery can narrow a large contract further without granting new Discord or local authority.

4. Request evidence

Exact IDs, complete permission evidence, bounded inputs, fresh state, and action-specific prerequisites must agree before a change can proceed.

Why exact IDs matter

Names are display text and can collide, change, or contain untrusted content. Destructive and administrative workflows target exact Discord snowflakes. Canonical Discord links and typed mentions may be parsed locally into those IDs, but the parser does not perform name lookup or gain downstream authority.

The reviewed-write path

1. RequestCall the reviewed executor with exact intent, normally without copying a digest
2. PlanResolve and bind permissions, hierarchy, scope, targets, and freshness
3. ApproveRequire signed request state and the MCP host's interactive write approval
4. ExecuteReplan, reserve durably, avoid mutation retries, and stop on ambiguity
5. VerifyRead back the exact result and record a content-free outcome

Canonical plan tools remain available for detached review and display, but manual digest transfer is not an extra security gate. The execute path prepares the same evidence, binds it into signed request state, and performs the same final fresh-plan comparison before a write.

Ergonomic choices with explicit risk

• Read scope uses visible allowlist or all-visible modes instead of an empty-list convention
• User notifications can be disabled, permanently allowlisted, or approved as an exact visibly mentioned exception during signed review
• Eligible message reads and publication writes can follow a freshly verified child thread from an exact configured parent, while administration stays exact-child scoped
• Safe Discord REST GET requests receive bounded transient retries; every mutation remains non-retried
• New setup uses progressive outcome-based discovery, while full canonical tools remain available for hosts with native deferral

Transport failure is not proof of failure

If Discord may have accepted a mutation before the response was lost, the connector quarantines the ambiguous operation for reconciliation. It does not blindly retry and risk applying the change twice.

What is never persisted

Messages, attachment URLs, embeds, components, audit-log reasons, usernames, profile names, role names, channel names, channel topics, scaffold symbols, and avatars remain outside durable activity and operation records. Receipts use Discord identifiers, timestamps, numeric parameters, domain-separated hashes, plan digests, strategies, sanitized errors, and outcomes.

Where to go deeper

• Complete safety model explains the product-level guarantees
• Safety and usability decisions records the threat, usability cost, retained controls, residual risk, and recovery rationale for every major restriction
• Reference foundations documents exact policy and protocol behavior
• Security details splits the security policy into searchable topics
• Fit and boundaries distinguishes verified properties from external constraints