Hermes에서 MCP 사용

기준일: 2026-08-02
난이도: 중급
공식 기준: Use MCP with Hermes

개요

MCP가 무엇인지는 별도 기능 문서가 다루고, 이 가이드는 실제 하루 단위 워크플로에서 MCP로 빠르고 안전하게 가치를 뽑아내는 방법을 다룹니다. 핵심은 "일단 다 연결"이 아니라 "필요한 것만, 가장 작은 표면으로 연결"입니다.

핵심 개념

개념	설명
least privilege	필요한 도구만 노출하는 최소 권한 원칙
include/exclude	서버별 도구 화이트리스트/블랙리스트
utility wrappers	Hermes가 추가하는 resources/prompts 래퍼
reload	`/reload-mcp`로 설정 변경 재적용

선택 기준

MCP를 쓰기 좋은 경우:

이미 MCP 형태로 존재하는 도구가 있어서 Hermes 네이티브 도구를 새로 만들고 싶지 않을 때
깔끔한 RPC 레이어로 로컬·원격 시스템을 조작하고 싶을 때
서버별로 세밀하게 노출 범위를 통제하고 싶을 때
Hermes 코어를 건드리지 않고 사내 API·DB·시스템에 연결하고 싶을 때

MCP를 쓰지 않는 게 나은 경우:

이미 내장 Hermes 도구로 충분히 해결되는 작업일 때
서버가 위험한 도구를 대량으로 노출하는데 필터링할 준비가 안 됐을 때
아주 좁은 통합 하나만 필요해서 네이티브 도구가 더 단순하고 안전할 때

멘탈 모델: MCP는 어댑터 레이어입니다.

Hermes는 그대로 에이전트로 남는다
MCP 서버는 도구를 제공한다
Hermes는 시작 시점 또는 reload 시점에 그 도구들을 발견한다
모델은 그 도구를 일반 도구처럼 쓸 수 있다
각 서버를 얼마나 노출할지는 사용자가 통제한다

좋은 MCP 사용은 "전부 연결"이 아니라 "맞는 것을, 가장 작은 유용한 표면으로 연결"하는 것입니다.

실습

1단계: MCP 지원 설치

표준 설치 스크립트로 Hermes를 설치했다면 MCP 지원은 이미 포함되어 있습니다(설치 스크립트가 uv pip install -e ".[all]"을 실행하기 때문입니다). extras 없이 설치했고 MCP만 추가해야 한다면:

cd ~/.hermes/hermes-agent
uv pip install -e ".[mcp]"

npm 기반 서버를 쓰려면 Node.js와 npx가 있어야 합니다. 많은 Python MCP 서버에는 uvx가 좋은 기본값입니다.

2단계: 서버 하나부터 추가

안전한 서버 하나로 시작합니다. 예를 들어 프로젝트 디렉터리 하나로 범위를 좁힌 파일시스템 접근입니다.

mcp_servers:
  project_fs:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/my-project"]

Hermes를 시작합니다.

hermes chat

구체적으로 물어봅니다.

이 프로젝트를 살펴보고 저장소 구조를 요약해줘.

3단계: 로드 검증

MCP가 로드됐는지는 몇 가지 방법으로 확인할 수 있습니다.

설정이 되어 있으면 Hermes 배너·상태 표시에 MCP 통합이 나타나야 한다
Hermes에게 지금 쓸 수 있는 도구가 뭔지 물어본다
설정을 바꾼 뒤에는 /reload-mcp를 쓴다
서버 연결에 실패했다면 로그를 확인한다

실전 테스트 프롬프트입니다.

지금 사용할 수 있는 MCP 기반 도구가 뭔지 알려줘.

4단계: 즉시 필터링 시작

서버가 도구를 많이 노출한다면 나중으로 미루지 않습니다.

예시: 원하는 것만 화이트리스트

mcp_servers:
  github:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "***"
    tools:
      include: [list_issues, create_issue, search_code]

민감한 시스템에는 대체로 이 방식이 기본값으로 가장 낫습니다.

예시: 위험한 액션 블랙리스트

