모델 컨텍스트 프로토콜

쉽게 말하면, 모델 컨텍스트 프로토콜(MCP)은 AI 앱이 외부 프로그램이나 데이터 소스와 맥락을 주고받고 기능을 호출하도록 정해 둔 공통 규칙이다. 앱마다 따로 만들던 연결 방식을 한 가지 약속으로 맞추는 것이 목적이다.^[1]

1. 개요

모델 컨텍스트 프로토콜(Model Context Protocol, MCP)은 대규모 언어 모델(large language model)을 쓰는 애플리케이션과 외부 프로그램·데이터 소스 사이에서 맥락을 주고받고 기능을 호출하는 개방형 프로토콜이다. Anthropic은 2024년 11월 25일 MCP를 발표하고 오픈소스로 공개했다. 프로젝트 저장소는 창시자를 David Soria Parra와 Justin Spahr-Summers로 밝힌다.^[2][3] MCP는 호스트·클라이언트·서버 구조를 쓴다. 호스트 애플리케이션은 연결된 서버마다 프로토콜 클라이언트를 만들고, 서버는 버전이 정해진 JSON-RPC 인터페이스로 리소스, 프롬프트, 도구와 선택 기능을 노출한다.^[4][1]

MCP는 AI 애플리케이션과 기능 제공자 사이의 통신을 표준화한다. 모델 아키텍처, 완전한 에이전트 루프, 호스트가 프롬프트를 구성하는 방식, 반환 정보의 안전성과 정확성은 정의하지 않는다. 호스트는 서버와 권한을 사용자에게 보여 줄 방식, 정보를 대규모 언어 모델에 전달할 방식, 결과를 처리할 방식을 스스로 정한다.^[4]

프로젝트는 2026-07-28 개정판을 안정 버전으로 공개했다. 이 사양은 이전 개정판의 연결 단위 초기화 모델을 버리고, 무상태(stateless) 요청, 요청마다 붙는 버전·기능 메타데이터, 필수 서버 탐색 메서드를 도입했다.^[5][8]

2. 목적과 범위

MCP 이전에는 여러 데이터 시스템에 접근해야 하는 AI 애플리케이션이 보통 시스템마다 별도 연동에 의존했다. MCP는 호환되는 여러 호스트가 독립적으로 개발된 서버에 연결할 수 있는 공통 프로토콜 경계를 제공한다. 이 프로토콜은 중복된 어댑터 작업을 줄일 수 있지만, 두 구현이 같은 선택 기능을 지원하거나 같은 기능을 똑같이 해석한다고 보장하지는 않는다.^[2][4]

서버는 데스크톱 앱이 실행한 로컬 프로그램, 같은 기기의 서비스, 원격 네트워크 서비스를 나타낼 수 있다. 연동 대상은 파일, 데이터베이스, 소스 관리 작업, 검색 서비스, 업무 애플리케이션, 특수 계산 등이다. 이는 서버가 구현할 수 있는 용도일 뿐 MCP에 기본 내장된 데이터 소스가 아니다.^[4][6][7]

프로토콜은 통신과 모델 선택을 의도적으로 분리한다. 호스트는 독점형 또는 공개형 모델을 쓸 수 있고, 그래픽 또는 명령줄 인터페이스를 제공할 수 있으며, 작업 승인을 사람이 할지 자동 정책이 할지 정할 수 있다. MCP는 모든 호스트나 서버가 모든 선택 기능을 구현하도록 요구하지는 않는다. 2026-07-28 개정판에서 클라이언트는 요청마다 관련 기능을 선언하고, 서버는 server/discover로 자신의 기능을 알린다.^[19][20][21]

이름의 ‘컨텍스트’는 검색된 텍스트보다 넓은 뜻이다. 서버는 읽을 수 있는 리소스, 재사용 가능한 프롬프트 템플릿, 실행 가능한 도구, 추가 입력을 요청하는 엘리시테이션 요청을 노출할 수 있다. 이 가운데 무엇이 모델의 컨텍스트 창(context window)에 들어가고 어떻게 쓰일지는 호스트가 정한다.^{[4][9][10][11][12]}

3. 구조

MCP 문서는 세 가지 역할을 구분한다.^[4]

• 호스트(host)는 사용자 경험, 모델 상호작용, 권한, 하나 이상의 프로토콜 클라이언트를 조율하는 애플리케이션이다. 코딩 어시스턴트, 데스크톱 채팅 앱, 다른 AI 에이전트 호스트가 예가 될 수 있다.^[4]
• 클라이언트(client)는 호스트 안에서 서버 하나와 통신하는 프로토콜 구성 요소다. 보통 서버 연결마다 별도 클라이언트를 만든다.^[4]
• 서버(server)는 MCP로 기능을 노출하는 프로그램 또는 네트워크 서비스이며, 로컬이나 원격에서 실행될 수 있다.^[4]

전용 클라이언트-서버 전송 관계는 프로토콜 세션이 아니다. 2026-07-28 개정판에서 서버는 같은 연결의 앞선 교환으로부터 프로토콜 버전, 클라이언트 신원, 기능, 대화 식별자 등 요청 맥락을 추론하면 안 된다. 여러 호출에 걸친 상태는 클라이언트가 다시 보내는 명시적 식별자로 표현해야 한다.^[4][19]

MCP 문서는 두 계층을 나눈다.^[1]

