1 puntos por kenjo 4 시간 전 | Aún no hay comentarios. | Compartir por WhatsApp

Problema actual: hay que adaptar por separado los servidores/hooks de MCP para cada CLI de agente

Cuando conectas servidores MCP a varios agent CLI, terminas manteniendo la misma configuración repetida en distintos formatos.

Por ejemplo:

  • Claude Code: JSON mcpServers
  • Codex: TOML [mcp_servers.*]
  • Cursor: mcp.json + hooks.json
  • Gemini: .gemini/settings.json

Solo registrar el servidor ya es engorroso, pero los hooks son todavía más complejos.
Como cada host tiene un modelo de eventos distinto, incluso la misma acción hay que volver a ajustarla para cada CLI.

Por eso creé agent-connector para reducir esta repetición.

Cómo lo resuelve

Si lo defines una sola vez con defineConnector(), se renderiza en los archivos de configuración nativos que cada host realmente lee.

defineConnector({  
  server,  
  hooks,  
  plugins,  
  marketplace,  
})  

No se trata de ejecutar un wrapper intermedio ni de imponer un formato propio.
La idea es generar el JSON, TOML, archivos settings y demás que cada CLI ya usa originalmente.

Alcance de lo que soporta

Actualmente no solo cubre el registro de servidores MCP, sino también las siguientes áreas.

  • Registro de servidores MCP
  • Conversión del modelo de eventos de hooks según el host
  • Empaquetado de plugins / extensiones
  • Flujo de instalación vía marketplace de cada host
  • Instalación masiva para múltiples CLIs
  • Eliminación de configuraciones residuales con uninstall --purge
  • Telemetría de tokens por herramienta
  • Creación de CLIs de marca propia basados en SDK

El usuario lo usaría más o menos así.

$ agent-connector install  
$ agent-connector uninstall --purge  
# o  
$ plugin install brand-name   

Estado actual

Hasta ahora lo estoy desarrollando yo solo.

En lo que más tiempo he invertido es en lo siguiente.

  • Renderizado de configuración cross-host
  • Normalización del modelo de eventos de hooks
  • Empaquetado de plugins / extensiones
  • Flujo de instalación en marketplaces
  • Telemetría
  • Pruebas en Linux / macOS / Windows

Actualmente puede generar configuración para 42 agent CLI.

Lo que ya validé

Como prueba real, porté el MCP existente context-mode.

El resultado fue este.

  • Código de despliegue por host: 20,322 líneas → 76 líneas
  • Scripts de hooks: 71 → 0
  • CLIs soportadas: 15 → 42

Pero este no es un servidor MCP creado por mí, sino un caso de migración de un servidor existente.
Por eso quiero ver más casos que se rompan con una mayor variedad de servidores MCP.

Feedback que estoy buscando

Me ayudaría muchísimo que quienes estén creando servidores MCP lo prueben directamente y me compartan feedback.

En particular, me gustaría recibir comentarios sobre esto.

  • Casos donde la configuración se rompa en un CLI específico
  • Casos donde el modelo de eventos de hooks se quede corto
  • Partes raras o poco naturales en el flujo de plugins / marketplace
  • Aspectos incómodos del diseño de la API
  • Observaciones sobre la estructura del proyecto OSS

Si MCP es la capa que conecta herramientas reales a un agente, creo que hace falta una estructura que no siga quedando atada a la forma en que cada CLI maneja su configuración.

Aún no hay comentarios.

Aún no hay comentarios.