mcp_servers:
  stripe:
    url: "https://mcp.stripe.com"
    headers:
      Authorization: "Bearer ***"
    tools:
      exclude: [delete_customer, refund_payment]

예시: 유틸리티 래퍼도 끄기

mcp_servers:
  docs:
    url: "https://mcp.docs.example.com"
    tools:
      prompts: false
      resources: false

WSL2: WSL의 Hermes를 Windows Chrome에 연결

다음 조건에 해당할 때 실용적인 구성입니다.

Hermes가 WSL2 안에서 실행 중이다
제어하고 싶은 브라우저는 Windows에 로그인된 평소 쓰는 Chrome이다
/browser connect가 WSL에서 어색하거나 불안정하다

이 구성에서 Hermes는 Chrome에 직접 연결하지 않습니다. 대신,

Hermes는 WSL 안에서 실행되고
Hermes가 로컬 stdio MCP 서버를 띄우고
그 MCP 서버는 Windows interop(cmd.exe 또는 powershell.exe)을 통해 실행되며
그 MCP 서버가 실행 중인 Windows Chrome 세션에 붙습니다

멘탈 모델은 다음과 같습니다.

Hermes (WSL) -> MCP stdio bridge -> Windows Chrome

이 방식이 유용한 이유입니다.

실제 Windows 브라우저 프로필·쿠키·로그인 상태를 그대로 쓸 수 있다
Hermes는 지원되는 Unix 환경(WSL2)에 그대로 머문다
브라우저 제어가 Hermes 코어 브라우저 전송에 의존하지 않고 MCP 도구로 노출된다

추천 서버는 chrome-devtools-mcp입니다. Windows Chrome에서 chrome://inspect/#remote-debugging으로 원격 디버깅이 이미 켜져 있다면 WSL에서 다음과 같이 추가합니다.

hermes mcp add chrome-devtools-win --command cmd.exe --args /c npx -y chrome-devtools-mcp@latest --autoConnect --no-usage-statistics

저장한 뒤 확인합니다.

hermes mcp test chrome-devtools-win

그다음 새 Hermes 세션을 시작하거나 다음을 실행합니다.

/reload-mcp

로드된 뒤에는 MCP 접두어가 붙은 브라우저 도구를 바로 쓸 수 있습니다. 예를 들어 다음과 같이 요청합니다.

MCP 도구 mcp_chrome_devtools_win_list_pages를 호출해서 지금 열려 있는 브라우저 탭 목록을 보여줘.

/browser connect가 맞지 않는 경우: Hermes가 WSL에서, Chrome이 Windows에서 실행 중이면 Chrome이 열려 있고 디버깅 가능해도 /browser connect가 실패할 수 있습니다. 흔한 이유는 다음과 같습니다.

WSL이 Chrome이 Windows 도구에 노출하는 host-local 엔드포인트에 똑같이 접근할 수 없다
최신 Chrome의 라이브 디버깅 흐름이 예전의 단순한 ws://localhost:9222 방식과 다르다
Windows 쪽 헬퍼(chrome-devtools-mcp 등)로 붙는 편이 더 쉽다

이런 경우 같은 환경 안에서는 /browser connect를 그대로 쓰고, WSL-Windows 간 브라우저 브리징에는 MCP를 씁니다.

알려진 함정

Windows용 stdio 실행 파일을 MCP로 쓸 때는 /mnt/c/Users/<you>나 /mnt/c/workspace/... 같은 Windows 마운트 경로에서 Hermes를 실행합니다.
/root나 /home/...에서 Hermes를 시작하면 MCP 서버가 뜨기 전에 Windows가 UNC 현재 디렉터리 경고를 낼 수 있습니다.
chrome-devtools-mcp --autoConnect가 페이지 목록을 가져오다 타임아웃되면 백그라운드·멈춘 탭 수를 줄이고 다시 시도합니다.

필터가 실제로 영향을 주는 것

Hermes에서 MCP가 노출하는 기능은 두 종류입니다.

서버 네이티브 MCP 도구 — tools.include / tools.exclude로 필터
Hermes가 추가하는 유틸리티 래퍼 — tools.resources / tools.prompts로 필터

보일 수 있는 유틸리티 래퍼입니다.

