Docs/Reference

REFERENCE / GUIDE 12

Permissions and security

Scope connections and protect answers and media.

An MCP connection is an explicit, revocable grant to a workspace. Its permissions and campaign scope are resolved on the server for each request. A tool argument cannot expand that scope.

Permission choices

  • draft:read permits campaign and mission reads, validation, preview, and change history.
  • draft:write permits draft changes, deriving drafts, and campaign media uploads.
  • playtest:create permits author-only playtest snapshots.
  • campaign:create permits creating a new campaign and requires entire-workspace scope.
  • answers:read permits hidden puzzle answers in authoring reads. Without it, read results redact those values.

The connection form initially selects draft read, draft write, and playtest creation. Choose Entire workspace or specific campaigns. Selected-campaign scope cannot include campaign:create, because a campaign that does not exist cannot be in the allow-list.

Token handling

Studio displays a remote bearer token once. The database retains only a SHA-256 identifier, not the plaintext token. The token expires after 90 days and can be revoked earlier. Store it in the MCP client's secret or environment configuration, not in source control, documentation screenshots, or a URL.

Authorization checks token validity, revocation, expiry, and the issuing author's active workspace membership. Removing author access also removes usable MCP access. A browser Studio session is separate from the MCP bearer token.

Draft and player boundaries

MCP writes change the mutable draft. Published revisions, existing playtests, and running players are snapshots and are not rewritten. Node preview returns the player-safe projection and excludes server-only data. Campaign images and player uploads use private storage; signed upload URLs are temporary capabilities, not public asset URLs.

Current transport

Remote clients use stateless Streamable HTTP at https://www.wayweaver.app/api/mcp. The endpoint expects authenticated JSON-RPC POST requests. It does not expose a GET stream or persistent SSE session. OAuth client login is not implemented; clients must support a manually configured bearer token.