• 데이터 계층은 JSON-RPC 메시지, 버전과 기능 탐색, 프로토콜 기능, 메시지 패턴을 정의한다.
• 전송 계층은 참여자 사이에서 메시지를 전달하며, 프레이밍, 연결 동작, 해당되는 경우 HTTP 인가 규칙을 정의한다.^[1]

모든 MCP 메시지는 JSON-RPC 2.0 봉투(envelope) 구조를 쓴다. 클라이언트 요청은 메서드, 식별자, 선택적 매개변수를 가지며, 알림(notification)은 응답이 없다. 서버는 결과나 오류를 돌려준다. 2026-07-28 개정판은 성공 결과에 resultType을 넣도록 요구한다. 일반 최종 결과는 ‘complete’, 여러 번 왕복이 필요한 중간 결과는 ‘input_required’를 쓴다. 호환을 위해 이전 버전 서버가 resultType을 보내지 않으면 클라이언트는 ‘complete’로 간주해야 한다.^[19]

3.1. 무상태 요청과 버전 선택

모든 최신(modern) MCP 요청은 params._meta 안에 필수 네임스페이스 필드 두 개를 담는다. 하나는 io.modelcontextprotocol/protocolVersion이고 다른 하나는 io.modelcontextprotocol/clientCapabilities다. 클라이언트는 자기 신원을 밝히지 않도록 설정되어 있지 않다면 io.modelcontextprotocol/clientInfo도 넣어야 한다. 서버는 자신의 구현 신원을 결과 메타데이터의 io.modelcontextprotocol/serverInfo에 넣어야 한다.^[8][19]

서버는 server/discover를 구현해야 한다. 응답에는 지원 프로토콜 개정판, 기능, 구현 신원, 선택 안내 문구, 캐싱 메타데이터가 담긴다. 클라이언트가 이를 호출하는 것은 선택 사항이며, 바로 다른 요청을 보낼 수도 있다. 요청한 개정판이 지원되지 않으면 최신 서버는 코드 -32022의 UnsupportedProtocolVersionError를 반환하고 지원 개정판 목록을 준다. 클라이언트는 그 목록에서 함께 지원하는 버전으로 다시 요청할 수 있다.^[20][21]

탐색 결과는 인증 증명이 아니라 설명 정보다. 서버 신원은 서버가 스스로 밝힌 것이므로, 사양은 이를 보안 판단 근거로 쓰지 말라고 경고한다. 기능 선언도 지원하는 프로토콜 동작을 보여 줄 뿐, 서버가 무해하다거나 구현이 올바르다는 증거가 아니다.^[21]

선택 확장 기능은 클라이언트와 서버 기능 안의 extensions 맵에 광고된다. 확장 식별자는 네임스페이스 키를 써야 한다. 한쪽만 확장을 지원하면 확장 사양에 따라 핵심 동작으로 돌아가거나 요청을 거부해야 한다.^[20]

사양은 2026-07-28 이후 개정판을 최신(modern), 2025-11-25 이전 개정판을 이전(legacy)이라 부른다. 두 시대를 아우르는 클라이언트와 서버는 두 모델을 모두 지원할 수 있다. 이런 stdio 클라이언트는 보통 server/discover로 먼저 확인한다. 응답이나 인식 가능한 최신 오류가 오면 최신 방식을 쓰고, 인식되지 않는 오류나 시간 초과가 나면 예전 initialize 핸드셰이크를 시도할 수 있다. HTTP 클라이언트는 전송 계층의 상태 코드와 오류 본문 규칙으로 같은 구분을 한다.^[20][6][7]

4. 전송 방식

현재 사양은 stdio와 Streamable HTTP를 표준 전송 방식으로 정의한다. 사용자 정의 전송 방식도 JSON-RPC 메시지 규칙과 무상태 요청 규칙을 지키면 정의할 수 있다.^[6][7]

4.1. stdio

stdio에서는 클라이언트가 서버를 하위 프로세스로 실행한다. 서버는 표준 입력에서 JSON-RPC 메시지를 읽고 표준 출력으로 쓴다. 각 메시지는 한 줄을 차지하며 줄바꿈을 포함하면 안 된다. 진단 텍스트는 표준 오류(standard error)로 쓸 수 있지만, 양쪽 모두 프로토콜 스트림에 비프로토콜 텍스트를 섞으면 안 된다.^[6]

클라이언트는 요청과 알림을 보내고, 서버는 응답과 알림을 보낸다. 2026-07-28 서버는 독립적인 JSON-RPC 요청을 클라이언트에게 보내면 안 된다. 요청을 처리하는 중에 엘리시테이션, 샘플링, 루트 정보가 필요하면 서버는 InputRequiredResult를 반환하고, 클라이언트가 요청된 입력을 붙여 원래 요청을 다시 보내게 한다.^[6][22]

stdio는 호스트가 하위 프로세스를 직접 통제하고 네트워크 포트가 필요 없어 로컬 연동에 편리하다. 그러나 샌드박스(sandbox)가 아니다. 로컬 서버를 시작하면 그 프로세스가 가진 운영체제 권한으로 코드가 실행된다. 호스트는 실행할 명령을 확인하고, 필요한 환경 변수만 넘기며, 가능하면 파일 시스템과 네트워크 접근을 제한해야 한다.^[23][24]

HTTP 인가 프레임워크는 stdio에 적용되지 않으며, 자격 증명이 필요한 구현은 실행 환경에서 얻어야 한다. 종료는 보통 클라이언트가 입력 스트림을 닫을 때 시작된다. 프로세스가 재시작되면 처리 중이던 요청은 사라지고 활성 구독은 다시 설정해야 한다. 프로토콜이 재시작을 넘어 상태를 보존하지 않기 때문이다.^[19][6][25]