Resources: list_resources, read_resource
Prompts: list_prompts, get_prompt

이 래퍼들은 설정에서 허용되어 있고 MCP 서버 세션이 실제로 그 capability를 지원할 때만 나타납니다. 그래서 Hermes는 서버가 지원하지 않는 resources/prompts를 있는 것처럼 보여주지 않습니다.

공통 패턴

패턴 1: 로컬 프로젝트 어시스턴트 — 경계가 있는 워크스페이스에서 Hermes가 추론하도록 repo-local 파일시스템·git 서버에 MCP를 씁니다.

mcp_servers:
  fs:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/project"]
  git:
    command: "uvx"
    args: ["mcp-server-git", "--repository", "/home/user/project"]

좋은 프롬프트:

프로젝트 구조를 살펴보고 설정이 어디에 있는지 알려줘.

로컬 git 상태를 확인하고 최근 변경 사항을 요약해줘.

패턴 2: Open Scaffold로 repo-native 작업 기록 남기기 — Hermes가 저장소의 지속적인 AI 작업 기록(mission, plans, evidence notes, handoff packets, review/gate 결과)을 읽게 하고 싶을 때 씁니다. Hermes는 그대로 에이전트로 남고 Open Scaffold는 repo-local 기록으로 남습니다.

스캐폴딩된 저장소 하나에 서버를 추가합니다.

hermes mcp add open_scaffold --command npx --args -y open-scaffold@latest mcp serve --repo /absolute/path/to/repo
hermes mcp test open_scaffold

노출 표면은 읽기 중심으로 유지합니다. hermes mcp add 프롬프트에서 select를 고르거나 나중에 config.yaml을 직접 고칩니다.

mcp_servers:
  open_scaffold:
    command: "npx"
    args: ["-y", "open-scaffold@latest", "mcp", "serve", "--repo", "/absolute/path/to/repo"]
    tools:
      include:
        - list_plans
        - get_plan
        - get_mission
        - list_evidence
        - get_evidence
        - get_status
        - search_plans
        - list_amendments
        - get_handoff
        - analyze_loop
        - gate_loop
      prompts: false

좋은 프롬프트:

Open Scaffold MCP 도구로 현재 handoff packet을 정리하고, 다음에 취할 수 있는 정당한 행동이 뭔지 알려줘.

활성 plan과 evidence note를 살펴보고, 이 저장소가 사람 리뷰를 받을 준비가 됐는지 아니면 한 번 더 작업이 필요한지 말해줘.

경계 사항:

Open Scaffold MCP는 기본적으로 local-first이고 읽기 전용입니다.
쓰기 도구는 서버가 --allow-write로 시작됐을 때만 동작합니다. Hermes가 .osc 파일을 바꾸길 원할 때만 명시적으로 켭니다.
Open Scaffold는 작업을 기록하고 게이트를 통과시킬 뿐, Hermes에게 머지·배포·런타임 실행 권한을 주지 않습니다.
재현 가능한 도구 스키마가 필요하면 @latest 대신 open-scaffold@<version>으로 버전을 고정합니다.

패턴 3: GitHub 트리아지 어시스턴트

mcp_servers:
  github:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "***"
    tools:
      include: [list_issues, create_issue, update_issue, search_code]
      prompts: false
      resources: false

좋은 프롬프트:

MCP에 관한 열린 이슈를 목록화하고 주제별로 묶은 다음, 가장 흔한 버그에 대해 품질 좋은 이슈 초안을 써줘.

저장소에서 _discover_and_register_server 사용처를 검색하고 MCP 도구가 어떻게 등록되는지 설명해줘.

패턴 4: 내부 API 어시스턴트

mcp_servers:
  internal_api:
    url: "https://mcp.internal.example.com"
    headers:
      Authorization: "Bearer ***"
    tools:
      include: [list_customers, get_customer, list_invoices]
      resources: false
      prompts: false

좋은 프롬프트:

ACME Corp 고객 정보를 찾아서 최근 인보이스 활동을 요약해줘.

이런 자리에서는 exclude 목록보다 엄격한 화이트리스트가 훨씬 낫습니다.

