Cómo usar MCP en Cursor para validar tu API

Integrar un Model Context Protocol (MCP) en Cursor te permite conectar el editor con herramientas externas como una base de datos y validar tu código contra datos reales sin escribir queries manualmente. Aquí verás cómo configurar un MCP a nivel de proyecto, activarlo y usarlo dentro del modo agéntico para implementar y verificar endpoints de una API.

Qué es MCP y por qué usarlo en Cursor

Cursor adoptó los estándares de la industria para asistentes de código, entre ellos los MCP y los skills. Esta integración cambia la forma en que el modelo toma decisiones porque le da acceso a contexto real, no a suposiciones.

¿Qué es un MCP? Es el Model Context Protocol, un protocolo creado por Anthropic que permite a un LLM comunicarse con herramientas externas como una base de datos, Git, Sentry o Datadog para obtener contexto y decidir los siguientes pasos [1:20].

La idea central es simple: en lugar de que el modelo asuma que un endpoint funciona, se conecta a la fuente de verdad y lo demuestra con una consulta. Eso reduce el error humano y el riesgo de que el agente reporte falsos positivos.

Cómo se prepara el spec inicial antes del MCP

Antes de instalar el MCP, corre el spec que construye la base. En este caso se ejecutó el spec número tres, que crea la base de datos, el esquema y los seeders con Drizzle [0:20].

El prompt fue directo: implementar el spec al pie de la letra, mostrar primero el esquema propuesto de Drizzle para validarlo, y al terminar correr seed y validar los criterios de aceptación. El agente devolvió los comandos útiles para generar migraciones, aplicarlas y correr los test de integración.

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

Cursor permite instalar MCP a nivel de usuario o a nivel de proyecto. Para este flujo se usó la instalación por proyecto, que queda versionada junto al código.

El estándar es un archivo llamado .cursor/mcp.json. En lugar de escribirlo a mano, puedes pedirle al agente que lo cree con un prompt claro que defina el alcance y los permisos.

El prompt utilizado en la clase pidió lo siguiente:

• Dar acceso vivo a la base de datos local por MCP para que el agente verifique su propio trabajo.
• Agregar la configuración a .cursor/mcp.json apuntando al archivo SQLite local.
• Listar las herramientas que expone el servidor antes de habilitarlas.
• Recomendar cuáles activar y cuáles no, dejando la decisión final al desarrollador.
• Regla fija: consultas de lectura libres, nada de operaciones destructivas.

Después de ejecutarlo, el agente creó la carpeta .cursor con el mcp.json correctamente configurado hacia la base de datos local [4:00].

Cómo verificar que el MCP quedó activo

Hay una forma visual de confirmarlo dentro del editor. Ve a View, luego a Settings, y entra a Tools and MCPs. Selecciona tu proyecto y revisa la lista de servidores MCP disponibles en ese workspace.

Ahí verás el MCP de SQL desactivado por defecto. Al activarlo, Cursor carga las tools a las que el modelo tendrá acceso:

• Read query para consultas de lectura.
• Write query para escribir queries.
• Create table, alter table, list tables y describe tables para operar sobre el esquema.

¿Puedo restringir qué operaciones ejecuta el MCP? Sí. Tú decides los permisos en la configuración. En este caso se permitieron lecturas libres y se bloquearon operaciones destructivas para evitar cambios accidentales.

Cómo usar el MCP para validar endpoints reales de la API

Con la base de datos lista y el MCP activo, el siguiente paso fue implementar el spec número cuatro, que crea los endpoints de la API: get por flags, por ID, y el patch [5:40].

El prompt clave marcó tres reglas de arquitectura y una de verificación:

• Mantener la separación de dominio en package domain.
• Acceso a datos en la capa de base de datos.
• Transporte por HTTP.
• Después de cada endpoint, usar el MCP para verificar el resultado contra datos reales.

La instrucción textual fue muy clara: no asumas que funciona, demuéstralo con una query. Por ejemplo, al traer un post de flags, el agente debía consultar la tabla feature_flags y confirmar que la fila existe con los valores correctos.

Qué entrega el agente al terminar la ejecución

El agente reportó la arquitectura implementada, los endpoints creados con filtros usando la ruta API versión uno /flags, y confirmó que no había endpoint de delete según el spec. Los resultados fueron concretos:

• 15 test pasando.
• Verificación contra la base local exitosa.
• Proyecto levantado en el puerto 3001, con endpoints de health y flags activos.

Al probar el endpoint de flags en el navegador, la respuesta trajo dos resultados desde la tabla, coincidiendo con los datos seedeados previamente [7:30].

Cuándo conviene apoyarte en MCP para tu flujo de trabajo

Este patrón funciona bien cuando trabajas con specs que dependen de estado en base de datos, cuando quieres evitar falsos positivos del agente, o cuando estás construyendo APIs donde la verificación contra datos reales es más confiable que un mock.

La documentación oficial en cursor.com describe qué es un MCP, por qué usarlo, en qué casos aplicarlo y cómo instalarlo a nivel de usuario o proyecto. Es una buena referencia si quieres explorar servidores más allá de SQLite, como Git, Sentry o Datadog.

Como reto, busca en Internet los MCP disponibles en el mercado, identifica cuáles encajan con tu flujo de trabajo, instálalos en tu proyecto y pruébalos. ¿Cuál MCP crees que le daría más valor a tu próximo proyecto? Déjalo en los comentarios.