# RevCent Sites Overview for AI/MCP AI/MCP-focused overview for RevCent Sites. This document explains how AI and MCP clients should understand, create, inspect, route, and troubleshoot RevCent Sites using public-facing RevCent concepts and the supported Site operations. --- ## Source References Primary references: - RevCent Sites ecosystem overview: `https://revcent.com/documentation/markdown/ecosystem/feature/Site.md` - Product Group overview: `https://revcent.com/documentation/markdown/mcp/operation/OverviewProductGroup.md` - Product overview: `https://revcent.com/documentation/markdown/mcp/operation/OverviewProduct.md` - Payment Profile overview: `https://revcent.com/documentation/markdown/mcp/operation/OverviewPaymentProfile.md` - PayPal Account overview: `https://revcent.com/documentation/markdown/mcp/operation/OverviewPayPalAccount.md` - Tracking Domain overview: `https://revcent.com/documentation/markdown/mcp/operation/OverviewTrackingDomain.md` - RevCent MCP operation schemas: - `CreateSite` - `GetSites` - `GetSite` - `EditSite` - `AddTrackingDomainToSite` - `RemoveTrackingDomainFromSite` - `GetSiteEvents` - `GetSiteLogs` This overview focuses on the user-facing Site workflow: catalog selection, payment setup, repository collaborators, dev/live status, custom domain routing, Site Events, and Site Logs. --- ## Core Concept A RevCent Site is an AI-developed, RevCent-hosted ecommerce storefront, shopping cart, or lander connected to RevCent commerce. In plain language: ```text RevCent Site = AI-developed, RevCent-hosted ecommerce experience Product Group = catalog source Payment Profile = credit card payment strategy PayPal Account = optional PayPal payment strategy Tracking Domain = optional custom live domain ``` RevCent Sites are an AI-only ecommerce feature. They are not created or edited with a visual site builder inside the RevCent web app. AI is the intended developer and update method, while RevCent hosts the resulting Site for the user or merchant. At this time, the RevCent Sites feature is in beta. Users and merchants are responsible for developing, testing, reviewing, and approving their Site changes before relying on them for live customer traffic. AI/MCP clients should present RevCent Sites as AI-developed, RevCent-hosted ecommerce experiences and keep explanations focused on user-visible configuration, returned status, catalog, routing, events, and logs. --- ## Sites vs Shops RevCent Sites are completely separate from Shops, Third Party Shops, User Shops, and Site Shops. AI/MCP clients must not confuse these concepts or treat them as interchangeable. | Concept | Meaning | Correct Operation Family | |---|---|---| | RevCent Site | AI-developed, RevCent-hosted ecommerce storefront, cart, or lander. | `CreateSite`, `GetSite`, `EditSite`, `DeleteSite`, Site Events, Site Logs, Site tracking-domain operations. | | Shop / Third Party Shop / User Shop | Remote external store connected to RevCent, such as WooCommerce hosted elsewhere. | `CreateUserShop`, `GetUserShop`, `EditUserShop`, `ValidateUserShop`, `FixUserShop`, shop operations. | | Site Shop | Supported shop integration type, such as WooCommerce. It is not a RevCent Site. | `GetSiteShops`, `GetSiteShop`. | Recommended AI/MCP distinction: ```text Use Site operations for RevCent-hosted AI-developed Sites. Use Shop operations for external remote stores connected to RevCent. ``` If the user is talking about a WooCommerce store, external storefront, remote shop, WordPress store, or third-party ecommerce platform, use Shop / Third Party Shop concepts. If the user is talking about an AI-developed ecommerce Site hosted by RevCent, use RevCent Site concepts. --- ## Beta Feature and Repository Responsibility RevCent Sites intentionally give users and AI full access to the Site repository. AI/MCP clients should explain the tradeoff clearly: ```text RevCent hosts the Site. AI and collaborators develop the Site. The user or merchant is responsible for testing and approving changes. ``` Full repository access gives AI and collaborators the flexibility to create and modify the ecommerce experience in ways that closed visual builders or walled-garden SaaS platforms may limit. That flexibility is a core part of RevCent Sites, but it also means AI/MCP clients should encourage careful review, dev-branch testing, checkout testing, and explicit approval before live changes are treated as production-ready. Each Site repository includes detailed documentation for developing, customizing, testing, and maintaining that specific Site. After a collaborator accepts the GitHub invite and clones the repository locally, AI should read the repository documentation before making source-code, design, or business-logic changes. These public RevCent markdown files intentionally do not include the extensive repository-level documentation. They explain the RevCent-facing concepts and MCP/API operations; the Site repository documentation explains the local development and customization workflow. Do not position RevCent Sites as a no-code web-app builder. Position them as an AI-native, RevCent-hosted ecommerce Site model with user-owned development responsibility during beta. --- ## Primary Site Workflow The recommended AI/MCP workflow is: 1. Identify the user's ecommerce goal. 2. Select or create the Product Group that should power the Site catalog. 3. Verify the Product Group contains the right Products. 4. Select the Payment Profile for credit card payments. 5. Select a PayPal Account only if PayPal checkout is needed. 6. Collect at least one GitHub collaborator username. 7. Call `CreateSite`. 8. Call `GetSite` to inspect provisioning, catalog, branch, and routing status. 9. Tell collaborators to accept their GitHub repository invite before trying to access the Site source. 10. After accepting the invite, have collaborators clone the repository locally for AI-assisted customization. 11. Have AI read the repository documentation before making Site code, design, or business-logic changes. 12. Use the dev branch for testing and review. 13. Use the main branch for the live customer-facing experience. 14. Attach a Tracking Domain only after the user confirms the correct domain. 15. Use `GetSiteEvents` and `GetSiteLogs` for focused troubleshooting. --- ## Operation Map | Operation | Use When | |---|---| | `CreateSite` | Create a new RevCent Site from a name, Payment Profile, Product Group, and collaborators. | | `GetSites` | List Sites in the account with bounded pagination. | | `GetSite` | Retrieve one Site and inspect catalog, deployment, branch, routing, and collaborator details. | | `EditSite` | Edit supported Site configuration. Does not edit Site code or business logic. | | `DeleteSite` | Permanently delete a Site. Irreversible and makes DNS still pointed at the Site non-reachable for that deleted Site. | | `AddTrackingDomainToSite` | Attach a ready Tracking Domain to route a custom domain to the live Site. | | `RemoveTrackingDomainFromSite` | Remove the custom domain routing association from a Site. | | `GetSiteEvents` | Review Site activity over a bounded date range. | | `GetSiteLogs` | Retrieve runtime logs for one Site and one branch over a bounded date range. | --- ## EditSite vs Repository Changes `EditSite` edits supported RevCent Site configuration only. Supported configuration includes: - Site name, - Site description, - Payment Profile, - Product Group, - optional PayPal Account, - collaborator list. `EditSite` does not edit the actual Site code, storefront design, page templates, cart behavior, checkout business logic, offer flow, product presentation, theme code, or custom ecommerce logic. Actual code and business-logic changes happen through the Site repository. Collaborators must accept the GitHub invite, clone the repository locally, and use AI-assisted development workflows to customize the ecommerce store. The Site repository includes detailed development documentation. AI should read that repository documentation after local clone and before making code, design, page behavior, cart behavior, checkout logic, offer flow, or custom business-logic changes. Recommended AI/MCP distinction: ```text Use EditSite for RevCent configuration. Use the Site repository for code and business logic. ``` When a user asks to change the look, layout, flow, copy, page behavior, theme, cart behavior, or custom commerce logic of a Site, AI/MCP clients should use the repository workflow instead of `EditSite`. --- ## Deleting Sites `DeleteSite` permanently deletes a RevCent Site. This operation is irreversible. It removes Site data, routing, and content associated with the Site. Any external DNS records still pointed at the deleted Site will no longer reach a working RevCent Site until the user changes or removes those DNS records. AI/MCP clients must distinguish deletion from domain removal: ```text DeleteSite = permanently delete the Site RemoveTrackingDomainFromSite = keep the Site, remove custom domain routing ``` Before calling `DeleteSite`, AI/MCP clients should: 1. Call `GetSite` if Site details are not already known. 2. Show the Site name and Site ID. 3. Mention attached Tracking Domain and routing context when available. 4. Explain that the action is irreversible. 5. Explain that DNS still pointed at the Site will become non-reachable for the deleted Site. 6. Confirm whether the user needs to preserve repository code before deletion. 7. Require explicit user confirmation. --- ## Required Objects Before Site Creation Before calling `CreateSite`, AI/MCP clients need these values: | Object | Required | Notes | |---|---:|---| | Site name | Yes | Must be unique from other Site names. | | Payment Profile ID | Yes | Used for Site credit card payments. | | Product Group ID | Yes | Used as the Site catalog source. | | Collaborators | Yes | At least one valid GitHub username is required. | | Site description | No | Helpful for organization and AI context. | | PayPal Account ID | No | Include only when the Site accepts PayPal payments. | Never guess IDs. Use the relevant list/get operation to retrieve the authoritative ID before creating the Site. --- ## Product Groups and Catalogs The Product Group associated with a Site is the catalog source for that Site. AI/MCP clients should: - choose a focused Product Group, - verify Products belong in the intended Site, - use Product metadata where supported to help with storefront slugs, categories, and presentation, - for each Product in the Site catalog, prefer `metadata` entries with `name` = `slug` and `name` = `site_categories` when the Site should use stable product URLs or category/collection organization, - explain that catalog status in `GetSite` indicates whether the Site catalog is ready, publishing, deferred, or failed. Do not tell the user that a product is available on the Site unless the Product Group and Site catalog status support that conclusion. Recommended Product metadata for Site catalogs: ```json [ { "name": "slug", "value": "organic-coffee-beans" }, { "name": "site_categories", "value": "[\"coffee/beans\",\"subscriptions\"]" } ] ``` Use `slug` for a clear, URL-friendly product slug. Use `site_categories` as a JSON array string of slash-delimited category paths. A Product can be assigned to more than one category path, and nested categories are represented with slashes, such as `apparel/mens/shirts`. Paths with more than three levels are ignored. --- ## Dev and Main Branches RevCent Sites expose separate status for `dev` and `main`. Recommended interpretation: | Branch | Meaning | |---|---| | `dev` | Development and review experience. Use this for testing changes before live use. | | `main` | Live customer-facing experience. Custom domains route to this branch when configured. | AI/MCP clients should clearly distinguish dev from live. A successful dev deployment does not automatically mean the main/live deployment is changed. --- ## Site Status Fields `GetSite` returns several status groups. Important high-level Site deployment statuses: | Status | Meaning | |---|---| | `ready` | The Site is idle and Site modification operations may be accepted. | | `provisioning` | The Site is being created. | | `updating` | A Site change, deployment, catalog update, or routing update is active. | | `deleting` | Site removal is active. | | `recovery_required` | The Site needs RevCent-side recovery attention before normal changes can continue. | Important health values: | Health | Meaning | |---|---| | `healthy` | Current dev and live deployments are healthy. | | `degraded` | A previous deployment remains available, but a later change failed. | | `unavailable` | One or more environments have not successfully deployed. | | `unknown` | Health has not been determined yet. | Branch status, routing status, and catalog status should be read from the returned `deployment.branches` and `catalog` objects. Treat returned status values as authoritative. --- ## Custom Domain Routing Use `AddTrackingDomainToSite` only when: - the user has identified the correct Site, - the user has identified the correct Tracking Domain, - the Tracking Domain is ready to be used, - the user understands this affects live custom domain routing. After adding a Tracking Domain, call `GetSite` and inspect: - `tracking_domain`, - `deployment.branches.main.routing.status`, - `deployment.branches.main.routing.a_record_ip`. Do not claim the custom domain is live until the returned status and DNS state support that conclusion. Use `RemoveTrackingDomainFromSite` only after user confirmation, because it prevents the custom domain from reaching the live Site. --- ## Site Events Use `GetSiteEvents` to inspect Site activity. Good uses: - check whether a Site creation event succeeded, - review recent deployment or catalog activity, - identify which branch or commit an event was related to, - inspect product count changes tied to catalog events, - build a concise timeline for a user. Rules: - `date_start`, `date_end`, `limit`, and `page` are required. - The date range cannot exceed 90 days. - Use `site_filter` when the user is asking about one or more known Sites. - Keep pagination bounded. There is no single-event retrieval operation for Site Events. Use the paginated `GetSiteEvents` results as the authoritative Site Event output. --- ## Site Logs Use `GetSiteLogs` for focused troubleshooting of one Site branch. There is no single-log retrieval operation for Site Logs. Use the paginated `GetSiteLogs` results as the authoritative Site Log output. Rules: - `date_start`, `date_end`, `limit`, `page`, `site_filter`, and `site_branch_filter` are required. - The date range cannot exceed 30 days. - `site_filter` must contain exactly one Site ID. - `site_branch_filter` must contain exactly one branch, either `main` or `dev`. Logs may include detailed operational messages. Summarize only what is relevant and avoid exposing sensitive details unnecessarily. --- ## Safety Guidance for AI/MCP Clients AI/MCP clients should: 1. Use exact IDs from prior RevCent MCP results. 2. Confirm consequential actions before creating a Site, attaching a Tracking Domain, or removing a Tracking Domain. 3. Keep date ranges and pagination narrow. 4. Treat Site status values as authoritative. 5. Explain that AI is the intended developer/customization method and RevCent hosts the Site. 6. Do not direct users to a RevCent web-app site builder for Site customization. 7. Keep explanations focused on user-visible Site status, routing, catalog, payments, events, and logs. 8. Do not use Site Events or Site Logs as reporting or analytics data sources. --- ## Final MCP Instruction Use RevCent Site operations when the user wants to create, inspect, route, monitor, or troubleshoot a RevCent-hosted ecommerce Site. Keep all explanations public-facing, status-driven, and grounded in returned MCP results. --- Document Parent Directory * [Operations](https://revcent.com/documentation/markdown/mcp/operation/index.md) - AI/MCP details and overviews for operations available within the RevCent MCP.