🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Hermes Agent의 Tools & MCP Servers는 모델을 “생각하는 챗봇”에서 파일·웹·브라우저·외부 앱을 실제로 다루는 실행형 에이전트로 바꾸는 핵심 계층이다.

📌 핵심 요점

1. Hermes에서 모델·프로바이더·폴백이 “두뇌”라면, 도구는 파일 읽기, 코드 패치, 웹 검색, 브라우저 조작, 이미지 분석, 플랫폼 연동 같은 실제 작업을 수행하게 하는 “손”에 해당한다.
2. 도구 호출은 모델이 직접 코드를 실행하는 방식이 아니라, 이름·설명·파라미터 스키마를 보고 구조화된 요청을 만들고, Hermes 런타임이 등록된 핸들러를 실행한 뒤 결과를 다시 모델 컨텍스트로 돌려주는 구조다.
3. 툴셋은 세션·플랫폼·작업 목적에 따라 접근 가능한 도구 범위를 정하며, safe 툴셋처럼 파일 쓰기와 터미널을 막고 웹·비전 중심으로 제한하면 실행 표면과 위험을 함께 줄일 수 있다.
4. MCP 서버는 외부 기능을 Hermes에 붙이는 확장 방식이며, 좋은 MCP 사용법은 가능한 모든 서버를 연결하는 것이 아니라 필요한 서버만 붙이고 최소한의 유용한 도구 표면만 노출하는 것이다.
5. Blender MCP, Hermes MCP server, custom stock price tool 사례는 Hermes가 외부 애플리케이션 조작, 다른 클라이언트에 도구 제공, 반복 API 작업 자동화까지 확장될 수 있음을 보여준다.

🧩 배경과 문제 정의

• Hermes Agent에서 모델, 프로바이더, 폴백, 로컬 추론, 프록시 같은 설정은 에이전트의 “두뇌”에 해당하지만, 그것만으로는 실제 파일을 읽거나 코드를 수정하거나 웹을 탐색하는 실행 작업을 수행하기 어렵다.
• 실제 작업 능력은 도구 계층에서 나오며, 도구는 Hermes가 파일 읽기, 코드 패치, 웹 검색, 브라우저 조작, 이미지 분석, 플랫폼 연동, 외부 시스템 호출을 수행하게 만드는 실행 인터페이스다.
• 도구는 단순한 기능 목록이 아니라 모델의 요청과 Hermes 런타임의 실제 실행을 분리하는 경계다.
• 이 분리 구조 덕분에 Hermes는 모델이 직접 시스템을 만지는 방식이 아니라, 이름·설명·파라미터 스키마로 정의된 호출 가능한 함수들을 통해 안전하게 작업을 위임할 수 있다.
• MCP 서버와 네이티브 도구는 Hermes의 capability를 확장하는 두 축이다.
• 핵심 문제는 가능한 모든 도구와 외부 시스템을 연결하는 것이 아니라, 작업에 필요한 신뢰 가능한 작은 실행 표면만 열고, 실패 처리·권한 축소·샌드박스·툴셋 제어를 통해 복구 가능성과 안전성을 유지하는 것이다.

🕒 시간순 섹션별 상세정리

1. 도구는 Hermes가 실제 작업을 수행하게 만드는 실행 계층이다

• 이번 모듈은 Hermes Agent의 tools와 MCP servers를 다루며, 이전 모듈에서 설명한 모델·프로바이더·폴백·로컬 추론·프록시가 “두뇌”였다면 도구는 Hermes가 외부 세계에 작동하는 “손”에 해당한다고 보여준다 [00:12]
• 도구가 없는 모델은 텍스트를 생성하는 챗봇에 가깝지만, 도구가 연결되면 파일 읽기, 코드 패치, 웹 검색, 브라우저 조작, 이미지 분석, 플랫폼 연동, 외부 시스템 호출 같은 실제 작업을 수행할 수 있다 [00:19]

