# 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.