orquestra-mcp 1.26.0 → 1.27.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "orquestra-mcp",
-  "version": "1.26.0",
-  "description": "Servidor MCP de Orquestra -- 109 tools para leer y escribir tareas, ideas, changelog, infraestructura, contenido, QA y más desde un agente de IA",
+  "version": "1.27.0",
+  "description": "Servidor MCP de Orquestra -- 112 tools para leer y escribir tareas, ideas, changelog, infraestructura, contenido, QA y más desde un agente de IA",
   "type": "module",
   "bin": {
     "orquestra-mcp": "bin/orquestra-mcp.mjs"

package/src/server.mjs

@@ -924,7 +924,7 @@ export function createServer() {
   server.registerTool(
     'publish_content_postproxy',
     {
-      description: 'Publica o programa una pieza de Contenido en redes sociales vía Postproxy -- solo funciona si la pieza tiene al menos una variante en estatus "approved" y su canal ya está conectado (ver connect_postproxy_channel/list_channels). Respeta approvalRequired -- no la llames para saltarte una aprobación pendiente. Cada variante aprobada va en SU PROPIO post de Postproxy (caption/media/fecha propios); antes de cada uno el server verifica el perfil EN VIVO y rechaza con un 400 claro si la cuenta está vencida, ya no existe, o (Instagram/TikTok) vive en el group de Postproxy de otro proyecto -- es decir, el canal apunta a la cuenta de otro proyecto y hay que reconectarlo. Devuelve {posts:[{channelId, postproxyPostId, status}], failed:[{channelId, channelName, error}]}: con éxito parcial responde 200 igual, así que revisa `failed` y cuéntaselo al usuario -- cada variante queda con su externalGuid o su publishError en la pieza.',
+      description: 'Publica o programa una pieza de Contenido en redes sociales vía Postproxy -- solo funciona si la pieza tiene al menos una variante en estatus "approved" y su canal ya está conectado (ver connect_postproxy_channel/list_channels). Si el workspace todavía no tiene Postproxy habilitado (BAJO SOLICITUD, ver connect_postproxy_channel), responde 403 `postproxy_not_enabled` -- no reintentes, dile al usuario que un admin lo solicite desde Contenido → Cuentas conectadas → "Solicitar conexión". Respeta approvalRequired -- no la llames para saltarte una aprobación pendiente. Cada variante aprobada va en SU PROPIO post de Postproxy (caption/media/fecha propios); antes de cada uno el server verifica el perfil EN VIVO y rechaza con un 400 claro si la cuenta está vencida, ya no existe, o (Instagram/TikTok) vive en el group de Postproxy de otro proyecto -- es decir, el canal apunta a la cuenta de otro proyecto y hay que reconectarlo. Devuelve {posts:[{channelId, postproxyPostId, status}], failed:[{channelId, channelName, error}]}: con éxito parcial responde 200 igual, así que revisa `failed` y cuéntaselo al usuario -- cada variante queda con su externalGuid o su publishError en la pieza.',
       inputSchema: {
         projectId: z.string().optional().describe(PROJECT_ID_DESC),
         contentId: z.string().describe('Pieza de Contenido a publicar (ver list_content)'),
@@ -941,6 +941,79 @@ export function createServer() {
     }
   )
 
+  // sync_content_postproxy / reschedule_content_postproxy (10 oct 2026, a
+  // pedido de José: "todo esto que estamos haciendo en web, también se
+  // puede hacer por MCP?") -- paridad con los botones "Consultar ahora" y
+  // "Reagendar en Postproxy" de ContentDetail.jsx, que hasta ahora solo
+  // existían en la web. Mismo criterio que publish_content_postproxy
+  // (server.registerTool directo, no CRUD estándar).
+  server.registerTool(
+    'sync_content_postproxy',
+    {
+      description: 'Pide el estado REAL de Postproxy para las variantes ya enviadas de una pieza (con externalGuid), en vez de esperar pasivamente el webhook -- usala si una pieza quedó "esperando confirmación" más tiempo del esperado (el webhook de Postproxy se perdió o tardó) o si el usuario pregunta "¿ya se publicó?" y querés confirmarlo ahora en vez de asumir. Actualiza status/publishedAt/postproxyPermalink/publishError en Firestore si Postproxy tiene novedades, y siempre estampa lastPostproxyCheckAt aunque no haya cambios -- también si la pieza ya está agendada a futuro (scheduledAt), en cuyo caso Postproxy SIEMPRE va a responder "todavía no", no es un error ni señal de que algo falló. Devuelve {checked}: cuántas variantes con externalGuid se consultaron (0 si la pieza nunca se envió a Postproxy). Después de llamarla, volvé a leer la pieza con list_content para ver si cambió -- la respuesta de esta tool no trae el contenido actualizado.',
+      inputSchema: {
+        projectId: z.string().optional().describe(PROJECT_ID_DESC),
+        contentId: z.string().describe('Pieza de Contenido a consultar (ver list_content)'),
+      },
+    },
+    async ({ projectId, contentId }) => {
+      try {
+        const data = await apiPost(config, `/v1/content/${contentId}/sync-postproxy`, { projectId: resolveProjectId(projectId) })
+        return textResult(data)
+      } catch (err) {
+        return errorResult(err)
+      }
+    }
+  )
+
+  server.registerTool(
+    'reschedule_content_postproxy',
+    {
+      description: 'Reagenda en Postproxy un canal de una pieza YA enviado (con externalGuid). Cambiar scheduledAt con update_content SOLO escribe Firestore -- el post real en Postproxy sigue en la hora VIEJA hasta llamar esta tool, así que después de mover la fecha con update_content llamá siempre a esta para que el cambio aplique de verdad. Postproxy solo deja editar drafts o posts programados a MÁS de 5 minutos de su hora real de publicación -- devuelve 422 "Post cannot be edited..." si ya se publicó o está a menos de 5 minutos, ese mensaje sube tal cual, no hay forma de evitarlo. Si sale bien, también actualiza scheduledAt en Firestore para esa variante (no hace falta un update_content aparte). channelId tiene que ser un canal que la pieza YA tenga y que ya esté enviado a Postproxy (ver list_content) -- si no tiene externalGuid todavía, falla con 400 explicando que primero hay que publish_content_postproxy.',
+      inputSchema: {
+        projectId: z.string().optional().describe(PROJECT_ID_DESC),
+        contentId: z.string().describe('Pieza de Contenido a reagendar (ver list_content)'),
+        channelId: z.string().describe('Canal ya enviado a Postproxy (con externalGuid) dentro de esa pieza'),
+        scheduledAt: z.number().describe('Nuevo timestamp en ms de cuándo debe publicarse'),
+      },
+    },
+    async ({ projectId, contentId, channelId, scheduledAt }) => {
+      try {
+        const data = await apiPost(config, `/v1/content/${contentId}/reschedule-postproxy`, { projectId: resolveProjectId(projectId), channelId, scheduledAt })
+        return textResult(data)
+      } catch (err) {
+        return errorResult(err)
+      }
+    }
+  )
+
+  // backfill_channel_content (10 oct 2026, a pedido de José: "agregar canal
+  // y agregar los contenidos que aún no se publican... para que todos
+  // estén parejos") -- recorre TODO el proyecto en un solo llamado, no una
+  // pieza a la vez (equivalente en bulk al botón "Copiar contenido acá" de
+  // ContentDetail.jsx en la web, que solo opera sobre una pieza). No es CRUD
+  // estándar (no crea ni edita UNA entidad con un id propio), así que va
+  // con server.registerTool directo, mismo criterio que publish_content_postproxy.
+  server.registerTool(
+    'backfill_channel_content',
+    {
+      description: 'Agrega un canal a TODAS las piezas de Contenido del proyecto que todavía no lo tienen, copiando caption/media/prompts/formato de otro canal que sí los tenga -- para que un canal recién conectado (ej. LinkedIn) no arranque en blanco pieza por pieza. Solo toca piezas pendientes: se SALTEA automáticamente una pieza si el canal fuente ya está en estatus "published" ahí, si el canal fuente no tiene contenido real que copiar, o si la pieza ya tiene el canal destino. NUNCA pisa fecha (scheduledAt)/aprobación/estatus/desempeño -- el canal nuevo arranca siempre en estatus "idea", sin fecha, cada canal programa/aprueba por separado. Devuelve {updated, updatedIds, skipped, skippedDetail:[{id,title,reason}], failed}: revisa `failed` (reintentos que fallaron la escritura) y contale al usuario cuántas piezas se saltearon y por qué, no asumas que "updated" es el total de piezas del proyecto.',
+      inputSchema: {
+        projectId: z.string().optional().describe(PROJECT_ID_DESC),
+        channelId: z.string().describe('Canal a agregar donde falte (ver list_channels) -- recién conectado o con pocas piezas todavía'),
+        sourceChannelId: z.string().describe('Canal del que copiar el contenido en cada pieza (ver list_channels) -- tiene que ser distinto de channelId'),
+      },
+    },
+    async ({ projectId, channelId, sourceChannelId }) => {
+      try {
+        const data = await apiPost(config, '/v1/content/backfill-channel', { projectId: resolveProjectId(projectId), channelId, sourceChannelId })
+        return textResult(data)
+      } catch (err) {
+        return errorResult(err)
+      }
+    }
+  )
+
   // Checklist de una tarea -- registradas directo con server.registerTool
   // (no con registerCreate/registerUpdate) porque su ruta necesita DOS ids
   // dinámicos (taskId + itemId del checklist), y esos helpers solo arman