MCP (Model Context Protocol)

Quave ONE MCP lets an AI client work with your Quave ONE account through a remote, authenticated MCP server. Ask your client to inspect logs, review a deployment, manage an environment, or run an approved Job without giving it unrestricted access to your infrastructure.

AI client → Quave ONE MCP server → Quave ONE API → your account resources

The MCP server validates identity, capabilities, account permissions, and tool-specific rules before an operation reaches the Quave ONE API. Results return to the AI client as MCP responses.

Discover app types before creation

Use list-app-presets before create-app. It includes Functions (isFunction) and Jobs (isJob) as well as ordinary framework and Custom presets. requiresDockerfile applies to source builds; pre-built images do not need one. Use list-database-presets for managed Databases & Services.

For Functions, the MCP idle-period input floor is 300 seconds, but the account minimum defaults to 900 and raises lower values. Do not interpret a successful configuration save as proof of timeout enforcement or safe migration of a protected custom-domain app: read the current Function limitations.

Update an existing Warren factory

Use create-solution with the existing installationId and unchanged account, name, environment, region and provider selection. An explicit inputs.warrenImage requests an in-place upgrade of both control and approved sandbox images without replacing the factory's data or credentials. Omit that input to leave a completed installation unchanged. Wait for current runs to finish, then verify get-app-env-status reports a successful deployment before starting a new run.

Choose how to connect

Method	Best for	How it works
OAuth	Clients that support remote MCP OAuth	The client opens Quave ONE consent and receives its own scoped tokens.
MCP key	Existing integrations or clients without OAuth support	You create a separate key and configure it in that client’s Authorization header.

OAuth is the recommended connection method. MCP keys remain supported unless an account administrator enables Require OAuth for automated API and MCP access for that account. That setting affects automated credentials only; it does not affect dashboard sign-in.

Start here

1. Connect your client with OAuth or an MCP key.
2. Choose server-enforced authorization: capabilities, or an explicit MCP tool allowlist for OAuth grants and MCP keys.
3. Apply safety best practices, especially before giving an agent access to production.
4. Review available tools and use least privilege.
5. Keep management, troubleshooting, and FAQ handy.

What Quave ONE enforces

The server enforces the authorization grant or key configuration, Quave ONE account and environment permissions, and tool-specific checks. Client-facing confirmation prompts and approval-session duration are helpful UX safeguards, but depend on the MCP client.

Security Best Practice: Grant only the access shape you need. Use By permissions for capability-scoped access, or By tools when you want an explicit MCP tool allowlist. The server blocks every other operation regardless of how the MCP client is configured. Read Safety best practices before connecting an agent to production.

For API automation that is not MCP, use the Public API instead. OAuth tokens are resource-bound: an MCP token can only open MCP sessions, and a Public API token can only call the Public API.

list-app-env-backups returns logical database backup metadata together with databaseBackupDisabled and backupListingUnavailable. When logical dumps are intentionally disabled and historical storage cannot be listed, it returns an empty backup list with both fields set to true; clients should treat that as an explicit opt-out, not a missing-backup finding.

For Job automation, run-app-env-job creates customer-visible JobRuns and list-app-env-job-runs returns a paged list. Use page and limit for pagination, status for one status or comma-separated statuses, and from / to for createdAt time filters.

The dashboard keeps Job execution settings under Settings → Job Config and recurring timing under Settings → Schedule. For recurring Jobs, update-app-env-job-schedule configures or disables one exactly five-field cron schedule on a Job environment, and get-app-env-job-schedule returns the next time plus recent scheduled, skipped, failed, or missed occurrences. Schedule updates take effect immediately and remain separate from pending Job execution config. Accepted occurrences create normal SCHEDULED JobRuns and Kubernetes Jobs, not a Kubernetes CronJob.

For actual CPU or memory usage by replica, call get-app-env-metrics-series with groupBy: "pod". The response returns seriesByLabel and summaryByLabel keyed by pod name, for both regular apps and managed databases. Omitting groupBy preserves the aggregate environment response.

The same grouping is available for anomaly summaries. Pass groupBy: "pod" to get-app-env-metrics-baseline-summary or get-account-observability-summary; each metric then returns baseline, recent, and deviation statistics under summaryByLabel for every pod.

update-app-env-resources can increase the disk allocation after it has been applied for managed databases and regular apps with a local persistent volume. Disk decreases are rejected because persistent volumes are grow-only. Shared NFS volumes and stateless apps do not use this disk setting. Use list-database-presets for the current managed-database min/max limits. For eligible Quave ONE Direct environments, storage overage uses this configured local disk allocation, including regular apps with a local persistent volume.

For alert replication, use copy-alert with sourceAlertId and one to five exact destination cliEnvName values in targetEnvNames. The server reads the source alert, reuses its condition and contact points, creates a unique rule name per target, and reports each destination separately. Use create-alert when defining a new condition instead.

When checking deployment progress with get-app-env-status, use currentDeployment for the content version currently attached to the environment and latestDeployment for the newest build or deploy activity. For source deploys, latestDeployment.status can be BUILDING before that version becomes current. CLI source deploy content can also expose latestDeployment.uploadEventId so tooling can correlate polling with the exact upload event.