프로토콜 사양
모델 컨텍스트 프로토콜의 상세 기술 사양
프로토콜 개요
모델 컨텍스트 프로토콜(MCP)은 각 호스트가 여러 클라이언트 인스턴스를 실행할 수 있는 클라이언트-호스트-서버 아키텍처를 따릅니다. 이 아키텍처는 사용자가 명확한 보안 경계를 유지하고 문제를 격리하면서 애플리케이션 전반에 걸쳐 AI 기능을 통합할 수 있게 합니다. MCP는 JSON-RPC를 기반으로 구축되어 클라이언트와 서버 간의 컨텍스트 교환 및 샘플링 조정에 중점을 둔 상태 유지 세션 프로토콜을 제공합니다.
아키텍처
핵심 구성 요소 아키텍처는 다음과 같습니다:
구성 요소 세부 정보
호스트
호스트 프로세스는 MCP 프로토콜의 핵심 조정자입니다. 클라이언트 인스턴스의 수명 주기를 관리하고, 연결 권한을 제어하며, 보안 정책을 실행합니다. 호스트는 또한 AI/LLM 통합을 조정하여 전체 시스템의 원활한 운영을 보장합니다.
클라이언트
클라이언트는 호스트에 의해 생성되어 서버와의 독립적인 연결을 유지합니다. 각 클라이언트는 서버와 1:1 관계를 유지하여 연결의 격리성과 보안을 보장합니다.
서버
서버는 리소스와 도구를 노출하고, 독립적으로 실행되며, 클라이언트 요청을 통해 샘플링할 수 있습니다. 서버는 로컬 또는 원격일 수 있으며, 시스템에 다양한 기능을 제공합니다.
프로토콜 기초
MCP의 모든 메시지는 JSON-RPC 2.0 사양을 따라야 합니다. 프로토콜은 세 가지 유형의 메시지를 정의합니다:
요청
클라이언트에서 서버로, 또는 그 반대로 전송할 수 있는 양방향 메시지
요청 예시
{
"jsonrpc": "2.0",
"id": "string | number",
"method": "string",
"param?": {
"key": "value"
}
}응답
요청에 대한 응답으로 전송됨
응답 예시
{
"jsonrpc": "2.0",
"id": "string | number",
"result?": {
"[key: string]": "unknown"
},
"error?": {
"code": "number",
"message": "string",
"data?": "unknown"
}
}알림
응답이 필요 없는 단방향 메시지로, 클라이언트에서 서버로 또는 그 반대로 전송 가능
알림 예시
{
"jsonrpc": "2.0",
"method": "string",
"params?": {
"[key: string]": "unknown"
}
}수명 주기
MCP는 클라이언트-서버 연결에 대한 엄격한 수명 주기를 정의하여 올바른 기능 협상 및 상태 관리를 보장합니다.
초기화 단계
초기화 단계는 클라이언트와 서버 간의 첫 번째 상호작용이어야 합니다. 이 단계에서 양측은:
초기화 요청
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2024-11-05",
"capabilities": {
"roots": {
"listChanged": true
},
"sampling": {}
},
"clientInfo": {
"name": "ExampleClient",
"version": "1.0.0"
}
}
}초기화 응답
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"protocolVersion": "2024-11-05",
"capabilities": {
"logging": {},
"prompts": {
"listChanged": true
},
"resources": {
"subscribe": true,
"listChanged": true
},
"tools": {
"listChanged": true
}
},
"serverInfo": {
"name": "ExampleServer",
"version": "1.0.0"
}
}
}초기화 완료 알림
{
"jsonrpc": "2.0",
"method": "initialized"
}버전 협상
초기화 요청에서, 클라이언트는 지원하는 프로토콜 버전을 전송해야 합니다.
기능 협상
클라이언트와 서버는 세션 기간 동안 사용 가능한 선택적 프로토콜 기능을 결정합니다.
클라이언트 기능
서버 기능
작동 단계
작동 단계에서, 클라이언트와 서버는 협상된 기능을 교환합니다.
종료 단계
종료 단계에서, 연결은 우아하게 종료됩니다.
전송 메커니즘
MCP는 현재 두 가지 표준 클라이언트-서버 통신 전송 메커니즘을 정의합니다: stdio(표준 입출력) 및 기반 SSE의 HTTP。클라이언트는 stdio를 지원해야 합니다. 또한, 클라이언트와 서버는 플러그인 가능한 방식으로 사용자 정의 전송 메커니즘을 구현할 수 있습니다.
표준 입출력（stdio）
stdio 전송 메커니즘에서:
- 클라이언트는 MCP 서버를 하위 프로세스로 시작합니다
- 서버는 표준 입력（stdin）을 통해 JSON-RPC 메시지를 수신하고 표준 출력（stdout）에 응답을 작성합니다
- 메시지는 줄바꿈 문자로 구분되며 줄바꿈 문자를 포함할 수 없습니다
- 서버는 UTF-8 문자열을 표준 오류（stderr）에 작성할 수 있으며, 클라이언트는 이 로그를 캡쳐, 전달 또는 무시할 수 있습니다
- 서버는 표준 출력에 유효한 MCP 메시지가 아닌 것을 작성할 수 없습니다
- 클라이언트는 서버의 표준 입력에 유효한 MCP 메시지가 아닌 것을 작성할 수 없습니다
SSE 기반 HTTP
SSE 전송 메커니즘에서, 서버는 독립적인 프로세스로 실행되며 여러 클라이언트 연결을 처리할 수 있습니다
서버는 두 개의 엔드포인트를 제공해야 합니다:
- SSE 엔드포인트 - 클라이언트가 연결을 설정하고 서버에서 메시지를 수신하는 데 사용됩니다
- HTTP POST 엔드포인트 - 클라이언트가 서버에 메시지를 보내는 데 사용됩니다
- 클라이언트가 연결할 때, 서버는 클라이언트가 메시지를 보내는 URI를 포함한 endpoint 이벤트를 전송해야 합니다
- 모든 후속 클라이언트 메시지는 이 엔드포인트에 HTTP POST 요청으로 보내야 합니다
- 서버 메시지는 SSE message 이벤트로 전송되며, 이벤트 데이터에 JSON 형식으로 인코딩됩니다
사용자 정의 전송 메커니즘
클라이언트와 서버는 특정 요구 사항을 충족하기 위해 추가 사용자 정의 전송 메커니즘을 구현할 수 있습니다. 프로토콜은 전송 메커니즘과 독립적이며, 양방향 메시지 교환을 지원하는 모든 통신 채널에서 구현할 수 있습니다.
- 사용자 정의 전송 메커니즘을 지원하는 구현자는 MCP 정의의 JSON-RPC 메시지 형식과 수명 주기 요구 사항을 보장해야 합니다
- 사용자 정의 전송 메커니즘은 특정 연결 설정 및 메시지 교환 패턴을 기록해야 하며, 이를 통해 상호 운용성을 지원할 수 있습니다
서버 기능
서버는 MCP를 통해 언어 모델에 컨텍스트를 추가하기 위한 기본 구성 요소를 제공하며, 컨텍스트 관리를 위한 세 가지 기본 요소를 제공합니다: 프롬프트, 리소스 및 도구.
| 요소 | 제어 | 설명 | 예시 |
|---|---|---|---|
| 프롬프트 | 시스템 | 모델의 행동과 역할 정의 | 당신은 전문 코드 리뷰어입니다 |
| 리소스 | 사용자 | 추가 컨텍스트 정보 제공 | 코드 파일, 문서 |
| 도구 | 시스템/사용자 | 모델의 기능 확장 | 코드 검색, 파일 편집 |
리소스 관리
AI 모델에 컨텍스트와 데이터 제공
- 다양한 리소스 유형 지원
- 동적 리소스 로딩
- 리소스 수명 주기 관리
도구 통합
AI 모델의 기능 범위 확장
- 유연한 도구 등록 메커니즘
- 도구 호출 권한 제어
- 비동기 도구 실행 지원
컨텍스트 제어
AI 모델 동작의 정확한 제어
- 시스템 수준 프롬프트 관리
- 동적 컨텍스트 업데이트
- 다중 대화 상태 유지