Show GN: agent-connector: MCP 서버/훅을 여러 에이전트 CLI에 한 번에 배포하는 도구

 (github.com/ken-jo)
1P by kenjo | ★ favorite | 댓글과 토론

현재 문제점: MCP 서버/훅을 에이전트 CLI마다 따로 맞춰야 하는 문제

MCP 서버를 여러 agent CLI에 붙이다 보면 같은 설정을 계속 다른 포맷으로 유지해야 합니다.

예를 들면:

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

서버 등록만 해도 번거로운데, 훅은 더 복잡합니다.
호스트마다 이벤트 모델이 달라서 같은 동작도 CLI별로 다시 맞춰야 합니다.

그래서 이 반복을 줄이려고 agent-connector를 만들었습니다.

해결 방식

defineConnector()로 한 번 정의하면, 각 호스트가 실제로 읽는 네이티브 설정 파일로 렌더링합니다.

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

중간 래퍼를 실행시키거나 독자 포맷을 강제하는 방식은 아닙니다.
각 CLI가 원래 읽는 JSON, TOML, settings 파일 등을 생성하는 방식입니다.

지원 범위

현재는 MCP 서버 등록뿐 아니라 아래 영역까지 다룹니다.

  • MCP 서버 등록
  • 호스트별 훅 이벤트 모델 변환
  • 플러그인 / 익스텐션 패키징
  • 각 호스트의 마켓플레이스 설치 흐름
  • 여러 CLI 대상 일괄 설치
  • uninstall --purge를 통한 잔여 설정 제거
  • per-tool 토큰 텔레메트리
  • SDK 기반 자체 브랜드 CLI 생성

사용자는 대략 이런 식으로 씁니다.

$ agent-connector install  
$ agent-connector uninstall --purge  
# 또는  
$ plugin install brand-name

현재 상태

지금까지는 혼자 만들고 있습니다.

주로 시간을 쓴 부분은 다음과 같습니다.

  • 크로스 호스트 설정 렌더링
  • 훅 이벤트 모델 정규화
  • 플러그인 / 익스텐션 패키징
  • 마켓플레이스 설치 흐름
  • 텔레메트리
  • Linux / macOS / Windows 테스트

현재 42개 agent CLI 대상으로 설정을 생성할 수 있습니다.

검증해본 것

실제 테스트로 기존 MCP인 context-mode를 포팅해봤습니다.

결과는 이렇습니다.

  • 호스트별 배포 코드: 20,322줄 → 76줄
  • 훅 스크립트: 71개 → 0개
  • 지원 CLI: 15개 → 42개

다만 이건 제가 만든 MCP 서버가 아니라 기존 서버를 옮겨본 사례입니다.
그래서 더 다양한 MCP 서버에서 깨지는 케이스를 보고 싶습니다.

찾고 있는 피드백

MCP 서버를 만들고 계신 분들이 직접 올려보고 피드백을 주시면 큰 도움이 됩니다.

특히 이런 피드백을 받고 싶습니다.

  • 특정 CLI에서 설정이 깨지는 케이스
  • 훅 이벤트 모델이 부족한 케이스
  • 플러그인 / 마켓플레이스 흐름에서 어색한 부분
  • API 설계가 불편한 부분
  • OSS 프로젝트 구조에 대한 지적

MCP가 agent에게 실제 도구를 붙여주는 레이어라면, 특정 CLI의 설정 방식에 계속 끌려다니지 않는 구조가 필요하다고 생각합니다.

함께 보면 좋은 글 β