AI Agent News/stories/supabase-adds-mcp-server-block-so-apps-can-run-their-own-mcp-server.md

MCP

Supabase adds MCP Server block so apps can run their own MCP server

Supabase has released an MCP Server block that lets developers give a Supabase app its own Model Context Protocol server. Customers can use the app from ChatGPT, Claude or other MCP clients, with each tool call running as the signed-in user under the database's existing RLS policies.

Source: supabase.com/blog/give-your-supabase-app-its-own-mcp-server

The MCP Server block is installed with a shadcn command and copies an Edge Function into supabase/functions/mcp. The function includes an MCP handler, authentication middleware and a whoami tool, and it builds on the official MCP TypeScript SDK. Developers register their own tools, each in a separate file.

Supabase Auth runs the OAuth flow and issues access tokens, while the @supabase/server helpers give each tool a client for the signed-in user. Tools can run plain queries without a service role key, call database functions, invoke Edge Functions or use existing application APIs. MCP Apps can display part of the app's interface inside the chat, as the Sizzle demo does with a product card and video player in ChatGPT.

Setup requires asymmetric signing keys, the OAuth 2.1 server and dynamic client registration, plus an OAuth consent page in the frontend. The function's built-in JWT check is turned off so that discovery requests without a token can reach it.

Why it matters if you build agents

Agents can use an app's actions without a separate API layer or a service role key, because queries run under each user's own identity. Access is limited by the RLS policies already in the database, so those policies need to be checked before tools are exposed. Teams should test the sign-in and consent flow before pointing clients at the deployed server URL.

Get stories like this every weekday

One short email with the day's agent tooling news.

Subscribe