Skip to main content
Glama
alexander-zuev

Supabase MCP Server

retrieve_logs

Access and analyze logs from Supabase services like PostgreSQL, API Gateway, and Edge Functions for debugging and monitoring. Query logs by collection, filters, or custom SQL to identify issues and track performance.

Instructions

Retrieve logs from your Supabase project's services for debugging and monitoring.

Returns log entries from various Supabase services with timestamps, messages, and metadata. This tool provides access to the same logs available in the Supabase dashboard's Logs & Analytics section.

AVAILABLE LOG COLLECTIONS:

  • postgres: Database server logs including queries, errors, warnings, and system messages

  • api_gateway: API requests, responses, and errors processed by the Kong API gateway

  • auth: Authentication and authorization logs for sign-ups, logins, and token operations

  • postgrest: Logs from the RESTful API service that exposes your PostgreSQL database

  • pooler: Connection pooling logs from pgbouncer and supavisor services

  • storage: Object storage service logs for file uploads, downloads, and permissions

  • realtime: Logs from the real-time subscription service for WebSocket connections

  • edge_functions: Serverless function execution logs including invocations and errors

  • cron: Scheduled job logs (can be queried through postgres logs with specific filters)

  • pgbouncer: Connection pooler logs

PARAMETERS:

  • collection: The log collection to query (required, one of the values listed above)

  • limit: Maximum number of log entries to return (default: 20)

  • hours_ago: Retrieve logs from the last N hours (default: 1)

  • filters: List of filter objects with field, operator, and value (default: []) Format: [{"field": "field_name", "operator": "=", "value": "value"}]

  • search: Text to search for in event messages (default: "")

  • custom_query: Complete custom SQL query to execute instead of the pre-built queries (default: "")

HOW IT WORKS: This tool makes a request to the Supabase Management API endpoint for logs, sending either a pre-built optimized query for the selected collection or your custom query. Each log collection has a specific table structure and metadata format that requires appropriate CROSS JOIN UNNEST operations to access nested fields.

EXAMPLES:

  1. Using pre-built parameters: collection: "postgres" limit: 20 hours_ago: 24 filters: [{"field": "parsed.error_severity", "operator": "=", "value": "ERROR"}] search: "connection"

  2. Using a custom query: collection: "edge_functions" custom_query: "SELECT id, timestamp, event_message, m.function_id, m.execution_time_ms FROM function_edge_logs CROSS JOIN unnest(metadata) AS m WHERE m.execution_time_ms > 1000 ORDER BY timestamp DESC LIMIT 10"

METADATA STRUCTURE: The metadata structure is important because it determines how to access nested fields in filters:

  • postgres_logs: Use "parsed.field_name" for fields like error_severity, query, application_name

  • edge_logs: Use "request.field_name" or "response.field_name" for HTTP details

  • function_edge_logs: Use "function_id", "execution_time_ms" for function metrics

NOTE FOR LLM CLIENTS: When encountering errors with field access, examine the error message to see what fields are actually available in the structure. Start with basic fields before accessing nested metadata.

SAFETY CONSIDERATIONS:

  • This is a low-risk read operation that can be executed in SAFE mode

  • Requires a valid Supabase Personal Access Token to be configured

  • Not available for local Supabase instances (requires cloud deployment)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
collectionYes
custom_queryNo
filtersNo
hours_agoNo
limitNo
searchNo

