MCP 2026-07-28 릴리스 후보(release candidate)는 MCP 출시 이후 가장 큰 규모의 주요 사양 개정입니다. 이는 또한 이 프로토콜을 기반으로 클라이언트(clients), 서버(servers), SDK, 게이트웨이(gateways) 및 개발자 도구(developer tools)를 구축하는 모든 이들을 위한 호환성 테스트이기도 합니다.

이 릴리스 후보는 2026년 5월 21일에 확정되었습니다. 최종 사양은 2026년 7월 28일로 예정되어 있습니다. 이 기간은 실제 구현을 테스트하고 마이그레이션(migration) 과정에서의 고충을 찾아낼 수 있는 시간입니다.

1. 전송(transport) 가정을 확인하세요

가장 큰 변화는 이제 MCP가 프로토콜 계층에서 무상태(stateless)가 되었다는 점입니다.

만약 현재의 스트리밍 가능 HTTP(Streamable HTTP) 구현이 initialize, initialized 또는 Mcp-Session-Id에 의존하고 있다면, 마이그레이션 작업이 필요합니다. 릴리스 후보에서는 각 요청이 _meta에 프로토콜 버전, 클라이언트 정보 및 기능(capabilities)을 포함합니다. 새로운 server/discover 메서드는 클라이언트가 사전에 서버의 기능(capabilities)을 알아야 하는 경우를 처리합니다.

스트리밍 가능 HTTP를 통한 tools/call 요청에는 이제 다음과 같은 헤더가 포함됩니다:

MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

이는 인프라가 MCP 트래픽을 처리하는 방식을 변화시킵니다. 게이트웨이는 더 이상 일반적인 작업을 라우팅하거나 속도 제한(rate-limit)하기 위해 JSON 본문을 검사할 필요가 없습니다. 프로토콜이 더 이상 스티키 세션(sticky session)을 가정하지 않기 때문에 로드 밸런서(load balancer)는 어떤 서버 인스턴스로든 요청을 보낼 수 있습니다.

호환성 질문은 간단합니다: 귀하의 서버가 여전히 연결(connection) 내에 필수적인 상태(state)를 숨기고 있습니까?

만약 그렇다면, 해당 상태를 명시적인 애플리케이션 핸들(application handle)로 이동시키세요. 예를 들어, 도구(tool)가 basket_id, browser_id 또는 작업 핸들(job handle)을 반환할 수 있으며, 모델은 나중에 이를 일반적인 도구 인자(tool argument)로 다시 전달할 수 있습니다. 이렇게 하면 상태가 모델에 가시화되고 서버 인스턴스 간에 이식(portable)이 가능해집니다.

2. 서버-클라이언트 요청 흐름(request flows) 테스트

상태 비저장(Stateless) MCP 역시 호출 중에는 상호작용이 필요합니다. 이번 릴리스 후보(Release Candidate)는 그 작동 방식을 변경합니다.

서버 주도형 요청(Server-initiated requests)은 서버가 클라이언트 요청을 처리하는 동안에만 발생할 수 있습니다. 유도(elicitation), 루트(roots), 또는 샘플링(sampling) 흐름의 경우, 서버는 InputRequiredResult를 반환하며, 클라이언트는 inputResponses와 requestState를 포함하여 원래의 호출을 재시도(retry)합니다.

이는 클라이언트가 적절한 데이터를 보존하고 다시 재생(replay)해야 함을 의미합니다. 서버는 재시도 요청이 다른 인스턴스에 도달하더라도 이를 연속된 작업(continuation)으로 취급해야 합니다.

좋은 테스트 케이스는 확인을 요청하는 파괴적인 도구 호출(destructive tool call)입니다. 서버는 입력 요청을 반환해야 하고, 클라이언트는 답변을 수집해야 하며, 재시도는 연결 메모리(connection memory)에 의존하지 않고 성공해야 합니다.

3. MCP 앱을 실제 앱 인터페이스(app surfaces)로 취급하기

MCP Apps를 통해 서버는 호스트가 샌드박스화된 iframe 내에서 렌더링할 수 있는 대화형 HTML 인터페이스를 제공할 수 있습니다.

이는 개발자 경험(developer-experience) 측면에서 큰 변화이지만, 보안 및 제품 측면에서도 시사하는 바가 큽니다. 도구(Tools)는 UI 템플릿을 사전에 선언할 수 있으며, 이를 통해 호스트는 무언가가 실행되기 전에 이를 프리페치(prefetch), 캐싱(cache) 및 검토할 수 있습니다. UI는 여전히 MCP의 JSON-RPC 프로토콜을 통해 통신하므로, UI 기반 작업은 도구 호출과 동일한 동의(consent) 경로를 거칩니다.

호스트를 관리한다면 iframe 격리, 권한 프롬프트, 캐싱 동작을 테스트하십시오. 서버를 관리한다면 UI 템플릿 선언이 결정론적(deterministic)이며 숨겨진 세션 상태(session state)에 의존하지 않는지 확인하십시오.