4.2. Streamable HTTP

2026-07-28 개정판에서 Streamable HTTP 서버는 POST를 받는 MCP 엔드포인트(endpoint) 하나를 노출한다. 클라이언트의 요청과 알림은 각각 별도의 POST로 보낸다. 요청은 JSON 응답 하나 또는 요청 범위의 Server-Sent Events(SSE) 스트림을 받으며, 이 스트림에는 관련 알림과 최종 응답이 담긴다. 알림 POST가 성공하면 본문 없이 HTTP 202 Accepted를 반환한다.^[7]

이 개정판은 이전 Streamable HTTP 개정판에 있던 선택적 HTTP GET 스트림과 Mcp-Session-Id 메커니즘을 제거했다. 오래 유지되는 변경 알림은 이제 POST로 보낸 subscriptions/listen 요청의 응답 스트림으로 전달된다. 서버에서 클라이언트로 가는 입력 요청은 독립 JSON-RPC 요청 대신 여러 차례 왕복 결과로 표현된다.^{[8][7][26][22]}

각 요청 POST에는 MCP-Protocol-Version 헤더로 프로토콜 개정판을, Mcp-Method 헤더로 메서드를 담는다. tools/call, resources/read, prompts/get 호출에는 요청 이름이나 URI에서 얻은 Mcp-Name도 필요하다. 서버는 이 헤더를 JSON 본문과 대조하고, 필수 값이 없거나 형식이 틀리거나 서로 맞지 않으면 코드 -32020의 HeaderMismatch 오류를 반환한다.^[7]

이 전송 방식은 Last-Event-ID로 끊긴 SSE 스트림을 이어 받는 재개를 지원하지 않는다. 응답 스트림이 끊기면 처리 중이던 요청은 사라지며, 재시도하는 클라이언트는 새 JSON-RPC 식별자를 붙인 새 요청을 보낸다. 요청 범위 알림은 발생한 응답 스트림에 머물고, 옵트인(opt-in)한 목록·리소스 변경 알림은 해당 subscriptions/listen 스트림에 남는다.^[8][7][26]

네트워크 배포에는 출처(origin), 인증, 메타데이터 탐색 위험이 따른다. Streamable HTTP 서버는 들어오는 Origin 헤더를 검증하고 잘못된 출처는 거부해야 한다. 로컬 서버는 모든 네트워크 인터페이스가 아니라 루프백(loopback)에 바인딩해야 하며, 원격 배포에는 적절한 인증과 암호화 전송을 써야 한다.^[7][25][27]

5. 서버 기능

서버는 리소스, 프롬프트, 도구라는 세 가지 주요 기능 묶음을 노출할 수 있다. 각 기능은 선택 사항이며 의도한 상호작용 모델이 다르다.^[9][10][11]

5.1. 리소스

리소스는 서버가 제공하는 애플리케이션 제어 데이터다. 각 리소스는 URI를 가지며 텍스트 또는 바이너리 데이터를 담을 수 있다. 메타데이터에는 이름, 제목, 설명, 미디어 타입, 크기, 주석, 아이콘이 들어갈 수 있다.^[9]

클라이언트는 resources/list로 리소스를 나열하고, resources/read로 하나를 읽으며, resources/templates/list로 매개변수가 있는 URI 템플릿을 찾는다. 목록 작업은 페이지로 나눌 수 있다. 2026-07-28 개정판은 이 메서드들의 완전한 결과에 ttlMs와 cacheScope 캐싱 힌트를 붙이도록 요구한다.^[9][28]

리소스 업데이트와 리소스 목록 변경은 옵트인 알림이다. 클라이언트는 subscriptions/listen을 열고, 선택한 URI에는 resourceSubscriptions를, 목록 변경에는 resourcesListChanged를 요청한다. 이 방식은 이전의 resources/subscribe와 resources/unsubscribe 메서드를 대신한다.^[8][9][26]

프로토콜은 보편적인 단일 URI 체계를 규정하지 않는다. 서버는 file이나 https 같은 익숙한 체계를 쓰거나 자체 체계를 정할 수 있다. URI는 서버 인터페이스 안에서 콘텐츠를 가리킬 뿐 접근 권한을 주지 않으며, 서버는 각 읽기 요청을 검증하고 인가해야 한다.^[9][27]

리소스는 도구 결과에 링크나 포함된 콘텐츠 형태로도 나타날 수 있다. 호스트는 출처를 보존해야 하며, 구조화된 필드로 들어왔다는 이유만으로 리소스 텍스트를 신뢰할 수 있는 지시문으로 취급하지 말아야 한다.^[9][23]

5.2. 프롬프트

프롬프트는 사용자가 고르도록 설계된 서버 정의 프롬프트 템플릿(prompt template)이다. 클라이언트는 prompts/list로 프롬프트를 찾고 prompts/get으로 이름 붙은 템플릿을 가져온다. 프롬프트 결과는 텍스트, 이미지, 오디오, 포함된 리소스, 리소스 링크를 담을 수 있는 메시지로 이루어진다.^[10]

‘사용자가 제어한다’는 말은 그래픽 설계를 요구하는 것이 아니라 상호작용 모델을 뜻한다. 호스트는 프롬프트를 명령, 메뉴 항목, 버튼 또는 다른 인터페이스로 노출할 수 있다. 목록 결과에는 캐싱 힌트가 붙고, 프롬프트 목록 변경을 광고한 서버는 이를 옵트인한 subscriptions/listen 스트림으로 보낼 수 있다.^[10][28][26]

