MCP

agent-config: unifica skills y reglas de gobernanza entre varias herramientas de IA, con un endpoint MCP de solo lectura autoalojado

agent-config encaja mejor con desarrolladores que quieren unificar la configuración de varias herramientas de IA con un solo conjunto de skills y reglas de gobernanza y autoalojar un endpoint MCP de solo lectura; antes hace falta Node ≥ 18, y ojo: init escribe únicamente en directorios globales y el lado del Worker ofrece solo contenido de gobernanza de solo lectura.

Official source · event4u-app/agent-config

Install

npx @event4u/agent-config init

agent-config distribuye un conjunto de skills, rules, commands, guidelines y personas vía npm y los proyecta en la configuración nativa de cada herramienta de IA compatible, siguiendo el estándar abierto Agent Skills; el mismo contenido de gobernanza también puede servirse desde tu propio Cloudflare Worker como endpoint MCP. No es un agent runtime: el bucle del agente, el enrutamiento de LLM y la orquestación de herramientas quedan en la herramienta anfitriona. Resuelve un problema muy concreto: un solo conjunto de skills y reglas de gobernanza, sin tener que configurarlo de nuevo en cada herramienta.

Para quién es

  • Para desarrolladores y equipos que alternan entre varias herramientas de IA y quieren mantener skills y reglas de gobernanza coherentes: la capa de contenido se proyecta en la configuración nativa de herramientas anfitrionas como Claude Code, Augment, Cursor, Cline, Windsurf, Gemini CLI y Copilot; se mantiene una vez y se usa en todas.
  • Para personas y equipos que necesitan un endpoint MCP autoalojado: el contenido de gobernanza se sirve desde tu propio Cloudflare Worker, y cualquier cliente MCP —Claude Desktop, Claude Code, Cursor, Zed, Continue, agentes alojados, entre otros— accede por HTTP, sin duplicar el contenido en cada cliente.
  • No sirve como agent runtime: no ejecuta el bucle del agente ni asume el enrutamiento de LLM ni la orquestación de herramientas; si buscas un servicio que ejecute tareas y reparta modelos por ti, esas capacidades viven en la herramienta anfitriona.
  • No va para quien espera un servicio local listo al instalar: el servidor local stdio integrado requiere un checkout local y no es de instalar y usar.
  • Requisito: Node ≥ 18; el resto de requisitos del sistema no aparecen en la evidencia y quedan sin confirmar.

Tu primer intento en 3 minutos

Hay un único camino principal: el comando de instalación canónico oficial más una comprobación de los directorios globales.

  1. Requisito previo: tener Node ≥ 18 instalado en la máquina.
  2. Ejecuta en una terminal el comando canónico oficial: npx @event4u/agent-config init.
  3. Antes de ejecutarlo, ten claros los efectos secundarios: init escribe solo en directorios globales —~/.event4u/agent-config/, ~/.claude/, ~/.cursor/, entre otros—; no escribe archivos de proyecto, y el project scope queda reservado a mantenedores. Es una escritura de estado local, no un envío remoto; la evidencia no describe cómo deshacerlo ni revertirlo: si no tienes claro el impacto, haz antes una copia de seguridad de esos directorios.
  4. Señales de éxito: al terminar el comando, los directorios globales citados contienen lo escrito, y en la configuración nativa de las herramientas compatibles se ven las skills, rules, commands, guidelines y personas proyectadas. Para confirmar antes el alcance, revisa directamente los archivos de esos directorios globales.

La vía de servidor queda como mención secundaria: tras desplegar tu propio Cloudflare Worker, el contenido de gobernanza queda accesible para los clientes como endpoint MCP. La evidencia confirma la capacidad, pero no aporta comandos de despliegue ni fragmentos de configuración; los pasos concretos siguen sin confirmarse. Es una acción de configuración remota: no la trates como paso obligatorio de una puesta en marcha rápida. Al empezar, prefiere las pequeñas herramientas de solo lectura (como memory_lookup y list_*): «solo lectura» significa únicamente que no se ejecutan operaciones de escritura; no implica que no existan otros riesgos ni permite deducir que no haya acceso a la red o lectura de datos locales.

