[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-mcp-produccion-transport-auth-scaling-desafios":3},{"article":4,"author":55},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":16,"meta_description":17,"focus_keyword":18,"og_image":19,"canonical_url":19,"robots_meta":20,"created_at":15,"updated_at":15,"tags":21,"category_name":35,"related_articles":36},"d0000000-0000-0000-0000-000000000520","a0000000-0000-0000-0000-000000000086","MCP en produccion: resolver desafios de transport, auth y scaling","mcp-produccion-transport-auth-scaling-desafios","Una guia detallada sobre la operacion de servidores Model Context Protocol en produccion — seleccion de transporte, patrones de autenticacion, estrategias de escalado, registro de auditoria y arquitecturas de gateway para despliegues empresariales.","## Del prototipo a produccion: que cambia\n\nConstruir un servidor MCP que funcione en tu portatil es relativamente sencillo. Operar uno que maneje miles de sesiones de agentes AI concurrentes a traves de una infraestructura distribuida es un desafio de ingenieria completamente diferente. Los despliegues MCP en produccion deben abordar cinco preocupaciones que los prototipos pueden ignorar: **escalabilidad del transporte**, **autenticacion y autorizacion**, **gestion de sesiones a escala**, **pistas de auditoria** y **orquestacion multi-servidor**.\n\nEste articulo es una guia tecnica para equipos de ingenieria que estan trasladando servidores MCP del desarrollo a produccion. Asumimos que has construido al menos un servidor MCP y comprendes los fundamentos del protocolo. Si no, comienza con nuestro articulo sobre como construir tu primer servidor MCP.\n\n## Escalabilidad del transporte: stdio vs SSE vs Streamable HTTP\n\nMCP define tres mecanismos de transporte. Elegir el adecuado para produccion es tu primera decision arquitectonica.\n\n### Transporte stdio\n\nEl transporte stdio se comunica a traves de flujos de entrada\u002Fsalida estandar. La aplicacion Host lanza el servidor MCP como un proceso hijo e intercambia mensajes JSON-RPC a traves de stdin\u002Fstdout.\n\n**Ventajas:**\n- Cero configuracion de red\n- Aislamiento a nivel de proceso\n- Sin conflictos de puertos\n- Latencia mas baja (sin pila de red)\n\n**Limitaciones:**\n- El servidor debe ejecutarse en la misma maquina que el Host\n- Un proceso de servidor por sesion de Client\n- Sin balanceo de carga\n- Sin escalado horizontal\n\n**Ideal para:** Herramientas de desarrollo local, extensiones de IDE, aplicaciones de escritorio de un solo usuario.\n\n### Transporte SSE (Server-Sent Events)\n\nEl transporte SSE utiliza HTTP para mensajes de cliente a servidor y Server-Sent Events para mensajes de servidor a cliente. El servidor funciona como un servicio HTTP.\n\n**Ventajas:**\n- Accesible a traves de la red (servidor remoto)\n- Compatible con infraestructura HTTP existente\n- Soporta multiples clientes simultaneos\n- Funciona a traves de firewalls y proxies\n\n**Limitaciones:**\n- Streaming unidireccional (SSE solo de servidor a cliente)\n- Requiere afinidad de sesion (conexion stateful)\n- Algunos balanceadores de carga tienen problemas con conexiones SSE de larga duracion\n- Sin semantica de reconexion incorporada en el protocolo\n\n**Ideal para:** Despliegues de pequena a mediana escala, herramientas internas, equipos con infraestructura HTTP existente.\n\n### Transporte Streamable HTTP\n\nStreamable HTTP es el transporte mas reciente, disenado especificamente para despliegues en produccion. Utiliza POST HTTP estandar para todos los mensajes, con streaming SSE opcional para operaciones de larga duracion.\n\n**Ventajas:**\n- Modelo request\u002Fresponse completamente stateless\n- Funciona con cualquier balanceador de carga HTTP\n- Gestion de sesiones incorporada a traves del header `Mcp-Session-Id`\n- Soporta respuestas streaming y no-streaming\n- Compatible con CDN y proxies\n\n**Limitaciones:**\n- Requiere almacenamiento de sesiones del lado del servidor (Redis, base de datos)\n- Overhead por mensaje ligeramente mayor que stdio\n- Transporte mas nuevo — menos herramientas en el ecosistema\n\n**Ideal para:** Despliegues cloud en produccion, plataformas multi-tenant, entornos empresariales.\n\n### Matriz de comparacion de transportes\n\n| Caracteristica | stdio | SSE | Streamable HTTP |\n|---------------|-------|-----|-----------------|\n| Soporte de red | No | Si | Si |\n| Escalado horizontal | No | Limitado | Si |\n| Balanceo de carga | No | Afinidad de sesion requerida | LB HTTP estandar |\n| Gestion de sesiones | Por proceso | Memoria del servidor | Store externo |\n| Latencia | La mas baja | Baja | Baja |\n| Compatible con firewall | N\u002FA | Si | Si |\n\n## Autenticacion y autorizacion\n\n### Integracion OAuth 2.0\n\nLos servidores MCP en produccion necesitan una forma para que los clientes se autentiquen y restrinjan el acceso a tools y resources especificos. El protocolo MCP soporta OAuth 2.0 para servidores remotos.\n\nEl flujo funciona asi:\n\n1. El MCP client se conecta al servidor y envia una solicitud `initialize`\n2. El servidor responde con `401 Unauthorized` y un header `WWW-Authenticate` con la URL de metadatos OAuth\n3. El Client obtiene la configuracion OAuth desde `\u002F.well-known\u002Foauth-authorization-server`\n4. El Client obtiene un token de acceso mediante un flujo de autorizacion basado en navegador\n5. Las solicitudes posteriores incluyen el token Bearer en el header `Authorization`\n\n### Autorizacion a nivel de tool\n\nLa autenticacion sola no es suficiente. Los sistemas de produccion necesitan autorizacion granular que controle que tools puede llamar un usuario y a que resources puede acceder.\n\nEnfoques recomendados:\n\n- **Control de acceso basado en roles (RBAC)**: Asignar permisos de tools a roles. Ejemplo: el rol `analyst` accede a tools de consulta de solo lectura, el rol `admin` accede a operaciones de escritura.\n- **Control basado en scopes**: Usar scopes OAuth para limitar el acceso a tools. Ejemplo: el scope `mcp:tools:query:read` solo permite consultas SELECT.\n- **Filtrado dinamico de tools**: Filtrar la lista de tools disponibles basandose en los permisos del usuario autenticado.\n\n## Escalado horizontal con Redis\n\nUsando el transporte Streamable HTTP stateless, puedes ejecutar multiples instancias de servidor MCP detras de un balanceador de carga. El estado de sesion se almacena en Redis y se comparte entre todas las instancias.\n\n```\nClient → Load Balancer → MCP Server 1 ↔ Redis\n                       → MCP Server 2 ↔ Redis\n                       → MCP Server 3 ↔ Redis\n```\n\nCada solicitud incluye el header `Mcp-Session-Id`, y cualquier instancia del servidor puede obtener el estado de sesion de Redis para continuar el procesamiento.\n\n### Auto-scaling en Kubernetes\n\nDesplegar servidores MCP en Kubernetes permite escalar automaticamente los Pods basandose en el numero de sesiones activas o la utilizacion de CPU. Usa metricas personalizadas con el Horizontal Pod Autoscaler (HPA).\n\n## Registro de auditoria\n\nLos despliegues empresariales requieren pistas de auditoria detalladas cada vez que una AI llama a una herramienta externa. Para cada llamada a un tool, registra:\n\n- **Marca de tiempo**: Hora de la llamada\n- **ID de usuario**: El usuario que inicio la accion de AI\n- **Nombre del tool**: El tool MCP llamado\n- **Parametros de entrada**: Los datos enviados al tool\n- **Resultado**: Los datos devueltos por el tool\n- **Duracion de ejecucion**: El tiempo que tomo la llamada\n- **Errores**: Cualquier error ocurrido\n\nUsa registro estructurado (formato JSON) y envia los logs a un sistema centralizado de gestion de logs (ELK Stack, Datadog, CloudWatch).\n\n## Arquitectura de gateway\n\nPara despliegues a gran escala, considera implementar un patron de gateway MCP. El gateway actua como un proxy inverso entre los MCP clients y los servidores MCP backend.\n\nResponsabilidades del gateway:\n\n- **Centralizacion de autenticacion**: Manejar toda la validacion OAuth en el gateway\n- **Limitacion de velocidad**: Aplicar limites por usuario y por tool\n- **Enrutamiento**: Enrutar solicitudes a los servidores backend apropiados basandose en el nombre del tool\n- **Recopilacion de logs de auditoria**: Registrar todas las llamadas a tools a nivel de gateway\n- **Circuit breaker**: Manejo de fallback cuando los servidores backend fallan\n\n## FAQ\n\n**P: Se puede usar el transporte stdio en produccion?**\nR: Si, pero solo en escenarios limitados. Es adecuado para aplicaciones de escritorio donde cada usuario ejecuta su propio proceso de servidor MCP local. Para infraestructura de servidor compartida, usa Streamable HTTP.\n\n**P: Es necesario persistir las sesiones MCP?**\nR: Si, al usar Streamable HTTP. El estado de sesion incluye las capacidades del cliente, la version del protocolo negociada y las notificaciones registradas. Redis es el almacen de sesiones recomendado.\n\n**P: Como se debe versionar los servidores MCP?**\nR: Usa el campo de version del servidor en la respuesta `initialize`. Para cambios incompatibles (eliminacion de tools, cambios de esquema), incrementa la version mayor y soporta tanto la version antigua como la nueva durante un periodo de migracion.\n\n**P: Cual es el tamano maximo de mensaje para MCP?**\nR: El protocolo no define un maximo, pero los limites practicos dependen del transporte. Para Streamable HTTP, manten las respuestas por debajo de 10 MB. Para stdio, los buffers de pipes del sistema (tipicamente 64 KB) pueden requerir chunking para respuestas grandes.","\u003Ch2 id=\"del-prototipo-a-produccion-que-cambia\">Del prototipo a produccion: que cambia\u003C\u002Fh2>\n\u003Cp>Construir un servidor MCP que funcione en tu portatil es relativamente sencillo. Operar uno que maneje miles de sesiones de agentes AI concurrentes a traves de una infraestructura distribuida es un desafio de ingenieria completamente diferente. Los despliegues MCP en produccion deben abordar cinco preocupaciones que los prototipos pueden ignorar: \u003Cstrong>escalabilidad del transporte\u003C\u002Fstrong>, \u003Cstrong>autenticacion y autorizacion\u003C\u002Fstrong>, \u003Cstrong>gestion de sesiones a escala\u003C\u002Fstrong>, \u003Cstrong>pistas de auditoria\u003C\u002Fstrong> y \u003Cstrong>orquestacion multi-servidor\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>Este articulo es una guia tecnica para equipos de ingenieria que estan trasladando servidores MCP del desarrollo a produccion. Asumimos que has construido al menos un servidor MCP y comprendes los fundamentos del protocolo. Si no, comienza con nuestro articulo sobre como construir tu primer servidor MCP.\u003C\u002Fp>\n\u003Ch2 id=\"escalabilidad-del-transporte-stdio-vs-sse-vs-streamable-http\">Escalabilidad del transporte: stdio vs SSE vs Streamable HTTP\u003C\u002Fh2>\n\u003Cp>MCP define tres mecanismos de transporte. Elegir el adecuado para produccion es tu primera decision arquitectonica.\u003C\u002Fp>\n\u003Ch3>Transporte stdio\u003C\u002Fh3>\n\u003Cp>El transporte stdio se comunica a traves de flujos de entrada\u002Fsalida estandar. La aplicacion Host lanza el servidor MCP como un proceso hijo e intercambia mensajes JSON-RPC a traves de stdin\u002Fstdout.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Ventajas:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Cero configuracion de red\u003C\u002Fli>\n\u003Cli>Aislamiento a nivel de proceso\u003C\u002Fli>\n\u003Cli>Sin conflictos de puertos\u003C\u002Fli>\n\u003Cli>Latencia mas baja (sin pila de red)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Limitaciones:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>El servidor debe ejecutarse en la misma maquina que el Host\u003C\u002Fli>\n\u003Cli>Un proceso de servidor por sesion de Client\u003C\u002Fli>\n\u003Cli>Sin balanceo de carga\u003C\u002Fli>\n\u003Cli>Sin escalado horizontal\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Ideal para:\u003C\u002Fstrong> Herramientas de desarrollo local, extensiones de IDE, aplicaciones de escritorio de un solo usuario.\u003C\u002Fp>\n\u003Ch3>Transporte SSE (Server-Sent Events)\u003C\u002Fh3>\n\u003Cp>El transporte SSE utiliza HTTP para mensajes de cliente a servidor y Server-Sent Events para mensajes de servidor a cliente. El servidor funciona como un servicio HTTP.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Ventajas:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Accesible a traves de la red (servidor remoto)\u003C\u002Fli>\n\u003Cli>Compatible con infraestructura HTTP existente\u003C\u002Fli>\n\u003Cli>Soporta multiples clientes simultaneos\u003C\u002Fli>\n\u003Cli>Funciona a traves de firewalls y proxies\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Limitaciones:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Streaming unidireccional (SSE solo de servidor a cliente)\u003C\u002Fli>\n\u003Cli>Requiere afinidad de sesion (conexion stateful)\u003C\u002Fli>\n\u003Cli>Algunos balanceadores de carga tienen problemas con conexiones SSE de larga duracion\u003C\u002Fli>\n\u003Cli>Sin semantica de reconexion incorporada en el protocolo\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Ideal para:\u003C\u002Fstrong> Despliegues de pequena a mediana escala, herramientas internas, equipos con infraestructura HTTP existente.\u003C\u002Fp>\n\u003Ch3>Transporte Streamable HTTP\u003C\u002Fh3>\n\u003Cp>Streamable HTTP es el transporte mas reciente, disenado especificamente para despliegues en produccion. Utiliza POST HTTP estandar para todos los mensajes, con streaming SSE opcional para operaciones de larga duracion.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Ventajas:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Modelo request\u002Fresponse completamente stateless\u003C\u002Fli>\n\u003Cli>Funciona con cualquier balanceador de carga HTTP\u003C\u002Fli>\n\u003Cli>Gestion de sesiones incorporada a traves del header \u003Ccode>Mcp-Session-Id\u003C\u002Fcode>\u003C\u002Fli>\n\u003Cli>Soporta respuestas streaming y no-streaming\u003C\u002Fli>\n\u003Cli>Compatible con CDN y proxies\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Limitaciones:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Requiere almacenamiento de sesiones del lado del servidor (Redis, base de datos)\u003C\u002Fli>\n\u003Cli>Overhead por mensaje ligeramente mayor que stdio\u003C\u002Fli>\n\u003Cli>Transporte mas nuevo — menos herramientas en el ecosistema\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Ideal para:\u003C\u002Fstrong> Despliegues cloud en produccion, plataformas multi-tenant, entornos empresariales.\u003C\u002Fp>\n\u003Ch3>Matriz de comparacion de transportes\u003C\u002Fh3>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Caracteristica\u003C\u002Fth>\u003Cth>stdio\u003C\u002Fth>\u003Cth>SSE\u003C\u002Fth>\u003Cth>Streamable HTTP\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Soporte de red\u003C\u002Ftd>\u003Ctd>No\u003C\u002Ftd>\u003Ctd>Si\u003C\u002Ftd>\u003Ctd>Si\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Escalado horizontal\u003C\u002Ftd>\u003Ctd>No\u003C\u002Ftd>\u003Ctd>Limitado\u003C\u002Ftd>\u003Ctd>Si\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Balanceo de carga\u003C\u002Ftd>\u003Ctd>No\u003C\u002Ftd>\u003Ctd>Afinidad de sesion requerida\u003C\u002Ftd>\u003Ctd>LB HTTP estandar\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Gestion de sesiones\u003C\u002Ftd>\u003Ctd>Por proceso\u003C\u002Ftd>\u003Ctd>Memoria del servidor\u003C\u002Ftd>\u003Ctd>Store externo\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Latencia\u003C\u002Ftd>\u003Ctd>La mas baja\u003C\u002Ftd>\u003Ctd>Baja\u003C\u002Ftd>\u003Ctd>Baja\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Compatible con firewall\u003C\u002Ftd>\u003Ctd>N\u002FA\u003C\u002Ftd>\u003Ctd>Si\u003C\u002Ftd>\u003Ctd>Si\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch2 id=\"autenticacion-y-autorizacion\">Autenticacion y autorizacion\u003C\u002Fh2>\n\u003Ch3>Integracion OAuth 2.0\u003C\u002Fh3>\n\u003Cp>Los servidores MCP en produccion necesitan una forma para que los clientes se autentiquen y restrinjan el acceso a tools y resources especificos. El protocolo MCP soporta OAuth 2.0 para servidores remotos.\u003C\u002Fp>\n\u003Cp>El flujo funciona asi:\u003C\u002Fp>\n\u003Col>\n\u003Cli>El MCP client se conecta al servidor y envia una solicitud \u003Ccode>initialize\u003C\u002Fcode>\u003C\u002Fli>\n\u003Cli>El servidor responde con \u003Ccode>401 Unauthorized\u003C\u002Fcode> y un header \u003Ccode>WWW-Authenticate\u003C\u002Fcode> con la URL de metadatos OAuth\u003C\u002Fli>\n\u003Cli>El Client obtiene la configuracion OAuth desde \u003Ccode>\u002F.well-known\u002Foauth-authorization-server\u003C\u002Fcode>\u003C\u002Fli>\n\u003Cli>El Client obtiene un token de acceso mediante un flujo de autorizacion basado en navegador\u003C\u002Fli>\n\u003Cli>Las solicitudes posteriores incluyen el token Bearer en el header \u003Ccode>Authorization\u003C\u002Fcode>\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch3>Autorizacion a nivel de tool\u003C\u002Fh3>\n\u003Cp>La autenticacion sola no es suficiente. Los sistemas de produccion necesitan autorizacion granular que controle que tools puede llamar un usuario y a que resources puede acceder.\u003C\u002Fp>\n\u003Cp>Enfoques recomendados:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Control de acceso basado en roles (RBAC)\u003C\u002Fstrong>: Asignar permisos de tools a roles. Ejemplo: el rol \u003Ccode>analyst\u003C\u002Fcode> accede a tools de consulta de solo lectura, el rol \u003Ccode>admin\u003C\u002Fcode> accede a operaciones de escritura.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Control basado en scopes\u003C\u002Fstrong>: Usar scopes OAuth para limitar el acceso a tools. Ejemplo: el scope \u003Ccode>mcp:tools:query:read\u003C\u002Fcode> solo permite consultas SELECT.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Filtrado dinamico de tools\u003C\u002Fstrong>: Filtrar la lista de tools disponibles basandose en los permisos del usuario autenticado.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"escalado-horizontal-con-redis\">Escalado horizontal con Redis\u003C\u002Fh2>\n\u003Cp>Usando el transporte Streamable HTTP stateless, puedes ejecutar multiples instancias de servidor MCP detras de un balanceador de carga. El estado de sesion se almacena en Redis y se comparte entre todas las instancias.\u003C\u002Fp>\n\u003Cpre>\u003Ccode>Client → Load Balancer → MCP Server 1 ↔ Redis\n                       → MCP Server 2 ↔ Redis\n                       → MCP Server 3 ↔ Redis\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Cada solicitud incluye el header \u003Ccode>Mcp-Session-Id\u003C\u002Fcode>, y cualquier instancia del servidor puede obtener el estado de sesion de Redis para continuar el procesamiento.\u003C\u002Fp>\n\u003Ch3>Auto-scaling en Kubernetes\u003C\u002Fh3>\n\u003Cp>Desplegar servidores MCP en Kubernetes permite escalar automaticamente los Pods basandose en el numero de sesiones activas o la utilizacion de CPU. Usa metricas personalizadas con el Horizontal Pod Autoscaler (HPA).\u003C\u002Fp>\n\u003Ch2 id=\"registro-de-auditoria\">Registro de auditoria\u003C\u002Fh2>\n\u003Cp>Los despliegues empresariales requieren pistas de auditoria detalladas cada vez que una AI llama a una herramienta externa. Para cada llamada a un tool, registra:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Marca de tiempo\u003C\u002Fstrong>: Hora de la llamada\u003C\u002Fli>\n\u003Cli>\u003Cstrong>ID de usuario\u003C\u002Fstrong>: El usuario que inicio la accion de AI\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Nombre del tool\u003C\u002Fstrong>: El tool MCP llamado\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Parametros de entrada\u003C\u002Fstrong>: Los datos enviados al tool\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Resultado\u003C\u002Fstrong>: Los datos devueltos por el tool\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Duracion de ejecucion\u003C\u002Fstrong>: El tiempo que tomo la llamada\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Errores\u003C\u002Fstrong>: Cualquier error ocurrido\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Usa registro estructurado (formato JSON) y envia los logs a un sistema centralizado de gestion de logs (ELK Stack, Datadog, CloudWatch).\u003C\u002Fp>\n\u003Ch2 id=\"arquitectura-de-gateway\">Arquitectura de gateway\u003C\u002Fh2>\n\u003Cp>Para despliegues a gran escala, considera implementar un patron de gateway MCP. El gateway actua como un proxy inverso entre los MCP clients y los servidores MCP backend.\u003C\u002Fp>\n\u003Cp>Responsabilidades del gateway:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Centralizacion de autenticacion\u003C\u002Fstrong>: Manejar toda la validacion OAuth en el gateway\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Limitacion de velocidad\u003C\u002Fstrong>: Aplicar limites por usuario y por tool\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Enrutamiento\u003C\u002Fstrong>: Enrutar solicitudes a los servidores backend apropiados basandose en el nombre del tool\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Recopilacion de logs de auditoria\u003C\u002Fstrong>: Registrar todas las llamadas a tools a nivel de gateway\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Circuit breaker\u003C\u002Fstrong>: Manejo de fallback cuando los servidores backend fallan\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"faq\">FAQ\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>P: Se puede usar el transporte stdio en produccion?\u003C\u002Fstrong>\nR: Si, pero solo en escenarios limitados. Es adecuado para aplicaciones de escritorio donde cada usuario ejecuta su propio proceso de servidor MCP local. Para infraestructura de servidor compartida, usa Streamable HTTP.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>P: Es necesario persistir las sesiones MCP?\u003C\u002Fstrong>\nR: Si, al usar Streamable HTTP. El estado de sesion incluye las capacidades del cliente, la version del protocolo negociada y las notificaciones registradas. Redis es el almacen de sesiones recomendado.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>P: Como se debe versionar los servidores MCP?\u003C\u002Fstrong>\nR: Usa el campo de version del servidor en la respuesta \u003Ccode>initialize\u003C\u002Fcode>. Para cambios incompatibles (eliminacion de tools, cambios de esquema), incrementa la version mayor y soporta tanto la version antigua como la nueva durante un periodo de migracion.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>P: Cual es el tamano maximo de mensaje para MCP?\u003C\u002Fstrong>\nR: El protocolo no define un maximo, pero los limites practicos dependen del transporte. Para Streamable HTTP, manten las respuestas por debajo de 10 MB. Para stdio, los buffers de pipes del sistema (tipicamente 64 KB) pueden requerir chunking para respuestas grandes.\u003C\u002Fp>\n","es","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:39.538923Z","MCP en produccion: transport, auth y desafios de scaling","Guia tecnica para operar servidores MCP en produccion. Cubre seleccion de transporte, autenticacion OAuth, escalado horizontal con sesiones Redis, registro de auditoria y patrones de gateway.","mcp produccion escalado",null,"index, follow",[22,27,31],{"id":23,"name":24,"slug":25,"created_at":26},"c0000000-0000-0000-0000-000000000008","AI","ai","2026-03-28T10:44:21.513630Z",{"id":28,"name":29,"slug":30,"created_at":26},"c0000000-0000-0000-0000-000000000012","DevOps","devops",{"id":32,"name":33,"slug":34,"created_at":26},"c0000000-0000-0000-0000-000000000013","Security","security","Ingeniería",[37,43,49],{"id":38,"title":39,"slug":40,"excerpt":41,"locale":12,"category_name":35,"published_at":42},"d0000000-0000-0000-0000-000000000683","Por qué Bali se está convirtiendo en el hub de impact-tech del Sudeste Asiático en 2026","por-que-bali-hub-impact-tech-sudeste-asiatico-2026","Bali ocupa el puesto 16 entre los ecosistemas startup del Sudeste Asiático. Con una concentración creciente de constructores Web3, startups de AI sostenible y empresas de eco-travel tech, la isla se consolida como capital de impact-tech de la región.","2026-03-28T10:44:49.926489Z",{"id":44,"title":45,"slug":46,"excerpt":47,"locale":12,"category_name":35,"published_at":48},"d0000000-0000-0000-0000-000000000682","El mosaico de protección de datos de ASEAN: checklist de cumplimiento para desarrolladores","mosaico-proteccion-datos-asean-checklist-cumplimiento-desarrolladores","Siete países de ASEAN tienen ahora leyes integrales de protección de datos, cada una con diferentes modelos de consentimiento, requisitos de localización y estructuras de sanciones. Un checklist práctico de cumplimiento para desarrolladores.","2026-03-28T10:44:49.919345Z",{"id":50,"title":51,"slug":52,"excerpt":53,"locale":12,"category_name":35,"published_at":54},"d0000000-0000-0000-0000-000000000681","La transformación digital de 29 mil millones de dólares de Indonesia: oportunidades para empresas de software","transformacion-digital-29-mil-millones-dolares-indonesia-oportunidades-empresas-software","El mercado de servicios IT de Indonesia alcanzará los 29.030 millones de dólares en 2026, frente a los 24.370 millones de 2025. La infraestructura cloud, la AI, el comercio electrónico y los centros de datos impulsan el crecimiento más rápido del Sudeste Asiático.","2026-03-28T10:44:49.897658Z",{"id":13,"name":56,"slug":57,"bio":58,"photo_url":19,"linkedin":19,"role":59,"created_at":60,"updated_at":60},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]