프롬프트는 여전히 서버가 제공한 콘텐츠다. 호스트는 출처를 보여 주어야 하며, 사용자가 선택했다는 이유만으로 모든 지시와 연결된 리소스가 신뢰할 만하다고 가정하면 안 된다.^[10][23]

5.3. 도구

도구는 서버가 노출하는 실행 가능한 함수다. 사양은 도구를 모델 제어형(model-controlled)으로 설명한다. 모델이 작업에 따라 도구를 고를 수 있기 때문이지만, 자동 실행을 요구하지는 않는다. 클라이언트는 tools/list로 도구를 찾고 tools/call로 호출한다.^[11]

각 도구는 고유한 이름과 입력 스키마를 가지며, 선택적으로 제목, 설명, 출력 스키마, 아이콘, 실행 메타데이터, 주석을 가질 수 있다. 스키마는 JSON Schema 2020-12 형식을 쓴다. 선언된 출력 스키마는 도구의 구조화된 출력을 제한한다. 2026 개정판은 $ref와 자원 한계(resource-bound) 규칙을 따르는 조건에서 JSON Schema 2020-12 키워드 전체를 허용한다.^[8][11][1]

도구 결과에는 텍스트, 이미지, 오디오, 리소스 링크, 포함된 리소스, 구조화된 데이터가 들어갈 수 있다. 도구는 성공한 프로토콜 결과 안에서 도구 수준의 오류를 보고할 수 있다. 서버는 호출을 끝내기 전에 지원되는 클라이언트 입력이 필요하면 resultType으로 input_required를 반환할 수도 있다.^[11][22]

도구 주석은 읽기 전용, 파괴적, 멱등성, 열린 세계(open-world) 같은 동작 속성을 설명할 수 있다. 이 주석은 강제 장치가 아니라 신뢰할 수 없는 힌트다. 공식 지침은 명확한 도구 출처, 인자 가시성, 사람이 민감한 호출을 거부할 수 있는 방법을 권장한다.^[11][23][29]

캐시 안정성을 위해 서버는 도구를 결정적 순서로 반환해야 한다. 완전한 도구 목록 결과에는 ttlMs와 cacheScope가 있어야 하며, 관련 목록 변경 알림은 유효 시간이 끝나기 전이라도 캐시된 결과를 무효화한다.^[8][11][28]

6. 클라이언트 기능과 공통 패턴

개정판 2026-07-28은 서버가 독립적으로 보내는 JSON-RPC 요청을 없앴다. 서버가 지원되는 작업을 끝내려면 클라이언트 입력이 필요하면 resultType이 input_required인 InputRequiredResult를 반환할 수 있다. 그 inputRequests 맵에는 클라이언트가 처리할 수 있다고 선언한 엘리시테이션, 샘플링, 루트 요청이 담길 수 있다. 결과에는 불투명한 requestState 값도 들어갈 수 있다.^[22]

입력 요청이 충족되면 클라이언트는 inputResponses를 붙여 원래 작업을 다시 요청하고, requestState가 주어졌다면 그대로 되돌려 보낸다. 서버는 클라이언트가 응답하거나 재시도할 것이라고 가정하면 안 된다. 이 방식은 각 네트워크 교환을 클라이언트가 시작하는 형태로 유지하면서 둘 이상의 상호작용 라운드를 지원한다.^[22]

6.1. 엘리시테이션

엘리시테이션은 서버가 사람에게 추가 정보를 요청할 수 있게 하는 능동형 클라이언트 기능이다. 클라이언트가 관련 기능을 선언한 경우에만 쓸 수 있다. 현재 개정판은 구조화된 비민감 입력을 위한 폼 모드(form mode)와 외부 주소에서 일어나는 상호작용을 위한 URL 모드(URL mode)를 지원한다.^[12]

폼 모드는 제한된 스키마를 쓰며, 비밀번호, API 키, 액세스 토큰, 결제 자격 증명 같은 비밀 정보를 요청하면 안 된다. URL 모드는 MCP 클라이언트 밖에서 처리되는 인증이나 민감한 입력에 맞는다. 여러 차례 왕복 설계에서 클라이언트는 원래 요청을 다시 보내 결과를 전달하며, 2025-11-25 개정판의 notifications/elicitation/complete 신호는 제거되었다.^[8][12]

클라이언트는 어느 서버가 묻는지 보여 주고, 사용자가 거절하거나 취소할 수 있게 하며, URL을 열기 전에 검증하고, 밝힌 요청 범위를 넘는 정보를 보내지 말아야 한다.^[12][23]

6.2. 비권장 기능

루트(roots)는 클라이언트가 프로젝트 디렉터리 같은 URI 경계를 서버에 알리는 기능이다. 샘플링(sampling)은 서버가 호스트에 모델 완성을 요청하는 기능이다. 로깅(logging)은 서버가 구조화된 로그 메시지를 클라이언트에 보내는 기능이다. 세 기능 모두 2026-07-28에서 여전히 명세되어 있고 동작하지만 비권장(deprecated)이다. 새 구현은 추가하지 말아야 하며, 기존 구현은 이전(migrate)해야 한다.^[13][14][15]

권장 대안은 다음과 같다. 루트 대신 도구 매개변수, 리소스 URI, 서버 구성으로 디렉터리나 파일을 전달하고, 샘플링 대신 모델 제공자 API와 직접 연동하며, stdio에서는 표준 오류에 로그를 쓰거나 관측성을 위해 OpenTelemetry를 쓴다. 루트는 접근 제어 경계였던 적이 없고, 샘플링은 호스트의 모델 선택 정책이나 자격 증명 정책을 서버에 넘겨준 적이 없다.^[13][14][15]