Apps 모델은 명시적인 템플릿, 명확한 도구 경계, 예측 불가능한 네트워크 동작 방지 등 일관된 규율을 준수하는 곳에 보상을 줄 것입니다.

4. 지금 바로 권한 부여(authorization) 강화하기

이번 릴리스 후보는 OAuth 2.0 및 OpenID Connect 배포를 중심으로 MCP 권한 부여를 더욱 강화합니다.

이제 클라이언트는 RFC 9207에 따라 권한 부여 응답(authorization responses)에서 iss 파라미터를 검증해야 합니다. 향후 클라이언트들이 iss가 없는 응답을 거부할 것으로 예상되므로, 권한 부여 서버(Authorization servers)는 지금부터 iss를 보내기 시작해야 합니다.

동적 클라이언트 등록(Dynamic Client Registration) 또한 변경됩니다. 클라이언트는 OpenID Connect application_type을 선언하며, 이는 localhost 리다이렉트 URI(redirect URIs)를 사용하는 데스크톱 및 CLI 클라이언트에게 중요합니다. 또한 클라이언트는 등록된 자격 증명(credentials)을 발급하는 권한 부여 서버의 issuer에 바인딩합니다.

이곳의 마이그레이션 체크리스트는 명확합니다:

• 클라이언트의 iss 처리 방식 검증.
• 권한 부여 서버가 iss를 전송하는지 확인.
• 동적 클라이언트 등록(Dynamic Client Registration) 메타데이터 확인.
• 리소스가 권한 부여 서버 간에 이동할 때 재등록 수행.

이는 하나의 클라이언트가 여러 서버에 연결될 수 있는 MCP의 특성상 특히 중요합니다. 이러한 구조에서 혼동(Mix-up) 위험은 이론적인 수준에 그치지 않습니다.

5. 지원 중단(Deprecated)된 핵심 기능으로 새로운 작업을 구축하는 것을 중단하십시오

이번 릴리스 후보(Release Candidate)에서는 Roots, Sampling, 그리고 Logging 기능이 지원 중단(deprecated)되었습니다.

해당 기능들은 여전히 작동합니다. 이번 릴리스에서의 지원 중단은 주석(annotation) 처리만 된 상태이며, 메서드(methods), 타입(types), 그리고 기능 플래그(capability flags)는 해당 기능이 발표된 후 1년 이내에 게시되는 모든 스펙 버전에서 계속 작동합니다. 완전히 제거하려면 별도의 SEP(Spec Enhancement Proposal)가 필요합니다.

그럼에도 불구하고, 새로운 작업은 다른 곳으로 옮겨가야 합니다:

• Roots는 도구 파라미터(tool parameters), 리소스 URI(resource URIs), 또는 서버 설정(server configuration)으로 이동해야 합니다.
• Sampling은 모델 제공자 API(model provider APIs)와의 직접적인 통합으로 이동해야 합니다.
• Logging은 stdio의 경우 stderr로, 구조화된 관측성(structured observability)의 경우 OpenTelemetry로 이동해야 합니다.

만약 SDK 추상화(abstractions)를 유지 관리한다면, 지금이 사용자의 코드를 깨뜨리지 않으면서 경고(warnings)를 추가할 적기입니다. 문서를 유지 관리한다면, 지원 중단된 기능을 기본 경로로 가르치는 것을 중단하십시오.

6. JSON Schema 2020-12를 기준으로 도구 스키마(tool schemas)를 검증하십시오

도구의 inputSchema 및 outputSchema는 이제 전체 JSON Schema 2020-12를 사용합니다.

입력 스키마 (input schemas)의 경우, 루트는 여전히 type: "object"여야 하지만, 이제 스키마에서 oneOf, anyOf, allOf, 조건문 (conditionals), $ref, 그리고 $defs를 사용할 수 있습니다. 출력 스키마 (output schemas)는 제한이 없습니다. structuredContent는 이제 객체 (object)뿐만 아니라 어떤 JSON 값이라도 가질 수 있습니다.

이는 기회와 위험을 동시에 창출합니다.

서버는 스키마 깊이 (schema depth)와 검증 시간 (validation time)을 제한해야 합니다. 구현 시 외부 $ref URI를 자동으로 역참조 (auto-dereference)해서는 안 됩니다. 단순한 객체 전용 스키마를 가정했던 클라이언트들은 복합 스키마 (composed schemas)에 대한 테스트를 수행해야 합니다.

또한 에러 핸들링 (error handling)도 확인하십시오. 리소스 누락 에러 (missing resource error)가 MCP의 커스텀 코드인 -32002에서 JSON-RPC 표준인 -32602 Invalid Params로 변경됩니다. 만약 귀하의 클라이언트가 리터럴 코드를 기준으로 매칭하고 있다면, 이를 업데이트하십시오.

체크리스트를 진행하면서 문제점이나 주요 마찰 지점 (friction points)을 발견하면 커뮤니티에 알려주세요. specification repository에 이슈를 생성할 수 있습니다. 구현 관련 질문의 경우, contributor Discord 내의 관련 Working Group 채널이 가장 빠르게 답변을 얻을 수 있는 방법입니다.