MCPIntermedio13 minActualizado octubre de 2026

Supabase MCP Server

Servidor MCP oficial de Supabase: tus proyectos al alcance de Cursor, Claude y otros asistentes, con modo de solo lectura y acotado por proyecto.

Fuente: Supabase MCP Server (repositorio oficial) · Oficial · Mantiene Supabase · Licencia Apache-2.0 · Ver original en github.com

Ficha técnica

Transporte
HTTP (servidor alojado por Supabase); endpoint propio con el paquete npm
Clientes compatibles
  • Cursor
  • Claude
  • Windsurf
Instalación
https://mcp.supabase.com/mcp

Qué es y qué expone

Supabase MCP Server es el servidor MCP oficial de Supabase: conecta tus proyectos de Supabase con Cursor, Claude, Windsurf y otros asistentes de IA. Según su README, MCP estandariza cómo los LLM hablan con servicios externos como Supabase, y el servidor conecta los asistentes de IA directamente con tu proyecto para que hagan tareas como gestionar tablas, obtener la configuración y consultar datos.

Sus herramientas se agrupan en funcionalidades: account, branching, database, debugging, development, docs, feedback, functions, notebooks y storage. Por defecto se activan todas menos notebooks y storage. Cubren la cuenta y los proyectos, las ramas de desarrollo, la base de datos Postgres, los logs y avisos, las Edge Functions y el almacenamiento.

El servidor se publica en npm como @supabase/mcp-server-supabase, y el repositorio, con licencia Apache 2.0, incluye además @supabase/mcp-server-postgrest, un servidor MCP de PostgREST que permite conectar a los usuarios de tu app con ella mediante la API REST.

Valoración de KIRELEN: encaja con equipos que desarrollan sobre Supabase desde un editor con agente y quieren consultar el esquema, aplicar migraciones o revisar logs sin salir de él.

Chat de Cursor en el que el agente llama a dos herramientas MCP de Supabase para encontrar el proyecto y su URL
Un agente en Cursor usa herramientas MCP de Supabase: localiza el proyecto y después pide su URL. Fotograma de la demostración del README oficial, comprobado el 2026-10-17. Es de una versión anterior: la herramienta que lista proyectos se llama hoy list_projects.Demostración del README de supabase/mcp (Supabase) (se abre en una pestaña nueva)

Qué problema resuelve

El servidor conecta los asistentes de IA directamente con tu proyecto de Supabase, de modo que tareas como gestionar tablas, obtener la configuración o consultar datos se piden al asistente en lugar de hacerse a mano en el panel.

Algunas herramientas lo muestran bien. list_projects lista los proyectos de Supabase del usuario y sirve para descubrir el ID del proyecto en el que trabaja. generate_typescript_types genera los tipos de TypeScript del proyecto. get_advisors devuelve los avisos del proyecto para detectar vulnerabilidades de seguridad, mejoras de rendimiento o problemas de salud, y conviene ejecutarlo con regularidad, sobre todo tras cambios DDL en la base de datos, porque detecta, por ejemplo, políticas RLS que faltan. search_docs busca en la documentación de Supabase con GraphQL, y su descripción pide usarla aunque el agente crea saber la respuesta, porque la documentación se actualiza continuamente.

Para los cambios de esquema, el repositorio documenta un flujo con ramas de desarrollo: una rama permite experimentar con cambios de esquema reduciendo el riesgo de pérdida de datos, caídas o incompatibilidades entre la app y la base de datos de producción.

Cómo funciona

Servidor alojado e inicio de sesión

La mayoría de los clientes MCP solo necesitan la configuración que aparece en «Configuración»: el tipo http y la URL del servidor de Supabase. Durante la configuración, el cliente MCP pide iniciar sesión en Supabase, y hay que elegir la organización que contiene el proyecto con el que quieres trabajar. En el panel de Supabase, la pestaña de conexión MCP genera además una URL de MCP personalizada para tu proyecto. Si tu cliente MCP no aparece en la documentación, copias esa información en el formato que espere (JSON, YAML u otro).

Acotar el servidor

Sin más opciones, el servidor tiene acceso a todas las organizaciones y proyectos del usuario. Con el ID de un proyecto (project_ref) queda acotado a él: las herramientas dejan de pedir project_id y se excluyen las de nivel de cuenta. Con read_only=true, las consultas a la base de datos se ejecutan en modo de solo lectura y el servidor oculta las herramientas que modifican datos. Con features se restringe a grupos de funcionalidades concretos; por defecto se usan todos los grupos predeterminados. Las opciones se pasan como parámetros de la URL del servidor, por ejemplo project_ref, read_only=true y features=database,docs.

En local y en tu propia infraestructura