수명 주기 정책은 보통 비권장 시점과 제거 대상이 될 수 있는 시점 사이에 최소 12개월을 요구한다. 활성 보안 위험에 대한 긴급 제거도 최소 90일과 Core Maintainer 승인이 필요하다. 따라서 비권장이라는 말은 기능이 2026년 7월 프로토콜에서 사라졌다는 뜻이 아니다.^[15][30]

6.3. 태스크 확장

태스크(Tasks)는 2025-11-25 개정판에서 실험적 핵심 기능이었다. 2026-07-28에서는 공식 io.modelcontextprotocol/tasks 확장으로 옮겨졌고 재설계되었다.^[8][31]

이 확장을 통해 서버는 오래 걸리는 작업에 지속성 있는 태스크 핸들을 반환할 수 있다. 클라이언트는 tasks/get으로 상태를 조회하고, tasks/update로 진행 중 요청된 입력을 제공하며, tasks/cancel로 취소를 요청한다. 태스크 상태 알림은 subscriptions/listen으로 전달될 수 있다. 지원 여부는 확장 기능 맵으로 협상하며, 핵심 프로토콜을 지원한다고 해서 자동으로 지원되는 것은 아니다.^[31]

7. 인가

MCP 인가는 선택 사항이며 HTTP 기반 전송에 적용되고 stdio에는 적용되지 않는다. 보호된 MCP 서버는 OAuth 리소스 서버로 동작하고, 별도의 인가 서버가 사용자를 인증하고 그 MCP 서버용 액세스 토큰을 발급할 수 있다.^[25]

서버는 클라이언트가 인가 서버를 찾을 수 있도록 OAuth Protected Resource Metadata를 게시한다. 클라이언트는 이어서 OAuth Authorization Server Metadata 또는 OpenID Connect Discovery 문서를 검증한다. 인가 서버 발급자(issuer)마다 별도의 보안 경계이므로, 저장된 클라이언트 자격 증명은 그것을 발급한 발급자에 묶여 있어야 한다.^[25][32]

공개 클라이언트는 PKCE(Proof Key for Code Exchange)를 쓰는 인가 코드 흐름을 사용한다. 클라이언트는 토큰이 의도한 MCP 서버에 묶이도록 RFC 8707 리소스 지시자(Resource Indicator)를 보낸다. 인가 서버는 인가 응답에 RFC 9207의 iss 매개변수를 포함해야 한다. 클라이언트는 사용자를 리다이렉트하기 전에 그 값이 있으면 기록해 둔 검증된 발급자와 비교해야 한다.^[25][27]

클라이언트 등록에는 우선순위가 있다. 미리 정해진 클라이언트 식별자가 있으면 그것을 쓰고, 지원되면 Client ID Metadata Documents를 우선하며, Dynamic Client Registration은 대체 수단으로만 쓴다. Dynamic Client Registration은 호환성을 위해 남아 있지만 2026-07-28 개정판에서 비권장(deprecated)이다. 이를 쓰는 클라이언트는 적절한 OpenID Connect application_type을 제공해야 하며, 그 결과로 받은 자격 증명을 다른 발급자와 재사용하면 안 된다.^[32][15]

MCP 서버는 액세스 토큰이 자기 대상으로 발급되었는지 검증해야 한다. 같은 토큰을 상위 API로 그대로 넘기면 안 되며, 서버는 하위 API 대상(audience)에 맞는 별도 토큰을 얻어야 한다. 토큰 전달은 의도된 리소스 경계를 무너뜨리고 혼동된 대리인(confused deputy) 취약점을 만들 수 있다.^[27][23]

스코프는 최소 권한 원칙을 따라야 하며, 특정 작업에 더 많은 권한이 필요할 때 넓어질 수 있다. 인증은 신원이나 권한 부여를 확인할 뿐, 서버의 지침, 도구 설명, 반환 콘텐츠가 신뢰할 만하다는 것을 확인해 주지 않는다.^[25][27][23]

8. 보안과 신뢰 모델

MCP는 상호운용성 프로토콜이며, 패키지 인증, 샌드박싱, 모델 안전 체계가 아니다. 보안은 호스트, 서버, 인가 서비스, 운영체제, 배포 구성, 사용자 인터페이스에 달려 있다.^[27][23]

공식 보안 자료는 반복되는 위험을 여러 가지로 설명한다.^[27][23]

모델이 신뢰할 수 없는 리소스, 프롬프트 템플릿, 도구 설명, 도구 결과를 처리하면 프롬프트 인젝션(prompt injection)은 여전히 가능하다. 구조화된 메시지는 유형과 출처를 보존하는 데 도움이 되지만 콘텐츠를 안전하게 만들지는 못한다. 호스트는 서버 데이터와 시스템 정책을 구분하고, 결과를 중요한 용도로 쓰기 전에 검증하며, 영향이 큰 작업을 검토할 수 있게 유지해야 한다.^[11][23][29]

serverInfo는 서버가 스스로 밝힌 정보이고, roots는 샌드박스가 아니라 설명 정보이며, 도구 주석은 검증된 동작이 아니라 주장이다. OAuth는 접근을 부여할 뿐 판단의 옳음을 보장하지 않는다. 이 가운데 하나를 완전한 신뢰 통제로 여기면 잘못된 안심을 낳는다.^{[21][13][27][29]}

