MCP permissions & safety

MCP uses the same Read-only and Read/write API-key permissions as REST. Each tool operation is checked before it runs.

Read and write boundaries

Read-only keys can inspect sites, buckets, files, functions, databases, migration status, and secret metadata. They cannot create, update, apply, or delete resources.

Use write approvals for mutating tools. Inspect current state before a change and verify the affected resource afterward.

Live file writes

write_file replaces the complete file and can affect an attached Site immediately.

• /web/* changes hosted content.
• /api/*.ts starts function deployment.
• /cron/*.ts starts scheduled-handler deployment.

There is no Site-level draft or deploy tool. Inspect the returned deployment status and verify the hosted URL or runtime before claiming success.

Deleting function or cron source also removes or pauses its deployed runtime.

Secrets

list_secrets returns names and metadata, never values. There is no get_secret tool. Do not place secrets in tool arguments other than the value field of an explicitly approved set_secret call.

Database migrations

Cloud-first agents can use list_database_migrations, get_database_migration, and apply_database_migration. List and get expose successful migration resources; get includes exact SQL when it was recorded. Apply accepts one filename and SQL body with confirm: true; it does not require previous local files or a preflight token. The MCP confirmation binds the exact SQL.

A Read-only key can inspect migrations but cannot apply them.

Recovery

When an underlying REST call fails, MCP reports a protocol-level tool error and preserves the REST generic code, message, and structured recovery metadata from error.details. Preserve fields such as retryable, nextAction, migrationName, and lease expiry. Re-read state after an ambiguous failure instead of assuming a write did or did not happen.