Supabase MCP Server connects an MCP client to selected Supabase project capabilities. The server supports project scoping, read-only mode and feature restrictions that should be used together with upstream account permissions.
Key takeaways
- Project scoping and read-only flags reduce the exposed surface.
- Remote OAuth and local or self-hosted configurations differ.
- Database operations can expose or modify application data.
What is Supabase MCP Server?
Supabase community server for working with projects, database schemas, SQL, configuration and development resources through MCP. MCP standardizes how a compatible client discovers and invokes tools, but it does not make those tools safe automatically. The client, server, credentials and upstream service remain separate trust boundaries.
What tools does it expose?
- Inspect projects, tables, migrations and database metadata.
- Run SQL and manage selected development operations.
- Access documentation and project configuration tools.
- Use feature groups to limit exposed capabilities.
The exact catalog can change by release, account, enabled feature or server configuration. Inspect the live tool list and JSON schemas before enabling it. A descriptive tool name is not an authorization control, and a read-sounding operation can still reveal sensitive metadata.
What is a safe first test?
Connect one disposable project with read_only and project_ref restrictions. Inspect schema and run a bounded SELECT over synthetic data before considering migrations or configuration changes.
Use a test account or project, allow only the required tools and record the client configuration, server version and arguments. Verify the result directly in the upstream service. Add write tools only after read-only behavior, authentication expiry, error handling and audit logs have been reviewed.
What data and credentials can it access?
The server can access Supabase project metadata, schemas, SQL results and configuration allowed by the authenticated identity. Write features can modify data, migrations or project settings.
Credentials should be supplied through the documented OAuth flow, a secret manager or a restricted environment variable, never pasted into prompts or committed to source. The upstream account should expose only the resources required for the pilot.
Which permissions should you grant?
- One explicit project reference.
- Read-only mode for the first evaluation.
- Only required feature groups and a non-production account.
Prefer project-scoped, read-only or restricted tokens. Where the server offers tool filters, combine them with upstream authorization rather than treating filtering as the only control. Separate development and production identities and rotate test credentials after the evaluation.
What should a security review cover?
- Keep service-role keys out of prompts and client logs.
- Use project scoping even when the account has wider access.
- Review SQL and migrations before execution.
Assume tool results can contain prompt injection or hostile content. Keep approval gates in application code for financial, administrative, destructive or public actions. Apply network restrictions, timeouts, output-size limits and audit logging at the host or gateway layer.
What are the main limitations?
- Hosted, local and self-hosted feature support is not identical.
- Database access can reveal tenant or user data.
- Community repository support should be evaluated separately from the Supabase service.
This is a documentation-based profile checked on 2026-10-04; Anavem did not connect the server or test it against a live account. Tool catalogs, transport support, pricing, licensing and authentication methods can change. Verify the current first-party documentation before installation.