MCP 아키텍처 개요 정리
Model Context Protocol(MCP)의 범위와 핵심 개념을 소개하고 하나의 완전한 예제로 상호작용 흐름을 설명했다.
중국어 원문을 AI로 번역했습니다. 고유명사와 수치는 원문 표기를 우선하며, 중요한 판단에는 아래 출처 원문을 함께 확인하세요.
원문: Architecture overview - Model Context Protocol 발행일: 2026-07-28 ｜ 출처: modelcontextprotocol.io
이 개요는 Model Context Protocol(MCP)의 범위와 핵심 개념을 소개하고, 하나의 완전한 예시를 통해 각 핵심 개념의 실제 상호작용 흐름을 엮어 보여준다.
MCP SDK가 이미 수많은 저수준 세부 사항을 대신 처리해 주기 때문에, 대부분의 개발자는 데이터 계층 프로토콜 섹션이 가장 실용적이라고 느낄 것이다. 이 섹션은 바로 MCP server가 어떻게 context를 AI 애플리케이션에 공급하는지를 다룬다.
구체적인 구현 세부 사항은 해당 언어의 SDK 문서를 참고하기 바란다.
범위
Model Context Protocol은 다음 항목들을 포함한다:
- MCP 명세: client와 server의 구현 요구 사항을 정의한다.
- MCP SDK: 각 언어의 SDK 구현.
- MCP 개발 도구: MCP server와 client를 개발하는 도구 모음으로, MCP Inspector를 포함한다.
- MCP 참조 server 구현: 공식 제공되는 server 참조 구현.
MCP는 context 교환 이 한 가지 일만 담당한다. 즉 AI 애플리케이션이 LLM을 어떻게 사용하는지 규정하지 않으며, context를 받은 뒤 그것을 어떻게 처리하는지도 관여하지 않는다.
MCP 핵심 개념
참여자
MCP는 client-server 아키텍처를 채택한다. 하나의 MCP host, 즉 Claude Code나 Claude Desktop 같은 AI 애플리케이션 자체가 하나 이상의 MCP server에 대한 연결을 수립하는 역할을 맡는다. 구체적인 방식은 다음과 같다. host는 각 MCP server마다 MCP client를 하나씩 생성하고, 각 client는 자신이 대응하는 server에 대한 전용 연결을 하나 유지한다.
STDIO transport를 사용하는 로컬 MCP server는 보통 하나의 client만 서비스하고, Streamable HTTP transport를 사용하는 원격 server는 여러 client를 동시에 서비스한다.
MCP 아키텍처의 세 가지 핵심 역할:
- MCP Host: 하나 이상의 MCP client를 조정하고 관리하는 AI 애플리케이션.
- MCP Client: MCP server에 대한 연결을 유지하며, server로부터 context를 가져와 host가 사용하도록 한다.
- MCP Server: client에게 context를 제공하는 프로그램.
예를 들어: VS Code는 하나의 MCP host다. VS Code가 MCP server(예: Sentry MCP server)에 연결하면, VS Code 런타임은 이 연결을 유지하기 위해 MCP client 객체를 하나 인스턴스화한다. 이후 VS Code가 또 다른 server(예: 로컬 파일 시스템 server)에 연결하면, MCP client 객체를 하나 더 인스턴스화한다.
주의할 점은, MCP server는 context 데이터를 제공하는 그 프로그램을 가리키며, 그것이 어디에서 실행되는지는 상관없다. MCP server는 로컬에서 실행될 수도 있고 원격에서 실행될 수도 있다. 예를 들어 Claude Desktop이 실행하는 filesystem server는 STDIO transport를 사용해 같은 머신에서 실행되는데, 이것이 이른바 '로컬' MCP server다. 반면 공식 Sentry MCP server는 Sentry 플랫폼에서 실행되며 Streamable HTTP transport를 사용하는데, 이것이 이른바 '원격' MCP server다.
계층
MCP는 두 계층으로 나뉜다:
- 데이터 계층(Data layer): JSON-RPC 기반의 client-server 통신 프로토콜을 정의하며, capability와 버전 발견, 그리고 tools, resources, prompts, notifications 등의 핵심 primitive를 포함한다.
- 전송 계층(Transport layer): client와 server 사이의 통신 메커니즘과 채널을 정의하며, 연결 수립, 메시지 프레임 형식, 인증을 포함한다.
개념적으로 데이터 계층은 안쪽 계층이고, 전송 계층은 바깥쪽 계층이다.
데이터 계층
데이터 계층은 JSON-RPC 2.0 기반의 교환 프로토콜을 구현하고 메시지 구조와 의미를 정의한다. 다음 부분들을 포함한다:
- Discovery: client가 server/discover 요청을 통해 server가 지원하는 프로토콜 버전, capability, 신원 정보를 조회한다.
- Server 기능: server가 제공하는 핵심 능력으로, tools(AI가 동작을 실행하도록 함), resources(context 데이터), prompts(상호작용 템플릿)가 있다.
- Client 기능: server가 사용자에게 입력을 요청할 수 있게 한다. Sampling은 프로토콜 버전 2026-07-28에서 폐기 되었다.
- 보조 기능: notifications(실시간 업데이트)와 progress tracking(장시간 작업 진행 상황 추적) 등의 부가 능력.
전송 계층
전송 계층은 client와 server 사이의 통신 채널과 인증을 관리하고, 연결 수립, 메시지 프레임 캡슐화, 안전한 통신을 담당한다.
MCP는 두 가지 전송 메커니즘을 지원한다:
- Stdio transport: 표준 입력/출력 스트림을 사용해 같은 머신의 프로세스 간에 직접 통신하며, 네트워크 오버헤드가 없고 성능이 가장 우수하다.
- Streamable HTTP transport: client에서 server로 가는 메시지가 HTTP POST를 통해 전달되고, 선택적으로 SSE(Server-Sent Events)를 통해 스트리밍 전송을 구현한다. 원격 server 통신과 표준 HTTP 인증 방식(bearer token, API key, 사용자 정의 header)을 지원한다. MCP는 인증 token을 얻는 데 OAuth 사용을 권장한다.
전송 계층은 통신 세부 사항을 프로토콜 계층으로부터 추상화하여, 동일한 JSON-RPC 2.0 메시지 형식이 모든 전송 메커니즘에서 통용되도록 한다.
데이터 계층 프로토콜
MCP의 핵심은 client와 server 사이의 schema와 의미를 정의하는 데 있다. 개발자가 가장 관심을 갖는 것은 보통 데이터 계층, 특히 primitive 부분이며, 이는 server가 client에게 context를 공유하는 모든 방식을 정의한다.
MCP는 저수준에서 JSON-RPC 2.0을 사용한다. Client와 server는 서로 요청을 보내고 응답한다. 응답이 필요 없는 상황에서는 notification을 사용한다.
무상태와 발견
MCP는 무상태 프로토콜이다. 각 요청은 _meta 필드에 프로토콜 버전과 해당 요청과 관련된 capability를 담고 있으며, server는 각 요청을 독립적으로 처리할 수 있다. Client도 같은 필드에 자신을 식별해야 한다(그렇게 하지 않도록 설정한 경우는 제외). Server는 반드시 응답해야 하는 server/discover 요청을 통해 자신이 지원하는 버전과 capability를 알리며, client는 다른 어떤 요청을 보내기 전에 먼저 이 단계를 수행할 수 있다. 자세한 내용은 명세를 참고하고, 뒤의 예시에서 per-request metadata와 discovery 흐름을 보여준다.
Primitive
MCP primitive는 프로토콜 전체에서 가장 중요한 개념이다. 이는 client와 server가 서로에게 무엇을 제공할 수 있는지, 즉 어떤 유형의 context 정보를 AI 애플리케이션에 공유할 수 있고 어떤 동작을 실행할 수 있는지를 정의한다.
MCP는 server가 노출할 수 있는 세 가지 핵심 primitive를 정의한다:
- Tools: AI 애플리케이션이 호출할 수 있는 실행 가능한 함수(예: 파일 작업, API 호출, 데이터베이스 쿼리).
- Resources: AI 애플리케이션에 context 데이터를 제공하는 데이터 소스(예: 파일 내용, 데이터베이스 레코드, API 응답).
- Prompts: LLM과의 상호작용을 조직하는 데 도움이 되는 재사용 가능한 템플릿(예: system prompt, few-shot 예시).
각 primitive에는 연관된 discovery 메서드( */list ), retrieval 메서드( */get )가 있고, 일부는 execution 메서드( tools/call )도 있다. Client는 */list 메서드로 사용 가능한 primitive를 발견한다. 예를 들어 client는 먼저 tools/list 로 모든 사용 가능한 tool을 나열한 뒤 그것들을 실행할 수 있다. 이런 설계 덕분에 목록은 동적일 수 있다.
구체적인 예를 들면: 데이터베이스 context를 제공하는 MCP server는 데이터베이스를 쿼리하는 tool, 데이터베이스 schema를 담은 resource, 그리고 few-shot 예시를 담은 prompt를 노출할 수 있다.
server primitive에 대한 더 자세한 내용은 server concepts를 참고하기 바란다.
MCP는 또한 client가 노출할 수 있는 primitive를 정의하여 server 개발자가 더 풍부한 상호작용을 구축할 수 있게 한다:
- Elicitation: server가 사용자에게 추가 정보를 요청할 수 있게 한다. server가 더 많은 정보를 필요로 하거나 어떤 작업을 확인하고 싶을 때 유용하다. Server는 elicitation/create 메서드를 통해 사용자 입력을 요청한다.
Elicitation 요청은 Multi Round-Trip Requests 패턴을 통해 전달되며, 자세한 내용은 elicitation 개요를 참고하기 바란다.
폐기됨: 다음 client primitive는 프로토콜 버전 2026-07-28에서 폐기되었다.
- Sampling: server가 client의 AI 애플리케이션에 LLM completion을 요청할 수 있게 한다. server 작성자가 LLM을 사용하고 싶지만 특정 모델에 묶이고 싶지 않고 MCP server 안에 LLM SDK를 도입하고 싶지도 않은 시나리오에 적합하다. Server는 sampling/createMessage 메서드를 통해 completion을 요청하며, 역시 Multi Round-Trip Requests 패턴을 따른다. 새로운 구현은 LLM provider API에 직접 연결해야 한다.
- Logging: server가 디버깅과 모니터링을 위해 로그 메시지를 client에 보낼 수 있게 한다. 새로운 구현은 stderr (stdio transport)에 쓰거나 OpenTelemetry를 사용해야 한다.
client primitive에 대한 더 자세한 내용은 client concepts를 참고하기 바란다.
server와 client primitive 외에도, 프로토콜은 핵심 프로토콜 위에 구축되는 선택적 extension 을 지원한다. 예를 들어 Tasks extension은 server가 장시간 실행되는 요청에 대해 영속적인 handle을 반환하게 하고, client는 상태를 폴링하고 나중에 결과를 가져올 수 있다.
Notification
프로토콜은 server와 client 사이의 동적 업데이트를 위한 실시간 notification을 지원한다. 예를 들어 server의 사용 가능한 tools에 변화가 생기면(새 기능 출시, 기존 tool 수정), server는 tool 업데이트 notification을 보내 연결된 모든 client에게 알릴 수 있다. Notification은 JSON-RPC 2.0 notification 메시지로 전송된다(응답은 기대하지 않음). Change notification은 opt-in 방식이다. client가 장기 연결인 subscriptions/listen stream을 열어 어떤 유형의 notification을 받을지 선언하면, server가 이 stream 위에서 일치하는 notification을 푸시한다.
예시
아래에서는 하나의 완전한 client-server 상호작용 흐름을 통해 MCP 데이터 계층 프로토콜을 단계별로 살펴본다. JSON-RPC 2.0 메시지로 discovery, tool 작업, notification을 시연한다.
단계 1: 연결과 Discovery
상호작용의 첫 단계는 client가 server의 능력을 발견하는 것이다. Client가 server/discover 요청을 보내면, server가 자신이 지원하는 프로토콜 버전, identity, capability를 반환한다. 이 단계를 통해 client는 어떤 비즈니스 요청도 보내기 전에 server가 무엇을 할 수 있는지 알게 된다.
Discovery 요청:
{ "jsonrpc" : "2.0" , "id" : 1 , "method" : "server/discover" , "params" : { "_meta" : { "io.modelcontextprotocol/protocolVersion" : "2026-07-28" , "io.modelcontextprotocol/clientInfo" : { "name" : "example-client" , "version" : "1.0.0" } , "io.modelcontextprotocol/clientCapabilities" : { "elicitation" : { } } } } }
Discovery 응답:
{ "jsonrpc" : "2.0" , "id" : 1 , "result" : { "protocolVersion" : "2026-07-28" , "serverInfo" : { "name" : "example-server" , "version" : "1.0.0" } , "capabilities" : { "tools" : { "listChanged" : true } } } }
Discovery 요청 이해하기
server/discover 요청은 모든 MCP 요청이 반드시 지녀야 하는 표준 _meta 필드 외에 추가 파라미터가 필요하지 않다. 여기서 _meta는 세 가지를 담는다:
- protocolVersion : client가 사용하려는 프로토콜 버전.
- clientInfo : client의 name과 version으로, server가 누구와 통신하는지 알게 한다.
- clientCapabilities : client 자신이 지원하는 능력(예: elicitation)으로, server가 사용자에게 추가 입력을 요청할 수 있음을 알린다.
Discovery 응답 이해하기
응답의 result 객체는 세 가지 핵심 필드를 담는다:
- protocolVersion : server가 선택한 프로토콜 버전. Client는 이 버전이 호환되는지 확인해야 한다.
- serverInfo : server의 name과 version.
- capabilities : server가 지원하는 능력. 여기서 "tools": {"listChanged": true}는 server가 tools를 노출하고, tool 목록이 변경될 때 notification을 보내는 것을 지원한다는 뜻이다.
AI 애플리케이션에서는 어떻게 동작하는가
AI 애플리케이션의 MCP client manager는 설정된 server에 연결하고, discovery 결과를 이후 사용을 위해 캐시한다. 애플리케이션은 이 정보로 어떤 server가 어떤 기능(tools, resources, prompts)을 제공할 수 있는지, 그리고 실시간 업데이트를 지원하는지 판단한다. Python SDK에서는 client가 연결될 때 discovery가 완료되고, 결과가 client 객체에 바로 붙는다.
의사 코드 async with Client(stdio_client(server_config)) as client: if client.server_capabilities.tools: app.register_mcp_server(client, supports_tools= True ) app.set_server_ready(client)
단계 2: Tool Discovery(Primitive)
Client는 tools/list 요청을 통해 사용 가능한 tool을 발견한다. 이것은 MCP tool 발견 메커니즘의 기초 요청으로——client가 tool을 사용하려 시도하기 전에 server에 어떤 tool이 있는지 알게 한다.
{ "jsonrpc" : "2.0" , "id" : 2 , "method" : "tools/list" , "params" : { "_meta" : { "io.modelcontextprotocol/protocolVersion" : "2026-07-28" , "io.modelcontextprotocol/clientInfo" : { "name" : "example-client" , "version" : "1.0.0" } , "io.modelcontextprotocol/clientCapabilities" : { "elicitation" : { } } } } }
{ "jsonrpc" : "2.0" , "id" : 2 , "result" : { "resultType" : "complete" , "tools" : [ { "name" : "calculator_arithmetic" , "title" : "Calculator" , "description" : "Perform mathematical calculations including basic arithmetic, trigonometric functions, and algebraic operations" , "inputSchema" : { "type" : "object" , "properties" : { "expression" : { "type" : "string" , "description" : "Mathematical expression to evaluate (e.g., '2 + 3 * 4', 'sin(30)', 'sqrt(16)')" } } , "required" : [ "expression" ] } } , { "name" : "weather_current" , "title" : "Weather Information" , "description" : "Get current weather information for any location worldwide" , "inputSchema" : { "type" : "object" , "properties" : { "location" : { "type" : "string" , "description" : "City name, address, or coordinates (latitude,longitude)" } , "units" : { "type" : "string" , "enum" : [ "metric" , "imperial" , "kelvin" ] , "description" : "Temperature units to use in response" , "default" : "metric" } } , "required" : [ "location" ] } } ] , "ttlMs" : 300000 , "cacheScope" : "public" } }
Tool Discovery 요청 이해하기
tools/list는 모든 MCP 요청이 지니는 표준 _meta 필드 외에 추가 파라미터가 필요하지 않다. 또한 分页를 위한 선택적 cursor 파라미터를 받는데, 위 예시에서는 생략했다.
Tool Discovery 응답 이해하기
응답의 tools 배열은 사용 가능한 각 tool의 상세 metadata를 담는다. 이 배열 구조 덕분에 server는 여러 tool을 동시에 노출하면서도 각 기능 사이의 경계를 명확히 유지할 수 있다. 각 tool 객체는 몇 가지 핵심 필드를 담는다:
- name : server namespace 내에서 tool의 고유 식별자. tool 실행의 기본 키로서, 이름은 명확하고 규칙성이 있어야 한다(예: 단순한 calculate가 아니라 calculator_arithmetic ).
- title : client가 사용자에게 보여줄 수 있는 사람이 읽을 수 있는 표시 이름.
- description : tool이 무엇을 하는지, 언제 사용해야 하는지 상세히 설명.
- inputSchema : 기대하는 입력 파라미터를 정의하는 JSON Schema로, 타입 검증을 지원하고 명확한 파라미터 문서를 제공한다.
응답은 "resultType": "complete"로 표시되어 있고 두 개의 캐시 필드를 지닌다. ttlMs는 신선도 힌트(밀리초)로, 이 tool 목록을 5분 동안 캐시할 수 있음을 뜻한다. cacheScope는 누가 이 응답을 재사용할 수 있는지를 나타낸다. 전체 규칙은 명세의 caching utility를 참고하라.
AI 애플리케이션은 연결된 모든 MCP server에서 사용 가능한 tool을 가져와, LLM이 접근할 수 있는 하나의 통합된 tool registry로 병합한다. 이로써 LLM은 자신이 어떤 동작을 수행할 수 있는지 알고, 대화 중에 적절한 tool call을 자동으로 생성한다.
의사 코드, MCP Python SDK 패턴 사용 available_tools = [] for client in app.mcp_clients(): tools_response = await client.list_tools() available_tools.extend(tools_response.tools) conversation.register_available_tools(available_tools)
여러 server를 연합(federate)하는 client는 시작 시점에 모든 tool을 한 번에 로드하는 대신 渐进式 tool discovery를 사용할 수 있다.
단계 3: Tool 실행(Primitive)
Client는 이제 tools/call 메서드로 tool을 실행할 수 있다. 이는 MCP primitive의 실제 사용법을 보여준다: 사용 가능한 tool을 발견한 뒤, client가 적절한 파라미터를 붙여 그것들을 호출한다.
Tool 실행 요청 이해하기
tools/call 요청은 구조화된 형식을 따르며, client와 server 사이의 타입 안전성과 명확한 통신을 보장한다. 우리가 discovery 응답에 있던 정식 tool 이름( weather_current )을 사용하고, 단순화한 이름이 아님에 주목하라:
{ "jsonrpc" : "2.0" , "id" : 3 , "method" : "tools/call" , "params" : { "name" : "weather_current" , "arguments" : { "location" : "San Francisco" , "units" : "imperial" } , "_meta" : { "io.modelcontextprotocol/protocolVersion" : "2026-07-28" , "io.modelcontextprotocol/clientInfo" : { "name" : "example-client" , "version" : "1.0.0" } , "io.modelcontextprotocol/clientCapabilities" : { "elicitation" : { } } } } }
{ "jsonrpc" : "2.0" , "id" : 3 , "result" : { "resultType" : "complete" , "content" : [ { "type" : "text" , "text" : "Current weather in San Francisco: 68°F, partly cloudy with light winds from the west at 8 mph. Humidity: 65%" } ] } }
Tool 실행의 핵심 요소
요청 구조는 몇 가지 중요한 구성 요소를 담는다:
- name : discovery 응답에 있던 tool 이름( weather_current )과 정확히 일치해야 하며, server가 실행할 tool을 올바르게 식별할 수 있게 한다.
- arguments ：tool의 inputSchema에 정의된 입력 파라미터를 포함한다. 이 예시에서는: location ："San Francisco"（필수）; units ："imperial"（선택, 지정하지 않으면 기본값 "metric"）。
- _meta ：표준 per-request 필드를 전달한다: 프로토콜 버전, client capability, 그리고 client 신원 정보.
- JSON-RPC 구조 ：표준 JSON-RPC 2.0 형식으로, 고유한 id로 요청-응답을 연결한다.
Tool 실행 응답 이해하기
응답은 MCP의 유연한 콘텐츠 시스템을 보여준다:
- content 배열 ：tool 응답은 content 객체 배열을 반환하며, 리치 텍스트와 다양한 형식의 응답(텍스트, 이미지, resource 등)을 지원한다.
- Content 유형 ：각 content 객체에는 type 필드가 있다. 이 예시의 "type": "text"는 순수 텍스트를 의미하지만, MCP는 여러 content 유형을 지원한다.
- 구조화된 출력 ：응답은 실행 가능한 정보를 제공하며, AI 애플리케이션은 이를 LLM 상호작용의 context로 사용할 수 있다.
이러한 실행 모델 덕분에 AI 애플리케이션은 server 기능을 동적으로 호출하고, 구조화된 응답을 받아 LLM 대화에 통합할 수 있다.
LLM이 대화 중에 tool을 사용하기로 결정하면, AI 애플리케이션이 이 tool call을 가로채 해당 MCP server로 라우팅해 실행하고, 그 결과를 대화 흐름의 일부로 LLM에 반환한다. 이를 통해 LLM은 실시간 데이터에 접근하고 외부 세계에서 동작을 수행할 수 있다.
의사 코드: AI 애플리케이션의 tool 실행 async def handle_tool_call ( conversation, tool_name, arguments ): client = app.find_mcp_client_for_tool(tool_name) result = await client.call_tool(tool_name, arguments) conversation.add_tool_result(result) return result
단계 4: Change Notification 구독
이제 client는 server가 discovery 단계에서 "listChanged": true 를 선언했다는 것을 알았으므로, tool 목록 변경 notification을 구독할 수 있다. Client는 subscriptions/listen 요청을 보내 어떤 유형의 notification을 받을지 선언한다:
{ "jsonrpc" : "2.0" , "id" : 4 , "method" : "subscriptions/listen" , "params" : { "notifications" : { "toolsListChanged" : true } , "_meta" : { "io.modelcontextprotocol/protocolVersion" : "2026-07-28" , "io.modelcontextprotocol/clientInfo" : { "name" : "example-client" , "version" : "1.0.0" } , "io.modelcontextprotocol/clientCapabilities" : { "elicitation" : { } } } } }
Server는 notifications/subscriptions/acknowledged로 구독을 확인하며, 이는 해당 subscription ID를 담은 첫 번째 메시지다(확인 전에는 server가 다른 notification을 보내지 않는다). notifications 필드는 server가 처리하기로 동의한 구독의 부분집합을 반영하며, 지원되지 않는 notification 유형은 생략된다:
{ "jsonrpc" : "2.0" , "method" : "notifications/subscriptions/acknowledged" , "params" : { "_meta" : { "io.modelcontextprotocol/subscriptionId" : 4 } , "notifications" : { "toolsListChanged" : true } } }
Tool 목록 변경 Notification 이해하기
확인 이후, server의 사용 가능한 tools에 변화가 생기면(새 기능 출시, 기존 tool 수정, tool 일시적 사용 불가), server는 이 stream 위로 notification을 푸시한다:
{ "jsonrpc" : "2.0" , "method" : "notifications/tools/list_changed" , "params" : { "_meta" : { "io.modelcontextprotocol/subscriptionId" : 4 } } }
MCP Notification의 핵심 특성
- 응답 불필요 ：notification에는 id 필드가 없다는 점에 주목하라. 이는 JSON-RPC 2.0 notification 의미론을 따르는 것으로, 응답은 기대되지도 전송되지도 않는다.
- Opt-in ：client가 subscriptions/listen에서 "toolsListChanged": true 를 요청했고, server가 tools capability에서 "listChanged": true 를 선언한 경우(단계 1 참조)에만 이 notification을 받는다.
- Subscription-ID 표시 ：stream 위의 각 notification은 _meta 안에 io.modelcontextprotocol/subscriptionId 를 담고 있으며, 그 값은 이 stream을 연 subscriptions/listen 요청의 JSON-RPC ID(이 예시에서는 4 )이다. client는 이를 근거로 notification을 해당 구독에 연결한다.
- 이벤트 기반 ：server는 내부 상태 변화에 따라 언제 notification을 보낼지 결정하며, 이를 통해 MCP 연결이 동적이고 반응적으로 유지된다.
- 최선 노력(best-effort) ：모든 notification이 전송되거나 수신된다는 보장은 없으며, 특히 transport를 넘나드는 재연결 시 그러하다. Client 역시 결과의 최신성을 보장하기 위해 폴링에 의존해야 한다.
Notification에 대한 Client의 응답
notification을 받은 후, client는 보통 갱신된 tool 목록을 요청하며, 이는 client가 사용 가능한 tool에 대한 인식을 최신으로 유지하는 새로고침 루프를 형성한다:
{ "jsonrpc" : "2.0" , "id" : 5 , "method" : "tools/list" , "params" : { "_meta" : { "io.modelcontextprotocol/protocolVersion" : "2026-07-28" , "io.modelcontextprotocol/clientInfo" : { "name" : "example-client" , "version" : "1.0.0" } , "io.modelcontextprotocol/clientCapabilities" : { "elicitation" : { } } } } }
Notification이 중요한 이유
이 notification 메커니즘은 여러 측면에서 중요하다:
- 동적 환경 ：Tool은 server 상태, 외부 의존성 또는 사용자 권한 변화에 따라 나타나거나 사라질 수 있다.
- 효율성 ：Client는 변화를 폴링할 필요 없이, 변화가 발생할 때 알림을 받는다.
- 일관성 ：client가 항상 server capability에 대한 정확한 정보를 갖도록 보장한다.
- 실시간 협업 ：AI 애플리케이션이 변화하는 context에 반응적으로 적응할 수 있게 한다.
이 notification 패턴은 tools에 국한되지 않고 모든 MCP primitive로 확장될 수 있으며, client와 server 간의 포괄적인 실시간 동기화를 구현한다.
AI 애플리케이션은 관심 있는 변화를 위해 notification stream을 하나 열어 둔다. 알림을 받으면 즉시 tool registry를 새로고침하고 LLM의 사용 가능한 capability를 갱신한다. 이는 진행 중인 대화가 항상 최신 tool 집합에 접근할 수 있게 보장하며, LLM이 새로 출시된 기능에 동적으로 적응할 수 있게 한다.