Cuando se habla de MCP, mucha gente cree que es algo complicado o no sabe por dónde empezar a crear uno. En este artículo vamos a lo práctico: construimos una aplicación web de gestión de ventas, le creamos un MCP server propio, lo probamos, lo desplegamos y lo conectamos a Cursor y a ChatGPT para que consulten (y modifiquen) los datos de la app. Al final también lo testeamos con un MCP de testing.

La idea de fondo es simple: si tu cliente ya paga ChatGPT, Claude o Cursor, no hace falta que le metas otro chat dentro de tu web. Le das un MCP y usa la IA que ya paga con sus propios datos de tu sistema.

Si todavía no tienes claro qué es MCP, empieza por el video anterior: ¿Por qué todo el mundo habla de MCP?. Aquí doy solo lo básico.

Qué es un MCP (en una frase)

Un MCP es un conector entre plataformas y aplicaciones de IA: Claude, ChatGPT, Cursor y cualquier cliente que soporte el protocolo. Cuando una plataforma ofrece un MCP server, significa que ya soporta esa conexión: si quieres que una IA lea tu Gmail o tu calendario, Gmail o el calendario tienen que proveer su servidor MCP.

Hoy casi todas las plataformas grandes ofrecen uno. Lo interesante para un desarrollador es el otro lado: crear el MCP server de tu propia aplicación, para que otras apps de IA puedan conectarse a ella.

Un MCP no reemplaza tu API

La aplicación que vamos a crear es una de toda la vida: frontend, backend (con su API) y base de datos. Nada impresionante. Lo nuevo viene después: si ya tienes una app así, y quizá clientes usándola, puedes extenderla con un MCP.

Los MCP no son un reemplazo de las API. Al revés: se apoyan en ellas. Un MCP server tiene su propia dirección, normalmente algo como tudominio.com/mcp, y las aplicaciones de IA se conectan a esa URL.

Por qué darle un MCP a tu cliente

Si tu usuario ya paga una suscripción de ChatGPT, Claude o GitHub Copilot, puede usar sus propios tokens para consultar tu sistema a través del MCP. Es una alternativa a montar un chat (o un RAG) dentro de tu web: tú no pagas los tokens del chat y el usuario trabaja con la herramienta que ya conoce.

Que el MCP consulte tu API, no tu base de datos

Técnicamente un MCP server puede hablar directo con la base de datos. Mi recomendación es que consulte tu API:

  • La API es la puerta de entrada (el gateway) de tu sistema. Ahí ya tienes autenticación, validación y control de quién accede a qué.
  • Si mañana creas otra herramienta (por ejemplo una CLI), también hablará con la API. Centralizas todo en un solo lugar y solo mejoras eso.
  • Si cada cliente toca la base de datos por su lado, terminas con muchos puntos de conexión que revisar.

La propia guía de seguridad de MCP va en esa línea: advierte de los riesgos de saltarse controles como el rate limiting y la validación, de perder trazabilidad y del problema del confused deputy. También recomienda dar el mínimo de permisos posible (buenas prácticas de seguridad de MCP).

Autenticación con OAuth 2.1

Si cualquiera pudiera conectarse a cualquier MCP, podría leer cualquier dato. Por eso, igual que una API pide un token, un MCP remoto también se autentica, y la forma estándar es OAuth 2.1: al conectar el MCP, se abre una ventana de login; el usuario pone las credenciales que ya tiene en tu sistema y autoriza a su chat a acceder a sus datos.

Según la especificación, el MCP server protegido actúa como resource server de OAuth 2.1. Si una petición llega sin token, responde con un 401 que indica dónde está la metadata del recurso. El cliente usa PKCE, y el servidor debe comprobar que el token se emitió para él (autorización en MCP). Otro detalle de la spec: el MCP no debe reenviar a otros servicios el token que recibe del cliente, el llamado token passthrough (consideraciones de seguridad).

Paso 1: la app de ventas con Cursor

Creé una carpeta vacía (gestor-ventas), la abrí en Cursor y pedí algo así:

Crea una aplicación web de gestión de ventas con backend y frontend para administrar las ventas de un e-commerce. Ambos en TypeScript: Express para el backend, Next.js para el frontend, PostgreSQL con Drizzle para la base de datos. No necesito landing page, solo un panel con dashboard para registrar productos, ventas, etc. Crea todo dentro de un monorepo.

Dos consejos:

  • Usa el modo plan. La primera vez el agente te hace preguntas que no cubriste en el prompt. En mi caso elegí PostgreSQL con Docker, login con email y contraseña, y las secciones recomendadas (ventas, productos, categorías, inventario).
  • Esfuerzo máximo para planificar, otro modelo para construir. Para el plan usé el esfuerzo máximo; para construir conviene cambiar a un modelo más barato, porque los más caros (como Opus) se comen los tokens. Yo usé Grok 4.6.

