Revisar y aprobar cambios de MCP

Aprueba un cambio individual o un trabajo completo y explícito antes de que el asistente lo aplique. Un write job agrupa operaciones conocidas en un sitio bajo una única revisión. El asistente puede ejecutar después sus partes por separado sin pedirte que apruebes cada lote. La lectura y las vistas previas de dry_run: true no requieren aprobación.

Para la edición iterativa en red, puedes autorizar en su lugar un work session temporal para operaciones seleccionadas en un destino. Tanto las autorizaciones de sesión como las nuevas revisiones web en red utilizan el inicio de sesión del sitio principal.

Revisar dentro de tu cliente

En conexiones directas a sitios y a redes multisitio, los clientes que admiten la obtención estándar de formularios MCP pueden mostrar la revisión en la conversación. Para ello se utiliza el protocolo estándar elicitation/create compatible con Codex, Claude Code y otros clientes MCP; no requiere un complemento específico del cliente.

1. Pide al asistente que lea los objetivos y prepare los cambios exactos.
2. Revisa el sitio, el título del trabajo, la caducidad y las entradas completas de las operaciones en el diálogo de confirmación del cliente.
3. Selecciona Approve these exact changes y envíalo, o recházalo o cancélalo.
4. El asistente recibe la decisión y ejecuta las operaciones aprobadas con su approval_id.
5. Inspecciona los resultados y pide al asistente que vuelva a leer los objetos modificados.

El diálogo está disponible cuando el cliente anuncia la obtención de formularios y acepta respuestas HTTP en streaming. Sus etiquetas y presentación pueden variar según el cliente. El servidor devuelve primero un recibo de tarea en segundo plano. Consulta pom_get_task para recibir la revisión preparada. La respuesta autenticada registra la decisión; las decisiones delegadas también se procesan mediante cron. Lee el estado del trabajo después de confirmar y antes de ejecutar. Un formulario cancelado, sin responder o no compatible, o un formulario enviado con su confirmación sin marcar, deja la revisión pendiente y ofrece la alternativa web. Solo una confirmación marcada aprueba el trabajo. Un rechazo explícito impide la ejecución y requiere una nueva revisión si más adelante quieres continuar. La aprobación no aplica los cambios de inmediato.

El alojamiento debe admitir la respuesta breve en streaming para el diálogo. El diálogo no mantiene abierta una solicitud PHP mientras decides. Si el alojamiento o el cliente interrumpe la conversación, utiliza el enlace de revisión web incluido en el diálogo e inspecciona el trabajo antes de continuar.

Aprobar un trabajo completo

Para varios lotes independientes, pide al asistente que use pom_site_prepare_write_job con el destino site_id, un title descriptivo y una lista de operations . Cada entrada contiene un name de herramienta admitida y sus argumentsexactos, incluidas las revisiones necesarias. Omite approval_id y dry_run dentro de las entradas. El dry_run: true externo muestra una vista previa del trabajo sin crear una revisión.

El trabajo admite hasta 100 operaciones, una carga de entrada de 1 MiB y una revisión completa de como máximo 2 MiB. Los límites de ejecución existentes por herramienta siguen aplicándose: por ejemplo, 180 cambios de nombre de categorías pueden usar cuatro operaciones de wp_rename_terms de un máximo de 50 términos cada una, con una sola aprobación para las cuatro. Un trabajo mayor puede dividirse en varios trabajos explícitos.

Preparar la revisión completa comparte un presupuesto de trabajo de 60 segundos entre sus vistas previas, tanto en conexiones directas a sitios como en red. Si la preparación alcanza ese presupuesto, no se crea ninguna aprobación; prepara un trabajo más pequeño. Cada operación posterior conserva su presupuesto de trabajo ordinario de 15 segundos. Estos límites se comprueban entre pasos y entradas de lote; no interrumpen una devolución de llamada nativa que ya ha comenzado.

Tras la aprobación, el asistente llama a cada herramienta original con sus argumentos devueltos y el approval_idcompartido. Cada operación listada puede ejecutarse una vez. Usa pom_site_get_write_job con ese ID para inspeccionar la aprobación y el estado de cada operación: pending, executing, applied o uncertain.

