El alojamiento de servidores MCP de ChatGPT lleva el despliegue a Sites, pero el acceso sigue marcando el límite

ChatGPT ahora admite un flujo de trabajo de servidor MCP de ChatGPT que permite crear, alojar y desplegar herramientas mediante Sites, sin necesidad de un proveedor de alojamiento independiente. El cambio elimina una de las mayores barreras prácticas en torno al Model Context Protocol, o MCP, que permite a los clientes de IA invocar herramientas externas a través de una interfaz compartida.

Una publicación pública de Tibo Thibault destacó la función el 1 de octubre de 2026. La documentación actual de OpenAI confirma el flujo de trabajo subyacente. Un usuario puede pedir a ChatGPT o Codex que añada un servidor MCP a un Site, publicarlo e instalar el plugin resultante.

Esto hace que el anuncio sea más relevante que otra actualización de un creador de sitios web. Hasta ahora, un servidor MCP de ChatGPT típico requería código, un endpoint accesible desde internet, infraestructura de despliegue y un proceso de conexión independiente. Sites integra varios de esos pasos en un único entorno conversacional.

Por tanto, la competencia importante no es ChatGPT frente a otro modelo. Es el despliegue gestionado e impulsado por prompts frente a la ruta MCP convencional autohospedada. OpenAI ha acortado el camino desde una idea hasta una herramienta instalada, pero los permisos, las pruebas y la distribución siguen determinando si esa herramienta es útil.

Qué cambió con el alojamiento de servidores MCP de ChatGPT

ChatGPT Sites ahora puede actuar tanto como superficie de aplicación como host para herramientas MCP utilizadas mediante un plugin.

ChatGPT Sites es el entorno de OpenAI para crear y publicar sitios web interactivos y aplicaciones ligeras. Los usuarios describen lo que quieren, revisan una vista previa generada, solicitan modificaciones y despliegan el resultado en una URL de Site.

El nuevo elemento es la posibilidad de añadir herramientas del lado del servidor a ese Site. La guía de Sites de OpenAI indica que los usuarios pueden pedir a ChatGPT o Codex que añada un servidor MCP a un Site nuevo o existente. Deben describir la información que esas herramientas pueden leer y los cambios que pueden realizar.

MCP es un protocolo para exponer herramientas y datos a clientes de IA compatibles. El servidor describe las operaciones disponibles, sus entradas y sus salidas. ChatGPT puede entonces llamar a esas operaciones cuando un usuario realiza una solicitud pertinente.

El propietario de un Site podría crear, por ejemplo, un panel de proyecto y añadir herramientas para consultar hitos y actualizar su estado. Al publicar el Site se crea un plugin asociado que expone esas herramientas en conversaciones compatibles de ChatGPT y Codex.

Esta secuencia condensa varias tareas que antes estaban separadas:

• El usuario define el flujo de trabajo deseado en una conversación.

• ChatGPT o Codex crean el Site y sus herramientas MCP.

• El propietario revisa el Site y prueba su comportamiento.

• La publicación genera un Site activo y su plugin asociado.

• El usuario instala y conecta ese plugin.

• ChatGPT puede invocar sus herramientas en conversaciones posteriores.

El Site sigue siendo más que una interfaz estática. Puede almacenar información, presentar una vista interactiva y proporcionar las operaciones expuestas mediante MCP. El ejemplo de OpenAI describe un manual de equipo con herramientas para buscar y acceder a sus contenidos.

Este patrón también se adapta a rastreadores de proyectos, directorios internos, calendarios de lanzamientos, buscadores de documentos y paneles operativos. Un equipo podría combinar este enfoque con una base de conocimientos con búsqueda, siempre que sus datos y permisos se diseñen cuidadosamente.

El propietario debe publicar el Site antes de que aparezca el plugin asociado. Añadir o modificar herramientas también requiere otra publicación antes de que esos cambios estén disponibles. Un borrador guardado no altera silenciosamente el plugin activo.

OpenAI describe Sites como una beta pública. Está disponible para espacios de trabajo de ChatGPT, cuentas Plus y cuentas Pro, aunque el despliegue puede no llegar a todas las cuentas al mismo tiempo. Los administradores de espacios de trabajo pueden controlar los derechos de creación y publicación.

