Ir al contenido
ComStack

El flujo de trabajo estándar de MCP

Qué es esto

El flujo de trabajo estándar para gestionar un sitio de ComStack mediante MCP, escrito como el bucle de primera ejecución: la ruta que sigue un chat nuevo sin contexto previo. Con solo la URL de una página, un asistente debe resolver el proyecto y la página, abrir el editor correcto, redactar un cambio, obtener la aprobación del usuario y publicar, sin perderse cuando el ID del documento cambia durante el proceso.

Esta página es el complemento legible para humanos de dos recursos de máquina que todo cliente carga: las instrucciones del servidor (enviadas una vez por sesión) y la herramienta get-guide (esquema completo + reglas de Lighthouse). La guía canónica para agentes legible por máquina es también el recurso transformento://guide.

Cómo funciona

El bucle tiene siete pasos:

knowledgecustomPage URLget-project-stateResolve page by slug plus languagepage_typecreate-page / update-pageupload-custom-pageDraft plus approvalpublish dry-runpublish-confirmpublish-status to live URL
  1. Proyecto. Llame primero a get-project-state. Devuelve project_name (repítalo en herramientas destructivas), site_url, available_doc_templates, las páginas en vivo y en borrador, un árbol de nav compacto y una workflow_hint que reafirma este bucle en línea.
  2. Página. Diríjase a una página por su slug + idioma, el identificador duradero. get-page-content y update-page aceptan el ID del documento de Firestore (path) o un par (slug, language); language utiliza por defecto la configuración regional del proyecto. Una referencia que no coincide con nada devuelve un limpio Page not found, nunca un error de base de datos sin procesar.
  3. Editor. Cada página tiene un page_type. Una página de knowledge es markdown (edítela con create-page / update-page). Una página custom es body_source con estilo libre (edítela con upload-custom-page). Se rechazará el uso de la herramienta incorrecta; consulte Tipos de página.
  4. Borrador. Editar una página en vivo nunca la cambia directamente; escribe un borrador y mantiene la URL en vivo. Las ediciones repetidas en la misma página se consolidan en un solo borrador, y una edición sin cambios no crea ningún borrador.
  5. Aprobación. publish es una prueba de simulación: devuelve un manifiesto de diferencias y un confirmation_token de un solo uso (TTL de 5 minutos) sin cambiar nada. Muestre el manifiesto al usuario y obtenga su aprobación explícita, siempre.
  6. Publicación. publish-confirm consume el token, verifica que nada haya cambiado desde la simulación e inicia el despliegue de forma asíncrona, devolviendo { publish_id, status: "running" }.
  7. Verificación. Realice sondeos a publish-status hasta que el estado sea succeeded. Sus published_urls contienen la ruta en vivo resultante (el nuevo ID del documento), por lo que usted lee la identidad post-publicación en lugar de adivinarla.

Cuándo utilizarlo

  • En una sesión de MCP nueva donde la única entrada es una URL de página o una solicitud vaga.
  • Al integrar a un asistente o compañero de equipo en el flujo de publicación de principio a fin.
  • Al depurar “¿en qué paso estoy?” cuando la respuesta de una herramienta es inesperada.

Herramientas en el bucle

PasoHerramientaNotas
Instantánea del proyectoget-project-statePrimera llamada. Incluye workflow_hint, nav y page_type en cada entrada.
Leer una páginaget-page-contentPor path o (slug, language). Devuelve page_type + el path resuelto.
Editar conocimientocreate-page / update-pageMarkdown. Editar en vivo crea un borrador.
Editar personalizadoupload-custom-pagebody_source opaco + marcadores de traducción.
Descartar borradordiscard-draftElimina un borrador pendiente; rechaza rutas en vivo, ocultas o archivadas.
SimulaciónpublishManifiesto + confirmation_token. Sin escrituras.
Desplegarpublish-confirmAsíncrono. Devuelve publish_id.
Sondeopublish-statussucceeded → published_urls.

Ejemplo

“Cambia el titular en https://example.com/pricing/ a ‘Precios simples y honestos’.”

get-project-state(project_id)
  -> project_name, site_url, the pricing page (slug 'pricing', page_type 'knowledge')


update-page(project_id, slug: 'pricing', language: 'en',
            content: '## Simple, honest pricing ...')
  -> { action: 'draft_created_from_live', draft_id, draft_url }


(present the draft_url and the change, get approval, then publish:)
publish(project_id, project_name)
  -> manifest { drafts: [ { slug: 'pricing', change_type: 'replace', will_publish_to } ] },
     confirmation_token   (single-use, 5-min TTL)


publish-confirm(project_id, confirmation_token)
  -> { publish_id, status: 'running' }


publish-status(project_id, publish_id)
  -> { status: 'succeeded', published_urls: [ { slug: 'pricing', url } ] }

Errores comunes

  • Editar con la herramienta incorrecta. Una edición markdown en una página custom (o upload-custom-page en una página de conocimiento) se rechaza con una redirección; verifique primero el page_type. Consulte Tipos de página.
  • Almacenar en caché un ID de documento. El path cambia durante el ciclo de edición-publicación; diríjase a las páginas por (slug, language) y lea el nuevo path desde publish-status. Consulte Publicación.
  • Publicar sin aprobación. publish solo devuelve un token; nada se despliega hasta publish-confirm. Muestre siempre el manifiesto primero.
  • Token expirado. El confirmation_token dura 5 minutos y es de un solo uso; llame a publish de nuevo para obtener uno nuevo.

Los pasos de recuperación completos para cada error estructurado se encuentran en la referencia de errores.

Relacionado

Última actualización: