Help Topics
Secure automation for your sites
MCP & AI Integrations
Connect compatible AI assistants to Site Building Factory so they can work with your sites through a controlled, permission-based interface.
What you can do
Discover your sites
List all sites owned by your account, including site IDs, page counts, design/template summaries, publication status and available public cloud URLs. This lets an assistant find the right site before reading or changing it.
Read site content
Ask an AI assistant to inspect one of your sites, including its pages and sections, so it can understand the current structure before suggesting or making changes.
Update site details
Update safe identity, SEO and call-to-action fields such as the site name, description, domain, meta title, meta description and primary button.
Create or update pages
Create a page or update an existing page by page ID or slug. Content is sanitized and revisions are created through the same site update pipeline used by the application.
Update sections
Change an existing section by section ID, optionally scoped to a page. This is useful for targeted content edits without rebuilding the whole site.
Delete pages
Remove a non-home page by page ID or slug. Home pages are protected from this MCP operation.
Queue a publish
Queue a complete cloud publish when you grant the separate publish permission and explicitly confirm the action.
Permissions and scopes
Each connected AI application receives only the permissions you approve during consent. Permissions are represented by OAuth scopes:
| Scope | Allows | Risk level |
|---|---|---|
sites.read |
Read owned sites, pages and sections. | Read only |
sites.write |
Update site fields, create or update pages, update sections and delete non-home pages. | Changes content |
sites.publish |
Queue a cloud publish for an owned site. | Separate confirmation |
offline_access |
Allow the client to request a refresh token for longer-running connections. | Session access |
sites.read. Add sites.write only when the assistant needs to make changes, and approve sites.publish only for an assistant you trust to queue deployments.
How authorization works
Your MCP client discovers the OAuth endpoints.
You authenticate in Site Building Factory.
You review and approve requested scopes.
The client receives short-lived access tokens.
- Authorization Code + PKCE: the connection uses the modern authorization-code flow with proof that the same client started and completed the request.
- Short-lived access: access tokens last approximately 10 minutes. A refresh token can be issued for approved offline access and lasts approximately 30 days.
- Account ownership: every operation is checked against the signed-in user, so an assistant cannot use your token to access another user's site.
- Audit trail: consent, token activity, revocation and publish events are recorded. Token values and webhook secrets are not recorded.
- Rate limits: OAuth and MCP requests are rate-limited to help protect your account and the service.
Publishing is deliberately harder
Editing content and publishing it are different actions. Even when a client has sites.publish, the publish tool requires an explicit confirmation in the same request:
confirm: true
confirmationText: "PUBLISH"This gives you a clear safety boundary: an assistant may prepare changes without automatically sending them live. The publish operation queues the existing cloud publishing workflow; it does not bypass your configured storage or site ownership checks.
MCP and webhooks are different
| MCP + OAuth | Site webhook | |
|---|---|---|
| Best for | AI assistants and interactive, user-approved work | Simple site-to-site automation and server jobs |
| Authentication | OAuth access token | Dedicated webhook secret or signed webhook headers |
| Permissions | Scopes such as sites.read and sites.write | Secret grants access to that webhook endpoint |
| Publishing | Separate scope plus explicit PUBLISH confirmation | Use the webhook workflow and its configured policy |
| Credential relationship | They are completely separate. Never enter a webhook secret as an OAuth credential. | |
Connecting an MCP client
Use an MCP client that supports OAuth 2.1 authorization code flow with PKCE and dynamic client registration. Give the client the MCP server URL:
The client should discover the authorization details from:
https://sitebuildingfactory.com/.well-known/oauth-authorization-serverhttps://sitebuildingfactory.com/.well-known/oauth-protected-resource
- Start the connection from the MCP client.
- Sign in when Site Building Factory opens the authorization page.
- Review the requested scopes carefully.
- Approve the connection.
- Return to the MCP client and ask it to list the available tools.
http://127.0.0.1. Redirect URIs must be registered by the client and are validated by Site Building Factory.
Managing and removing access
You remain in control after connecting an assistant:
- Review connected applications and their approved scopes in Manage connected access.
- Revoke an application when you no longer use it or do not recognize it.
- Revocation invalidates the authorization and its associated tokens.
- Administrators can review security events in the OAuth audit area.
Frequently asked questions
sites.publish scope and must send confirm=true together with the exact confirmation text PUBLISH.