Además le pedí documentar la API con Swagger (OpenAPI). No es solo por orden: esos mismos endpoints son los que después va a llamar el MCP, y viene bien verlos en una interfaz. Ojo, OpenAPI (documentar APIs) no es OpenAI.

Tras un rato (en mi caso cerca de una hora) tenía un panel típico: productos, categorías y ventas. Lo importante es la API que hay detrás.

Paso 2: el MCP server (Streamable HTTP + OAuth 2.1)

Con la app lista, le pedí a Cursor, de nuevo en modo plan:

Implementa un MCP básico en TypeScript que use la REST API. Para el transporte usa Streamable HTTP en el endpoint /mcp, y OAuth 2.1 para la autenticación.

  • Streamable HTTP es el transporte para que un MCP funcione sobre HTTP. Apareció en la revisión 2025-03-26 de la especificación y sustituyó al antiguo HTTP+SSE. El servidor expone un único endpoint que recibe peticiones POST, por ejemplo https://tudominio.com/mcp (transporte Streamable HTTP).
  • La revisión vigente (2026-07-28) además es stateless: ya no hay handshake inicial ni ID de sesión, y cada petición lleva su información (changelog).

En el plan le indiqué que el MCP viviera dentro del mismo servidor Express que la API, con la autenticación en ese mismo servidor. Más adelante podrías separarlo (el MCP en su propio servidor, hablando con la API), pero así se despliega todo de una sola vez.

Paso 3: probarlo con MCP Inspector

Antes de conectarlo a nada, conviene probarlo con el MCP Inspector, la herramienta oficial para depurar servidores MCP:

npx @modelcontextprotocol/inspector