2. 도구·스킬·MCP는 서로 다른 확장 방식이다

• 이전 다섯 개 모듈에서도 도구 호출은 계속 등장했지만, 그때는 내부 동작이 블랙박스처럼 처리되었고, 이번 모듈부터 도구 호출 구조와 실행 흐름을 직접 보여준다 [01:19]
• 스킬은 에이전트가 불러오는 지침이고, 도구는 Hermes가 실행할 수 있는 호출 가능한 함수이며, 도구 호출 결과는 다시 컨텍스트로 들어가 모델의 다음 판단에 영향을 준다 [01:32]

3. 도구 호출은 모델 요청과 Hermes 런타임 실행으로 분리된다

• 도구는 모델이 Hermes에 실행을 요청할 수 있는 함수로 정의되며, 실제 작업은 일반 Python 함수가 맡아 파일 읽기, API 호출, 브라우저 액션 같은 구체적인 동작을 수행한다 [03:04]
• 모델이 직접 보는 것은 함수 본문이 아니라 도구의 이름, 설명, 파라미터로 구성된 스키마이며, 설명 품질이 낮으면 모델이 도구를 언제 어떻게 써야 하는지 잘못 판단할 수 있다 [03:25]

4. 실패까지 포함한 도구 루프와 내장 레지스트리가 복구 가능성을 만든다

• 도구 호출 루프는 모델이 도구명과 JSON 인자를 생성하고, 레지스트리가 해당 핸들러로 dispatch하며, 핸들러가 실행된 뒤 JSON 문자열 결과를 반환하고, 모델이 그 결과를 바탕으로 다음 행동을 결정하는 방식으로 계속된다 [04:12]
• 도구 실행이 실패하더라도 전체 턴을 즉시 중단시키기보다 오류 정보를 JSON 결과로 반환해야 하며, 그래야 모델이 다른 도구를 선택하거나 누락 정보를 요청하거나 깨끗하게 중단할 수 있다 [04:34]

5. 툴셋은 세션·플랫폼·런타임 상황별 접근 범위를 결정한다

• 레지스트리는 단순한 도구 목록이 아니라 툴셋 단위로 구성되며, 툴셋은 현재 세션, 플랫폼, 작업 맥락에서 에이전트가 실제로 접근할 수 있는 도구 범위를 정한다 [05:52]
• 핵심 툴셋에는 파일, 터미널, 웹, 비전이 있고, 디버깅 같은 복합 툴셋은 파일·터미널·필요 시 웹을 묶으며, safe 툴셋은 쓰기와 셸 없이 읽기 전용 리서치와 미디어 중심으로 제한된다 [06:01]

6. 도구 표면 제어와 샌드박스는 실행 위치와 위험도를 함께 제한한다

• 세션 중에는 /tools로 활성·비활성 도구를 확인하고 특정 도구를 켤 수 있으며, 설정 파일과 웹 대시보드에서도 커스텀 툴셋과 프로젝트별 번들을 관리할 수 있다 [07:57]
• 대시보드에서는 툴셋 카테고리별 활성 상태를 확인하고, 필요한 통합을 승인하거나 API 키 설정 절차를 거쳐 실제 사용 가능 상태로 전환할 수 있다 [08:48]

7. MCP의 역할과 최소 노출 원칙

• Hermes에서 파일 읽기 같은 기능은 도구로 실행되며, MCP 서버는 외부 기능을 Hermes에 붙이는 Model Context Protocol 계층으로 작동한다 [12:04]
• MCP에는 비판적 시각도 있지만 널리 쓰이고 있으며, Hermes는 코어 코드를 바꾸지 않고 외부 capability를 연결하되, 서버를 가장 작은 신뢰 가능한 서비스로 좁혀 노출할 수 있다고 보여준다 [12:15]

8. MCP 서버 연결 방식과 동적 도구 등록

• MCP 서버 transport는 로컬 subprocess 방식의 STDIO와 원격 endpoint 방식의 HTTP로 나뉘며, Blender MCP는 uvx blender-mcp 같은 command와 arguments 형태를 사용하는 예로 드러난다 [13:12]
• HTTP 방식은 Stripe처럼 bearer token으로 인증하고 endpoint를 호출하는 구조이며, 서버가 연결되면 각 도구는 MCP server 이름과 tool 이름을 포함한 형태로 Hermes에 등록된다 [13:36]

9. CLI와 dashboard를 통한 MCP 서버 추가

• hermes mcp 명령은 사용 가능한 MCP 관련 기능을 보여주며, catalog, install, remove, list, configure 같은 명령으로 승인된 MCP와 설정 흐름을 확인할 수 있다 [14:22]
• Blender MCP 서버는 수동 설정도 가능하지만 Hermes에 요청해 추가할 수도 있고, 실제 연결을 위해서는 Blender 쪽에서도 별도 준비가 필요하다 [14:48]

10. Blender MCP 연결과 실제 도구 실행

• Blender에서는 edit preferences의 add-ons에서 Blender MCP를 enable하고, 별도 Blender MCP add-on script를 내려받아 연결 기능을 활성화해야 한다 [16:04]
• Blender MCP 패널을 열고 local port에서 MCP server에 connect하면 Hermes prompt가 Blender와 연결되며, 기본 cube 상태에서 tower 생성 요청 같은 실제 작업을 실행할 수 있다 [16:31]

11. MCP 도구 권한 축소와 보안 장치

• Blender MCP는 22개 도구를 노출하고, MCP Blender prefix 아래에 scene info 조회, Blender code 실행, Poly Haven asset 다운로드 같은 도구들이 등록된다 [17:38]
• config.yaml에서 include 또는 exclude allow list를 설정하면 특정 도구를 허용하거나 제외할 수 있고, 예를 들어 asset 다운로드 도구를 차단해 신뢰 범위를 줄일 수 있다 [17:58]

12. Hermes를 MCP 서버로 노출하고 custom tool을 등록하는 흐름

• hermes mcp serve는 FastMCP 기반 STDIO MCP server를 시작하고, conversations list, conversation get, message read 같은 10개 도구를 외부 클라이언트에 노출한다 [19:32]
• 읽기 작업은 gateway 없이 가능하지만 send 작업은 live Hermes runtime으로 메시지를 전달할 gateway가 필요하며, list는 되지만 send가 실패한다면 MCP config보다 gateway 상태를 먼저 확인해야 한다 [19:57]

13. 반복 작업을 도구로 등록하는 기준과 모듈 6 핵심 정리

• Nvidia 가격 조회에 이어 Tesla 가격도 별도 도구 호출 지시 없이 처리되며, Hermes가 등록된 stock price tool을 상황에 맞게 선택하는 흐름을 보여준다 [24:06]
• 같은 종류의 작업을 반복해야 하는 워크플로에서는 도구 등록이 효율적인 선택이지만, 도구가 자동 선택될 가능성도 생기므로 사용 범위와 안전성을 함께 고려해야 한다 [24:14]

14. 도구·MCP에서 cron 기반 자동화로 넘어가는 전환

• 모듈 6의 결론은 tools와 MCP servers가 Hermes Agent의 힘과 기능을 크게 확장하는 요소라는 점이다 [25:16]
• 다음 모듈 7의 주제는 cron과 Hermes Agent의 일반 자동화이며, 이전에 만든 skills, tools, MCP servers, scoped surface, model stack이 자동 실행의 기반으로 연결된다고 예고한다 [25:29]

🧾 결론