패턴 5: 문서·지식 서버 — 일부 MCP 서버는 직접 액션이라기보다 공유 지식 자산에 가까운 prompts나 resources를 노출합니다.

mcp_servers:
  docs:
    url: "https://mcp.docs.example.com"
    tools:
      prompts: true
      resources: true

좋은 프롬프트:

docs 서버에서 쓸 수 있는 MCP resource 목록을 보여주고, 온보딩 가이드를 읽어서 요약해줘.

docs 서버가 노출하는 prompt 목록을 보여주고 인시던트 대응에 도움이 될 만한 것을 알려줘.

튜토리얼: 필터를 포함한 End-to-End 설정

1단계: 좁은 화이트리스트로 GitHub MCP 추가

mcp_servers:
  github:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "***"
    tools:
      include: [list_issues, create_issue, search_code]
      prompts: false
      resources: false

Hermes를 시작하고 물어봅니다.

코드베이스에서 MCP 관련 참조를 검색하고 주요 통합 지점을 요약해줘.

2단계: 필요할 때만 확장 — 나중에 이슈 업데이트도 필요하면:

tools:
  include: [list_issues, create_issue, update_issue, search_code]

그다음 재적용합니다.

/reload-mcp

3단계: 다른 정책의 두 번째 서버 추가

mcp_servers:
  github:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "***"
    tools:
      include: [list_issues, create_issue, update_issue, search_code]
      prompts: false
      resources: false
  filesystem:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/project"]

이제 두 서버를 함께 씁니다.

로컬 프로젝트 파일을 살펴본 다음, 발견한 버그를 요약하는 GitHub 이슈를 만들어줘.

MCP가 강력해지는 지점이 여기입니다. Hermes 코어를 바꾸지 않고도 여러 시스템을 넘나드는 워크플로를 만들 수 있습니다.

안전한 사용 권장 사항

위험한 시스템에는 화이트리스트를 우선한다 — 금융·고객 대면·파괴적 작업에는 tools.include를 쓰고 가능한 가장 작은 집합으로 시작합니다.
쓰지 않는 유틸리티는 끈다 — 모델이 서버가 제공하는 resources/prompts를 뒤지길 원하지 않으면 끕니다.

tools:
  resources: false
  prompts: false

서버 범위를 좁게 유지한다 — 파일시스템 서버는 홈 디렉터리 전체가 아니라 프로젝트 하나에 루트를 두고, git 서버는 저장소 하나만 가리키고, 내부 API 서버는 기본적으로 읽기 위주 도구만 노출합니다.
설정 변경 후에는 재적용한다

/reload-mcp

다음을 바꾼 뒤에는 항상 재적용합니다: include/exclude 목록, enabled 플래그, resources/prompts 토글, auth 헤더·env.

증상별 트러블슈팅

서버는 연결되는데 기대한 도구가 없다 — tools.include로 필터됐거나 tools.exclude로 제외됐는지, resources: false/prompts: false로 유틸리티 래퍼를 껐는지, 서버가 애초에 resources/prompts를 지원하는지 확인합니다.
서버는 설정했는데 아무것도 로드되지 않는다 — 설정에 enabled: false가 남아 있지 않은지, npx/uvx 같은 실행 커맨드가 존재하는지, HTTP 엔드포인트에 접근 가능한지, auth env·헤더가 맞는지 확인합니다.
왜 MCP 서버가 광고하는 것보다 적은 도구가 보이나 — Hermes가 서버별 정책과 capability-aware 등록을 지키기 때문입니다. 의도된 동작이고 대체로 바람직합니다.
설정을 지우지 않고 MCP 서버를 제거하려면 — enabled: false를 씁니다. 설정은 남기고 연결·등록만 막습니다.

enabled: false

Hermes에 입력할 프롬프트

지금 연결된 MCP 서버 목록과 각 서버의 tools.include/exclude, resources/prompts 설정을 정리해줘.
민감한 서버 중 화이트리스트 없이 열려 있는 게 있으면 알려줘.

체크리스트

