루트

루트 (Roots)

클라이언트가 파일시스템 "roots"를 서버에 노출하는 표준화된 방법을 설명하는 페이지예요. Roots는 서버에게 클라이언트가 관련 있다고 보는 디렉터리와 파일을 알려줘서, 서버가 그에 맞춰 작업을 집중하게 해요. 참고로 이 기능은 **폐기(Deprecated)**되었어요.

출처: 문서

본문

경고 (Warning): Deprecated: Roots 기능은 프로토콜 버전 2026-07-28 기준으로 폐기되었어요 (SEP-2577). 기능 수명주기 정책 아래에서 이 개정이 릴리스된 후 최소 12개월 동안 사양에 남아 있다가 제거 자격을 얻어요. 새 구현은 SHOULD NOT 이를 채택하고, 기존 구현은 디렉터리나 파일을 도구 파라미터·리소스 URI·서버 설정으로 전달하는 방식으로 SHOULD 이전해야 해요. 폐기 기능 레지스트리를 참조하세요.

Model Context Protocol (MCP)은 클라이언트가 파일시스템 "roots"를 서버에 노출하는 표준화된 방법을 제공해요. Roots는 클라이언트가 관련 있다고 간주하는 디렉터리와 파일을 서버에 알려줘서, 서버가 그에 맞춰 작업을 집중할 수 있게 해요. 이는 접근 통제 메커니즘이 아니라 정보 제공용 안내(guidance)예요. 프로토콜은 서버가 roots 안에 머물도록 강제하지 않아요. 서버는 지원하는 클라이언트에게 roots 목록을 요청할 수 있어요.

사용자 상호작용 모델 (User Interaction Model)

MCP의 Roots는 일반적으로 워크스페이스 또는 프로젝트 설정 인터페이스를 통해 노출돼요.

예를 들어 구현체는 사용자가 서버가 접근해야 할 디렉터리와 파일을 선택할 수 있는 워크스페이스/프로젝트 선택기(picker)를 제공할 수 있어요. 이는 버전 관리 시스템이나 프로젝트 파일로부터의 자동 워크스페이스 감지와 결합할 수 있어요.

하지만 구현체는 자신의 필요에 맞는 어떤 인터페이스 패턴으로든 roots를 노출할 자유가 있어요. 프로토콜 자체는 특정 사용자 상호작용 모델을 강제하지 않아요.

기능 (Capabilities)

roots를 지원하는 클라이언트는 MUST 각 요청의 _meta.io.modelcontextprotocol/clientCapabilities에 roots 기능을 선언해야 해요:

{
  "_meta": {
    "io.modelcontextprotocol/clientCapabilities": {
      "roots": {}
    }
  }
}

프로토콜 메시지 (Protocol Messages)

루트 나열하기 (Listing Roots)

클라이언트 요청 처리 중에 roots를 검색하려면, 서버는 roots/list 요청을 담은 InputRequiredResult를 보내요:

입력 요청 (InputRequiredResult.inputRequests 안에 전달됨):

{
  "method": "roots/list"
}

클라이언트 결과 (재시도된 요청의 inputResponses 안에 반환됨):

{
  "roots": [
    {
      "uri": "file:///home/user/projects/myproject",
      "name": "My Project"
    }
  ]
}

메시지 흐름 (Message Flow)

sequenceDiagram
    participant Server
    participant Client

    Note over Server,Client: Initial Request
    Client->>Server: tools/call(id: 1)
    Server-->>Client: InputRequiredResult(roots/list)
    Client->>Server: tools/call(id: 2, inputResponses{key: roots} + requestState)

데이터 타입 (Data Types)

Root

루트 정의는 다음을 포함해요:

uri: 루트의 고유 식별자. 현재 사양에서는 MUST file:// URI여야 해요.
name: 표시용 선택적 사람이 읽을 수 있는 이름.

다양한 사용 사례에 대한 루트 예시:

프로젝트 디렉터리 (Project Directory)

{
  "uri": "file:///home/user/projects/myproject",
  "name": "My Project"
}

여러 저장소 (Multiple Repositories)

[
  {
    "uri": "file:///home/user/repos/frontend",
    "name": "Frontend Repository"
  },
  {
    "uri": "file:///home/user/repos/backend",
    "name": "Backend Repository"
  }
]

오류 처리 (Error Handling)

오류가 발생하면, InputRequiredResult 패턴에서는 서버가 오류 메시지가 담긴 응답을 기다리지 않으므로 클라이언트는 오류 메시지를 넣어 초기 호출을 다시 재생(replay)할 필요가 없어요.

보안 고려 사항 (Security Considerations)

클라이언트는 MUST:
- 적절한 권한으로만 roots를 노출한다
- 경로 횡단(path traversal)을 막기 위해 모든 루트 URI를 검증한다
- 적절한 접근 통제를 구현한다
- 루트 접근성을 모니터링한다
서버는 SHOULD:
- roots를 사용할 수 없게 되는 경우를 처리한다
- 작업 중 루트 경계를 존중한다
- 제공된 roots에 대해 모든 경로를 검증한다

구현 지침 (Implementation Guidelines)

클라이언트는 SHOULD:
- roots를 서버에 노출하기 전에 사용자 동의를 요청한다
- 루트 관리를 위한 명확한 사용자 인터페이스를 제공한다
- 노출하기 전에 루트 접근성을 검증한다
- 루트 변경을 모니터링한다
서버는 SHOULD:
- 사용 전에 roots 기능을 확인한다
- 작업에서 루트 경계를 존중한다
- 루트 정보를 적절히 캐시한다

루트