Abre una interfaz web donde añades el servidor a mano: un nombre (yo puse "ventas MCP"), el transporte Streamable HTTP y la URL local (http://localhost:4000/mcp). Al activarlo me pidió el correo y la contraseña de la app: era el login de OAuth. Necesita Node 22.19 o superior (MCP Inspector).

Desde ahí ves las tools, las funciones que expone el MCP: listar productos (con página y tamaño de página), obtener un producto, listar categorías… Al ejecutarlas te das cuenta de algo: lo que devuelve una tool es lo mismo que devuelve la API. El MCP llama a tu API por ti; la "magia" de convertirlo en tablas, textos o gráficas la pone después la IA.

Añadir tools que faltan

Probando vi que no había una tool para obtener una sola categoría. Se lo pedí a Cursor y, como la API tampoco tenía esa ruta, la creó junto con la tool. Tras refrescar el Inspector aparecieron "obtener categoría" y "crear categoría", y creé una categoría "muebles" desde ahí.

Moraleja: tu MCP solo puede hacer lo que tus tools permiten, y estas dependen de las rutas que tengas.

Paso 4: conectarlo a Cursor

En Cursor, en Customize → MCPs → añadir nuevo MCP server, puedes instalarlo a nivel de usuario o de carpeta. Se abre el JSON de configuración y basta con añadir el nuevo servidor junto a los que ya tengas. Cursor guarda esto en ~/.cursor/mcp.json (global) o .cursor/mcp.json (del proyecto), y un servidor remoto se declara con su url (MCP en Cursor):

{
  "mcpServers": {
    "gestor-ventas": {
      "url": "http://localhost:4000/mcp"
    }
  }
}

Al principio muestra errores porque falta autenticarse. Con un clic en "autenticar" se abre el login de tu frontend, redirige a localhost:8787 (el callback de OAuth de Cursor) y queda autorizado.

Desde un chat ya puedes preguntar "¿cuántos productos tengo en gestor ventas?" y verás cómo llama a las tools. Dos aprendizajes de las pruebas:

  • Nombra tu app en el prompt ("en gestor ventas") para que el modelo sepa que te refieres a ella.
  • Diseña bien las rutas. Al preguntar por las ventas del último mes, la respuesta salió mal: la tool que usó era la del resumen del dashboard, no un listado real de ventas. Si quieres respuestas precisas, define las rutas pensando en lo que te van a pedir.

Cursor además dibuja gráficas con los datos cuando se lo pides. Para alguien que analiza ventas a diario, esto ya es útil.

Paso 5: desplegar en Railway

Un MCP remoto, como cualquier app web, tiene que estar en un servidor encendido siempre y con dominio. Para desplegar todo en un solo lugar usé Railway. No lo hice a mano desde el panel, sino con su CLI y una skill, para que el propio agente se encargue:

  1. Instalar la Railway CLI: en macOS con brew install railway, en Windows con scoop install railway o en cualquier sistema con npm i -g @railway/cli.
  2. Autenticarte con railway login: abre el navegador y solo tienes que autorizar.
  3. Instalar las Railway Agent Skills, que enseñan a tu agente a usar Railway. Yo usé la vía de skills.sh, el directorio de Agent Skills de Vercel, porque sirve para casi cualquier agente:
npx skills add railwayapp/railway-skills

Después basta con decirle a Cursor "despliega este proyecto en Railway": como mencionas Railway, sabe qué skill y qué comandos usar. Crea el proyecto en tu cuenta con la base de datos, la API y el frontend. Tarda: en mi caso entre 40 minutos y una hora con Grok; con Claude o GPT puede ir más rápido.

Un fallo que tuve: el MCP desplegado seguía apuntando a localhost. Revisa que la versión en producción use las URL de producción.

Paso 6: conectarlo a ChatGPT

Con la app en producción, la URL del MCP es la de tu backend más /mcp. En ChatGPT (web), los MCP aparecen como complementos, porque está pensado para usuarios no técnicos.

  1. Activa el modo desarrollador. Tu MCP no está en el catálogo que OpenAI ya revisó, así que necesitas este modo para añadir URLs externas. En el video lo activo desde la configuración, al final de la sección de complementos. La documentación de OpenAI lo ubica hoy en Security and login → Developer mode. Está disponible en los planes Plus, Pro, Business, Enterprise y Education, y OpenAI lo describe como "potente pero peligroso" (developer mode).
  2. Crea el complemento. En el explorador de complementos, pulsa + y rellena:
    • un nombre ("seguimiento de ventas");
    • una descripción real de lo que hace tu MCP, porque el modelo la usa para decidir cuándo llamarlo;
    • la URL https://…/mcp (conectar un MCP a ChatGPT).
  3. Inicia sesión. Se abre el mismo login de tu app: el usuario pone su cuenta y listo.

Una vez conectado, ves la lista de acciones (las tools) y puedes ajustar los permisos: preguntar siempre, permitir solo lectura, acciones de bajo riesgo o todo.

Luego, en un chat, activas el complemento y preguntas: "dame un listado de ventas de este mes de mi gestor de ventas". Los datos vienen de tu sistema, no del entrenamiento del modelo. Y si pides "crea gráficas para entender mejor estos datos", ChatGPT las dibuja dentro del chat.

También puede escribir

Si tus tools incluyen operaciones de creación o actualización, el chat también puede hacerlas. Pedí crear un producto y no pudo: mi MCP no tenía esa tool, solo la de crear categorías. En cambio, "crea una categoría llamada informática" funcionó, y "crea 10 categorías nuevas" también: antes listó las existentes para no duplicarlas.

Paso 7: tests automáticos con TestSprite

Para la última parte usé TestSprite, una plataforma de testing que también tiene MCP: genera los tests, los ejecuta en su nube y te devuelve reportes. No los escribes ni los corres en local.

  1. Creas una cuenta (hay plan gratuito), un proyecto nuevo y eliges la conexión por MCP.
  2. Lo añades a Cursor: es un MCP local que se levanta con un comando (npx @testsprite/testsprite-mcp@latest) y necesita una API key, que creas en el panel. Con unos segundos de espera aparecen sus herramientas habilitadas (instalación del MCP de TestSprite).
  3. En un chat nuevo: "Ayúdame a testear el proyecto usando TestSprite". Se abre una ventana de configuración: elegí probar el backend (es lo que usa el MCP), con autenticación por bearer token (le pedí al proyecto generar uno en local), el puerto localhost:4000 y un PRD que también generé con Cursor.

El resultado fue un reporte con lo que probó: búsqueda de productos, que un administrador pueda crear y renombrar categorías, consulta de ventas… y algunos fallos reales, como la validación del inventario. En la plataforma quedan las grabaciones de cada test y sus pasos. Puedes editar un paso (por ejemplo, otro correo) y volver a ejecutarlo, o decirle al agente "corrige y vuelve a ejecutar".

Conclusión

  • Un MCP no es otro chat: es un conector. Tu cliente usa la IA que ya paga (ChatGPT, Claude, Cursor) con los datos de tu aplicación.
  • No reemplaza tu API, se apoya en ella: haz que el MCP consulte tu API, con OAuth 2.1 para que cada usuario autorice sus propios datos.
  • Llévalo a producción: despliégalo (aquí con Railway) y conéctalo a ChatGPT en modo desarrollador. No te quedes en la demo local.

Un último aviso: aunque el MCP parezca gratis, cada consulta llega a tu backend. Piensa qué operaciones son críticas o caras para tu servidor y limita la cantidad o el tipo de consultas si hace falta.

¿Qué aplicación tuya conectarías a ChatGPT con un MCP? Déjamelo en los comentarios del video. Con tus dudas puedo armar un curso más completo de MCP.

Fuentes