La URL de despliegue es una URL de producción. OpenAI aconseja a los creadores guardar una versión y revisar los cambios antes del despliegue. Esta distinción importa porque la edición conversacional puede parecer informal incluso cuando el software resultante tiene usuarios activos.

El resultado es una ruta de despliegue notablemente más corta. No elimina las operaciones de software, pero traslada muchas de ellas a un producto gestionado y a un flujo de trabajo conversacional.

Por qué el despliegue impulsado por prompts presiona a la ruta autohospedada

Sites convierte el despliegue de MCP, para muchos flujos de trabajo más pequeños, de un proyecto de infraestructura en una tarea de configuración de producto.

Un despliegue MCP remoto convencional sigue requiriendo un servidor funcional al que ChatGPT pueda acceder por internet público. El desarrollador debe implementar herramientas, exponer un endpoint HTTPS, configurar la autenticación y mantener el servicio disponible.

El inicio rápido de MCP de OpenAI ilustra esa ruta. Los desarrolladores instalan un kit de desarrollo de software MCP, crean un servidor, exponen un endpoint /mcp y conectan la URL pública mediante los controles de desarrollador de ChatGPT.

Esa sigue siendo la ruta adecuada cuando un equipo necesita infraestructura personalizada, integraciones complejas, escalado independiente o control sobre el entorno de ejecución. También otorga a los desarrolladores autoridad directa sobre los calendarios de despliegue, los registros, las redes y el almacenamiento de datos.

Sin embargo, muchas herramientas internas no comienzan con esos requisitos. Empiezan como solicitudes acotadas, como buscar en un manual, actualizar un hito o recuperar un registro de proyecto. El trabajo de infraestructura puede superar el alcance funcional de la primera versión.

ChatGPT Sites se dirige a esa brecha. Un usuario puede describir el Site, sus datos y las operaciones que ChatGPT debe realizar. Codex puede entonces generar la capa de herramientas necesaria y conectarla a un plugin instalable.

Esto no vuelve irrelevantes los conocimientos de ingeniería. Cambia el punto en el que esos conocimientos se vuelven necesarios.

La primera versión puede surgir mediante una creación guiada en lugar de una pila de despliegue montada manualmente. La atención de ingeniería puede centrarse en los límites de las herramientas, la autorización, el manejo de errores y la calidad de los datos.

Ese es el cambio central. MCP fue diseñado para estandarizar conexiones, pero operar un servidor seguía generando fricción para quienes solo querían un flujo de trabajo específico. OpenAI ahora utiliza un host gestionado para reducir esa carga operativa.

La presión afecta primero a los patrones de alojamiento ligeros y a los prototipos internos. Es posible que un desarrollador ya no necesite un proyecto en la nube independiente solo para comprobar si un flujo de trabajo de tres herramientas resuelve un problema real.

La presión también alcanza a los creadores de IA sin código y de bajo código. ChatGPT conecta ahora la especificación conversacional, la generación de aplicaciones, el alojamiento y la instalación de plugins dentro de un único entorno de cuenta. Esto reduce la distancia entre un prototipo y una herramienta de ChatGPT utilizable.

Sin embargo, el autoalojamiento conserva ventajas importantes. Un Site gestionado no ofrece automáticamente la flexibilidad de despliegue, la observabilidad, la portabilidad ni la capacidad que exige todo sistema de producción.

OpenAI también aplica límites de uso específicos por plan durante la beta pública. Esos límites abarcan Sites en toda una cuenta y pueden afectar la capacidad de crear Sites, añadir almacenamiento o mantener un Site con mucho tráfico disponible públicamente.

La documentación indica a los usuarios que consulten los límites mostrados en su cuenta. No proporciona una capacidad fija que se aplique universalmente.

Esa incertidumbre impide concluir de forma simple que Sites sustituya al alojamiento MCP convencional. En cambio, crea una opción gestionada predeterminada para despliegues más pequeños o en fases iniciales.

Los desarrolladores deberían considerar las dos rutas como compromisos operativos distintos:

• Las herramientas alojadas en Sites priorizan la velocidad, el despliegue integrado y un flujo de trabajo guiado.

