Muse Code: configurar MCP, skills y workflows

Elige la extensión adecuada para la tarea

Haz una prueba concreta. En un gestor de incidencias, utiliza una incidencia inocua que conozcas. Para una skill, elige un cambio existente con un defecto fácil de identificar. Así podrás distinguir una conexión que funciona de una explicación que simplemente parece convincente.

Conecta un servidor MCP y verifica sus herramientas

Muse lee los servidores del bloque mcp_servers de sus ajustes. La ruta habitual es ~/.config/muse/settings.json. Conserva la configuración existente al añadir un servidor y mantén schema_version: 1. Usa el comando o la URL reales que publique su proveedor. La referencia de extensiones documenta los transportes disponibles.

Integra esta entrada en tus ajustes actuales; no sustituyas el archivo entero. La URL es un ejemplo. Cámbiala por el endpoint MCP real de tu servidor antes de arrancar Muse. Aquí el servidor es obligatorio porque la tarea depende de él.

{
  "schema_version": 1,
  "mcp_servers": {
    "issue-tracker": {
      "transport": "streamable_http",
      "url": "https://mcp.example.com/mcp",
      "headers": {},
      "enabled": true,
      "mode": "required"
    }
  }
}

muse mcp login issue-tracker

Este ejemplo presupone un servidor remoto ya configurado con el nombre issue-tracker que requiere OAuth. Sustituye el nombre por el de tu servidor. Autenticarse en Muse y autenticarse en una herramienta externa son comprobaciones separadas. Dentro de la sesión interactiva, abre /mcp y confirma la conexión antes de pedir datos.

Solicita un elemento conocido y compara sus campos con la fuente. No empieces pidiendo cambios en cien incidencias. Si el inventario de herramientas está vacío, conserva el nombre del servidor y su error de inicio; investiga la conexión antes de reescribir la petición.

Por qué un servidor puede bloquear el arranque

El fallo de un servidor MCP requerido interrumpe el inicio. Marcarlo como opcional cambia ese comportamiento, así que decide según la dependencia real de la tarea. Un calendario puede ser opcional para revisar código. Una comprobación obligatoria de políticas no debería omitirse en silencio porque resulte incómoda de arrancar.

Comprueba la ruta del ejecutable, sus argumentos y el entorno disponible para el proceso que abre Muse. Un servidor que funciona desde tu shell puede depender de un perfil o una variable ausentes en una app de escritorio. Evita pegar tokens resueltos en ejemplos de configuración o logs de soporte. Cambia un ajuste cada vez y repite la misma lectura pequeña.

Si falla al retomar una sesión, distingue entre la conversación original y una bifurcación e incluye el error exacto. Parte de la conversación que contiene tu tarea en lugar de crear copias hasta que alguna se abra.

Convierte una revisión repetida en una skill

muse skills list
muse skills inspect review-validation

El segundo comando presupone que existe una skill con ese identificador. Una skill del proyecto puede guardarse en .agents/skills/review-validation/SKILL.md. Examina sus instrucciones antes de ejecutarla, sobre todo si procede de otro repositorio. Si no aparece en la lista, comprueba la ruta y la confianza concedida al proyecto.

---
name: review-validation
description: Revisa cambios de validación y aporta evidencia sin modificar archivos.
---

Revisa el cambio de validación actual y quién usa ese código.
Identifica una entrada que deba fallar y otra que deba pasar.
Ejecuta el test específico existente cuando esté disponible.
Entrega referencias a archivos y problemas pendientes. No edites.

Guarda el archivo en .agents/skills/review-validation/SKILL.md, valídalo y abre Muse en el proyecto de confianza. Ejecuta /review-validation. Pruébalo con un diff que contenga un caso límite conocido y comprueba que la revisión lo detecta.

muse skills validate .agents/skills/review-validation
muse skills list

Comprueba los workflows antes de depender de ellos

Si tu versión los admite, la guía oficial de workflows explica los grupos paralelos y las fases dependientes. Prueba primero una revisión de lectura antes de permitir que varios agentes escriban. Exige evidencia para cada hallazgo y pide a un revisor final que descarte las afirmaciones sin fundamento.

Si hay workflows disponibles, revisa este cambio con dos lectores.
Uno comprueba compatibilidad de API; otro, cobertura de tests.
Un revisor final contrasta los hallazgos con el diff real.
Entrega un informe con referencias a archivos. No edites ni hagas commits.

Si no están disponibles, haz esas dos revisiones en secuencia en una sesión normal. Mantén separadas las preguntas y sus resultados. El trabajo paralelo ahorra tiempo cuando las tareas son independientes; aporta poco a una edición pequeña con un único test claro.

Separa la coordinación del aislamiento de archivos

La mensajería nativa entre sesiones conecta sesiones locales compatibles en macOS y Linux; no está disponible en Windows. Un mensaje puede transmitir un hallazgo, pero no fusiona directorios ni aprueba acciones por el destinatario. Usa worktrees de Git distintos para agentes que escriban en paralelo y revisa los cambios antes de integrarlos.

La integración de CodeAgentSwarm sigue en beta para una próxima versión. Empieza con una tarea verificada en la CLI y revisa el modelo y sus condiciones de datos antes de conectar servicios privados.