Casos de uso

Caso 1: que Claude Code y Cursor compartan el mismo conjunto de habilidades y reglas. Mantener dos configuraciones por separado tiende a divergir. En una máquina con Node ≥ 18, ejecuta npx @event4u/agent-config init y deja que escriba la capa de contenido en los directorios globales. Resultado esperado dentro de la evidencia: se escriben ~/.event4u/agent-config/, ~/.claude/, ~/.cursor/ y otros directorios, el contenido sigue el estándar abierto Agent Skills y los archivos de tus proyectos quedan intactos; desde entonces, ambos leen el mismo conjunto de skills y rules desde su configuración nativa. Según la descripción oficial, la proyección apunta a cada herramienta compatible, no solo a las dos del ejemplo. Cuándo usar esta vía: cuando las habilidades y las reglas de las dos herramientas han evolucionado por separado y ya no coinciden, y quieres que un único contenido prevalezca. Limitación: solo resuelve la distribución de contenido y no ejecutará ninguna skill por ti dentro de las herramientas.

Caso 2: autoalojar un endpoint MCP de gobernanza de solo lectura. El equipo quiere que varios clientes lean un contenido de gobernanza unificado por HTTP, sin instalar nada máquina por máquina. Sírvelo desde tu Cloudflare Worker como endpoint MCP: el contenido de gobernanza se expone como MCP prompts y resources —skills, commands, rules, guidelines, contexts— junto con las herramientas de solo lectura memory_lookup, chat_history_read y list_*; clientes MCP como Claude Desktop, Claude Code, Cursor, Zed, Continue y agentes alojados pueden acceder por HTTP. Resultado observable: al conectar, el cliente ve este contenido en sus listas de prompts y resources, y puede invocar las herramientas de solo lectura citadas. Ten en cuenta además: el Worker no ejecuta los ~112 scripts de Python (linters, audits, task ci, work-engine hooks); esos requieren instalación local según el Quickstart. Los pasos de despliegue del Worker no constan en la evidencia: solo se puede confirmar hasta la declaración oficial de la capacidad.

Límites de uso

  • Naturaleza de lectura/escritura: el lado del Worker es de solo lectura —el contenido de gobernanza se ofrece como prompts y resources, y las herramientas se limitan a utilidades pequeñas de solo lectura como memory_lookup, chat_history_read y list_*; oficialmente no se menciona ninguna herramienta de escritura. init escribe en local y solo en directorios globales, sin tocar repositorios de proyecto. Las herramientas de solo lectura solo prueban que no se ejecutan escrituras; si hay acceso a la red o lectura de datos locales, la evidencia no lo dice.
  • Efectos secundarios y puntos de comprobación: init escribe en ~/.event4u/agent-config/, ~/.claude/, ~/.cursor/, entre otros; el project scope queda reservado a mantenedores, así que una instalación normal no altera ninguno de tus repositorios de proyecto. La evidencia no describe deshacer ni rollback automáticos, y no enumera los archivos escritos.
  • Límites oficiales: el Worker no ejecuta los ~112 scripts de Python (linters, audits, task ci, work-engine hooks), que requieren instalación local según el Quickstart; el servidor local stdio integrado figura en la Glama MCP Registry solo para descubrimiento y exige un checkout local (véase ADR-067).
  • Verificación de rutas: para repartir contenido en las herramientas, init; para leer el contenido de gobernanza por MCP, el Worker; para ejecutar los scripts de Python, instalación local según el Quickstart y ejecución allí.
  • Aún sin confirmar: comandos de despliegue y fragmentos de configuración del Worker, configuración de conexión concreta de cada cliente y requisitos completos del sistema más allá de Node ≥ 18. La evidencia no cubre nada de esto: antes de actuar, guíate por el repositorio oficial.