• Las herramientas autohospedadas priorizan el control de la infraestructura, la arquitectura personalizada y las operaciones independientes.

• Los plugins alojados en Sites heredan los controles de cuentas y espacios de trabajo de OpenAI.

• Los servidores autohospedados siguen heredando los requisitos de conexión, autorización y revisión de ChatGPT.

Para muchos equipos, la elección dependerá menos de la generación de código que de la gobernanza. Crear una herramienta MCP es cada vez más sencillo. Decidir quién puede invocarla sigue siendo la decisión de producto más difícil.

Cómo el Site se convierte en un plugin instalable

El flujo de trabajo vincula un Site publicado a un plugin, pero la instalación y la autorización siguen siendo pasos separados.

La guía de alojamiento de OpenAI describe una secuencia específica. El creador comienza con un Site de su propiedad, pide a ChatGPT o Codex que añada herramientas MCP, las revisa y publica el Site.

Una vez finalizada la configuración MCP, ChatGPT presenta una tarjeta de plugin asociada a ese Site. El creador puede revisar la tarjeta, seleccionar Instalar y completar el flujo de conexión.

El plugin instalado puede mencionarse después en una conversación compatible de ChatGPT o Codex. ChatGPT también puede seleccionar un plugin instalado cuando coincida con la solicitud del usuario.

Este paso de empaquetado importa porque un endpoint MCP sin procesar y una experiencia de ChatGPT distribuible no son idénticos. El plugin proporciona una unidad reconocible que los usuarios pueden instalar, encontrar, seleccionar y gestionar.

Los plugins pueden incluir skills, aplicaciones conectadas, herramientas respaldadas por MCP y extensiones interactivas. Una aplicación MCP alojada en Sites se convierte en un componente dentro de ese sistema de empaquetado más amplio.

El directorio actual de plugins aparece en ChatGPT para web, escritorio y móvil. Sin embargo, OpenAI advierte que las capacidades individuales pueden variar según la superficie, la cuenta, la región, el plan, el rol y la configuración del espacio de trabajo.

Esta salvedad es importante. Que un plugin aparezca en el directorio no garantiza que todas las herramientas o vistas incluidas funcionen de forma idéntica en todas partes.

Las aplicaciones MCP locales ilustran esta distinción. OpenAI indica que una aplicación local puede ejecutarse mediante un plugin en ChatGPT Desktop. Guardar ese plugin en una cuenta no hace que sus herramientas locales estén disponibles en web o móvil.

El alojamiento en Sites aborda esa limitación al proporcionar un entorno de ejecución remoto. Incluso entonces, la compatibilidad precisa del plugin con cada superficie depende de las capacidades incluidas y de la disponibilidad actual del producto.

El Site asociado también tiene su propio modelo de acceso. Un destinatario puede necesitar permiso para ver el Site, permiso para usar el plugin y autorización para cualquier servicio conectado.

Instalar el plugin no elude esas capas. Compartir únicamente un Site no comparte el plugin, y compartir un plugin no concede acceso a datos no relacionados.

Esta separación protege frente a una suposición sencilla, pero peligrosa. Que una herramienta pueda instalarse no significa que pueda leer todo lo que su creador puede leer.

Cada usuario puede tener que conectar una cuenta elegible. Cuando un Site accede a aplicaciones conectadas, los visitantes utilizan sus propias conexiones y sus permisos existentes.

Pensemos en un panel de proyecto conectado a un rastreador de incidencias. El Site podría mostrar las incidencias asignadas y exponer una acción de actualización. Un destinatario solo debería ver los registros permitidos por su cuenta del rastreador de incidencias.

El mismo principio se aplica a repositorios de documentos, registros de clientes y manuales internos. El Site proporciona la interfaz y las herramientas alojadas, pero el servicio subyacente sigue siendo un límite de autorización.

Este modelo crea una ruta más práctica para herramientas personales y de espacios de trabajo. También introduce un problema de resolución de incidencias multicapa cuando falla el acceso.

Una llamada a una herramienta que falla puede originarse en el Site, la conexión del plugin, un rol del workspace, la aplicación subyacente o la cuenta del proveedor del usuario. Los creadores deberán probar cada capa de forma independiente.