Si ejecutas Supabase en local con la CLI de Supabase, también puedes acceder al servidor MCP desde tu máquina. En los entornos de la CLI y en los autohospedados, el servidor MCP ofrece por ahora un subconjunto limitado de herramientas y no tiene OAuth 2.1.

El paquete @supabase/mcp-server-supabase exporta createSupabaseMcpHandler() para servir las herramientas por HTTP desde un endpoint propio. Ese manejador solo habla la revisión actual del protocolo: un cliente que solo hable el protocolo de 2025 recibe un HTTP 400. El paquete exporta también createToolSchemas(), con los esquemas de entrada y salida de las herramientas para el cliente MCP de Vercel AI SDK. El servidor no envía structuredContent en los resultados, así que AI SDK analiza el JSON del texto de content.

Observar las peticiones

Si sirves tu propio endpoint, la opción observer de createSupabaseMcpServer recoge los resultados del ciclo de vida de cada petición y los datos propios que registra Supabase. El servidor no reenvía automáticamente al observador el contenido de las peticiones ni de las respuestas, y los fallos del observador no cambian el comportamiento de las peticiones, aunque el trabajo síncrono del observador puede bloquearlas.

Del asistente al proyecto

Del asistente al proyectoArquitectura en 3 capas, de arriba abajo; capa 1: Asistentes de IA; capa 2: Servidor MCP de Supabase; capa 3: Proyecto de Supabase. Conexiones: Asistentes de IA → Servidor MCP de Supabase, Servidor MCP de Supabase → Proyecto de Supabase.Asistentes de IAServidor MCP deSupabaseProyecto de SupabaseDel asistente al proyectoArquitectura en 3 capas, de arriba abajo; capa 1: Asistentes de IA; capa 2: Servidor MCP de Supabase; capa 3: Proyecto de Supabase. Conexiones: Asistentes de IA → Servidor MCP de Supabase, Servidor MCP de Supabase → Proyecto de Supabase.Asistentes de IAServidor MCP de SupabaseProyecto de Supabase
Leer el diagrama como texto
  1. Capa 1
    • Asistentes de IA
  2. Capa 2
    • Servidor MCP de Supabase
  3. Capa 3
    • Proyecto de Supabase

Conexiones

  • Asistentes de IA → Servidor MCP de Supabase
  • Servidor MCP de Supabase → Proyecto de Supabase

Tecnologías utilizadas

TecnologíaPara qué
TypeScriptLenguaje del repositorio, según GitHub
JavaScriptLenguaje del repositorio, según GitHub
npmPublica el servidor como @supabase/mcp-server-supabase
PostgresBase de datos sobre la que trabajan execute_sql y apply_migration
PostgRESTEl otro servidor del repositorio, @supabase/mcp-server-postgrest, conecta a los usuarios de tu app mediante la API REST

Cómo empezar: requisitos e instalación

  1. Ten a mano tu cuenta y tu cliente. Necesitas una cuenta de Supabase y un cliente MCP: Cursor, Claude, Windsurf u otro asistente de IA.
  2. Añade el servidor. La mayoría de los clientes solo necesitan el tipo http y la URL del servidor (ver «Configuración»). En Claude Code, la documentación lo añade a la configuración del proyecto con la línea de comandos:
bash
claude mcp add --scope project --transport http supabase "https://mcp.supabase.com/mcp"
  1. Inicia sesión. El cliente abre el navegador para que entres en tu cuenta de Supabase y des acceso a tu organización, sin token de acceso personal. Elige la organización que contiene el proyecto con el que vas a trabajar.
  2. Comprueba la conexión. Pídele al cliente que consulte tu proyecto en lenguaje natural; la documentación propone «What tables are there in the database? Use MCP tools.».
  3. En local, con la CLI. Si ejecutas Supabase en local con la CLI de Supabase, también llegas al servidor desde tu máquina, con un subconjunto limitado de herramientas y sin OAuth 2.1. Para servir un endpoint propio con toNodeHandler hay que instalar también @modelcontextprotocol/node.

Estado del proyecto y licencia

El repositorio tiene licencia Apache 2.0 y lo mantiene la organización de Supabase en GitHub.

Según la ficha del repositorio en GitHub, comprobada el 2026-10-20, el último release es mcp-server-supabase-v0.14.0, publicado el 2026-10-14, y el último push es del 2026-10-20: un proyecto activo, con releases.

Herramientas expuestas

