Skip to content

SQL confirmations do not appear in your MCP client

Last edited: 10/2/2026

The Supabase MCP server can ask for confirmation before running detected destructive SQL through execute_sql or apply_migration. If you expect a confirmation dialog and don't see one, work through these checks.

Form-based SQL confirmation is unavailable or unsupported#

SQL confirmation dialogs require your client to support form elicitations for the request. Check your connection against Client support.

If form-based SQL confirmation is unavailable or unsupported, the tools follow their existing SQL execution behavior without an additional MCP confirmation prompt. Permissions and read-only restrictions still apply. There is no legacy cost-style confirmation workflow for SQL.

The SQL does not trigger detection#

The tools only request confirmation for SQL detected as destructive. Detection does not catch every destructive statement. A missing prompt does not prove that SQL is safe.

Review the SQL itself rather than relying on a confirmation dialog. Do not run destructive SQL to test whether a prompt appears.

Your connection is read-only#

execute_sql only requests destructive SQL confirmation outside read-only mode. Keep read-only mode enabled when you do not need write access; do not disable it to get a confirmation prompt.

SQL confirmations are skipped for the tool#

Check your MCP server URL for skip_elicitations. If it includes execute_sql or apply_migration, that tool follows its existing SQL execution behavior without the additional MCP confirmation prompt. Permissions and read-only restrictions still apply.

To receive supported confirmations, remove the affected tool from skip_elicitations. See Skip form confirmations.

Your client answers elicitations automatically#

Some clients support hooks or rules that respond to elicitations without showing a dialog. If your client supports form elicitations but no dialog appears, check its elicitation or hook configuration.