• 이 영상의 핵심은 Hermes Agent의 실전 능력이 모델 자체보다 도구 계층, 툴셋 관리, MCP 연결, 권한 축소 설계에 크게 좌우된다는 점이다.
• 도구는 단순한 편의 기능이 아니라 모델 요청과 실제 실행을 분리하는 안전 경계이며, 실패를 JSON 결과로 돌려주는 구조 덕분에 복구와 재시도가 가능해진다.
• MCP는 Hermes의 기능을 빠르게 넓히는 방법이지만, 서버와 도구가 많아질수록 모델이 잘못 선택하거나 불필요한 권한을 갖게 될 수 있으므로 최소 노출 원칙이 중요하다.
• 실전 운영에서는 /tools, 툴셋 설정, dashboard, sandbox backend, approval gating, include/exclude allow list, OAuth, malware advisory 확인 같은 통제 장치를 함께 사용해야 한다.
• 다음 단계인 cron 기반 자동화는 이번 모듈에서 다룬 skills, tools, MCP servers, scoped surface, model stack을 정해진 시간에 실행되는 워크플로로 연결하는 방향으로 이어진다.

📈 투자·시사 포인트

• Hermes Agent를 도입하거나 확장하려는 사용자는 먼저 “어떤 모델을 쓸 것인가”보다 “어떤 도구를 어떤 범위로 열 것인가”를 설계하는 데 시간을 투자해야 한다.
• MCP 서버는 외부 애플리케이션과 서비스를 빠르게 붙일 수 있는 강력한 확장 지점이지만, 운영 관점에서는 서버별 권한, 노출 도구 수, 인증 방식, secret 관리가 핵심 리스크가 된다.
• 반복적으로 수행하는 API 조회나 외부 시스템 호출은 custom tool로 등록할 가치가 있지만, 등록 후에는 모델이 자동으로 선택할 수 있으므로 설명·파라미터·오류 처리·사용 범위를 신중하게 설계해야 한다.
• 조직이나 팀 환경에서는 safe 툴셋, 샌드박스 실행 위치, 승인 게이트, OAuth 기반 인증처럼 권한을 좁히는 기능이 생산성만큼 중요한 도입 기준이 될 수 있다.
• 검증 필요: 실제 운영 환경에서 특정 MCP 서버를 붙이기 전에는 해당 서버가 노출하는 도구 목록, 인증 방식, 패키지 출처, 실행 위치, Hermes gateway 필요 여부를 별도로 확인해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• 영상에서 언급된 “약 30개 툴셋과 70개 도구” 구성은 업로드 시점 기준일 수 있으므로, 현재 Hermes 버전에서 실제 도구 수와 기본 활성 툴셋은 별도로 확인이 필요하다.
• Blender MCP 설정 절차, add-on 설치 방식, uvx blender-mcp 실행 방식은 MCP 서버나 Blender add-on 버전에 따라 달라질 수 있으므로 최신 문서 확인이 필요하다.
• HTTP 기반 MCP 서버의 OAuth, bearer token, refresh token 저장 방식은 서버별 구현 차이가 있을 수 있어, 모든 MCP 서버에 동일하게 적용된다고 단정하기 어렵습니다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 새 세션을 시작할 때 작업 목적에 맞는 최소 툴셋만 활성화해 도구 표면을 줄입니다.
• /tools 또는 대시보드에서 현재 활성·비활성 도구를 확인하고, 불필요한 도구는 켜지 않도록 점검한다.
• MCP 서버를 추가할 때는 “편의성”보다 “가장 작은 useful surface” 원칙을 우선해 필요한 서버만 연결한다.
• MCP 서버별 include/exclude allow list를 설정해 asset 다운로드, 코드 실행 등 위험도가 높은 도구를 제한한다.

❓ 열린 질문

• 실제 운영 환경에서 기본으로 열어 둘 최소 Hermes 툴셋 조합은 무엇이 가장 안전하고 효율적인가요?
• MCP 서버를 여러 개 연결할 때, 모델이 모호한 도구 목록에 묻히지 않도록 도구 설명과 네이밍을 어떻게 표준화해야 할까요?
• 위험한 MCP 도구 호출을 승인 보조 모델이 분류할 때, 어떤 기준으로 자동 승인과 사용자 확인을 나눠야 할까요?