wisewigdocs
GitHubWebsite

MCP policy

Each site may offer two MCP surfaces. Both compose the protocol’s three server primitives—tools, resources, and prompts—through the same contracts used by Studio and the editor. Neither exposes raw SQL, R2 access, environment bindings, or unrestricted plugin APIs.

Public and private MCP

  • Public MCP offers only explicitly declared, read-only tools with no user/session context. It is appropriate for bounded site search or research, and must enforce rate limits, output filtering, and tenant/site scope. A public tool’s sole declared data scope is public_content.
  • Private MCP requires an authenticated session. Core and plugin tools are offered only if the caller’s WiseWig roles grant the tool’s required permission.

Plugins declare MCP tools, resources, and prompts in their manifest. Every primitive declares visibility and data scopes. A public capability cannot specify a private permission and may use only public_content; a private capability must specify a permission. The site composes the core catalog with only the installed plugin capabilities permitted for the current audience.

For example, a sermons plugin may expose sermons.research publicly to search sermon metadata and excerpts, while sermons.create_entry is private and requires content.edit. An authenticated client can submit a document/PDF through the normal signed-upload flow, create a draft sermon record, attach notes/media, link a Bible passage, and record the preacher. Publication remains a separate confirmed action.

Initial tools

  • Read: site context, page document, navigation, settings, media metadata, version diff.
  • Draft: create structured patch, validate draft, update navigation/settings, register an already-uploaded asset.
  • Controlled effects: request preview, request publish, create redirect, configure approved plugin settings.

All tools carry tenant/site scope, caller identity, expected document version where relevant, and an idempotency key. Writes produce drafts by default. Publish, delete, theme switch, plugin install, domain configuration, and outbound effects require an explicit confirmation step.

AI-assisted text changes use a two-step plan/apply pair. Planning is a no-write schema validation that returns a digest-bound field diff and immutable source version. Applying accepts that unchanged plan through the same guarded command ledger and atomically records the resulting draft version plus request/model/source attribution in tenant SQLite. Tampering or any intervening draft change fails closed. Restoring the source version is a separate confirmed, idempotent draft command. Provenance listing requires audit.view, not ordinary content visibility.

Private retrieval provides draft page search plus fixed navigation, settings, form-definition, and version resources. Draft search includes non-public pages but reads only the typed page collection in the tenant Worker. Form definitions never include response rows. Submission, engagement, personal-data, audit, and plugin-record access remain separate permissioned operations; private search cannot use them as an ambient corpus.

MCP does not upload binary media. It obtains a signed upload URL through the hosting adapter, then registers validated metadata after upload.

First-class resources and prompts

The public service exposes published structured content as a wisewig:// resource and a research prompt that tells the client to answer from that resource. The private service exposes the authenticated site’s current draft as a resource and a planning prompt that explicitly stops before publication. Tools carry MCP annotations such as read-only, idempotent, destructive, and open-world hints so capable clients can present safer interaction affordances.

Page metadata and component ai guidance are compiled into these primitives; they do not create new authority. The framework projects the canonical Zod definitions into Draft 2020-12 JSON Schema together with controls, variants, structure, placement, defaults, and writing guidance. Public publishing copies only this non-secret catalog and a citation-bearing index of discoverable published pages. Resources repeat the same audience and data-scope checks as tools, and prompt text never bypasses the guarded command path. Plugin resources and prompts use the same public/private validation rules as plugin tools.

Hard security boundary

Public and private MCP are separate deployable gateways, not two route conditions around the same privileged binding. The public gateway receives a read-only public-content search/index binding only. It must not receive tenant workspace/D1 bindings, private R2 buckets, form-submission or engagement stores, outbound webhooks, session verification secrets, or a service binding that can query them.

The private gateway authenticates the caller, resolves tenant and site membership, authorizes every invocation by role, and writes an audit record. Catalog filtering is defense in depth, not authorization: the invocation path repeats the public-content-only check and private command authorization.

The deployed reference services and exact binding boundary are described in MCP gateways. Production deployment must preserve their separate binding sets.

Engagement, survey responses, customer purchases, and any personal data are private-only scopes. Aggregate cohort queries (for example, eligible customers who bought crayons) require engagement.view or audience.manage; raw personal-data/export operations require the separate engagement.export permission, explicit confirmation, consent/unsubscribe enforcement, small-cohort suppression, and audit logging. Raw exports are intentionally not an initial public feature.