MCP en Cursor: valida tu API con datos reales

Si trabajas con asistentes de código y quieres que tu API se valide sola contra datos reales, aprender a usar MCP en Cursor cambia por completo tu flujo de trabajo. Aquí verás cómo instalar un Model Context Protocol que se comunica con tu base de datos local y confirma que tus endpoints responden bien antes de dar por terminada la implementación. Es una guía práctica para desarrolladores que buscan escribir menos código y confiar más en la verificación automática.

Qué es MCP y por qué importa dentro de Cursor

Cursor, igual que otros asistentes de código, adoptó estándares de la industria como los MCP o los skills para generar código de forma más confiable. La idea central es sencilla: darle al modelo la capacidad de comprobar su propio trabajo.

¿Qué es el MCP? Es el Model Context Protocol, un protocolo de comunicación creado por Anthropic que le permite a un LLM conectarse con herramientas externas como una base de datos, Git, Sentry o Datadog para tomar decisiones con contexto real.

Ese contexto es la clave. En lugar de que el modelo asuma que un endpoint funciona, puede lanzar una consulta directa a la base de datos y demostrarlo. Ahí está la diferencia entre "parece que funciona" y "lo comprobé con una query" [00:29].

Para qué sirve conectar un LLM con herramientas externas

Cuando el modelo tiene acceso vivo a una fuente de datos, puede indicarte los siguientes pasos con fundamento. En el flujo mostrado, el agente ejecuta un spec que construye toda la base de datos, genera el esquema con Drizzle, corre los seeders y valida los criterios de aceptación [01:44].

El agente incluso devuelve los comandos útiles que necesitas después:

• Generar las migraciones.
• Aplicar las migraciones.
• Aplicar los seeders.
• Correr los test de integración.

Con esa base lista, el siguiente paso es darle al modelo una forma de auto verificarse.

Cómo instalar un MCP a nivel de proyecto en Cursor

La documentación oficial en cursor.com explica qué es un MCP, por qué usarlo, en qué casos aplica y cómo instalarlo a nivel de usuario o a nivel de proyecto. Aquí el objetivo era evitar escribir código a mano, así que todo se resuelve con un prompt [03:00].

El prompt le pide al agente darle acceso vivo a la base de datos local por MCP y agregar la configuración a .cursor/mcp.json, que es el estándar de Cursor para instalar un MCP a nivel de proyecto [03:19]. El servidor apunta al archivo SQLite local.

¿Dónde queda la configuración del MCP en Cursor? En el archivo .cursor/mcp.json dentro de tu proyecto. Ahí se define el servidor MCP apuntando a tu base de datos local para acceso a nivel de proyecto.

Un detalle importante del prompt: antes de habilitar nada, se le pide al agente listar las herramientas que expone y recomendar cuáles activar. Tú decides los permisos. La regla fija fue clara: consultas de lectura libres, pero nada de operaciones destructivas [03:56].

Cómo activar y verificar el MCP recién instalado

Una vez añadida la configuración, el agente pide reiniciar y activar el servidor. Puedes confirmar que quedó bien de dos maneras:

1. Abriendo la carpeta .cursor y revisando que exista el mcp.json apuntando a tu base de datos local.
2. Yendo a view, luego settings y después a tools and MCPs, donde seleccionas tu proyecto [04:36].

Al activarlo, el MCP carga las tools permitidas. En este caso: read query, escribir queries, crear tablas, alter tables, listar tablas y describir tablas [05:11]. Nada de borrado, tal como pedía la regla.

Cómo verificar endpoints contra datos reales con MCP

Con la base de datos construida y el MCP activo, solo falta implementar los endpoints. El prompt pide ejecutar el spec número 4, que crea los endpoints de get por flags, por ID y el patch [05:42].

La instrucción clave mantiene una separación limpia de responsabilidades:

• Dominio en package domain.
• Acceso a datos en la base de datos.
• Transporte por HTTP.

Y aquí viene lo interesante: después de cada endpoint, el agente usa el MCP para verificar el resultado contra datos reales. Por ejemplo, al traer un get de flags, consulta la tabla de feature flags y confirma que la fila existe con los valores correctos. La consigna fue directa: no asumas que funciona, demuéstralo con una query [06:16].

¿Por qué validar endpoints con una query en vez de confiar en el test? Porque una query contra la tabla real confirma que los datos existen con los valores correctos. El agente demuestra el funcionamiento en lugar de asumirlo.

El resultado: el spec 4 implementado, la API bajo hash versión uno, 15 test pasando y la verificación contra la base local funcionando [06:34].

Qué hacer si el endpoint no responde en el puerto

Al probar el endpoint de flags en el navegador, el puerto 3001 devolvió un error de conexión. La causa era simple: había que reiniciar la terminal. Tras pedirle al agente iniciar el proyecto, levantó web, la API, el endpoint de health y el de flags [07:37].

Al volver a probar, el endpoint respondió con dos resultados de la tabla. La prueba real, no la suposición.

Como reto, busca en Internet qué MCPs existen en el mercado, identifica cuáles encajan en tu flujo de trabajo, instálalos en tu proyecto y pruébalos. ¿Cuál vas a conectar primero? Cuéntame en los comentarios.