Skip to main content
Glama
alexander-zuev

Supabase MCP Server

confirm_destructive_operation

Execute high-risk database or API operations safely by confirming with a unique ID. Designed for Supabase PostgreSQL, this tool ensures user approval before proceeding with destructive actions.

Instructions

Execute a destructive database or API operation after confirmation. Use this only after reviewing the risks with the user.

HOW IT WORKS:

  • This tool executes a previously rejected high-risk operation using its confirmation ID

  • The operation will be exactly the same as the one that generated the ID

  • No need to retype the query or api request params - the system remembers it

STEPS:

  1. Explain the risks to the user and get their approval

  2. Use this tool with the confirmation ID from the error message

  3. The original query will be executed as-is

PARAMETERS:

  • operation_type: Type of operation ("api" or "database")

  • confirmation_id: The ID provided in the error message (required)

  • user_confirmation: Set to true to confirm execution (default: false)

NOTE: Confirmation IDs expire after 5 minutes for security

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmation_idYes
operation_typeYes
user_confirmationNo

Implementation Reference

  • Core handler implementing the confirm_destructive_operation tool logic: checks user confirmation and delegates to API or database manager's handle_confirmation method.
    async def confirm_destructive_operation(
        self,
        container: "ServicesContainer",
        operation_type: Literal["api", "database"],
        confirmation_id: str,
        user_confirmation: bool = False,
    ) -> QueryResult | dict[str, Any]:
        """Execute a destructive operation after confirmation. Use this only after reviewing the risks with the user."""
        api_manager = container.api_manager
        query_manager = container.query_manager
        if not user_confirmation:
            raise ConfirmationRequiredError("Destructive operation requires explicit user confirmation.")
    
        if operation_type == "api":
            return await api_manager.handle_confirmation(confirmation_id)
        elif operation_type == "database":
            return await query_manager.handle_confirmation(confirmation_id)
  • MCP server tool registration with @mcp.tool decorator and wrapper function that invokes the feature manager.
    @mcp.tool(description=tool_manager.get_description(ToolName.CONFIRM_DESTRUCTIVE_OPERATION))  # type: ignore
    async def confirm_destructive_operation(
        operation_type: Literal["api", "database"], confirmation_id: str, user_confirmation: bool = False
    ) -> QueryResult | dict[str, Any]:
        """Execute a destructive operation after confirmation. Use this only after reviewing the risks with the user."""
        return await feature_manager.execute_tool(
            ToolName.CONFIRM_DESTRUCTIVE_OPERATION,
            services_container=services_container,
            operation_type=operation_type,
            confirmation_id=confirmation_id,
            user_confirmation=user_confirmation,
        )
  • ToolName enum value defining the tool name.
    CONFIRM_DESTRUCTIVE_OPERATION = "confirm_destructive_operation"
  • Dispatch in execute_tool method routing to the confirm_destructive_operation handler.
    elif tool_name == ToolName.CONFIRM_DESTRUCTIVE_OPERATION:
        return await self.confirm_destructive_operation(services_container, **kwargs)
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it's for executing high-risk operations, requires user confirmation, uses a confirmation ID from a previous error, executes the original query as-is, and includes a security note about 5-minute expiration. However, it doesn't detail potential side effects (e.g., data loss specifics) or error handling, leaving some gaps in full transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (HOW IT WORKS, STEPS, PARAMETERS, NOTE), making it easy to scan. Each sentence adds value, such as explaining the confirmation process and security constraints. It could be slightly more concise by integrating some details (e.g., merging the STEPS and PARAMETERS sections), but overall, it's efficient and front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (destructive operations, confirmation flow) and lack of annotations or output schema, the description does a good job of covering essential context: purpose, usage steps, parameters, and security notes. It addresses the high-risk nature and user interaction requirements. However, it doesn't specify what happens after execution (e.g., success/failure responses or side effects), which is a minor gap for such a critical tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds meaningful context for all three parameters: 'operation_type' is explained as 'Type of operation ("api" or "database")', 'confirmation_id' as 'The ID provided in the error message (required)', and 'user_confirmation' as 'Set to true to confirm execution (default: false)'. This goes beyond the schema's basic titles and enums, clarifying usage and requirements. A point is deducted because it doesn't elaborate on the implications of each operation_type choice.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Execute a destructive database or API operation after confirmation.' It specifies the verb ('execute'), resource ('destructive database or API operation'), and the key condition ('after confirmation'). The title 'confirm_destructive_operation' reinforces this, and it distinguishes itself from siblings like 'live_dangerously' or 'execute_postgresql' by focusing on confirmation of previously rejected high-risk operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: 'Use this only after reviewing the risks with the user.' It outlines a clear process (explain risks, get approval, use confirmation ID) and specifies prerequisites (confirmation ID from an error message). It also distinguishes usage from alternatives by noting that no retyping of queries is needed, which sets it apart from tools like 'execute_postgresql' or 'send_management_api_request' that might require full parameter input.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/alexander-zuev/supabase-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server