Skip to main content
Glama
alexander-zuev

Supabase MCP Server

send_management_api_request

Send requests to the Supabase Management API to programmatically manage project resources, configurations, and settings using specified HTTP methods, paths, and parameters.

Instructions

Execute a Supabase Management API request.

This tool allows you to make direct calls to the Supabase Management API, which provides programmatic access to manage your Supabase project settings, resources, and configurations.

REQUEST FORMATTING:

  • Use paths exactly as defined in the API specification

  • The {ref} parameter will be automatically injected from settings

  • Format request bodies according to the API specification

PARAMETERS:

  • method: HTTP method (GET, POST, PUT, PATCH, DELETE)

  • path: API path (e.g. /v1/projects/{ref}/functions)

  • path_params: Path parameters as dict (e.g. {"function_slug": "my-function"}) - use empty dict {} if not needed

  • request_params: Query parameters as dict (e.g. {"key": "value"}) - use empty dict {} if not needed

  • request_body: Request body as dict (e.g. {"name": "test"}) - use empty dict {} if not needed

PATH PARAMETERS HANDLING:

  • The {ref} placeholder (project reference) is automatically injected - you don't need to provide it

  • All other path placeholders must be provided in the path_params dictionary

  • Common placeholders include:

    • {function_slug}: For Edge Functions operations

    • {id}: For operations on specific resources (API keys, auth providers, etc.)

    • {slug}: For organization operations

    • {branch_id}: For database branch operations

    • {provider_id}: For SSO provider operations

    • {tpa_id}: For third-party auth operations

EXAMPLES:

  1. GET request with path and query parameters: method: "GET" path: "/v1/projects/{ref}/functions/{function_slug}" path_params: {"function_slug": "my-function"} request_params: {"version": "1"} request_body: {}

  2. POST request with body: method: "POST" path: "/v1/projects/{ref}/functions" path_params: {} request_params: {} request_body: {"name": "test-function", "slug": "test-function"}

SAFETY SYSTEM: API operations are categorized by risk level:

  • LOW RISK: Read operations (GET) - allowed in SAFE mode

  • MEDIUM/HIGH RISK: Write operations (POST, PUT, PATCH, DELETE) - require UNSAFE mode

  • EXTREME RISK: Destructive operations - require UNSAFE mode and confirmation

  • BLOCKED: Some operations are completely blocked for safety reasons

SAFETY CONSIDERATIONS:

  • By default, the API client starts in SAFE mode, allowing only read operations

  • To perform write operations, first use live_dangerously(service="api", enable=True)

  • High-risk operations will be rejected with a confirmation ID

  • Use confirm_destructive_operation with the provided ID after reviewing risks

  • Some operations may be completely blocked for safety reasons

For a complete list of available API endpoints and their parameters, use the get_management_api_spec tool. For details on safety rules, use the get_management_api_safety_rules tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
methodYes
pathYes
path_paramsYes
request_bodyYes
request_paramsYes

Implementation Reference

  • Primary MCP tool handler and registration for 'send_management_api_request'. This decorated function is exposed to the MCP client and handles input parameters before delegating to the feature manager.
    @mcp.tool(description=tool_manager.get_description(ToolName.SEND_MANAGEMENT_API_REQUEST))  # type: ignore
    async def send_management_api_request(
        method: str,
        path: str,
        path_params: dict[str, str],
        request_params: dict[str, Any],
        request_body: dict[str, Any],
    ) -> dict[str, Any]:
        """Execute a Supabase Management API request."""
        return await feature_manager.execute_tool(
            ToolName.SEND_MANAGEMENT_API_REQUEST,
            services_container=services_container,
            method=method,
            path=path,
            path_params=path_params,
            request_params=request_params,
            request_body=request_body,
        )
  • Core implementation of the send_management_api_request logic. This method retrieves the API manager from the services container and executes the actual Management API request.
    async def send_management_api_request(
        self,
        container: "ServicesContainer",
        method: str,
        path: str,
        path_params: dict[str, str],
        request_params: dict[str, Any],
        request_body: dict[str, Any],
    ) -> dict[str, Any]:
        """Execute a Supabase Management API request."""
        api_manager = container.api_manager
        return await api_manager.execute_request(method, path, path_params, request_params, request_body)
  • Definition of the ToolName enum value for 'send_management_api_request', used throughout the codebase for tool identification and dispatching.
    SEND_MANAGEMENT_API_REQUEST = "send_management_api_request"
  • Dispatch logic in FeatureManager.execute_tool that routes calls to the send_management_api_request method based on the tool name.
    elif tool_name == ToolName.SEND_MANAGEMENT_API_REQUEST:
        return await self.send_management_api_request(services_container, **kwargs)
Behavior5/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 and does so comprehensively. It details the safety system with risk categories (LOW, MEDIUM/HIGH, EXTREME, BLOCKED), explains the default SAFE mode, specifies that write operations require UNSAFE mode, describes confirmation requirements for destructive operations, and mentions automatic injection of the {ref} parameter.

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 (REQUEST FORMATTING, PARAMETERS, PATH PARAMETERS HANDLING, EXAMPLES, SAFETY SYSTEM, SAFETY CONSIDERATIONS) but is quite lengthy. While every section adds value, it could be more concise by integrating some safety information more tightly with usage guidance.

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

Completeness5/5

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

Given the complexity of a 5-parameter API request tool with no annotations and no output schema, the description provides complete context. It covers purpose, usage, parameters, safety considerations, examples, and references to related tools, leaving no significant gaps for an agent to understand and use this tool correctly.

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

Parameters5/5

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

With 0% schema description coverage for 5 parameters, the description fully compensates by providing detailed parameter explanations. It defines each parameter's purpose, provides examples of valid values, explains how path parameters work with placeholders, and gives concrete usage examples showing all parameters in action.

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 as 'Execute a Supabase Management API request' and specifies it provides 'programmatic access to manage your Supabase project settings, resources, and configurations.' This is a specific verb+resource combination that distinguishes it from sibling tools like execute_postgresql or get_management_api_spec.

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 versus alternatives, directing users to 'use the get_management_api_spec tool' for endpoint details and 'use the get_management_api_safety_rules tool' for safety specifics. It also clearly explains when write operations require enabling UNSAFE mode via live_dangerously.

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