Servidor MCP remoto en acción: un nuevo punto de entrada para productos SaaS en la era de la IA

Los productos SaaS tienen un problema de larga data: el time-to-value es demasiado lento. Muchos usuarios abandonan antes de llegar al momento “¡ajá!”.

Hemos iterado varias veces en el onboarding de Logto. Ayudó, pero el cuello de botella no desapareció. Todavía terminas leyendo documentación, hojeando tutoriales, instalando SDKs, configurando, escribiendo código y depurando el último 10 % antes de que funcione algo.

Así que probamos un enfoque diferente: un servidor MCP remoto como plano de control nativo del IDE de Logto. En vez de hacer clics en una consola de administración, configuras Logto y generas el código de integración conversando justo donde estás construyendo la app.

Un solo prompt puede llevarte de cero a una integración funcionando. El agente no solo genera código, sino que también crea y configura la aplicación Logto en tu tenant. Todo desde dentro de tu IDE. (Prueba Logto MCP Server)

En este artículo, compartiré nuestra experiencia y reflexiones sobre construir el Servidor Logto MCP, incluyendo:

• MCP vs. Agent Skills: por qué elegimos MCP
• Problemas encontrados al lanzar un servidor MCP y cómo los resolvimos
• Cómo diseñamos herramientas MCP y cómo deberías diseñar las tuyas
• Nuestras expectativas para el futuro de MCP

MCP vs. Agent Skills: por qué elegimos MCP#

Antes de decidir cómo debería acceder la IA a Logto, evaluamos dos opciones: servidores MCP y Agent Skills.

Los servidores MCP tienen dos formas: local y remota.

Un servidor MCP local corre en la máquina del usuario. Requiere instalación de servicios, configuración de entorno, credenciales o flujos de inicio de sesión especiales. En uso y entrega, es muy similar a las skills.

Un servidor MCP remoto se aloja en el servidor. Los usuarios se conectan vía URL y autorizan con OAuth. Este modelo se parece más a una extensión de servicios SaaS.

Desde un punto de vista estructural, una Agent Skill es la combinación de "lógica de negocio + capacidades subyacentes". Esas capacidades pueden ser herramientas, CLIs o llamadas a API. Las herramientas MCP pueden llevar esta capa de forma unificada.

Así que la pregunta clave no es cómo se implementan las capacidades, sino cómo se entregan a los usuarios.

• Agent Skills entregan: una cadena de herramientas local completa (paquete Skill + runtime local + llaves o credenciales de plataforma + herramientas CLI + flujos de instalación, configuración, actualización y mantenimiento).
  En esencia, das la capacidad para que los usuarios la ejecuten por sí mismos.

• Servidores MCP remotos entregan: una entrada de servicio remoto (URL + inicio de sesión OAuth).
  En esencia, brindas la capacidad como servicio.

Abajo los comparamos en experiencia de usuario, alcance en ecosistema y costo de entrega/mantenimiento.

Experiencia de usuario#

Las Agent Skills suelen depender de APIs de la plataforma o CLIs. Los usuarios deben crear llaves API o instalar e iniciar sesión en CLIs primero. No son pasos complejos, pero suben la barrera de entrada.

Los servidores MCP soportan OAuth. Los usuarios inician sesión con su cuenta SaaS. La experiencia es como “Iniciar sesión con Google”.

Para el usuario, usar un servidor MCP es simple: pones una URL, inicias sesión, conectas. Esta es la experiencia que queremos dar.

Alcance en el ecosistema#

En la web de MCP, ya hay 104 apps de IA que soportan MCP, incluyendo herramientas como VS Code, Cursor y Windsurf.

Las Agent Skills siguen siendo específicas de cada plataforma. Incluso si varias plataformas las soportan, cuando lanzamos un servidor MCP, los usuarios pueden usarlo al instante. Si lanzamos una Skill, solo los usuarios de esa plataforma podrán usarla.

MCP también está incluido en la Agentic AI Foundation (AAIF). Es un estándar a nivel de protocolo. El ecosistema seguirá creciendo. Para nosotros, esto hace que MCP valga la inversión a largo plazo.

Costo de entrega y mantenimiento#

Las Agent Skills dependen de APIs de plataforma o CLIs, lo cual trae problemas rápidamente:

