answer.cloud CMS

Managing Multiple Production Sites with answer.cloud MCP

How organization-scoped MCP keys manage multiple answer.cloud production sites, including multi-organization setup, safe deployment targeting, access isolation, and key rotation.

Published July 22, 2026

A hosting API key authorizes one answer.cloud organization. It is not bound to the site you were viewing when you created it. One key can manage every production site owned by that organization.

For general setup, see MCP: Overview, Connection & Authentication. For detailed tool arguments and responses, see MCP: Site & Deploy Tools.

How sites, organizations, and keys relate

Organization
├── Hosting API and MCP keys
├── Production site: acme
├── Production site: acme-docs
└── Production site: acme-support

Every site has a unique site slug. MCP tools use that slug to identify the production site you want to inspect, deploy, or roll back.

Manage several production sites in one organization

You only need one answer.cloud MCP connection when all of your production sites belong to the same organization.

  1. In answer.cloud, switch to the organization that owns the sites.
  2. Open Settings → API & MCP.
  3. Create a hosting key, or use an existing active hosting key.
  4. Connect your coding agent to https://answer.cloud/mcp with that key.
  5. Ask the agent to run list_sites before making changes.
  6. Use the exact site_slug returned by list_sites for every site-specific operation.

For example, you can ask your agent:

List the production sites available through answer.cloud and show their live URLs.

Before a deployment, include the intended site slug explicitly:

Deploy this project to the production site with slug acme-docs. Confirm the
organization, site slug, and live URL before starting the deployment.

Creating another key in the same organization does not restrict that key to a single site. Every active hosting key for the organization can manage all of its sites.

Manage production sites in different organizations

Create one hosting key for each organization:

  1. Switch to the organization in answer.cloud.
  2. Open Settings → API & MCP.
  3. Create and copy the hosting key. The full key is shown only once.
  4. Give each MCP connection a distinct name so its organization is clear.

The MCP connection selects the organization. The site slug selects the production site inside that organization.

Configure multiple organizations in Codex

Store each key in a separate environment variable:

export ANSWERCLOUD_ACME_API_KEY="aeo_host_..."
export ANSWERCLOUD_CONTOSO_API_KEY="aeo_host_..."

Add a separate server entry for each organization to ~/.codex/config.toml:

[mcp_servers.answercloud_acme]
url = "https://answer.cloud/mcp"
bearer_token_env_var = "ANSWERCLOUD_ACME_API_KEY"

[mcp_servers.answercloud_contoso]
url = "https://answer.cloud/mcp"
bearer_token_env_var = "ANSWERCLOUD_CONTOSO_API_KEY"

Start a new Codex session after changing the configuration.

Configure multiple organizations in Claude Code

Add one named MCP connection for each organization:

claude mcp add --transport http answercloud-acme https://answer.cloud/mcp \
  --header "Authorization: Bearer aeo_host_ACME_KEY"

claude mcp add --transport http answercloud-contoso https://answer.cloud/mcp \
  --header "Authorization: Bearer aeo_host_CONTOSO_KEY"

Use connection names that make the organization unambiguous.

Use a safe production deployment workflow

Before every deployment:

  1. Confirm the MCP connection is authenticated to the intended organization.
  2. Run list_sites and select the exact production site_slug.
  3. Confirm the site's current live URL.
  4. Build and review the deployment artifact.
  5. Start the deployment for the confirmed site slug.
  6. Wait until get_deploy reports live.
  7. Review deployment warnings and verify the public site.

Do not select a production target based only on a similar display name. The site slug is the deployment target.

For additional protection, keep the organization and production site slug in the project's agent context:

# answer.cloud site

- Site kind: hosting
- Slug: acme-docs
- Served at: https://docs.acme.com
- Organization: Acme
- Deploy: through the answer.cloud MCP server only, and only when explicitly requested.

Separate production access when needed

Hosting keys are organization-wide. Creating multiple keys inside one organization lets you rotate or revoke credentials independently, but it does not create site-level permissions.

Use separate organizations when production sites require a hard access boundary, such as sites owned by different customers, business units, or security teams. Each organization should have its own MCP connection and hosting keys.

Rotate or revoke a production key

To rotate a key without interrupting access:

  1. Create a replacement key under Settings → API & MCP for the same organization.
  2. Update the MCP connection or environment variable.
  3. Start a new agent session.
  4. Run list_sites and confirm that the expected production sites are present.
  5. Revoke the old key from Settings → API & MCP.

Never commit hosting keys to a repository or include them in screenshots, support messages, deployment artifacts, or browser-side code.

Frequently asked questions

Do I need one key for every production site?

No. One hosting key can manage every site in its organization.

Why can a newly created key see existing production sites?

The key authenticates the organization. Existing sites owned by that organization are therefore available through the same MCP connection.

Can I restrict a key to one production site?

No. Hosting keys are organization-wide. Use a separate organization when a site requires isolated access.

Does creating a new key disable existing keys?

No. Existing keys remain active until they are explicitly revoked.

How do I make sure an agent deploys to the correct site?

Run list_sites, use the exact site_slug, and require the agent to confirm the organization, site slug, and live URL before starting the deployment.