Implementation Reference

  • Primary MCP handler function for the 'retrieve_logs' tool, registered with @mcp.tool decorator. Defines input schema via type annotations and delegates execution to FeatureManager.
    @mcp.tool(description=tool_manager.get_description(ToolName.RETRIEVE_LOGS))  # type: ignore
    async def retrieve_logs(
        collection: str,
        limit: int = 20,
        hours_ago: int = 1,
        filters: list[dict[str, Any]] = [],
        search: str = "",
        custom_query: str = "",
    ) -> dict[str, Any]:
        """Retrieve logs from your Supabase project's services for debugging and monitoring."""
        return await feature_manager.execute_tool(
            ToolName.RETRIEVE_LOGS,
            services_container=services_container,
            collection=collection,
            limit=limit,
            hours_ago=hours_ago,
            filters=filters,
            search=search,
            custom_query=custom_query,
        )
  • FeatureManager's retrieve_logs method, which logs the call and delegates to ApiManager for actual log retrieval.
    async def retrieve_logs(
        self,
        container: "ServicesContainer",
        collection: str,
        limit: int = 20,
        hours_ago: int = 1,
        filters: list[dict[str, Any]] = [],
        search: str = "",
        custom_query: str = "",
    ) -> dict[str, Any]:
        """Retrieve logs from your Supabase project's services for debugging and monitoring."""
        logger.info(
            f"Tool called: retrieve_logs(collection={collection}, limit={limit}, hours_ago={hours_ago}, filters={filters}, search={search}, custom_query={'<custom>' if custom_query else None})"
        )
    
        api_manager = container.api_manager
        result = await api_manager.retrieve_logs(
            collection=collection,
            limit=limit,
            hours_ago=hours_ago,
            filters=filters,
            search=search,
            custom_query=custom_query,
        )
    
        logger.info(f"Tool completed: retrieve_logs - Retrieved log entries for collection={collection}")
    
        return result
  • Core implementation of retrieve_logs in ApiManager: constructs SQL query using LogManager and executes it against Supabase Logs API endpoint.
    async def retrieve_logs(
        self,
        collection: str,
        limit: int = 20,
        hours_ago: int | None = 1,
        filters: list[dict[str, Any]] | None = None,
        search: str | None = None,
        custom_query: str | None = None,
    ) -> dict[str, Any]:
        """Retrieve logs from a Supabase service.
    
        Args:
            collection: The log collection to query
            limit: Maximum number of log entries to return
            hours_ago: Retrieve logs from the last N hours
            filters: List of filter objects with field, operator, and value
            search: Text to search for in event messages
            custom_query: Complete custom SQL query to execute
    
        Returns:
            The query result
    
        Raises:
            ValueError: If the collection is unknown
        """
        log_manager = self.log_manager
    
        # Build the SQL query using LogManager
        sql = log_manager.build_logs_query(
            collection=collection,
            limit=limit,
            hours_ago=hours_ago,
            filters=filters,
            search=search,
            custom_query=custom_query,
        )
    
        logger.debug(f"Executing log query: {sql}")
    
        # Make the API request
        try:
            response = await self.execute_request(
                method="GET",
                path="/v1/projects/{ref}/analytics/endpoints/logs.all",
                path_params={},
                request_params={"sql": sql},
                request_body={},
            )
    
            return response
        except Exception as e:
            logger.error(f"Error retrieving logs: {e}")
            raise
  • Definition of ToolName.RETRIEVE_LOGS enum value used for tool identification and dispatch.
    RETRIEVE_LOGS = "retrieve_logs"
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 explains the tool's operation ('makes a request to the Supabase Management API endpoint'), includes safety considerations (low-risk read operation, requires Personal Access Token, not available for local instances), and provides metadata structure details crucial for effective use. The 'HOW IT WORKS' and 'SAFETY CONSIDERATIONS' sections add significant value beyond basic functionality.

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 (PARAMETERS, HOW IT WORKS, EXAMPLES, METADATA STRUCTURE, SAFETY CONSIDERATIONS) that make information easy to find. While comprehensive, some sections like the detailed log collection list (10 items) could be more concise, though each serves a purpose in helping users select the right collection. The front-loaded purpose statement is clear and effective.

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?

For a tool with 6 parameters, 0% schema coverage, no annotations, and no output schema, the description provides complete contextual information. It covers purpose, parameters with semantics, usage examples, operational mechanics, metadata structure, safety considerations, and even troubleshooting guidance ('NOTE FOR LLM CLIENTS'). This fully compensates for the lack of structured documentation elsewhere.

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?

Given 0% schema description coverage for 6 parameters, the description compensates exceptionally well. It provides detailed explanations for each parameter including required status, default values, format specifications (especially for the complex 'filters' array), and practical examples showing how to use them. The 'AVAILABLE LOG COLLECTIONS' section effectively documents the valid values for the 'collection' parameter despite no enum in the schema.

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 'Retrieve logs from your Supabase project's services for debugging and monitoring' with specific verb ('retrieve') and resource ('logs'), and distinguishes it from siblings like 'execute_postgresql' or 'retrieve_migrations' by focusing on log retrieval across multiple services rather than database queries or migration history.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool (debugging and monitoring Supabase services) and mentions it provides 'access to the same logs available in the Supabase dashboard's Logs & Analytics section,' giving users a familiar reference point. However, it doesn't explicitly state when not to use it or name specific alternatives among the sibling tools.

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