En pocas palabras: El dolor de MCP en producción no es de código: es OAuth 2.1 con PKCE (obligatorio desde la revisión de la spec de marzo de 2025), versionado del protocolo, observabilidad de logs y permisos de herramientas. La demo en localhost oculta load balancers, sesiones distribuidas y tokens que expiran.
Armás un servidor MCP, lo probás en tu máquina, anda perfecto. Lo conectás a ChatGPT en la demo y aplauden. Después lo mandás a producción y empieza el dolor: sesiones que se pierden, tokens que no validan, herramientas que se cuelgan y logs que no aparecen por ningún lado. Los problemas MCP ChatGPT producción casi nunca son de código: son de autenticación, versionado, observabilidad y permisos.
El Model Context Protocol (MCP) es un estándar abierto de Anthropic, presentado en noviembre de 2024, que define cómo un modelo de IA se conecta a herramientas, datos y APIs externas mediante JSON-RPC. Sirve para que clientes como ChatGPT o Claude Desktop invoquen funciones tuyas de forma estructurada. La especificación exige OAuth 2.1 con PKCE para autenticación, algo que rompió muchas integraciones armadas antes.
En 30 segundos
- La demo miente: localhost no tiene load balancers, sesiones distribuidas ni tokens que expiran. Producción sí.
- OAuth 2.1 con PKCE es obligatorio en MCP. Si tu server no valida el
auddel JWT, sos vulnerable al confused deputy. - ChatGPT congela un snapshot de tus herramientas cuando el admin aprueba la app. Los cambios no se aplican solos.
- Reportes de la comunidad señalan dos bugs que dejaron las MCP apps de ChatGPT “esencialmente inutilizables” tras un update de multi-step tool calls.
- La arquitectura segura es un gateway central con RBAC, no un monolito con una API key master.
¿Por qué mi servidor MCP funciona en desarrollo pero falla en producción?
Falla porque tu entorno local esconde todo lo difícil. En localhost la conexión es directa, la sesión vive en memoria y el token nunca expira porque lo generaste hace cinco minutos. En producción hay un load balancer que manda tu segundo request a otra instancia que no conoce tu sesión, el token de acceso caduca a mitad de una llamada larga y los logs se escriben en un contenedor que ya se recicló.
El MCP usa conexiones persistentes. Está bueno para latencia, pero cada conexión abierta consume memoria y file descriptors, y detrás de un balanceador esas conexiones se rebalancean y perdés estado.
Después está el tema de las herramientas de larga duración. Ponele que tu tool corre un query pesado que tarda 40 segundos. Para el usuario, ChatGPT parece colgado. No hay feedback, no hay progreso, solo un spinner. Y si el balanceador tiene un timeout de 30 segundos, la conexión se corta antes de que devuelvas nada. Cubrimos ese tema en detalle en Fundamentos de ChatGPT.
Reportes en el foro de la comunidad de OpenAI describen dos bugs que, según los desarrolladores afectados, dejaron las MCP apps “esencialmente inutilizables” para producción, incluido un update de ChatGPT que rompió las multi-step tool calls. ¿Alguien lo verificó de forma independiente y oficial? Todavía no del todo, así que tomalo con pinzas: es evidencia de la comunidad, no un comunicado.
¿Cómo autenticar correctamente un servidor MCP con ChatGPT?
Con OAuth 2.1 y PKCE, que es el estándar que la especificación MCP exige. El flujo es: el cliente pide un token de autorización, tu server valida contra el authorization server y emite un access token con scope limitado y duración corta. El cliente manda ese token en cada request, y vos lo verificás antes de ejecutar cualquier herramienta.
Acá conviene separar dos cosas que la gente mezcla:
- Autenticación es quién sos. El token demuestra que el usuario es quien dice ser. Nada más.
- Autorización es qué podés hacer. Que estés logueado no significa que puedas borrar la base de datos. El scope del token define el límite.
Lo recomendable es apoyarte en el proveedor de identidad de tu plataforma en vez de escribir tu propio manejo de tokens. La regla de oro: tokens de vida corta, refresh controlado, y nunca hardcodear credenciales en el código.
¿Qué es el ataque del “diputado confundido” y cómo prevenirlo?
El confused deputy (diputado confundido) es cuando engañan a tu servidor MCP para que use sus propios privilegios (más altos) en una acción que pidió el usuario. Tu server tiene acceso a toda una API. Un atacante hace que el server ejecute algo que el usuario no debería poder hacer, aprovechando que el server no distingue entre “el usuario está autenticado” y “el usuario está autorizado para esta acción puntual”.
Ponele el caso típico: tu server valida que el usuario tiene un token válido y de ahí asume que puede llamar cualquier endpoint de tu backend. Error. El usuario está logueado, sí, pero eso no autoriza toda tu API.
Hay tres defensas concretas contra este vector:
- Validá el claim
auddel JWT. El “audience” del token tiene que coincidir con el ID de tu server. Si un token fue emitido para otro servicio y llega al tuyo, rechazalo. - Nunca reenvíes el token OAuth al backend. El token que ChatGPT te manda es para vos, no para que lo pases aguas abajo. Usá credenciales propias del server hacia tu backend.
- Mínimo privilegio siempre. Que el server solo pueda hacer lo que necesita para su función, ni un permiso más.
¿Cómo loguear y monitorear un servidor MCP de forma segura?
Registrando tres cosas en cada invocación: qué herramienta se llamó, con qué parámetros y qué resultado devolvió. Sumale los intentos de autenticación fallidos y los patrones raros, tipo un mismo cliente probando credenciales en loop (credential stuffing). Sin eso, cuando algo se rompa en producción vas a estar debuggeando a ciegas. En Cómo funcionan estos modelos profundizamos sobre esto.
El problema que reportan las early implementations es justo ese: logs que desaparecían o que no escalaban con el volumen. Si tu server corre en un contenedor efímero y escribís a stdout sin centralizar, cada redeploy se lleva la evidencia.
Conviene centralizar todo en un SIEM o agregador de logs, y rotar de forma regular las credenciales guardadas en un gestor de secretos. Si necesitás alojar la infraestructura donde correr esos servers y su capa de observabilidad, en donweb.com tenés VPS y cloud en Argentina para montarlo cerca de tus usuarios.
¿Cuáles son los problemas de versionado en herramientas MCP?
El principal es que ChatGPT congela un snapshot de tus herramientas cuando el admin aprueba la app MCP, y los cambios posteriores no se aplican solos. El admin tiene que revisar y publicar cada actualización a mano.
Hay una diferencia clave entre tipos de cambio:
- Cambios retrocompatibles: agregar un parámetro opcional nuevo suele funcionar sin re-aprobación.
- Cambios que rompen compatibilidad: renombrar una tool, cambiar el tipo de un parámetro o sacar un campo requieren que el admin vuelva a aprobar.
Esto se cruza con el cambio de la especificación, cuando OAuth pasó a ser requisito más estricto. Servers que andaban con auth vieja de golpe dejaron de conectar hasta que los actualizaron. Si versionás tus herramientas de forma inmutable (cortás una versión, la activás, podés hacer rollback), evitás sorpresas. Plataformas de hosted MCP como Vectoralix ofrecen justo eso: cortar una versión inmutable, activarla y volver atrás cuando quieras.
¿Cómo gestionar permisos con el principio de mínimo privilegio?
Dándole a cada servidor MCP solo los permisos de su función específica, con tokens de scope mínimo y duración corta. Nada de API keys master con acceso total a todo.
El antipatrón clásico: un server de consulta de datos que además tiene acceso a los emails, las facturas y los logs del sistema, porque en el apuro le pusiste la credencial que ya tenías a mano. Si comprometen ese server, comprometen todo. Con scopes separados, el daño queda contenido.
La arquitectura recomendada es un gateway centralizado que refuerza RBAC e inspecciona cada invocación de herramienta. Vos no dejás que cada server hable directo con todo: pasás todo por un punto que aplica las reglas. Relacionado: Novedades en las últimas versiones.
¿Qué errores de diseño cometen los desarrolladores al crear servidores MCP?
El error más común es envolver un OpenAPI entero dentro de MCP y llamarlo servidor. Eso te deja con 50 herramientas chiquitas donde el modelo se pierde, en vez de 5 bien pensadas. Las tool descriptions no son documentación técnica: funcionan como prompts que el modelo lee para decidir cuándo usar cada herramienta. Si son confusas, el modelo elige mal.
Los otros clásicos que se ven una y otra vez:
- Validación solo en el cliente. Si confiás en que ChatGPT filtró los datos, cualquiera que hable directo con tu endpoint se saltea el control.
- Storage en memoria sin persistencia. Anda en la demo, se evapora en el primer redeploy.
- Cero observabilidad desde el arranque. Meter logs después de que se rompió todo es tarde.
¿Cuál es la arquitectura segura recomendada para MCP en producción?
Un gateway centralizado adelante de servers chicos y especializados. El gateway revisa una lista blanca de servidores MCP aprobados, centraliza autenticación y autorización, inspecciona todas las invocaciones y correlaciona con el comportamiento de identidad y el tráfico de red. Nada de servers monolíticos.
En transporte, TLS 1.2 o superior con suites fuertes hacia el cliente, y mTLS para las conexiones server a server. Así ningún componente confía en otro solo porque está en la misma red.
Comparativa: demo vs producción en MCP
| Dimensión | Demo (localhost) | Producción |
|---|---|---|
| Autenticación | Ninguna o token fijo | OAuth 2.1 + PKCE, tokens cortos |
| Sesiones | En memoria, una instancia | Distribuidas, detrás de load balancer |
| Logs | stdout local | SIEM / agregador central |
| Permisos | API key master | Scope mínimo por herramienta (RBAC) |
| Versionado | Cambio en caliente | Snapshot congelado, re-approval del admin |
| Herramientas largas | Esperás sin drama | Timeouts del balanceador cortan la conexión |
Qué está confirmado y qué no
- Confirmado: MCP es un estándar de Anthropic presentado en noviembre de 2024 (anuncio oficial).
- Confirmado: OAuth 2.1 con PKCE es requisito de la especificación.
- Confirmado: ChatGPT congela un snapshot de herramientas al aprobar la app, según la documentación de OpenAI.
- No confirmado del todo: los “dos bugs críticos” que dejarían las MCP apps inutilizables vienen de reportes de la comunidad, no de un comunicado oficial de OpenAI. Habría que ver si ya se resolvieron.
Errores comunes al llevar MCP a producción
- Asumir que el login autoriza todo. Autenticar no es autorizar. Validá el scope en cada acción, no solo la identidad.
- No validar el claim
auddel token. Sin esa verificación, un token emitido para otro servicio pasa por tu server y abrís la puerta al confused deputy. - Dejar los logs en el contenedor. Si no centralizás, el primer redeploy se lleva la única evidencia de qué salió mal.
- Cambiar herramientas sin avisar al admin. El snapshot congelado no se actualiza solo. Un cambio que rompe compatibilidad tira la integración hasta que alguien re-apruebe.
Preguntas Frecuentes
¿Qué es MCP y para qué sirve con ChatGPT?
MCP (Model Context Protocol) es un estándar abierto de Anthropic, presentado en noviembre de 2024, que define cómo un modelo de IA se conecta a herramientas y datos externos vía JSON-RPC. Con ChatGPT sirve para que el modelo invoque funciones tuyas (consultar una base, ejecutar código, llamar una API) de forma estructurada y segura.
¿Por qué OAuth 2.1 es obligatorio en MCP?
Porque la especificación MCP lo exige para asegurar la autenticación entre cliente y servidor. Usa PKCE para proteger el intercambio de tokens y define scopes que limitan qué puede hacer cada token, reduciendo el riesgo de accesos no autorizados. Más contexto en Integración de herramientas externas.
¿Cómo evito el ataque del diputado confundido?
Validando que el claim aud del JWT coincida con el ID de tu servidor, nunca reenviando el token OAuth al backend y aplicando mínimo privilegio. Así tu server no usa sus permisos altos para ejecutar acciones que el usuario no debería poder hacer.
¿Se actualizan solas las herramientas MCP en ChatGPT?
No. ChatGPT congela un snapshot de las herramientas cuando el admin aprueba la app. Los cambios retrocompatibles (un parámetro opcional nuevo) suelen andar, pero cualquier cambio que rompa compatibilidad requiere que el admin revise y vuelva a publicar la actualización.
¿Dónde conviene alojar un servidor MCP de producción?
En infraestructura con conexiones persistentes estables, TLS fuerte y logs centralizados. Podés usar un VPS o cloud propio para tener control total del entorno, o una plataforma de hosted MCP como Vectoralix si preferís no manejar el transporte ni el JSON-RPC. Para hosting en Argentina, donweb.com cubre VPS y cloud.
Conclusión
La demo de MCP con ChatGPT es fácil. Producción es otra cosa, y lo que te rompe no es el protocolo sino lo de siempre: autenticación floja, permisos demasiado amplios, versionado que no controlás y cero observabilidad. La especificación ya te empuja en la dirección correcta con OAuth 2.1 y PKCE, pero el confused deputy sigue vivo si no validás el aud del token.
Si vas a llevar un server MCP a producción, arrancá por tres cosas: gateway central con RBAC, tokens de scope mínimo y logs centralizados desde el día uno. Servers chicos y especializados, no un monolito con una API key que abre todo. Y ojo con los reportes de bugs de la comunidad: verificá con tu propia integración antes de asumir que algo anda o no anda.