Por tanto, la experiencia de instalación representa un avance real del producto, pero no una portabilidad universal. OpenAI ha unificado el flujo de creación y empaquetado, manteniendo dominios de seguridad diferenciados.

Los permisos son el límite del producto

La función más potente del nuevo flujo de trabajo es también su mayor riesgo: una herramienta generada mediante conversación puede realizar acciones reales.

Los creadores deben decidir si cada herramienta solo lee información o también puede modificarla. Una operación de búsqueda y una de actualización pueden aparecer una junto a la otra, pero conllevan consecuencias operativas diferentes.

OpenAI indica a los creadores que revisen los contenidos del Site y el comportamiento de las herramientas antes de compartir el acceso. En concreto, les pide considerar si los usuarios deben limitarse a leer datos o también realizar acciones de escritura.

El acceso de escritura puede incluir cambiar un hito, crear un registro, enviar información o actualizar contenido almacenado. Estas operaciones exigen un escrutinio mayor del que puede sugerir una interfaz generada.

Una vista previa pulida del Site no demuestra que sus reglas de acceso sean correctas. Tampoco demuestra que cada entrada active la acción prevista en el servidor.

Los creadores deberían probar registros representativos, niveles de permiso, datos ausentes, entradas no válidas y acciones denegadas. También deberían verificar los resultados abriendo el Site después de que una herramienta realice un cambio.

Los controles empresariales añaden otra capa. OpenAI afirma que varios permisos de plugins pueden administrarse de manera independiente, incluido el uso, la carga, la creación de plugins con MCP, el uso compartido y la publicación en un directorio del workspace.

Algunos permisos están desactivados de forma predeterminada en entornos Enterprise. Es posible que un administrador deba habilitar el rol correspondiente antes de que un creador pueda publicar un Site o compartir su plugin.

Este diseño limita la distribución accidental, pero también puede hacer que la función parezca inconsistente entre cuentas. Un usuario podría crear e instalar una herramienta de inmediato, mientras que otro no puede ver los controles necesarios.

El acceso público merece aún más cuidado. La afirmación original en redes sociales sugería que un creador podía restringir una herramienta a personas seleccionadas o compartirla con todo el mundo. La documentación oficial respalda el uso compartido controlado dentro del workspace y una vía independiente para el envío público.

No describe el uso compartido de plugins personales como algo universalmente abierto. Actualmente, los usuarios Pro y de cuentas personales no pueden invitar directamente a otros usuarios de ChatGPT a un plugin alojado en un Site mediante un enlace para compartir.

Los miembros de Business y Enterprise pueden compartir con compañeros de trabajo, sujetos a los permisos del workspace. Los destinatarios necesitan acceso tanto al plugin como a su Site, y después deben instalarlo y conectarlo por su cuenta.

La distribución mediante directorio público sigue otro proceso. Los desarrolladores envían un plugin a revisión, cumplen requisitos de identidad y permisos, y solo publican tras la aprobación.

Los requisitos de revisión de OpenAI exigen un endpoint MCP real y accesible públicamente para los envíos remotos. La revisión puede inspeccionar esquemas de herramientas, sistemas de seguridad, anotaciones, manejo de datos de usuarios y comportamiento previsto.

La guía de revisión también distingue entre operaciones de solo lectura, destructivas y de mundo abierto. Esas clasificaciones influyen en cómo los revisores entienden el comportamiento y los riesgos de una herramienta.

Una herramienta no puede convertirse en solo lectura simplemente porque su descripción la presente como inocua. Sus anotaciones declaradas y su comportamiento real deben coincidir.

Ese estándar importa tanto para las herramientas generadas con Site como para los servidores programados manualmente. La creación mediante lenguaje natural puede reducir el esfuerzo de implementación, pero no puede sustituir un modelo de seguridad preciso.

La mayor cuestión sin resolver es hasta qué punto los creadores corrientes reconocerán de forma fiable límites de herramientas inseguros. Los desarrolladores saben que una función de actualización aparentemente pequeña puede activar sistemas posteriores o exponer campos sensibles.

Los usuarios menos técnicos pueden centrarse en si el flujo de trabajo funciona. Es posible que no inspeccionen campos de respuesta excesivos, efectos secundarios indirectos o reglas de autorización incoherentes.