Los trabajos caducan una hora después de su preparación. Las revisiones individuales caducan a los 15 minutos. La caducidad y los cambios de credenciales pueden requerir otra revisión. Un trabajo no autoriza objetivos adicionales, argumentos modificados ni cambios futuros que no estuvieran incluidos. Los cambios que dependen de ID desconocidos o de revisiones posteriores del plan necesitan su propia vista previa una vez que existan esas entradas. Un plan de autoría guardado por sí solo no autoriza sus pasos futuros.

Usar la alternativa web

Un enlace de revisión sigue disponible para clientes sin obtención de formularios, conexiones enrutadas por cuenta y solicitudes exactas demasiado grandes para mostrarse por completo en un formulario. Los formularios están limitados a 128 KiB de texto de revisión; la revisión web conserva la vista previa y las entradas completas.

Para elegir WordPress como el único lugar donde decidir un nuevo trabajo, pide al asistente que lo prepare con review_mode: "web". Esto funciona para trabajos en sitios directos y trabajos de red delegados. No se ofrece ningún formulario de confirmación del cliente para ese trabajo, y las respuestas del cliente MCP no pueden aprobarlo ni rechazarlo. Aun así debes iniciar sesión y tomar tu decisión en approval_url. El review_mode: "auto" predeterminado conserva el formulario del cliente y la alternativa web descritos anteriormente.

Usa el modo web cuando prefieras revisar en WordPress o cuando el cliente no presente las confirmaciones de forma fiable. El modo queda fijado cuando se crea el trabajo; no puede reabrir un trabajo rechazado ni cambiar una decisión existente. Prepara en su lugar una nueva revisión para el trabajo restante confirmado.

1. Abre tú mismo la approval_url devuelta. Inicia sesión en ese sitio de WordPress como el usuario que autorizó la conexión, o como el usuario de servicio configurado para una conexión por clave de API. Si los visitantes no autenticados son redirigidos, inicia sesión a través de tu página de acceso habitual y vuelve a abrir el enlace.
2. Comprueba el sitio, las operaciones y las vistas previas. Expande Exact request para inspeccionar las entradas.
3. Selecciona Approve these changes o Reject e indica al asistente tu decisión.
4. El asistente comprueba o reanuda con el mismo approval_id; no se necesita ninguna revisión web adicional por lote en un trabajo preparado.

Tras enviar, el navegador abre de nuevo la revisión con su estado guardado. Actualizar o enviar un formulario antiguo no cambia una decisión existente. El estado de la revisión y del trabajo identifica si se registró una nueva decisión a través de WordPress o del cliente MCP. Una revisión rechazada no puede aprobarse de nuevo; pide al asistente que prepare una revisión nueva. Una decisión de formulario ausente o no válida deja el estado existente sin cambios.

El asistente nunca debe aprobar mediante automatización del navegador ni inventar una confirmación del cliente. El cliente MCP es responsable de presentar la decisión a su usuario. Evita configuraciones del cliente o ganchos que respondan automáticamente a los formularios de aprobación cuando quieras revisar personalmente cada trabajo.

Las nuevas revisiones multisitio delegadas se abren en el sitio principal. Inicia sesión allí como el superadministrador que autorizó la conexión de red; no se necesita ningún inicio de sesión en el navegador en el destino. La revisión identifica el destino, y los cambios siguen ejecutándose con el tema y los complementos de ese destino. Las revisiones existentes creadas antes de que este comportamiento estuviera disponible conservan el enlace de su sitio original. Enruta pom_site_prepare_write_job a través de pom_network_execute_site; enruta las lecturas de estado a través de pom_network_read_site. Coloca el approval_id compartido dentro de los argumentsde cada operación delegada, junto a su site_idde destino. El cliente del sitio principal puede presentar la revisión del destino en su diálogo de formulario.

Autorizar una sesión de trabajo en red

