Manage multiple organizations and sites

An organization is the workspace that owns sites, content, and access. A site is an individual publishing and reporting target within that organization. Select both explicitly when you manage several customers, brands, or production websites.

Establish the target#

1. Ask your agent to call list_organizations when the organization has not been established.
2. If more than one is returned, select the intended organization.
3. Supply its organization_id on subsequent calls when required by the connection.
4. Call list_sites and inspect the site's slug, kind, live URL, and release workflow.
5. Use the returned site_slug for site-specific operations.

A display name can be similar across workspaces. A familiar dashboard tab also does not establish the agent's selected organization. Use identifiers returned by the connection instead of inferring them from names.

A clear request is:

In the Example organization, inspect the site with slug example-docs. Show its current production URL and latest deployment before making the requested documentation update.

Keep site kinds distinct#

For a companion, inspect existing collections and use its actual configured hostname. Do not deploy a copy of the main website or create a standalone replacement because the companion cannot be found. Follow existing-website setup for that workflow.

Understand access boundaries#

A personal OAuth connection follows the organizations you approved and your active memberships. Personal tokens act as the issuing user in one organization. An organization service key is a different credential path; creating a second service key does not create a site-only boundary.

Use separate organizations when the intended customer or team isolation requires it. Avoid assuming a connection is restricted to one site merely because that was the last site used. Review credentials before sharing automation access.

Verify changes in the selected environment#

For a code release, inspect the source, build it, and choose the intended destination. Explicit MCP deployments accept staging, production, or both; staging needs the release workflow, and production in that workflow needs an active custom domain. Companions use production only.

Read the deployment's warnings and live_urls, then verify the actual content, links, search, and a meaningful chat answer at the intended hostname. Record the organization, site slug, deploy ID, sequence, and environment together so another operator can identify the same release.

See deployment tools and release configuration.