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.

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 can be compiled into these primitives; they do not create new authority. 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.