로컬 서버는 특별한 주의가 필요하다. 설치하거나 시작하는 과정에서 임의의 코드가 실행될 수 있기 때문이다. 예를 들어 Visual Studio Code는 MCP 서버를 시작하기 전에 사용자가 그 서버를 이해해야 한다고 경고한다. 조직은 허용 목록, 서명된 패키지, 컨테이너, 제한된 서비스 계정, 네트워크 정책, 감사 로깅을 추가할 수 있지만, 이는 기본 프로토콜 요구 사항이 아니라 배포 단계의 통제 수단이다.^[24]

ACM Transactions on Software Engineering and Methodology에 실린 동료 심사 조사 논문은 MCP 위협을 서버 생성, 배포, 운영, 유지 관리 단계별로 정리한다.^[33] 이 분류 체계는 시스템을 체계적으로 검토하는 틀을 제공할 뿐, 설명된 공격이 모두 실제로 일어났다는 뜻이 아니며 보편적인 사고율을 제시하지도 않는다.

9. 버전 기록

MCP 개정판은 YYYY-MM-DD 형식의 날짜를 쓴다. 수명 주기, 전송, 기능의 의미가 릴리스마다 크게 다르므로 구현은 자신이 따르는 개정판 이름을 명시해야 한다.^[20]

2024-11-05 개정판은 2024년 11월 25일 Anthropic의 공개 출시와 함께 나온 최초의 최종 사양이다. 호스트-클라이언트-서버 모델, JSON-RPC 메시지, 리소스, 프롬프트, 도구, 루트, 샘플링, 기능 협상, 상태를 가진 initialize 수명 주기를 확립했다.^[2][34]

이 개정판의 HTTP 전송은 SSE와 POST 엔드포인트를 따로 썼다. 그 HTTP+SSE 전송은 현재 비권장이지만, 원래 개정판은 호환되는 이전 구현에 여전히 관련이 있다.^[34][15]

2025-03-26 개정판은 HTTP+SSE를 대체하는 Streamable HTTP, OAuth 기반 인가 프레임워크, 도구 주석을 도입했다. 초기화 핸드셰이크를 유지했고 선택적 HTTP 세션을 허용했다.^[35]

2025-06-18 개정판은 JSON-RPC 일괄 처리(batching)를 제거하고, 구조화된 도구 출력, 엘리시테이션, 도구 결과의 리소스 링크, HTTP 프로토콜 버전 헤더를 추가했다. 인가 변경에는 OAuth Protected Resource Metadata와 Resource Indicators가 포함되었다.^[36]

일괄 처리 제거는 JSON-RPC 적합성만으로 MCP 동작이 정해지지 않는다는 점을 보여 준다. JSON-RPC 2.0은 일괄 페이로드를 허용하지만, 2025년 6월 이후의 MCP 개정판은 이를 허용하지 않는다.^[36][1]

2025-11-25 개정판은 OpenID Connect Discovery, 점진적 인가 스코프, 아이콘, URL 모드 엘리시테이션, 도구를 쓰는 샘플링, Client ID Metadata Documents를 추가하거나 확장했고, 실험적 핵심 태스크를 도입했다. 스키마가 다른 방언(dialect)을 선언하지 않으면 기본값으로 JSON Schema 2020-12를 선택했다.^[37]

2025-11-25 개정판은 마지막 이전(legacy) 개정판이자 initialize 기반 개정판이다. 그 태스크, 세션, 서버 발신 요청, 여러 클라이언트 기능은 현재 2026-07-28의 동작으로 설명하면 안 된다.^[8][20]

프로젝트는 2026년 7월 28일 프리릴리스가 아닌 안정 GitHub 릴리스로 2026-07-28 개정판을 공개했다.^[5] 이 개정판은 핵심을 무상태로 만들고 initialize와 프로토콜 세션을 제거했으며, 요청마다 버전과 기능 메타데이터를 필수로 하고 server/discover를 필수로 추가했다.^[8]

이 개정판은 HTTP GET 스트림과 리소스별 구독 메서드를 subscriptions/listen으로 바꾸었고, 독립된 서버 발신 요청을 여러 차례 왕복 결과로 바꾸었으며, 성공 결과에 resultType을 요구했다. SSE 재전송을 제거했고, Tasks를 확장으로 옮겼으며, 표준 요청 헤더와 캐시 메타데이터를 추가했다. 루트, 샘플링, 로깅, Dynamic Client Registration, HTTP+SSE, 샘플링의 includeContext 값 두 개는 비권장 레지스트리에 편입되거나 공식화되었다.^[8][15]

일부 구현은 이전 호환성이 필요하므로 개정판은 두 시대 병행(dual-era) 감지와 대체 규칙을 명시한다. 새 개정판을 지원한다고 2025-11-25를 버릴 필요는 없다. 다만 서버는 두 방식을 섞지 말고, 선택한 개정판의 의미에 따라 최신 방식과 이전 방식의 교환을 각각 처리해야 한다.^[20][6][7]

10. 거버넌스와 운영

프로젝트는 주요 프로토콜과 절차 변경에 사양 개선 제안(Specification Enhancement Proposals, SEP)을 쓴다. SEP-932는 기여자, 유지관리자, 핵심 유지관리자, 수석 유지관리자 등의 역할을 정했다. 멤버십은 고용 기업이 아니라 개인에게 속한다. 유지관리자는 제안과 구현을 검토하고, 핵심 및 수석 유지관리자는 프로젝트의 더 넓은 방향과 저장소 관리를 맡는다.^[16][17]