El flujo de trabajo gestionado de OpenAI puede proporcionar salvaguardas, pero la documentación sigue asignando al creador la responsabilidad de las pruebas. Indica a los propietarios que revisen las herramientas, prueben datos de ejemplo y comprueben los resultados antes de compartirlas.

Eso convierte a la gobernanza en la verdadera restricción para la adopción. Una herramienta útil necesita tanto una capacidad clara como un límite de permisos defendible.

Los casos de uso de servidores MCP de ChatGPT empiezan por lo pequeño

Los mejores usos iniciales son flujos de trabajo acotados, con límites de datos evidentes, acciones reversibles y resultados que los usuarios pueden inspeccionar.

Un manual de equipo es el ejemplo más claro de OpenAI. Un Site puede presentar el manual mientras las herramientas MCP permiten a ChatGPT buscar en su contenido y recuperar secciones pertinentes durante una conversación.

Este caso de uso tiene un corpus definido y una salida relativamente sencilla. El creador puede comparar la respuesta de ChatGPT con el Site subyacente e identificar información ausente o incorrecta.

Un panel de proyectos ofrece un segundo patrón. Las herramientas de lectura podrían recuperar hitos, responsables, bloqueos o fechas límite. Una herramienta de escritura controlada podría actualizar el estado de un hito tras la confirmación del usuario.

Ese flujo ofrece una verificación visible. El usuario puede volver a abrir el panel y confirmar que el registro solicitado cambió correctamente.

Los buscadores de documentos ofrecen otro punto de partida práctico. Un Site podría exponer herramientas que busquen en carpetas aprobadas, devuelvan títulos coincidentes y abran registros a los que el usuario actual tenga acceso.

Estas herramientas ganan valor cuando se combinan con una buena organización de la información. Un flujo de trabajo de conocimiento personal o de equipo sigue dependiendo de material fuente preciso, permisos estables y límites claros de recuperación.

Los directorios internos, calendarios de lanzamientos e informes de estado también encajan en el modelo. Cada uno puede utilizar un conjunto reducido de herramientas con entradas delimitadas y salidas comprensibles.

Los flujos de trabajo de mayor riesgo exigen más cautela. Una herramienta que envía mensajes, elimina registros, publica contenido, cambia permisos o inicia trabajos externos puede generar consecuencias fuera del Site.

Estas acciones deberían exponer parámetros claros y requerir la confirmación adecuada. Los creadores deberían evitar combinar un amplio acceso a datos con una amplia autoridad de escritura en un primer prototipo.

El Site también debería mostrar suficiente estado para que los usuarios puedan verificar los resultados. Una confirmación conversacional no es evidencia suficiente de que una acción externa se haya completado correctamente.

Aquí es donde el alojamiento de servidores MCP de ChatGPT difiere de un generador de sitios web convencional. El resultado no es simplemente contenido o código de interfaz. Puede convertirse en un participante operativo dentro de conversaciones futuras.

Esto crea un efecto acumulativo. Una vez instalado, el plugin puede seleccionarse cuando ChatGPT lo considere relevante o cuando un usuario lo mencione directamente.

Por lo tanto, los metadatos importan. Los nombres y descripciones de las herramientas deberían dejar claro el alcance previsto. Las descripciones ambiguas pueden hacer que se seleccione la herramienta equivocada o fomentar solicitudes inadecuadas.

El entorno gestionado también cambia la iteración. Los creadores pueden pedir a ChatGPT o Codex que añada una nueva herramienta, revise una acción existente o modifique la interfaz del Site.

Esos cambios no pasan automáticamente a producción. El propietario debe publicar el Site de nuevo y después confirmar que el plugin expone la versión esperada de la herramienta.

Este requisito de publicación crea un punto de control útil. Los equipos pueden revisar las capacidades modificadas antes de que lleguen a los usuarios.

Sin embargo, también genera una posible confusión de versiones. Un borrador de Site, un Site publicado y un plugin instalado pueden no reflejar siempre el mismo comportamiento esperado.

Los equipos deberían mantener notas de versión sencillas, casos de prueba con nombre y un responsable para cada herramienta. Incluso un pequeño plugin interno se beneficia de saber qué versión invocan actualmente los usuarios.