서버를 하나씩 추가하고 hermes mcp test나 /reload-mcp로 검증했다.
민감한 서버는 tools.include 화이트리스트로 좁혔다.
쓰지 않는 resources/prompts 래퍼를 껐다.
설정 변경 후 /reload-mcp를 실행했다.
서버를 끌 때는 삭제 대신 enabled: false를 썼다.

다음 단계

Hermes에서 MCP 사용

기준일: 2026-08-02
난이도: 중급
공식 기준: Use MCP with Hermes

개요

핵심 개념

개념	설명
least privilege	필요한 도구만 노출하는 최소 권한 원칙
include/exclude	서버별 도구 화이트리스트/블랙리스트
utility wrappers	Hermes가 추가하는 resources/prompts 래퍼
reload	`/reload-mcp`로 설정 변경 재적용

선택 기준

MCP를 쓰기 좋은 경우:

이미 MCP 형태로 존재하는 도구가 있어서 Hermes 네이티브 도구를 새로 만들고 싶지 않을 때
깔끔한 RPC 레이어로 로컬·원격 시스템을 조작하고 싶을 때
서버별로 세밀하게 노출 범위를 통제하고 싶을 때
Hermes 코어를 건드리지 않고 사내 API·DB·시스템에 연결하고 싶을 때

MCP를 쓰지 않는 게 나은 경우:

이미 내장 Hermes 도구로 충분히 해결되는 작업일 때
서버가 위험한 도구를 대량으로 노출하는데 필터링할 준비가 안 됐을 때
아주 좁은 통합 하나만 필요해서 네이티브 도구가 더 단순하고 안전할 때

멘탈 모델: MCP는 어댑터 레이어입니다.

Hermes는 그대로 에이전트로 남는다
MCP 서버는 도구를 제공한다
Hermes는 시작 시점 또는 reload 시점에 그 도구들을 발견한다
모델은 그 도구를 일반 도구처럼 쓸 수 있다
각 서버를 얼마나 노출할지는 사용자가 통제한다

좋은 MCP 사용은 "전부 연결"이 아니라 "맞는 것을, 가장 작은 유용한 표면으로 연결"하는 것입니다.

실습

1단계: MCP 지원 설치

cd ~/.hermes/hermes-agent
uv pip install -e ".[mcp]"

npm 기반 서버를 쓰려면 Node.js와 npx가 있어야 합니다. 많은 Python MCP 서버에는 uvx가 좋은 기본값입니다.

2단계: 서버 하나부터 추가

안전한 서버 하나로 시작합니다. 예를 들어 프로젝트 디렉터리 하나로 범위를 좁힌 파일시스템 접근입니다.

mcp_servers:
  project_fs:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/my-project"]

Hermes를 시작합니다.

hermes chat

구체적으로 물어봅니다.

이 프로젝트를 살펴보고 저장소 구조를 요약해줘.

3단계: 로드 검증

MCP가 로드됐는지는 몇 가지 방법으로 확인할 수 있습니다.

설정이 되어 있으면 Hermes 배너·상태 표시에 MCP 통합이 나타나야 한다
Hermes에게 지금 쓸 수 있는 도구가 뭔지 물어본다
설정을 바꾼 뒤에는 /reload-mcp를 쓴다
서버 연결에 실패했다면 로그를 확인한다

실전 테스트 프롬프트입니다.

지금 사용할 수 있는 MCP 기반 도구가 뭔지 알려줘.

4단계: 즉시 필터링 시작

서버가 도구를 많이 노출한다면 나중으로 미루지 않습니다.

예시: 원하는 것만 화이트리스트

mcp_servers:
  github:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "***"
    tools:
      include: [list_issues, create_issue, search_code]

민감한 시스템에는 대체로 이 방식이 기본값으로 가장 낫습니다.

예시: 위험한 액션 블랙리스트

mcp_servers:
  stripe:
    url: "https://mcp.stripe.com"
    headers:
      Authorization: "Bearer ***"
    tools:
      exclude: [delete_customer, refund_payment]

예시: 유틸리티 래퍼도 끄기

mcp_servers:
  docs:
    url: "https://mcp.docs.example.com"
    tools:
      prompts: false
      resources: false

WSL2: WSL의 Hermes를 Windows Chrome에 연결