Para el trabajo iterativo donde las entradas posteriores aún no se conocen, un superadministrador de red puede autorizar un work sessiontemporal. Cubre un destino y una conexión OAuth. Las revisiones exactas siguen siendo la opción predeterminada; solicitar una sesión no la autoriza ni aplica cambios.

1. Descubre el destino a través de la conexión de red del sitio principal. Activa los grupos de escritura necesarios en Network Admin → Settings → POM AI Network MCP.
2. Enruta pom_site_request_work_session a través de pom_network_execute_site, con el site_idde destino, un title, groups descriptivo, duration_hours y 1, 4 opcional de 8 o 8(predeterminado dry_run: true ). Una solicitud de
3. Abre approval_url en el sitio principal. Revisa el destino, la duración, los grupos y la lista completa de Allowed operations . Selecciona Authorize this work session o Reject tú mismo. La sesión no puede aprobarse mediante un formulario de cliente MCP.
4. Lee pom_site_get_work_session a través de pom_network_read_site, pasando el work_session_id devuelto y el site_idde destino. Espera session_status: approved.
5. Para cada escritura permitida, coloca work_session_id y un nuevo UUID operation_id dentro de los argumentsde la herramienta delegada. No envíes también approval_id. Las entradas pueden evolucionar dentro del alcance aprobado; lee las revisiones actuales e inspecciona cada vista previa y resultado.
6. Abre la misma URL de revisión y selecciona Revoke this work session cuando termines. La revocación detiene las operaciones posteriores; una operación ya iniciada puede terminar.

Los identificadores de grupo disponibles son site_content_writes, theme_writes, option_writes, woocommerce_writes y cache_writes. Solo pueden solicitarse los grupos habilitados y las herramientas permitidas por los ámbitos de la conexión. La configuración de escritura anterior solo de páginas no habilita las sesiones de trabajo. El allowed_tools devuelto es autoritativo: las herramientas de eliminación, la moderación de comentarios, la configuración del modelo de contenido y los planes de autoría compuestos conservan la aprobación exacta. Las herramientas recién disponibles requieren una sesión nueva.

Una solicitud pendiente debe aprobarse en un plazo de 15 minutos. La duración de sesión seleccionada comienza cuando la apruebas. Cada sesión admite como máximo 500 ID de operación. Cada ID puede iniciarse una vez; su recibo registra la herramienta, el estado y el momento. Nunca sustituyas un ID para repetir una escritura con resultado desconocido. Inspecciona primero la tarea, los recibos de sesión y el destino. Una operación incompleta o incierta pausa la sesión; prepara una sesión nueva o una revisión exacta solo para el trabajo restante confirmado.

Una renovación OAuth normal conserva la sesión. Reconectar con una nueva autorización, cambiar la política de red o la identidad del sitio, revocar el acceso, perder permisos o alcanzar la caducidad impide su uso posterior. Una sesión nunca añade ámbitos OAuth ni capacidades de WordPress, y cada ejecución sigue comprobando los grupos de escritura y las revisiones actuales de la red. Autoriza cambios futuros admitidos dentro de su alcance, no una reversión automática ni un permiso para superar tu tarea.

Permisos y recuperación

En Settings → POM AI → MCP server → Write permissions, habilita solo los grupos necesarios para la tarea:

Cada operación sigue necesitando sus ámbitos OAuth, capacidades de WordPress, revisión actual y grupos de escritura abiertos en el momento de la ejecución. La aprobación no puede añadir permisos. Los propietarios de la red configuran los grupos delegados en Network Admin → Settings → POM AI Network MCP.

Los objetivos o vistas previas modificados se rechazan. Una operación fallida o aplicada parcialmente pausa su trabajo, y una operación que sigue marcada como executing debe inspeccionarse antes de continuar. Lee el destino y prepara una nueva revisión para el trabajo restante confirmado. Nunca repitas todo el trabajo después de un tiempo de espera. Los cambios completados permanecen aplicados; un trabajo no es una transacción de base de datos ni una anulación automática.

Relacionado: Organizar taxonomías, Gestionar sitios web multisitio, Mapa de capacidades de MCP.