Por lo tanto, el mejor primer proyecto no es el asistente más amplio imaginable. Es un flujo de trabajo concentrado en el que el propietario pueda responder claramente a cuatro preguntas:

• ¿Qué información puede leer la herramienta?

• ¿Qué puede modificar la herramienta?

• ¿Quién puede invocarla?

• ¿Cómo pueden los usuarios verificar el resultado?

Si esas respuestas siguen siendo vagas, un despliegue más rápido solo lleva antes la incertidumbre a producción.

Tres señales mostrarán si Sites cambia la adopción de MCP

La siguiente prueba no es cuántos Sites se generan, sino cuántas herramientas alojadas se convierten en flujos de trabajo fiables y repetibles.

La primera señal es la fiabilidad entre superficies. OpenAI afirma que el directorio de plugins está disponible en web, escritorio y móvil, aunque las funciones individuales pueden variar entre esas superficies.

Habrá que observar si las herramientas alojadas en Site se comportan de forma consistente en cada cliente compatible. Una instalación, autorización, selección de herramientas y salida coherentes reforzarían el argumento a favor de Sites como capa general de despliegue de MCP.

Las diferencias persistentes entre superficies debilitarían ese argumento. Los creadores seguirían teniendo que diseñar expectativas distintas para usuarios de escritorio, web y móvil.

La segunda señal es la adopción en el workspace. Los entornos Business y Enterprise proporcionan uso compartido controlado, pero los administradores gobiernan los permisos necesarios.

Habrá que observar si las organizaciones habilitan la creación de Sites, la creación de plugins MCP y el uso compartido dentro del workspace para grupos amplios de empleados. La adopción más allá de los equipos de desarrolladores mostraría que el despliegue conversacional responde a una necesidad operativa genuina.

Las políticas predeterminadas restrictivas producirían el resultado contrario. Sites podría quedarse como una herramienta de prototipado si los equipos de seguridad no pueden auditar con confianza las acciones generadas y los datos conectados.

La tercera señal es la calidad de los plugins públicos. La distribución privada y la publicación pública son vías distintas, y el envío al directorio incluye una revisión formal.

Habrá que buscar plugins respaldados por Site que pasen de experimentos personales a productos públicos aprobados. Su fiabilidad, divulgaciones de privacidad, prácticas de soporte y satisfacción de los usuarios pondrán a prueba el modelo gestionado bajo una demanda real.

Un flujo constante de herramientas aprobadas reforzaría la afirmación de OpenAI de que Sites puede respaldar más que demostraciones internas. Los fallos repetidos de permisos o el comportamiento poco claro de las herramientas dejarían al descubierto los límites del despliegue impulsado por prompts.

La incertidumbre restante es, por tanto, práctica y no conceptual. OpenAI ha documentado el flujo de creación, alojamiento, publicación, instalación y uso compartido. El mecanismo es real.

Lo que todavía no se ha establecido es qué tan bien gestiona tráfico sostenido, autorizaciones complejas, depuración operativa y mantenimiento a largo plazo entre muchos creadores.

Para los desarrolladores, el paso inmediato es probar un flujo de trabajo acotado frente a la ruta convencional autohospedada. Comparen el tiempo de configuración, la claridad de los permisos, el diagnóstico de errores, el control de actualizaciones y la cobertura de clientes.

Para los compradores empresariales, la prioridad es la gobernanza. Revisen qué roles pueden crear herramientas, quién aprueba las acciones de escritura, cómo se comportan las cuentas conectadas y qué evidencia reciben los usuarios después de los cambios.

Para los trabajadores del conocimiento, la oportunidad es directa. Un panel interno útil o una colección de referencias puede convertirse ahora en una herramienta conversacional sin empezar como un proyecto de infraestructura independiente.

El cambio de los servidores MCP de ChatGPT importa porque el despliegue se está acercando a la propia solicitud. La pregunta decisiva es si los equipos pueden mantener igual de cerca el acceso, las pruebas y la propiedad. Elijan un flujo de trabajo acotado, definan sus límites antes de crearlo y pruébenlo con usuarios que tengan permisos distintos. Esa evidencia revelará si Sites es simplemente un alojamiento más rápido o una vía nueva y duradera para crear herramientas de IA.