다음 조건에 해당할 때 실용적인 구성입니다.

Hermes가 WSL2 안에서 실행 중이다
제어하고 싶은 브라우저는 Windows에 로그인된 평소 쓰는 Chrome이다
/browser connect가 WSL에서 어색하거나 불안정하다

이 구성에서 Hermes는 Chrome에 직접 연결하지 않습니다. 대신,

Hermes는 WSL 안에서 실행되고
Hermes가 로컬 stdio MCP 서버를 띄우고
그 MCP 서버는 Windows interop(cmd.exe 또는 powershell.exe)을 통해 실행되며
그 MCP 서버가 실행 중인 Windows Chrome 세션에 붙습니다

멘탈 모델은 다음과 같습니다.

Hermes (WSL) -> MCP stdio bridge -> Windows Chrome

이 방식이 유용한 이유입니다.

실제 Windows 브라우저 프로필·쿠키·로그인 상태를 그대로 쓸 수 있다
Hermes는 지원되는 Unix 환경(WSL2)에 그대로 머문다
브라우저 제어가 Hermes 코어 브라우저 전송에 의존하지 않고 MCP 도구로 노출된다

hermes mcp add chrome-devtools-win --command cmd.exe --args /c npx -y chrome-devtools-mcp@latest --autoConnect --no-usage-statistics

저장한 뒤 확인합니다.

hermes mcp test chrome-devtools-win

그다음 새 Hermes 세션을 시작하거나 다음을 실행합니다.

/reload-mcp

로드된 뒤에는 MCP 접두어가 붙은 브라우저 도구를 바로 쓸 수 있습니다. 예를 들어 다음과 같이 요청합니다.

MCP 도구 mcp_chrome_devtools_win_list_pages를 호출해서 지금 열려 있는 브라우저 탭 목록을 보여줘.

WSL이 Chrome이 Windows 도구에 노출하는 host-local 엔드포인트에 똑같이 접근할 수 없다
최신 Chrome의 라이브 디버깅 흐름이 예전의 단순한 ws://localhost:9222 방식과 다르다
Windows 쪽 헬퍼(chrome-devtools-mcp 등)로 붙는 편이 더 쉽다

이런 경우 같은 환경 안에서는 /browser connect를 그대로 쓰고, WSL-Windows 간 브라우저 브리징에는 MCP를 씁니다.

알려진 함정

Windows용 stdio 실행 파일을 MCP로 쓸 때는 /mnt/c/Users/<you>나 /mnt/c/workspace/... 같은 Windows 마운트 경로에서 Hermes를 실행합니다.
/root나 /home/...에서 Hermes를 시작하면 MCP 서버가 뜨기 전에 Windows가 UNC 현재 디렉터리 경고를 낼 수 있습니다.
chrome-devtools-mcp --autoConnect가 페이지 목록을 가져오다 타임아웃되면 백그라운드·멈춘 탭 수를 줄이고 다시 시도합니다.

필터가 실제로 영향을 주는 것

Hermes에서 MCP가 노출하는 기능은 두 종류입니다.

서버 네이티브 MCP 도구 — tools.include / tools.exclude로 필터
Hermes가 추가하는 유틸리티 래퍼 — tools.resources / tools.prompts로 필터

보일 수 있는 유틸리티 래퍼입니다.

Resources: list_resources, read_resource
Prompts: list_prompts, get_prompt

공통 패턴

패턴 1: 로컬 프로젝트 어시스턴트 — 경계가 있는 워크스페이스에서 Hermes가 추론하도록 repo-local 파일시스템·git 서버에 MCP를 씁니다.

mcp_servers:
  fs:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/project"]
  git:
    command: "uvx"
    args: ["mcp-server-git", "--repository", "/home/user/project"]

좋은 프롬프트:

프로젝트 구조를 살펴보고 설정이 어디에 있는지 알려줘.

로컬 git 상태를 확인하고 최근 변경 사항을 요약해줘.

스캐폴딩된 저장소 하나에 서버를 추가합니다.

hermes mcp add open_scaffold --command npx --args -y open-scaffold@latest mcp serve --repo /absolute/path/to/repo
hermes mcp test open_scaffold

