Publicar con un agente de IA es fácil de imaginar, pero más difícil de controlar: el agente necesita un destino, permiso para escribir y una forma de informar qué se publicó realmente. Para permitir que los agentes de IA publiquen mediante MCP, conecta un agente compatible con MCP a una herramienta de publicación y diseña el flujo de trabajo de modo que la redacción, la aprobación, la publicación y la verificación sean acciones distintas.
El Model Context Protocol (MCP) se está convirtiendo en una capa de conexión práctica para este trabajo, en lugar de ser una promesa de que cualquier agente puede publicar de forma segura en cualquier sitio. OpenAI admite el uso de herramientas MCP en sus agentes en la nube, el registro oficial de MCP incluye un servidor centrado en la publicación y el protocolo está evolucionando para admitir flujos de trabajo remotos y gestionados con agentes. La pregunta útil no es simplemente si un agente puede llamar a una herramienta de publicación, sino qué debería poder publicar esa herramienta, bajo la autoridad de quién y con qué pruebas de que la publicación se realizó correctamente.
¿Qué significa permitir que los agentes de IA publiquen mediante MCP?
Un agente que publica mediante MCP utiliza una herramienta expuesta por un servidor MCP para enviar contenido o instrucciones de publicación a un destino. El agente podría preparar HTML, solicitar una vista previa, enviar un elemento aprobado o recuperar la URL resultante. MCP proporciona la conexión entre el agente y la herramienta; el servidor y el destino determinan qué hace realmente la acción de publicación.
Respuesta directa: Para permitir que los agentes de IA publiquen mediante MCP, da acceso a un servidor de publicación a un agente compatible con MCP, define el contenido y el destino que puede utilizar, exige la aprobación correspondiente antes de una publicación pública y haz que el agente compruebe el resultado del servidor. MCP conecta el agente con la acción de publicación; no sustituye el criterio editorial, el control de acceso ni la verificación.
Esta distinción importa porque la palabra publicar abarca varios resultados. Una página HTML en una URL privada y difícil de adivinar no es lo mismo que un artículo en un sitio web público, una actualización de documentación o una publicación en redes sociales. Un flujo de trabajo debería definir el resultado deseado antes de seleccionar un servidor: ¿el agente crea una vista previa para que alguien la revise, reemplaza una página existente o publica un nuevo elemento para que el público pueda encontrarlo?
El registro oficial de MCP ilustra un caso de uso concreto y acotado. Su entrada ee.stacktr/publish se describe como una forma de publicar HTML en URL privadas, difíciles de adivinar y que permiten reemplazar el contenido existente desde un agente de IA compatible con MCP. Esa descripción demuestra que se puede exponer una acción de publicación mediante MCP, pero no establece que el mismo servidor pueda actualizar un sistema de gestión de contenidos, distribuir una publicación en varios canales o proporcionar todos los controles de gobernanza que necesita un equipo.
OpenAI describe el uso de herramientas MCP como una función disponible en sus agentes en la nube, listos para producción: se puede crear un agente mediante una llamada a la API que incluya una herramienta con type: "mcp". Los materiales del Agents SDK también identifican el uso de herramientas MCP como una primitiva central, junto con las habilidades, la ejecución de shell y la edición de archivos. Estas capacidades hacen de MCP una vía de integración viable para una aplicación con agentes; no convierten por defecto un destino de publicación recién conectado en uno seguro para producción.
Define la relación entre el agente, el servidor MCP y el destino de publicación
Antes de elegir un servidor, representa el flujo de trabajo como tres responsabilidades distintas. El agente decide qué acción solicitar según sus instrucciones y el contexto disponible. El servidor MCP expone una acción y media el acceso al sistema de publicación subyacente. El destino almacena o muestra el contenido resultante según su propio funcionamiento y permisos.
En el caso de una vista previa HTML sencilla, la secuencia podría ser la siguiente: el agente prepara un documento HTML revisado, llama a una herramienta de publicación, recibe una URL y se la entrega a una persona para que la revise. Para actualizar documentación pública, la secuencia podría requerir más etapas: identificar el documento correcto, proponer un cambio, obtener aprobación, aplicar la actualización e inspeccionar la página resultante. Se trata de diseños de flujos de trabajo, no de funciones garantizadas por MCP ni por una entrada concreta del registro.
Define el contrato de la herramienta antes de redactar las instrucciones
Una instrucción como «publica el artículo» deja demasiadas preguntas operativas sin respuesta. Un contrato útil para la herramienta especifica el formato de contenido aceptado, el destino previsto, si una operación crea o reemplaza un elemento y qué respuesta debería esperar quien la invoca. Si un servidor admite más de una acción, el agente debería saber cuál genera un borrador o una vista previa y cuál hace que algo sea visible para su público previsto.
- Define la entrada. Indica si el servidor acepta HTML, campos estructurados, un identificador de documento o una referencia a contenido almacenado en otro lugar.
- Define el destino. Identifica el sitio, la colección, el espacio de trabajo o el tipo de página permitido, en lugar de permitir que el agente deduzca el destino a partir de una solicitud imprecisa.
- Define el resultado. Aclara si la acción crea una vista previa, actualiza un elemento existente o publica contenido para los lectores.
- Define la respuesta. Pide al flujo de trabajo que conserve el identificador, la URL, el estado o los detalles del error que proporcione realmente el servidor.
- Define qué hacer si algo falla. Decide qué debería hacer el agente si falla la validación, no se encuentra un elemento o la solicitud de publicación devuelve un resultado incierto.
Estas definiciones deben confirmarse consultando la documentación y el comportamiento del servidor elegido. Una conexión MCP informa al agente de que hay una herramienta disponible; no le indica al equipo que el nombre de esa herramienta coincide con el significado editorial de «publicar». Considera la descripción de la herramienta como punto de partida para las pruebas, no como sustituto de ellas.
La división de responsabilidades también ayuda a revisar los incidentes. Si se envió el texto equivocado, examina la preparación del contenido y la aprobación. Si el texto correcto se envió al lugar equivocado, examina la selección del destino y los permisos. Si el servidor informó de que la operación se realizó correctamente, pero la página se ve mal, examina la visualización y la verificación en el destino.
Crea paso a paso un flujo de trabajo para publicar mediante MCP
La primera implementación más segura es deliberadamente pequeña: un destino, un tipo de contenido y un límite claro entre preparar el material y publicarlo. Añade autonomía solo después de poder observar qué solicita el agente y qué devuelve el destino. La siguiente secuencia sirve como marco de planificación tanto si utilizas un servicio de agentes gestionado, una aplicación del Agents SDK u otro cliente compatible con MCP.
- Elige un resultado de publicación específico. Decide si el primer entregable será una URL de vista previa, una página HTML reemplazable o una actualización en un destino existente. Una vista previa resulta útil cuando el equipo quiere que un agente prepare contenido sin concederle también autoridad amplia para publicarlo.
- Identifica un servidor que admita ese resultado. Revisa las acciones que anuncia, las entradas que acepta, el modelo de autenticación y el comportamiento del destino. El registro oficial de MCP puede ayudar a encontrar servidores candidatos, pero una entrada en el registro no equivale a una revisión completa de la integración.
- Conecta el agente al servidor. En una plataforma de agentes que admita herramientas MCP, configura la conexión y pon a disposición del flujo de trabajo únicamente la herramienta pertinente. La compatibilidad documentada de OpenAI con herramientas de
type: "mcp"es un ejemplo de vía de integración, no un requisito para usar OpenAI. - Limita la solicitud de contenido. Proporciona el material de origen, el público, el formato requerido y las normas editoriales que debe seguir el agente. Indícale que distinga los hechos proporcionados por el usuario de su propia redacción y que señale las lagunas en lugar de rellenarlas con afirmaciones inventadas.
- Incluye un punto de revisión donde sea necesario. Para una publicación pública, pide a una persona o a un proceso de aprobación gobernado de forma independiente que acepte el contenido final y el destino antes de ejecutar la acción de escritura. Una persona puede revisar el material completo en lugar de una descripción imprecisa de lo que el agente pretende publicar.
- Ejecuta la acción y registra el resultado. Haz que el agente llame a la herramienta aprobada con el material revisado y conserva la URL, el identificador o el estado devuelto, si el servidor proporciona alguno. Si la respuesta es ambigua, considera que el estado es desconocido en lugar de repetir la solicitud de inmediato.
- Verifica el contenido publicado. Recupera o inspecciona el contenido en el destino mediante un canal apropiado, compáralo con la versión aprobada e informa de cualquier diferencia. Una llamada a la herramienta que se realiza correctamente confirma lo que informó la herramienta, no necesariamente lo que ve cada lector en ese momento.
Por ejemplo, un equipo podría empezar con un agente que convierte textos aprobados a HTML y los envía, mediante MCP, a un destino privado de vista previa. Una persona revisa la página renderizada, solicita correcciones si hace falta y se encarga de la publicación pública final en el CMS existente. Así, el agente realiza una tarea de publicación real sin dar por sentado que el acceso a vistas previas y la autoridad para publicar contenido públicamente deban concederse juntos.
Cuando ese proceso sea fiable, el equipo puede plantearse si el agente debería actualizar directamente una página determinada. Para ello, se necesita una validación más estricta del destino y un plan de respuesta ante reemplazos accidentales. Si la herramienta elegida permite reemplazar contenido, confirma exactamente cómo identifica la página que se reemplazará; no dependas de que el agente adivine una URL o un título.
Mantén la autoridad para publicar más limitada que la capacidad de generar contenido
Generar un borrador y publicarlo son niveles de autoridad distintos. Se puede permitir que un agente proponga textos sobre muchos temas, pero autorizarlo a actualizar solo un conjunto reducido de destinos. Mantener separados estos permisos limita las consecuencias de una instrucción equivocada, una inferencia incorrecta o material no confiable encontrado durante la investigación.
Decide quién puede autorizar cada transición
Un flujo de trabajo práctico indica en qué momento un elemento pasa de borrador a vista previa, de vista previa a aprobado y de aprobado a publicado. Para cada transición, especifica si el agente puede actuar por sí solo, si una persona debe aprobarla y qué credencial ejecuta la acción. Esta es una decisión operativa del sistema de publicación; MCP ofrece una forma de llamar a herramientas, no una política editorial de aprobación universal.
Los permisos deben reflejar el alcance mínimo necesario. Si la tarea del agente es preparar vistas previas internas, no necesita credenciales que puedan modificar la página de inicio pública. Si actualiza la documentación de un área de producto definida, no le des acceso de escritura a espacios de trabajo no relacionados solo porque el mismo CMS los admita. Revisa también el modelo de permisos del propio destino, además de los controles del servidor MCP o la pasarela.
- Limita los destinos a los que realmente utiliza el flujo de trabajo y, si la herramienta lo permite, indica explícitamente el destino previsto.
- Separa las credenciales de vista previa o borrador de las credenciales de publicación pública cuando el destino permita esa separación.
- Exige un registro de aprobación que identifique el contenido final y el destino, en vez de una aprobación de un borrador anterior que podría cambiar.
- Registra la acción solicitada y su resultado para que quien revise el proceso pueda distinguir una propuesta del agente de una publicación completada.
- Planifica cómo responder ante una publicación equivocada antes de habilitar las escrituras autónomas: determina quién puede corregir, reemplazar o retirar el elemento en el destino.
El contenido no confiable requiere especial cuidado. Un documento, una página web o un comentario que lea el agente puede contener instrucciones dirigidas al agente, en lugar de datos para el artículo. Trata ese material como datos de origen que deben evaluarse, no como autoridad para cambiar el destino de publicación o eludir la aprobación. Ese límite sigue siendo importante incluso cuando la conexión con la herramienta funciona correctamente.
Tampoco debe confundirse una URL privada o difícil de adivinar con una etapa de aprobación editorial. La descripción de ee.stacktr/publish indica que sus URL son privadas y difíciles de adivinar, lo que describe un método de publicación, no un conjunto completo de controles de acceso ni una política de conservación. Confirma cómo gestiona el uso compartido el destino elegido antes de utilizarlo con contenido sensible.
Elige el patrón de publicación MCP adecuado para cada tarea
«Publicación» no es una única categoría de integración. El destino determina el formato del contenido, el coste de un error y lo que significa tener éxito. Elegir primero un patrón evita que el equipo adapte una herramienta conveniente a un flujo de trabajo para el que nunca fue diseñada.
Vista previa o contenido compartible
Un servidor de publicación HTML puede ser una buena opción cuando el objetivo inmediato es que un agente cree una página para revisión. La entrada ee.stacktr/publish del registro describe específicamente la publicación de HTML en URL privadas, difíciles de adivinar y que permiten reemplazar el contenido existente. Un flujo de trabajo basado en esta capacidad podría permitir que una persona revise el resultado renderizado y pida al agente que lo modifique en el mismo destino.
Su limitación es igual de importante: una URL de revisión no es necesariamente la página oficial que los lectores deberían encontrar mediante la navegación o la búsqueda del sitio web. Si necesitas un artículo público gestionado con una categoría, una persona responsable y un proceso editorial establecido, comprueba si necesitas una integración con otro destino. No des por sentado que una herramienta de publicación orientada a vistas previas ofrece las funciones de un CMS.
Actualización de documentación o de un sistema de gestión de contenidos
Para actualizar documentación, el agente suele necesitar algo más que un campo. Necesita un destino de documento inequívoco, una forma de preservar el material existente que no debería cambiar y un medio para inspeccionar el resultado. Un servidor MCP conectado al sistema de documentación o gestión de contenidos real del equipo puede ser adecuado si las acciones que expone admiten ese ciclo de vida.
Empieza con una actualización limitada en lugar de una instrucción amplia como «actualiza la documentación». Proporciona al agente el identificador del documento y el cambio aprobado; luego compara el resultado renderizado con la revisión prevista. La colección más amplia de herramientas para documentación, datos de aplicaciones y flujos de trabajo web del registro oficial muestra que las operaciones disponibles para agentes van más allá de la publicación de HTML independiente, pero las capacidades de cada servidor deben comprobarse por separado.
Distribución después de la publicación
Publicar un enlace o adaptar un artículo aprobado para otro canal es una acción independiente de crear el artículo original. Un flujo de distribución puede requerir textos adaptados a cada canal, decisiones de programación y confirmación de lo que se envió. Si el agente se encarga tanto de la publicación como de la distribución, mantén visible cada llamada a una herramienta y cada límite de aprobación para que una publicación fallida no se convierta en una afirmación falsa de que se lanzó toda una campaña.
Entradas del registro como ai.agentui/apps y ai.agentsindex/mcp reflejan un ecosistema más amplio de aplicaciones nativas de IA e infraestructura para agentes. Su presencia señala que están surgiendo herramientas diseñadas para agentes, pero no demuestra que ninguna de esas entradas cumpla un requisito de publicación concreto. Elige un servidor según las acciones documentadas y el comportamiento probado, no por su categoría ni por la presencia de la palabra «agente» en su nombre.
Entiende qué cambia la nueva infraestructura MCP y qué no
La evolución de MCP importa porque un flujo de trabajo con agentes debe seguir siendo útil cuando las herramientas son remotas, se conectan muchos agentes y las organizaciones necesitan un control uniforme de las solicitudes. La especificación MCP del 28 de julio de 2026 introduce un núcleo de protocolo sin estado, solicitudes que requieren varios intercambios, enrutamiento basado en encabezados, resultados de listas almacenables en caché y extensiones formales. Estos son cambios de infraestructura: no redactan textos, no los aprueban ni garantizan que un sitio de destino muestre la página correcta.
Según el núcleo sin estado descrito en la especificación, cada solicitud es autónoma y puede dirigirse a cualquier instancia detrás de un balanceador de carga con distribución por turnos. Esto puede facilitar la operación de un servicio remoto de publicación en varias instancias, ya que no es necesario que una solicitud llegue a la misma instancia del servidor que una solicitud anterior. El equipo sigue necesitando reglas a nivel de aplicación para el estado del contenido, las aprobaciones, el comportamiento de reemplazo y las solicitudes duplicadas.
Enrutamiento y descubrimiento
Los encabezados HTTP Mcp-Method y Mcp-Name de la especificación contienen los nombres de los métodos y las herramientas para el enrutamiento. Esto permite que las pasarelas dirijan o autoricen las solicitudes según la acción invocada. En un entorno de publicación, podría ayudar a distinguir una acción de lectura o vista previa de una acción de escritura en la pasarela, siempre que la infraestructura circundante esté configurada para hacer cumplir esa distinción.
Las indicaciones de caché y el orden determinista de los catálogos de herramientas ayudan a mantener estables los resultados de las listas tras una reconexión. Las listas estables de herramientas pueden hacer que los flujos de trabajo repetidos de los agentes sean más predecibles y favorecer la estabilidad de la caché de prompts, especialmente cuando un cliente vuelve a conectarse a un servidor remoto. No deben confundirse con el almacenamiento en caché del artículo publicado ni con la confirmación de que una página se haya actualizado.
Las extensiones formales del protocolo incluyen Tasks, MCP Apps y Enterprise Managed Authorization. La hoja de ruta destaca la escalabilidad del transporte, la comunicación entre agentes y el descubrimiento mediante metadatos .well-known. Estas líneas de desarrollo son relevantes para los equipos que planifican un acceso remoto y gobernado a herramientas, pero la existencia de una extensión o de un elemento en la hoja de ruta no demuestra que un servidor de publicación concreto implemente un control determinado.
La actividad del ecosistema justifica tomar en serio este patrón sin exagerar su madurez. Anthropic ha descrito MCP como una forma de hacer posible la conectividad de los agentes y ha dicho que está ampliando su ecosistema de conectores y aplicaciones MCP. El informe State of AI Agents 2026 de BCG prevé que surja más infraestructura preparada para agentes, incluidos servidores MCP remotos. Estas señales apuntan a un acceso más amplio a las herramientas; la calidad del flujo de publicación sigue dependiendo del servidor, el destino, los permisos y el proceso editorial elegidos.
Prueba los fallos que importan después de que un agente invoque la publicación
Una prueba de publicación debe hacer algo más que confirmar que el agente puede ver una herramienta. Debe determinar si el contenido correcto llega al destino correcto con la autoridad adecuada, y si el equipo puede saber qué ocurrió cuando algo sale mal. Realiza estas comprobaciones en un destino de bajo riesgo antes de conceder acceso a páginas públicas importantes.
- Prueba un caso de éxito normal. Envía contenido de muestra aprobado, sigue la referencia devuelta si la hay y compara la página renderizada con la versión enviada.
- Prueba los casos en los que el destino sea ambiguo. Proporciona al flujo de trabajo páginas o destinos con nombres similares y confirma que solicita una aclaración o utiliza un identificador explícito en vez de adivinar.
- Prueba contenido rechazado. Confirma que los errores de validación, los campos obligatorios ausentes o los formatos no admitidos se comuniquen a una persona encargada de la revisión, en lugar de describirse como una publicación exitosa.
- Prueba las respuestas inciertas. Si una llamada a la herramienta agota el tiempo de espera o devuelve un resultado poco claro, comprueba el destino antes de volver a intentarlo para evitar que una segunda llamada cree un duplicado o reemplace contenido inesperado.
- Prueba las acciones no autorizadas. Confirma que un flujo de trabajo destinado a crear vistas previas no pueda publicar contenido en un destino público con solo cambiar sus propias instrucciones.
- Prueba cómo corregir el contenido. Reemplaza o modifica un elemento de prueba mediante el proceso admitido y verifica el resultado visible, en lugar de suponer que una segunda llamada exitosa corrige la primera.
Los registros deberían permitir que alguien que no haya observado trabajar al agente entienda la secuencia. Conserva juntos en el registro del flujo de trabajo, siempre que tus políticas lo permitan, el contenido aprobado, el destino autorizado, la acción solicitada a la herramienta, la respuesta del servidor y el resultado de la verificación. Esta es una recomendación de implementación, no una garantía de que todos los servidores MCP proporcionen automáticamente todos esos datos.
Presta atención a lo que ven realmente los lectores. Un servidor puede aceptar HTML, pero el destino puede renderizarlo de una forma inesperada; una URL devuelta puede apuntar a un elemento que requiera más revisión; una actualización puede afectar a una página existente cuyo contenido circundante no haya inspeccionado el agente. La verificación cierra la brecha entre «la herramienta indicó que la operación se realizó correctamente» y «el elemento previsto es correcto».
Define también una regla para detenerse. Si al agente le falta un destino obligatorio, no puede verificar el resultado o encuentra un conflicto entre el texto aprobado y la página actual, debe derivar el problema a una persona en lugar de improvisar una decisión de publicación. Esta regla ayuda a preservar la confianza incluso cuando el agente tiene buenas capacidades de redacción y uso de herramientas.
¿Cuándo deberías usar MCP en lugar de otra integración de publicación?
MCP resulta atractivo cuando un agente necesita descubrir y utilizar herramientas mediante una interfaz común, sobre todo si el mismo flujo de trabajo puede conectarse a varios servicios. El crecimiento del registro y la compatibilidad de las plataformas de agentes hacen que sea una opción razonable que conviene evaluar para tareas de publicación. Aun así, la decisión depende de que exista un servidor MCP adecuado que exponga la acción y los controles exactos que requiere tu destino.
Una integración directa con la API de un CMS puede ser más sencilla cuando hay un único destino fijo, un conjunto reducido de operaciones conocidas y un equipo de aplicaciones que ya mantiene esa integración. Una plataforma de automatización puede ser adecuada para una secuencia muy definida en la que una persona aprueba un borrador y un proceso determinista se encarga de publicarlo. La publicación manual sigue siendo razonable cuando el contenido es especialmente sensible, el destino carece de los permisos adecuados o no es posible verificar el resultado de forma fiable.
Estas opciones no se excluyen entre sí. Un agente puede preparar un borrador estructurado, un servidor MCP puede proporcionar una vista previa privada y un flujo de trabajo de CMS existente puede encargarse de la publicación pública final. A la inversa, un equipo con una conexión MCP bien gobernada a su CMS puede utilizar el agente para realizar una actualización directa de alcance limitado y seguir exigiendo la aprobación humana para los cambios de mayor impacto.
Una decisión práctica para la implementación
Hazte tres preguntas antes de ampliar la autoridad del agente. Primero, ¿puede el servidor elegido realizar la acción necesaria en el destino real, en lugar de en un sustituto conveniente? Segundo, ¿puede la organización limitar y revisar esa acción según lo que requiera el contenido? Tercero, ¿puede el flujo de trabajo verificar el resultado y recuperarse de una publicación incorrecta o incierta?
Si la respuesta a alguna de estas preguntas es no, mantén al agente ocupado con la redacción o las vistas previas mientras resuelves el problema. Si las pruebas respaldan las tres respuestas, amplía sus capacidades en pequeños pasos: un tipo de contenido definido, un destino definido y luego una clase de actualizaciones definida. Este avance aprovecha las ventajas de MCP, conectar agentes con herramientas, sin pedirle a la conectividad por sí sola que sustituya un proceso de publicación.
Permitir que un agente de IA publique mediante MCP resulta más útil cuando el flujo de trabajo considera la llamada a una herramienta como un paso controlado, no como la totalidad de la tarea. Elige un servidor para un destino y un resultado específicos, mantén la autoridad de publicación en proporción al riesgo y verifica el contenido que realmente verán los lectores o las personas encargadas de revisarlo.
Empieza con una tarea de publicación de bajo riesgo y documenta el proceso desde el contenido aprobado hasta la confirmación del resultado. Cuando ese proceso funcione de forma fiable, podrás decidir si las capacidades del servidor y los controles asociados justifican ampliar la publicación mediante agentes.