제안, 이슈 토론, 공개된 사양은 서로 다른 목적을 가진다. 제안은 규범적 효력 없이 동기와 설계 논의를 담을 수 있다. 공개된 사양 개정판과 릴리스 기록이 무엇이 출시되었는지를 결정한다.^[1]

2025년 12월 9일 Anthropic은 MCP를 Linux Foundation의 지시형 펀드인 Agentic AI Foundation에 기증했다. 이 재단은 MCP, Block의 goose 프로젝트, OpenAI의 AGENTS.md를 창립 기여물로 출범했다.^[18] 이 기증은 중립적인 조직적 기반을 제공했지만 프로젝트의 기술 거버넌스를 대체하지는 않았다.^[1]

MCP 저장소는 MIT에서 Apache-2.0으로 옮겨 가는 중이며, 하나의 라이선스로 통일되어 있지 않다. 라이선스 파일은 신규 코드와 사양 기여에 Apache-2.0을, 사양이 아닌 문서 기여에 CC BY 4.0을 적용한다고 밝힌다. 저작자가 재라이선스에 동의하지 않은 기존 기여는 MIT로 남아 있다.^[1]

파일 이력이 서로 다르므로 하류 사용자는 자신이 복사하거나 재배포하는 자료에 붙은 고지를 확인해야 한다. 프로젝트 전체를 단순히 ‘MIT 라이선스’라고 부르면 이 전환과 별도의 문서 라이선스가 빠진다.^[1]

11. 구현체와 프로젝트 도구

프로젝트는 공식 소프트웨어 개발 키트(SDK), 대화형 Inspector, 공개 메타데이터 레지스트리를 운영한다. 이 도구들은 구현과 탐색을 돕지만, 서버가 안전하다거나 모든 호스트와 상호운용된다고 인증하지는 않는다.^[1]

2026년 7월 28일 기준 공식 SDK 페이지는 TypeScript, Python, C#, Go를 1단계(Tier 1), Java와 Rust를 2단계(Tier 2), Swift, Ruby, PHP, Kotlin을 3단계(Tier 3)로 분류했다. 단계는 기능 범위, 테스트, 유지 관리, 릴리스 약속을 반영하며 시간이 지나면 바뀔 수 있다.^[1]

SDK는 프로토콜 배관 작업을 줄이지만, 도구 뒤의 업무 로직을 검증하거나 권한을 선택하거나 사용자 정의 호스트 동작과의 호환성을 보장하지는 않는다. 클라이언트와 서버는 공식 SDK 없이도 사양을 구현할 수 있다.^[1]

MCP Inspector는 공식 대화형 테스트 및 디버깅 도구다. 서버에 연결해 기능과 프로토콜 메시지를 살펴보고, 리소스와 프롬프트를 탐색하며, 도구를 호출할 수 있다. 인증 프로그램이나 악성코드 검사기가 아니며, 자동화된 적합성 및 보안 테스트를 대신하지도 않는다.^[1]

공식 MCP 레지스트리는 2025년 9월 공개 프리뷰에 들어갔다. 표준화된 server.json 메타데이터를 저장하고, 네임스페이스 소유권을 검증하며, 하류 마켓플레이스와 집계 서비스를 위한 API를 제공한다. 공개 패키지와 원격 엔드포인트를 설명하지만 패키지 자체를 호스팅하지는 않는다.^[1][38]

레지스트리는 역방향 도메인(reverse-domain) 네임스페이스를 검증된 GitHub 계정이나 도메인 소유권으로 인증한다. 모더레이션 정책은 제한적인 큐레이션을 제공할 뿐, 등재된 서버를 보증하거나 취약점 스캔을 대체하지 않는다.^[38] 따라서 레지스트리 항목은 발행된 메타데이터와 네임스페이스 통제의 근거일 뿐, 서버가 안전하다는 근거가 아니다.^[1]

MCP Apps는 2026년 1월 26일 첫 공식 MCP 확장이 되었다. 호환되는 도구는 ui:// URI로 리소스를 가리킬 수 있고, 이를 지원하는 호스트는 그 리소스를 샌드박스된 iframe에서 렌더링할 수 있다. 포함된 인터페이스와 호스트는 postMessage 위에서 JSON-RPC로 통신한다.^[1]

앱은 선택 사항이다. 확장을 지원하지 않는 호스트도 일반 결과를 제공한다면 기저 도구를 계속 쓸 수 있다. iframe 샌드박싱은 일부 브라우저 기능을 제한하지만, 호스트에는 여전히 콘텐츠 보안 정책, 권한 통제, 출처 검사, 명확한 출처 표시가 필요하다.^[1]

12. 도입 사례

공식 제품 기록은 여러 벤더의 구현을 보여 주지만, 보편적 지원이나 완전한 프로토콜 적합성을 입증하지는 않는다.^[1]

• Anthropic의 2024년 11월 발표에는 SDK, 참조 서버, Claude Desktop의 로컬 서버 지원, 더 넓은 Claude 제품 지원 계획이 포함되었다.^[2]
• GitHub Copilot은 2025년 4월 VS Code 1.99에서 에이전트 모드에 MCP 서버 지원을 추가했다.
• OpenAI는 2025년 5월 21일 Responses API에 원격 MCP 서버 지원을 추가했다. 그 전에는 Agents SDK에서 지원했다.^[39]
• Google Cloud는 2025년 12월 11일 일부 Google 서비스용 관리형 원격 MCP 서버를 발표했다.^[1]