노출 표면은 읽기 중심으로 유지합니다. hermes mcp add 프롬프트에서 select를 고르거나 나중에 config.yaml을 직접 고칩니다.

mcp_servers:
  open_scaffold:
    command: "npx"
    args: ["-y", "open-scaffold@latest", "mcp", "serve", "--repo", "/absolute/path/to/repo"]
    tools:
      include:
        - list_plans
        - get_plan
        - get_mission
        - list_evidence
        - get_evidence
        - get_status
        - search_plans
        - list_amendments
        - get_handoff
        - analyze_loop
        - gate_loop
      prompts: false

좋은 프롬프트:

Open Scaffold MCP 도구로 현재 handoff packet을 정리하고, 다음에 취할 수 있는 정당한 행동이 뭔지 알려줘.

활성 plan과 evidence note를 살펴보고, 이 저장소가 사람 리뷰를 받을 준비가 됐는지 아니면 한 번 더 작업이 필요한지 말해줘.

경계 사항:

Open Scaffold MCP는 기본적으로 local-first이고 읽기 전용입니다.
쓰기 도구는 서버가 --allow-write로 시작됐을 때만 동작합니다. Hermes가 .osc 파일을 바꾸길 원할 때만 명시적으로 켭니다.
Open Scaffold는 작업을 기록하고 게이트를 통과시킬 뿐, Hermes에게 머지·배포·런타임 실행 권한을 주지 않습니다.
재현 가능한 도구 스키마가 필요하면 @latest 대신 open-scaffold@<version>으로 버전을 고정합니다.

패턴 3: GitHub 트리아지 어시스턴트

mcp_servers:
  github:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "***"
    tools:
      include: [list_issues, create_issue, update_issue, search_code]
      prompts: false
      resources: false

좋은 프롬프트:

MCP에 관한 열린 이슈를 목록화하고 주제별로 묶은 다음, 가장 흔한 버그에 대해 품질 좋은 이슈 초안을 써줘.

저장소에서 _discover_and_register_server 사용처를 검색하고 MCP 도구가 어떻게 등록되는지 설명해줘.

패턴 4: 내부 API 어시스턴트

mcp_servers:
  internal_api:
    url: "https://mcp.internal.example.com"
    headers:
      Authorization: "Bearer ***"
    tools:
      include: [list_customers, get_customer, list_invoices]
      resources: false
      prompts: false

좋은 프롬프트:

ACME Corp 고객 정보를 찾아서 최근 인보이스 활동을 요약해줘.

이런 자리에서는 exclude 목록보다 엄격한 화이트리스트가 훨씬 낫습니다.

패턴 5: 문서·지식 서버 — 일부 MCP 서버는 직접 액션이라기보다 공유 지식 자산에 가까운 prompts나 resources를 노출합니다.

mcp_servers:
  docs:
    url: "https://mcp.docs.example.com"
    tools:
      prompts: true
      resources: true

좋은 프롬프트:

docs 서버에서 쓸 수 있는 MCP resource 목록을 보여주고, 온보딩 가이드를 읽어서 요약해줘.

docs 서버가 노출하는 prompt 목록을 보여주고 인시던트 대응에 도움이 될 만한 것을 알려줘.

튜토리얼: 필터를 포함한 End-to-End 설정

1단계: 좁은 화이트리스트로 GitHub MCP 추가

mcp_servers:
  github:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "***"
    tools:
      include: [list_issues, create_issue, search_code]
      prompts: false
      resources: false

Hermes를 시작하고 물어봅니다.

코드베이스에서 MCP 관련 참조를 검색하고 주요 통합 지점을 요약해줘.

2단계: 필요할 때만 확장 — 나중에 이슈 업데이트도 필요하면:

tools:
  include: [list_issues, create_issue, update_issue, search_code]

그다음 재적용합니다.

/reload-mcp

3단계: 다른 정책의 두 번째 서버 추가

mcp_servers:
  github:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "***"
    tools:
      include: [list_issues, create_issue, update_issue, search_code]
      prompts: false
      resources: false
  filesystem:
    command: "npx"
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/project"]