• ¿Qué pasa si la API cambia?
• ¿Qué pasa si la CLI rompe compatibilidad?
• ¿Cómo actualizas y distribuyes la Skill?

También tienes que distribuir CLIs, manejar credenciales dispersas, adaptarte a varias plataformas y guiar al usuario para actualizar. El ROI es muy bajo.

El MCP es mucho más simple. Los usuarios se conectan mediante URL. Siempre apunta a la última versión. Cuando actualizamos el servidor MCP, los usuarios lo obtienen la próxima vez que se conecten. No hacen falta actualizaciones. Si cambian las APIs, las modificamos dentro del MCP server.

La mayoría de SaaS ya tienen buena infraestructura: APIs sólidas y sistemas de autenticación maduros. Un servidor MCP encaja naturalmente como la “interfaz de IA” del API, igual que la consola de administración es otra interfaz sobre las mismas APIs.

Para Logto, elegir un MCP server encaja con nuestra arquitectura y aprovecha nuestras fortalezas.

También centraliza todas las solicitudes en un solo punto de entrada. Logs y auditorías son más fáciles. Los permisos son claros: la IA solo puede hacer lo que autoriza el usuario. Este modelo es estructuralmente más claro en escenarios empresariales y de cumplimiento.

Problemas encontrados al lanzar un servidor MCP y cómo los resolvimos#

MCP no es perfecto. Muchos issues son por la madurez del ecosistema. Mejorarán con el tiempo. Hasta entonces, usamos soluciones temporales según la necesidad real.

Soporte fragmentado de funciones MCP#

La especificación MCP define muchas funciones, pero el soporte de los clientes varía:

• Herramientas: ampliamente soportadas
• OAuth: bien soportado en VS Code; herramientas como Cursor necesitan mcp-remote como puente
• Otras funciones (Recursos, Prompts, Instrucciones): soporte inconsistente

Por ahora, las herramientas son la capa común más fiable (consulta la Página de la Comunidad MCP para ver qué soporta cada cliente).

Así que nuestra estrategia es simple: basarnos en herramientas.

La LLM no sabe cómo usar tus herramientas#

Esto es un problema de la capa de negocio.

Con Agent Skills, la lógica de negocio y contexto están empaquetados. La LLM sabe cómo usarlas. MCP solo aporta herramientas. Tras conectarse, la LLM no sabe:

• Los escenarios de uso
• El orden de llamadas
• Las restricciones de negocio

MCP tiene el concepto de Instrucciones, pero no todos los clientes lo soportan. Además, las Instrucciones mandan todo el contenido al contexto en la conexión, lo que derrocha tokens.

Otra idea es poner la guía en las descripciones de herramientas. Pero esto causa dos problemas:

• Las descripciones se vuelven complejas. Los flujos que combinan herramientas se confunden y cuesta mantenerlo.
• Al crecer el número de herramientas, las descripciones consumen gran parte de la ventana de contexto.

Nuestra solución: ofrecer una herramienta getInstructions

La idea es simple: si las Instrucciones no están bien soportadas, conviértelas en herramientas.

La LLM puede llamar a getInstructions bajo demanda.
Para la tarea A, llama a getTaskAInstructions. El MCP server devuelve un prompt que explica cómo completar la tarea A y combinar otras herramientas.

La lógica de negocio compleja queda oculta tras las herramientas de instrucciones. Las demás herramientas se mantienen simples. Sus descripciones solo tratan de su función.

Esto es parecido a Agent Skills: los prompts se cargan bajo demanda. Además, es más eficiente que las Instrucciones globales porque evita llenar el contexto con todo.

La LLM puede filtrar tus secretos#

En muchos SaaS, hay secretos que nunca deben exponerse (por ejemplo, client secrets, API keys o llaves de firma webhook). Si se filtran, pueden hacerse pasar por ti o acceder a recursos.

El riesgo con las LLM es que un chat no es un canal seguro. Las conversaciones pueden ser registradas, copiadas, reenviadas o acabar en logs de depuración. No puedes asumir que “solo yo y el modelo lo vemos”. Así que entregar un secreto duradero a una LLM, o pedirle que lo muestre para que el usuario lo copie, es muy riesgoso.