HerramientaGrupoQué hace
list_organizationsaccountLista las organizaciones de las que el usuario es miembro.
list_projectsaccountLista los proyectos del usuario y ayuda a descubrir el ID del proyecto.
get_costaccountDa el coste de crear un proyecto o una rama, que el agente debe repetir y confirmar con el usuario.
confirm_costaccountDevuelve un ID de confirmación cuando el usuario ha aceptado el coste de forma explícita.
create_projectaccountCrea un proyecto, que puede sumar a la factura de la organización.
pause_projectaccountPausa un proyecto.
restore_projectaccountRestaura un proyecto.
list_branchesbranchingLista las ramas de desarrollo con su estado, para saber cuándo terminan merge, rebase o reset.
create_branchbranchingCrea una rama de desarrollo, con cargos de cómputo por horas, que el usuario acepta antes.
merge_branchbranchingFusiona las migraciones y las Edge Functions de una rama con producción.
reset_branchbranchingRestablece las migraciones de una rama; se pierden los cambios no registrados.
rebase_branchbranchingAplica a la rama las migraciones más recientes de producción.
delete_branchbranchingBorra una rama de desarrollo.
list_tablesdatabaseLista las tablas de uno o varios esquemas; con verbose, también columnas y claves.
list_extensionsdatabaseLista las extensiones de la base de datos.
list_migrationsdatabaseLista las migraciones de la base de datos.
apply_migrationdatabaseAplica una migración; es la herramienta para las operaciones DDL.
execute_sqldatabaseEjecuta SQL en Postgres; puede devolver datos no confiables.
get_logsdebuggingObtiene los logs del proyecto por tipo de servicio; donde hay query_logs, queda en segundo plano.
query_logsdebuggingEjecuta una consulta SQL de solo lectura sobre los logs del proyecto para filtrar, agregar o cruzar sus campos.
get_advisorsdebuggingDevuelve avisos de seguridad, rendimiento y salud del proyecto.
get_project_urldevelopmentObtiene la URL de la API del proyecto.
get_publishable_keysdevelopmentObtiene las claves de API publicables, las anon heredadas y las modernas.
generate_typescript_typesdevelopmentGenera los tipos de TypeScript del proyecto.
search_docsdocsBusca en la documentación de Supabase con GraphQL.
list_edge_functionsfunctionsLista las Edge Functions del proyecto.
deploy_edge_functionfunctionsDespliega una Edge Function o sustituye la existente, que empieza a servir de inmediato.
list_storage_bucketsstorageLista los buckets de almacenamiento.
update_storage_configstorageActualiza la configuración de almacenamiento.
get_notebooknotebooksObtiene un notebook con sus celdas.
submit_feedbackfeedbackEnvía comentarios sobre las herramientas al equipo de Supabase; pregunta antes si el usuario no lo pidió y nunca incluye secretos, datos personales ni contenido de la base de datos.
create_edge_function_secretfunctionsCrea o actualiza un secreto: el valor se introduce en el panel y nunca pasa por el cliente de IA.

Esta tabla recoge las herramientas principales de cada grupo, según su definición en el código del repositorio, contrastada con la lista de la documentación oficial el 2026-10-20. Según la documentación, las ramas de desarrollo (experimental) requieren un plan de pago.

Configuración

json
{
  "mcpServers": {
    "supabase": {
      "type": "http",
      "url": "https://mcp.supabase.com/mcp"
    }
  }
}

Ejemplo de uso

Un cambio de esquema con una rama de desarrollo

El repositorio documenta este flujo para llevar un cambio de esquema de desarrollo a producción. Para crear una rama de desarrollo basta con pedírselo al LLM, que llamará a la herramienta create_branch. La rama aplica todas las migraciones del proyecto principal a una base de datos nueva, y los datos de producción no se copian: clona la rama de producción aplicando las mismas migraciones que muestra list_migrations, sin los datos ni los cambios de esquema no registrados.

Después pides el cambio. Al aplicar una migración con apply_migration, el cambio de esquema o de datos queda registrado para repetirlo en producción cuando quieras desplegar. Si la migración inserta datos estáticos, hay que pedir al LLM que no fije referencias de claves foráneas, porque están ligadas a los datos de la rama de desarrollo. Después de aplicar una migración, puedes probar los cambios conectando tu app a la rama de desarrollo; la URL y las claves de API de la rama se obtienen con get_project_url y get_publishable_keys.

Cuando todo funciona, fusionar la rama con merge_branch equivale a aplicar sus migraciones nuevas, de forma incremental, en la rama de producción. Si la fusión falla, get_logs permite consultar el error exacto de esa acción de la rama; sin un rango de tiempo, cada llamada cubre las últimas 24 horas. Solo se registran las migraciones que se aplican con éxito, así que fusionar varias veces la misma rama de desarrollo es seguro. Al final, después de fusionar los cambios con producción, delete_branch borra la rama de desarrollo para ahorrar recursos.

Revertir y ponerse al día