이 구현들은 프로토콜 개정판, 전송 방식, 인증, 기능 범위, 사용자 인터페이스, 정책 통제에서 서로 다르다. ‘MCP를 지원한다’는 말이 두 제품의 동작이 같다는 뜻은 아니다. 호환성은 특정 호스트, 서버, 개정판, 전송 방식, 인가 구성에 대해 시험해야 한다.^[1]

공개된 다운로드 수, 저장소 수, 서버 수 합계는 정의가 서로 호환되지 않을 수 있고 빠르게 바뀐다. 패키지 다운로드가 활성 사용자와 같지 않고, 레지스트리 항목이 안전한 배포와 같지 않으며, 소스 코드 검색 결과가 적합한 구현과 같지 않다. 따라서 출처 없는 생태계 총계는 제시하지 않으며, MCP를 보편 표준이라고 부르지 않는다.^[1]

13. 인접 인터페이스와의 관계

함수 호출(function calling)은 애플리케이션이 함수 스키마를 제공하고 모델이 고른 구조화된 인자를 받는 모델 API 기능이다. MCP는 호스트 쪽 클라이언트와 외부 서버 사이의 탐색과 호출을 정의한다. 호스트는 MCP 도구 정의를 선택한 모델의 도구 형식으로 바꿀 수 있다.^[11][39]

함수 호출만으로는 독립적으로 개발된 기능 제공자가 리소스와 프롬프트를 어떻게 노출하는지, 클라이언트가 서버의 프로토콜 개정판을 어떻게 찾는지, 서버가 추가 클라이언트 입력을 어떻게 얻는지 정해지지 않는다. MCP는 모델 제공자의 도구 API를 대체하지 않으며, 호스트가 그 API에 맞춰 옮길 수 있는 기능을 제공할 뿐이다.^[11][39][1]

Language Server Protocol은 코드 편집기와 언어 지능 서버 사이의 통신을 표준화한다. MCP는 비슷한 재사용 패턴을 따르고 JSON-RPC도 쓰지만, 메서드, 데이터 타입, 신뢰 경계가 다르다. LSP 서버는 자동 완성과 진단 같은 프로그래밍 언어 작업을 제공하고, MCP 서버는 여러 영역의 도구나 컨텍스트를 노출할 수 있다.^[1]

OpenAPI 3.2는 HTTP API를 언어에 독립적으로 기술하는 형식을 정의한다. 반면 MCP는 서버 탐색, 리소스, 프롬프트, 도구, 클라이언트 입력, 표준 전송 방식을 갖춘 런타임 JSON-RPC 교환을 정의한다.^[4][19][40] 한 시스템이 두 인터페이스를 함께 쓸 수 있지만, 어느 한쪽 사양을 채택했다고 해서 애플리케이션의 인가 정책이나 기저 작업의 의미가 정해지지는 않는다.^[25][40]

Google은 독립 에이전트 사이의 통신과 작업 조율을 위해 Agent2Agent 프로토콜을 소개했다. 출시 자료는 A2A와 MCP를 상호 보완적인 것으로 제시했다. MCP는 애플리케이션이나 에이전트를 도구와 컨텍스트에 연결하고, A2A는 대등한 주체로 행동하는 에이전트 사이의 협업을 다룬다. 시스템은 두 프로토콜을 모두, 하나만, 또는 어느 것도 쓰지 않을 수 있다.^[1]

14. 설계 한계와 상호운용성

MCP는 메시지 교환을 표준화하며 AI 시스템 전체의 동작을 표준화하지 않는다. 실질적 한계는 다음과 같다.^[1]

• 선택 기능: 개정판이 정의한 기능이라도 엔드포인트가 광고하지 않을 수 있다.
• 버전 차이: 최신, 이전, 초안 문서는 수명 주기와 전송 동작이 크게 다를 수 있다.
• 의미 차이: 이름이 비슷한 두 도구도 부작용, 검증 규칙, 결과 품질이 다를 수 있다.
• 호스트 정책: 호스트는 승인, 모델 선택, 로깅, 콘텐츠 처리 규칙을 다르게 적용할 수 있다.
• 서버 신뢰: 규격을 따르는 서버도 악의적이거나 손상되었거나 과도한 권한을 갖거나 부정확할 수 있다.
• 모델 동작: 모델은 잘못된 도구를 고르거나 잘못된 인자를 넣거나 올바른 결과를 잘못 해석할 수 있다.
• 전송 제약: stdio, 원격 HTTP, 사용자 정의 전송 방식은 서로 다른 배포 및 보안 요구 사항을 만든다.
• 인가 경계: OAuth 권한 부여는 서버 접근을 통제하지만, 임의의 다운스트림 토큰 사용까지 허가하지는 않는다.

견고한 구현에는 프로토콜 적합성과 시스템 수준 통제가 모두 필요하다. 관련 조치는 명시적 서버 신원, 최소 권한 자격 증명, 작업별 인가, 스키마 검증, 출력 출처 표시, 타임아웃, 속도 제한, 취소, 감사 로그, 패키지 검증, 네트워크 격리, 영향이 큰 작업에 대한 사람의 확인이다.^[27][23]

MCP의 주된 기여는 애플리케이션과 기능 사이의 경계에서 공유되고 버전이 붙은 인터페이스를 제공하는 데 있다. 이를 모델 안전 장치나 패키지 신뢰 체계로 여기거나, 시험 없이도 모든 참여 제품이 상호운용된다는 증거로 여기면 안 된다.^[1]