이제 두 서버를 함께 씁니다.

로컬 프로젝트 파일을 살펴본 다음, 발견한 버그를 요약하는 GitHub 이슈를 만들어줘.

MCP가 강력해지는 지점이 여기입니다. Hermes 코어를 바꾸지 않고도 여러 시스템을 넘나드는 워크플로를 만들 수 있습니다.

안전한 사용 권장 사항

위험한 시스템에는 화이트리스트를 우선한다 — 금융·고객 대면·파괴적 작업에는 tools.include를 쓰고 가능한 가장 작은 집합으로 시작합니다.
쓰지 않는 유틸리티는 끈다 — 모델이 서버가 제공하는 resources/prompts를 뒤지길 원하지 않으면 끕니다.

tools:
  resources: false
  prompts: false

서버 범위를 좁게 유지한다 — 파일시스템 서버는 홈 디렉터리 전체가 아니라 프로젝트 하나에 루트를 두고, git 서버는 저장소 하나만 가리키고, 내부 API 서버는 기본적으로 읽기 위주 도구만 노출합니다.
설정 변경 후에는 재적용한다

/reload-mcp

다음을 바꾼 뒤에는 항상 재적용합니다: include/exclude 목록, enabled 플래그, resources/prompts 토글, auth 헤더·env.

증상별 트러블슈팅

서버는 연결되는데 기대한 도구가 없다 — tools.include로 필터됐거나 tools.exclude로 제외됐는지, resources: false/prompts: false로 유틸리티 래퍼를 껐는지, 서버가 애초에 resources/prompts를 지원하는지 확인합니다.
서버는 설정했는데 아무것도 로드되지 않는다 — 설정에 enabled: false가 남아 있지 않은지, npx/uvx 같은 실행 커맨드가 존재하는지, HTTP 엔드포인트에 접근 가능한지, auth env·헤더가 맞는지 확인합니다.
왜 MCP 서버가 광고하는 것보다 적은 도구가 보이나 — Hermes가 서버별 정책과 capability-aware 등록을 지키기 때문입니다. 의도된 동작이고 대체로 바람직합니다.
설정을 지우지 않고 MCP 서버를 제거하려면 — enabled: false를 씁니다. 설정은 남기고 연결·등록만 막습니다.

enabled: false

Hermes에 입력할 프롬프트

지금 연결된 MCP 서버 목록과 각 서버의 tools.include/exclude, resources/prompts 설정을 정리해줘.
민감한 서버 중 화이트리스트 없이 열려 있는 게 있으면 알려줘.

체크리스트

서버를 하나씩 추가하고 hermes mcp test나 /reload-mcp로 검증했다.
민감한 서버는 tools.include 화이트리스트로 좁혔다.
쓰지 않는 resources/prompts 래퍼를 껐다.
설정 변경 후 /reload-mcp를 실행했다.
서버를 끌 때는 삭제 대신 enabled: false를 썼다.

Hermes에서 MCP 사용

개요

핵심 개념

선택 기준

실습

1단계: MCP 지원 설치

2단계: 서버 하나부터 추가

3단계: 로드 검증

4단계: 즉시 필터링 시작

WSL2: WSL의 Hermes를 Windows Chrome에 연결

필터가 실제로 영향을 주는 것

공통 패턴

튜토리얼: 필터를 포함한 End-to-End 설정

안전한 사용 권장 사항

증상별 트러블슈팅

추천 첫 MCP 구성

Hermes에 입력할 프롬프트

체크리스트

다음 단계

관련 가이드

Hermes에서 MCP 사용

개요

핵심 개념

선택 기준

실습

1단계: MCP 지원 설치

2단계: 서버 하나부터 추가

3단계: 로드 검증

4단계: 즉시 필터링 시작

WSL2: WSL의 Hermes를 Windows Chrome에 연결

필터가 실제로 영향을 주는 것

공통 패턴

튜토리얼: 필터를 포함한 End-to-End 설정

안전한 사용 권장 사항

증상별 트러블슈팅

추천 첫 MCP 구성

Hermes에 입력할 프롬프트

체크리스트

다음 단계

관련 가이드