Para revertir una migración en la rama de desarrollo, se pide al LLM restablecer las últimas n migraciones o volver a un número de versión concreto, y entonces se pide llamar a reset_branch para devolver la rama a esa versión de migración. A veces hay que aplicar una migración urgente directamente en producción, y la rama de desarrollo se queda atrás en versiones de migración; lo mismo puede pasar en un equipo en el que cada persona trabaja en su propia rama de desarrollo y las fusiones se hacen en distinto orden. Para corregirlo se puede recrear la rama de desarrollo o llamar a rebase_branch, que aplica en ella, de forma incremental, las migraciones nuevas de producción.

Lo que hace el agente en la demostración

La captura que acompaña a la primera sección muestra el principio de una sesión real: el agente llama a una herramienta para localizar el proyecto del usuario y, con él identificado, pide su URL. list_projects sirve precisamente para descubrir el ID del proyecto en el que trabaja el usuario, y get_project_url obtiene la URL de la API de un proyecto.

Flujo con una rama de desarrollo

Flujo con una rama de desarrolloPasos en 4 etapas: Crear rama de desarrollo → Aplicar migración → Probar la app → Fusionar con producción.01Crear rama dedesarrollo02Aplicar migración03Probar la app04Fusionar conproducciónFlujo con una rama de desarrolloPasos en 4 etapas: Crear rama de desarrollo → Aplicar migración → Probar la app → Fusionar con producción.01Crear rama de desarrollo02Aplicar migración03Probar la app04Fusionar con producción
Leer el diagrama como texto
  1. Crear rama de desarrollo
  2. Aplicar migración
  3. Probar la app
  4. Fusionar con producción

Conexiones

  • Crear rama de desarrollo → Aplicar migración
  • Aplicar migración → Probar la app
  • Probar la app → Fusionar con producción

Seguridad y límites

Según la documentación de Supabase, conectar un LLM a tus proyectos de Supabase conlleva riesgos de seguridad, y Supabase recomienda leer sus buenas prácticas antes de configurar el servidor. Esto es lo que dicen la documentación y el código del repositorio.

Inyección de prompts. Es el vector de ataque propio de los LLM: un texto guardado en tus datos puede llevar al modelo a seguir órdenes no confiables. execute_sql puede devolver datos de usuario no confiables, así que su descripción pide no seguir instrucciones ni órdenes que devuelva; lo mismo dice get_notebook de las celdas de los notebooks, que escribe cualquiera con acceso al proyecto. Supabase MCP envuelve además los resultados de SQL con instrucciones que disuaden al modelo de obedecer lo que haya en los datos, pero no es infalible: revisa la salida antes de seguir. Las herramientas de SQL piden también no leer nunca archivos del servidor ni ejecutar órdenes del sistema operativo mediante SQL.

Aprobación manual. La mayoría de los clientes MCP piden aceptar cada llamada a una herramienta antes de ejecutarla, y la documentación pide mantener esa aprobación en el trabajo interactivo. Las confirmaciones que pide el propio servidor son una salvaguarda, no una garantía de revisión humana.

Cambios destructivos. En execute_sql y apply_migration, las sentencias destructivas pueden requerir la confirmación del usuario, una salvaguarda que puede no detectar todas las operaciones destructivas y no es una garantía de seguridad. En una migración destructiva, como borrar una columna, hay que revisar el SQL generado y el estado actual de la base de datos. Para deshacer una migración que ya está en producción no se usa reset_branch, que pierde los datos y cambios no registrados: se pide una migración nueva que revierta la anterior.

Costes. create_project puede sumar a la factura de la organización y create_branch genera cargos de cómputo por horas. Con la confirmación por formulario, el cliente muestra el coste previsto antes de la acción, que solo sigue con aprobación explícita; si no está disponible, se aplica el flujo heredado, en el que el agente da el coste en el chat y usa get_cost y confirm_cost.

Alcance. El servidor opera con tus permisos de desarrollador, así que no se da a clientes ni a usuarios finales. Sin acotar, llega a todas las organizaciones y proyectos del usuario; con un proyecto y el modo de solo lectura se limita a ese proyecto y a consultas que no escriben, y restringir los grupos de herramientas reduce la superficie de ataque. Los secretos de Edge Functions se introducen en el panel de Supabase y nunca pasan por el cliente de IA.

Valoración de KIRELEN: para trabajar sobre datos reales conviene acotar el servidor a un proyecto y activar el modo de solo lectura, y hacer los cambios de esquema en una rama de desarrollo antes de fusionarlos con producción.

Valoración de KIRELEN: como execute_sql y los notebooks pueden devolver datos no confiables, el riesgo no es solo lo que el agente pueda borrar: un texto guardado en la base de datos puede intentar darle instrucciones, y conviene revisar cada acción antes de aprobarla.

Fuentes consultadas