Supabase Retires Its Logs API, Breaking AI Agents on MCP

Supabase is shutting down the logs.all Management API endpoint on September 23, 2026, forcing anyone who queries logs programmatically to switch to a new endpoint that speaks only ClickHouse SQL, according to a changelog post the Supabase team published July 23. The cutover also breaks AI agents pulling logs through the Supabase MCP server unless that server is updated first.

What’s changing

The old endpoint, analytics/endpoints/logs.all, returned each log source, Postgres, API gateway, auth, storage, from its own separate table. The replacement, analytics/endpoints/logs, unifies every source into a single logs table and accepts only ClickHouse SQL, not the Postgres-flavored queries the old endpoint took. A query that used to select from a source-specific table now has to filter on a source column instead: SELECT * FROM logs WHERE source = 'edge_logs' in place of SELECT * FROM edge_logs.

Supabase says only direct callers of the Management API endpoint are affected, dashboard users working in the Logs Explorer see no change. But that direct-caller group turns out to include more than custom scripts. The Supabase MCP server’s get_logs tool, the one an AI agent calls when a developer asks it to check logs mid-session, was itself built on logs.all. Versions of mcp-server-supabase before 0.10.0 will start failing that call the moment the old endpoint disappears. The fix is an update, not a rewrite: 0.10.0 and later already point at the new endpoint.

The community catch

A commenter on the GitHub discussion thread flagged that Supabase’s own migration guide has a bug: it tells developers to filter the new endpoint by a source_name column, but the live endpoint only recognizes source. Anyone who migrates by copying the documented example verbatim gets queries that silently return nothing, not an error, just an empty result set. Supabase has not yet corrected the guide as of publication; developers migrating now should use source, confirmed against the working example in the changelog post itself, not the prose describing it.

The take

A backend-storage migration forcing a client-facing SQL dialect change is already a heavier lift than most changelog entries admit, ClickHouse SQL is not a drop-in swap for whatever Postgres-style queries teams wrote against the old endpoint two years ago. The MCP angle raises the stakes: it puts an AI agent between the developer and the API call, so a breaking change here doesn’t just fail loudly in a script someone reads. It can fail inside an agent session, where the failure mode is a tool call quietly returning nothing useful. Teams running MCP-connected agents against Supabase should confirm their server version now, not on September 23. Two months of runway from a GitHub discussion post is standard notice; verifying the pinned mcp-server-supabase version in whatever agent config runs today takes five minutes and beats finding out mid-incident.