Es un caso común en la integración web tradicional: los desarrolladores a menudo necesitan un secreto, lo ponen en variables de entorno del servidor o archivos de configuración, y luego terminan pasos como inicializar SDKs.

Para mantener el onboarding fácil sin sacrificar seguridad, hacemos tres cosas:

• Usar secretos temporales durante la integración

  Durante la configuración por chat, el MCP server solo devuelve secretos temporales de corta duración (por ejemplo, válidos una hora). Son suficientes para que funcione la integración, y suelen expirar antes de ir a producción. Antes de ir live, los desarrolladores los reemplazan con secretos reales fuera del chat.

• Marcar explícitamente el límite seguro

  Advertimos claramente a los usuarios: no crees, pegues ni guardes secretos reales en el chat. También recordamos a los developers que incluso variables de entorno o archivos de config pueden filtrarse si una IA/LLM puede leerlas por herramientas o acceso indirecto. Pon los secretos reales solo en entornos sin integración con IA.

• No manejar secretos reales en el chat; guiar al usuario a la consola

  Los secretos duraderos no se generan ni distribuyen en el chat. Se crean y controlan en la página de credenciales de la consola. En el chat solo damos un link directo a la consola para completar ahí la configuración de secretos de producción.

Cómo diseñamos las herramientas MCP#

Nuestro camino#

Logto tiene una Management API completa. Nuestra primera idea fue simple: exponer cada endpoint como herramienta MCP.

Esto falló rápido.

Primero: explosión de contexto. Logto tiene muchas APIs. Mapear una a una llena el contexto. Cada descripción gasta tokens.

Segundo: se pierde el sentido. Las APIs son piezas atómicas para desarrolladores. Pero los usuarios del Logto MCP Server no construyen sistemas. Solo quieren terminar tareas. No les importan cuántas APIs existen.

Ejemplo: Logto tiene una API sign-in-experience para marca, métodos de inicio, registro y políticas de seguridad.
Al principio pensamos cómo exponer todos los parámetros a la LLM. Cómo enseñarle a combinar llamadas.

Pero ese es el enfoque equivocado. Los usuarios no llaman APIs. Solo quieren cambiar la marca o configurar métodos de acceso.

Así que las herramientas deben ser updateBranding, updateSignInMethod, updateSignUpMethod. El MCP server maneja la composición de APIs internamente.

Debemos ver Logto MCP Server como un producto, no como un wrapper de APIs. Es "otra consola de administración".

Cómo diseñar herramientas MCP#

La regla es clara:

• Si los usuarios usan directamente tu servicio (como una consola), las herramientas deben ser orientadas al negocio.
• Si das capacidades base para que otros construyan, las herramientas deben ser atómicas y simples. Ejemplo: un servidor MCP de archivos con read_file, write_file, luego los agentes combinan esas llamadas.

Principios adicionales:

• Mantén la lógica y descripción de cada herramienta simple para ahorrar contexto.
• Para workflows complejos, usa herramientas getInstructions para cargar la guía bajo demanda. Mantén sus descripciones simples también.

Nuestras expectativas para el futuro de MCP#

Mientras creábamos el servidor MCP, pensamos también qué podría mejorar en el ecosistema.

Entrega de capacidades a nivel Skill#

A veces los servidores MCP necesitan dar no solo herramientas, sino guías de cómo combinarlas en tareas, como Agent Skills.

Esto es común en SaaS: por ejemplo, GitHub MCP Server, Logto MCP Server o plataformas de analíticas. El usuario quiere workflows, no solo llamadas atómicas.

La herramienta getInstructions es un parche. Mejor si hubiera soporte a nivel de protocolo.

Activación MCP por sesión#

Los clientes se conectan a muchos MCP servers, pero no todas las sesiones los necesitan. Poder activar/desactivar por sesión ahorraría contexto.

Aislamiento de contexto en llamadas a herramientas MCP#

Las llamadas a herramientas consumen bastante contexto. Si las interacciones MCP son manejadas por subagentes, la conversación principal solo recibe el resumen.

Conclusión#

Esta es nuestra experiencia construyendo un servidor MCP remoto.

Si exploras este camino, prueba el Logto MCP Server o únete a nuestro Discord para compartir experiencias de implementación reales con la comunidad.

En futuros posts también compartiremos detalles sobre el diseño de arquitectura y el flujo de OAuth.