2026-07-28 사양에서 달라진 연결 방식
MCP(Model Context Protocol) 공식 사이트는 2026-10-03 기준 현행(Current) 사양을 2026-07-28 버전으로 표시합니다. 이 버전의 변경 목록(Key Changes)에 따르면 이전 버전의 initialize 핸드셰이크와 프로토콜 수준 세션이 빠졌습니다. 이제 모든 요청이 _meta 필드에 프로토콜 버전과 클라이언트 기능(capabilities)을 담습니다. 서버는 지원 버전, 기능, 서버 정보를 알려 주는 server/discover를 반드시 구현해야 하고, 클라이언트는 이 요청을 먼저 보낼 수도 있고 바로 다른 요청을 보낸 뒤 버전 오류를 처리할 수도 있습니다.
서버가 클라이언트에 먼저 요청을 보내던 방식도 바뀌었습니다. 서버가 추가 입력이 필요하면 결과로 input_required를 돌려주고, 클라이언트가 입력을 모아 원래 요청을 다시 보냅니다. 사양은 이 방식을 다중 왕복 요청(Multi Round-Trip Requests, MRTR)이라고 부릅니다. 모든 결과에는 resultType 필드가 붙고, Roots, Sampling, Logging 기능은 폐지 예정(Deprecated)으로 바뀌었습니다. 2025-11-25 이전 버전을 기준으로 쓴 예제를 보고 있다면 이 차이부터 확인해야 합니다.
누가 호출을 정하는지로 기능 3종을 나누기
사양의 서버 기능 개요는 서버가 제공하는 기능을 제어 주체로 구분합니다. 프롬프트는 사용자가 골라 쓰는 템플릿이고, 리소스는 애플리케이션이 맥락에 붙이고 관리하는 데이터이며, 도구는 모델이 행동하려고 호출하는 함수입니다. 사양은 각각의 예로 메뉴에서 고르는 명령, 파일 내용과 git 기록, API POST 요청과 파일 쓰기를 듭니다. 공식 학습 문서는 여행 계획을 예로 들어 항공편 검색은 도구, 캘린더는 리소스, 휴가 계획 템플릿은 프롬프트로 나눕니다.
같은 데이터라도 누가 언제 부르는지에 따라 기능 종류가 달라집니다. 작성자가 만든 견적 업무 서버 예시에서, 단가표를 모델이 필요할 때 조회하게 하려면 도구로 두고, 호스트 앱이 견적 작업을 시작할 때 맥락으로 붙이게 하려면 리소스로 둡니다. 아래 표는 이 예시를 사양 메서드에 대응시킨 것입니다.
| 기능 | 제어 주체 | 사양 메서드 | 예시 이름 | 설계 메모 |
|---|---|---|---|---|
| 프롬프트 | 사용자 | prompts/list, prompts/get | quote_reply | 인자: 고객사, 품목. 서버가 인자를 검증 |
| 리소스 | 애플리케이션 | resources/list, resources/templates/list, resources/read | pricing://catalog/{item} | 읽기 전용. lastModified 주석으로 기준일 표시 |
| 도구(조회·작성) | 모델 | tools/list, tools/call | create_quote_draft | outputSchema로 결과 구조 고정 |
| 도구(외부 발송) | 모델, 사람이 거부 가능 | tools/call | send_quote | 호스트에서 실행 전 확인 |
프롬프트는 사용자가 골라서 작업을 시작합니다
사양의 Prompts 문서는 사용자 제어를 언제 쓸지 사용자가 정한다는 뜻으로 설명합니다. 내용은 서버가 정합니다. 클라이언트는 prompts/list로 목록을 받고, prompts/get에 이름과 인자를 보내 메시지 배열을 받습니다. 메시지에는 텍스트, 이미지, 오디오와 함께 resource_link나 내장 리소스를 넣을 수 있습니다. 이름이 틀리거나 필수 인자가 빠지면 서버는 -32602(Invalid params) 오류를 돌려줘야 합니다(SHOULD). 사양은 슬래시 명령을 예로 보여 주지만, 프로토콜이 특정 화면 방식을 정하지는 않는다고 적었습니다.
작성자 예시의 quote_reply 프롬프트는 고객사와 품목을 인자로 받고, 단가표 리소스를 resource_link로 붙인 메시지를 돌려줍니다. 사용자가 이 프롬프트를 고르면 누가 시작하든 같은 절차와 같은 참조 자료로 견적 회신이 시작됩니다.
리소스는 URI로 불러 맥락에 붙입니다
리소스는 URI로 식별합니다. 클라이언트는 resources/list로 고정 리소스를, resources/templates/list로 RFC 6570 URI 템플릿을 받고, resources/read로 내용을 읽습니다. resources/read 1번에 여러 contents를 돌려줄 수 있습니다. 리소스에는 audience(user 또는 assistant), priority(0.0~1.0), lastModified 주석을 붙일 수 있습니다. https:// 스킴은 클라이언트가 웹에서 직접 가져올 수 있을 때만 쓰고, 그렇지 않으면 다른 스킴이나 사용자 정의 스킴을 쓰라고 사양은 권합니다.
없는 리소스를 요청받으면 서버는 -32602 오류를 돌려줘야 하며, 빈 contents 배열로 답하면 안 됩니다. 목록과 읽기 결과에는 ttlMs와 cacheScope 필드가 붙습니다. ttlMs는 밀리초 단위의 신선도 힌트이고, cacheScope가 private이면 공유 중간 서버가 응답을 캐시하지 않아야 합니다. 목록은 요청에 담긴 권한에 따라 달라질 수 있지만 연결별로 달라지면 안 됩니다. 작성자 예시에서 단가표처럼 고객별 할인율이 섞이는 데이터는 private로 두는 편이 맞습니다.
도구는 스키마와 오류 2종을 함께 정의하기
tools/list는 이름(name), 기능 설명(description), 입력 스키마(inputSchema) 등을 포함한 도구 정의를 반환합니다. 표시용 이름(title)과 출력 스키마(outputSchema)는 선택 항목입니다. inputSchema는 JSON Schema 객체여야 하며 $schema가 없으면 2020-12 버전으로 봅니다. outputSchema를 제공하면 서버는 이에 맞는 structuredContent를 반드시 돌려줘야 하고, 클라이언트는 결과를 검증해야 합니다(SHOULD). 도구 이름은 1~128자, 영문 대소문자와 숫자, 밑줄, 하이픈, 점만 쓰도록 권합니다. 여러 서버의 도구를 모으는 클라이언트는 이름이 겹칠 수 있으므로 서버 식별자 접두어 같은 구분 방법을 써야 하며, serverInfo의 이름은 고유하다는 보장이 없습니다.
오류는 2종으로 나뉩니다. 모르는 도구나 형식이 틀린 요청은 JSON-RPC 프로토콜 오류로 돌려줍니다. API 실패, 입력 검증 실패, 업무 규칙 위반은 결과 안에 isError: true로 돌려주며, 사양은 이 오류를 모델이 읽고 인자를 고쳐 다시 시도할 수 있는 피드백으로 설명합니다. 작성자 예시에서 납기일 형식이 틀렸거나 최소 주문 수량에 못 미치면 isError로 이유를 문장으로 적어 돌려주면 됩니다.
사양은 사람이 도구 호출을 거부할 수 있어야 하고(SHOULD), 신뢰하는 서버가 아니면 도구 주석(annotations)을 믿지 말아야 한다(MUST)고 적었습니다. send_quote처럼 외부로 기록을 보내는 도구는 호스트가 실행 전에 입력값을 보여 주고 확인을 받는 흐름으로 설계합니다.
추가 입력이 필요하면 원래 요청을 다시 보내기
MRTR 흐름에서 서버는 tools/call에 resultType이 input_required인 결과로 답하고, inputRequests에 필요한 요청(예: form 방식 elicitation/create)과 선택 필드 requestState를 담습니다. 클라이언트는 사용자 입력을 모아 inputResponses와 requestState를 넣어 원래 요청을 다시 보내며, 이때 JSON-RPC id는 처음 요청과 달라야 합니다. 사양은 이 방식이 서버 인스턴스 사이 공유 저장소나 상태 유지 로드 밸런싱 없이 동작한다고 설명합니다.
아래 도식은 이 순서를 견적 예시로 다시 그렸습니다. 할인율이 정책 범위를 넘으면 서버가 할인 사유 입력을 요청하는 경우입니다. 사양은 requestState를 공격자가 바꿀 수 있는 입력으로 다루고, 권한이나 업무 판단에 영향을 주면 HMAC 같은 방법으로 무결성을 보호하라고 요구합니다(MUST). 할인율을 requestState에 담는다면 서버가 서명을 확인한 뒤에만 사용해야 합니다. form 방식으로 비밀번호나 인증 정보 같은 민감 정보를 요청해서는 안 되며, 이런 경우는 URL 방식을 쓰도록 정해져 있습니다.
목록이 바뀌는 경우는 클라이언트가 subscriptions/listen으로 받을 알림 종류를 지정해 둡니다. 서버는 요청받지 않은 종류의 알림을 보내면 안 되고, toolsListChanged를 요청한 클라이언트에게 notifications/tools/list_changed를 보냅니다. 클라이언트는 알림을 받은 뒤 tools/list를 다시 요청합니다.
견적 업무의 연결 명세 작성하기
MCP로 연결하려는 업무 시스템 1개를 골라 데이터와 동작을 나열하고, 항목마다 사용자, 앱, 모델 중 누가 호출하는지 적어 보십시오. 모델이 호출하는 항목 중 외부에 기록을 남기는 도구에는 실행 전 확인을, 업무 규칙 위반에는 isError로 돌려줄 문장을 정합니다. 쓰고 있는 SDK가 2026-07-28 버전과 server/discover를 지원하는지도 함께 확인하면 됩니다.