MCP 기본 프로토콜

MCP 기본 프로토콜 (Basic) — 메시지와 통신 기반

MCP(Model Context Protocol)는 함께 동작하는 몇 가지 핵심 구성 요소로 이뤄져 있어요:

기본 프로토콜(Base Protocol): 코어 JSON-RPC 메시지 타입
버전 관리와 호환성(Versioning and Compatibility): 프로토콜 버전 협상, 확장 협상, 이전 프로토콜 개정판과의 상호운용
메시지 패턴(Message Patterns): 코어 프로토콜이 지원하는 메시징 패턴 — 요청/응답, 다중 왕복 요청(MRTR), 구독·알림
인가(Authorization): HTTP 기반 전송용 인증·인가 프레임워크
서버 기능(Server Features): 서버가 노출하는 리소스, 프롬프트, 도구
클라이언트 기능(Client Features): 클라이언트가 제공하는 elicitation, sampling, 루트 디렉터리 목록
유틸리티(Utilities): 로깅과 인자 완성 같은 횡단 관심사

모든 구현은 기본 프로토콜, 버전 관리, 메시지 패턴을 반드시(MUST) 지원해야 해요. 다른 구성 요소는 애플리케이션의 특정 필요에 따라 구현할 수 있습니다(MAY).

이 프로토콜 계층들은 관심사의 명확한 분리를 확립하면서도 클라이언트와 서버 사이의 풍부한 상호작용을 가능하게 해요. 모듈식 설계 덕분에 구현은 정확히 필요한 기능만 지원할 수 있습니다.

출처: MCP 공식 문서 — Basic

메시지 (Messages)

MCP 클라이언트와 서버 사이의 모든 메시지는 JSON-RPC 2.0 명세를 따라야 합니다(MUST). 프로토콜은 다음 유형의 메시지를 정의합니다.

요청 (Requests)

요청(Requests)은 작업을 시작하기 위해 클라이언트에서 서버로 보내집니다.

{
  jsonrpc: "2.0";
  id: string | number;
  method: string;
  params?: {
    [key: string]: unknown;
  };
}

요청에는 문자열 또는 정수 ID가 포함되어야 합니다(MUST).
기본 JSON-RPC와 달리 ID는 null이면 안 됩니다(MUST NOT).
요청 ID는 발신자가 발행했지만 아직 응답을 받지 못한 다른 어떤 요청의 ID와도 일치하면 안 됩니다(MUST NOT).

응답 (Responses)

응답은 요청에 대한 답으로 보내지며, 작업의 결과나 오류를 담습니다.

결과 응답 (Result Responses)

결과 응답(Result responses)은 작업이 성공적으로 완료됐을 때 보내집니다.

{
  jsonrpc: "2.0";
  id: string | number;
  result: {
    resultType: string;
    [key: string]: unknown;
  };
}

결과 응답에는 대응하는 요청과 같은 ID가 포함되어야 합니다(MUST).
결과 응답에는 result 필드가 포함되어야 합니다(MUST).
result는 어떤 JSON 객체 구조라도 따를 수 있어요(MAY).
result는 결과의 타입을 나타내는 resultType 필드를 포함해야 합니다(MUST).

ResultType

결과의 resultType 필드는 반환되는 결과의 타입을 나타냅니다. MCP는 다형적 결과 타입(polymorphic result types)을 지원해서, 서버가 요청의 결과에 따라 다른 구조를 반환하게 해줘요. resultType 필드는 클라이언트가 result 객체를 어떻게 해석하고 처리할지 결정하는 데 사용하는 문자열입니다.

resultType이 "complete"이면 요청이 성공적으로 완료되었고 결과에 최종 콘텐츠가 담겨 있음을 나타냅니다.
resultType이 "input_required"이면 요청이 불완전하고 처리에 더 많은 정보가 필요함을 나타냅니다. 결과에는 필요한 추가 정보가 담긴 InputRequiredResult 객체가 포함돼요.
확장은 추가 ResultType 값을 추가할 수 있어요(MAY). 지원되는 ResultType 값의 집합은 코어 프로토콜에 정의된 집합에서 만들어져야 하며(MUST), 역량(capabilities)을 통해 광고되는 지원 확장의 추가 값을 포함해야 합니다(MUST).
클라이언트가 인식하지 못하는 어떤 값의 resultType도 유효하지 않은 것으로 간주되어야 합니다(MUST).
resultType을 포함하지 않는 이전 프로토콜 버전을 구현하는 서버와의 하위 호환을 위해, 클라이언트는 resultType이 없으면 "complete"로 처리해야 합니다(MUST).

오류 응답 (Error Responses)

오류 응답(Error responses)은 작업이 실패하거나 오류를 만났을 때 보내집니다.

{
  jsonrpc: "2.0";
  id?: string | number;
  error: {
    code: number;
    message: string;
    data?: unknown;
  }
}

오류 응답에는 대응하는 요청과 같은 ID가 포함되어야 합니다(MUST)(잘못된 요청 때문에 ID를 읽을 수 없는 오류 케이스 제외).
오류 응답에는 code와 message가 담긴 error 필드가 포함되어야 합니다(MUST).
오류 코드는 정수여야 합니다(MUST).
오류 응답은 중첩 오류 같은 모든 타입의 추가 정보를 담은 data 멤버를 포함할 수 있어요(MAY).

오류 코드 (Error Codes)

MCP는 일반 프로토콜 실패에 표준 JSON-RPC 2.0 오류 코드(-32700, -32600 ~ -32603)를 사용합니다.

JSON-RPC 2.0은 구현 정의 서버 오류를 위해 -32000 ~ -32099 범위를 예약합니다. MCP는 이 범위를 다음과 같이 나눠요:

-32000 ~ -32019 — 레거시. 이 하위 범위의 코드는 이 정책이 도입되기 전에 구현들이 할당했어요. 이 하위 범위에는 새 코드를 할당하면 안 되고(MUST NOT), 새 구현은 이 하위 범위의 코드를 전혀 쓰지 말아야 합니다(SHOULD NOT). -32002(아래 참조)를 제외하고 수신자는 이 코드들에 특정 의미를 가정하면 안 됩니다(MUST NOT).
-32020 ~ -32099 — MCP 명세 예약. 이 하위 범위의 오류 코드는 MCP 명세만이 정의하며 스키마에 기록됩니다. 구현은 이 명세가 정의하지 않은 이 하위 범위의 어떤 코드도 내보내면 안 되고(MUST NOT), 정의된 코드는 지정된 의미로만 사용해야 합니다(MUST).

MCP는 다음 오류 코드를 정의합니다:

코드	이름
`-32020`	`HeaderMismatch`
`-32021`	`MissingRequiredClientCapability`
`-32022`	`UnsupportedProtocolVersion`

이전 프로토콜 버전이 정의한 코드는 예약된 채로 유지되며 재사용되지 않습니다. 이 프로토콜 버전의 구현은 이 코드들을 내보내면 안 됩니다(MUST NOT):

-32002 — 리소스 없음(2025-11-25 및 이전; -32602로 대체). 클라이언트는 이전 버전을 구현하는 서버로부터 -32002를 여전히 수락해야 합니다(SHOULD).
-32042 — URL elicitation 필요(2025-11-25만).

구현에 국한된(예: SDK 안에서 발생한 요청 타임아웃) 순수 로컬 오류는 이 명세가 아직 코드를 할당하지 않아요. JSON-RPC 형태 구조에 로컬 오류를 실어 보내는 구현은 그것이 상대방에게서 받은 오류로 오인되지 않게 해야 합니다. 미래 명세 버전은 예약된 하위 범위에서 일반적인 로컬 오류 조건에 표준 코드를 정의할 수 있어요.

이 명세가 정의하지 않은 목적의 새 오류 코드는 JSON-RPC 예약 범위(-32768 ~ -32000) 밖에서 할당해야 합니다(SHOULD). 정수 공간의 나머지는 애플리케이션 정의 오류에 쓸 수 있어요.

알림 (Notifications)

알림(Notifications)은 클라이언트에서 서버로, 또는 서버에서 클라이언트로 일방향 메시지로 보내집니다. 수신자는 응답을 보내면 안 됩니다(MUST NOT).

{
  jsonrpc: "2.0";
  method: string;
  params?: {
    [key: string]: unknown;
  };
}

알림에는 ID가 포함되어서는 안 됩니다(MUST NOT).

메시지 패턴 (Message Patterns)

MCP는 클라이언트와 서버가 어떻게 상호작용하는지를 정의하는 여러 메시지 패턴을 지원합니다:

요청과 응답(Request and Response): 클라이언트가 서버에 요청을 보내고, 서버가 결과나 오류로 응답한다.
다중 왕복 요청(MRTR): 서버가 요청을 완료하려면 추가 클라이언트 입력(sampling, elicitation, roots)이 필요하다.
구독·알림(Subscribe and Notify): 클라이언트가 서버의 알림 스트림을 구독하고, 알림은 발생 시점에 전송된다.

무상태성 (Statelessness)

MCP는 무상태 프로토콜입니다. 요청을 처리하는 데 필요한 모든 정보가 요청 자체에 담겨 있어요. 서버는 각 요청을 독립적으로 처리하며, 같은 연결이나 스트림의 이전 요청에서도 상태를 추론하면 안 됩니다.

구체적으로:

서버는 같은 연결을 통한 이전 요청에 의존해 문맥을 세우면 안 됩니다(MUST NOT)(예: 역량, 프로토콜 버전, 클라이언트 정체성). 모든 요청이 이 메타데이터를 _meta 필드에 공급해요.
서버는 여러 작업, 스레드, 대화와 연결된 요청을 처리할 준비가 되어 있어야 합니다(SHOULD).
서버는 클라이언트가 관련 작업을 수행하기 위해 같은 연결이나 프로세스를 재사용하도록 요구해서는 안 됩니다(SHOULD NOT).
클라이언트는 개별 작업, 스레드, 대화를 stdio 프로세스의 수명 경계로 사용해서는 안 됩니다(SHOULD NOT).
여러 요청에 걸쳐 유지해야 하는 상태(예: 장기 실행 작업, 애플리케이션 수준 핸들)는 클라이언트가 각 요청에 전달하는 명시적 식별자로 참조되어야 합니다(MUST).

참고: 이는 STDIO 프로세스 같은 열린 연결이 대화나 세션이 아니라는 뜻입니다. 클라이언트는 같은 전송에서 무관한 요청을 섞어 보낼 수 있고, 서버는 연결이나 프로세스 정체성을 대화·세션 연속성의 대용으로 취급하면 안 됩니다.

subscriptions/listen 같은 장수명 요청도 여전히 요청/응답이며, 응답은 그저 열린 알림 스트림일 뿐이에요. 그 상태는 밑의 연결이 아니라 요청 자체에 한정됩니다.

참고: 요청별 모델이 SDK 코드에 어떻게 매핑되는지에 대한 워크스루는 Architecture guide를 참고하세요.

인가 (Auth)

MCP는 HTTP와 함께 사용하는 Authorization 프레임워크를 제공합니다. HTTP 기반 전송을 쓰는 구현은 이 명세를 따라야 하며(SHOULD), STDIO 전송을 쓰는 구현은 이 명세를 따르지 말고(SHOULD NOT) 대신 환경에서 자격 증명을 가져와야 합니다.

또한 클라이언트와 서버는 자체 커스텀 인증·인가 전략을 협상할 수 있어요(MAY).

MCP 인증 메커니즘 발전에 대한 논의와 기여는 GitHub Discussions에서 함께해 주세요.

스키마 (Schema)

프로토콜의 전체 명세는 TypeScript 스키마로 정의됩니다. 이것이 모든 프로토콜 메시지와 구조의 진실 원천입니다.

또한 TypeScript 진실 원천에서 자동 생성되는 JSON Schema도 있고, 다양한 자동화 도구와 함께 쓰입니다.

JSON Schema 사용 (JSON Schema Usage)

MCP는 프로토콜 전반에서 검증에 JSON Schema를 사용합니다. 이 절은 MCP 메시지 안에서 JSON Schema를 어떻게 사용해야 하는지 명확히 해줘요.

스키마 방언 (Schema Dialect)

MCP는 다음 규칙으로 JSON Schema를 지원합니다:

기본 방언: 스키마가 $schema 필드를 포함하지 않으면 JSON Schema 2020-12로 기본 설정됩니다.
명시적 방언: 스키마는 다른 방언을 지정하기 위해 $schema 필드를 포함할 수 있어요(MAY).
지원 방언: 구현은 적어도 2020-12를 지원해야 하며(MUST), 추가로 지원하는 방언을 문서화해야 합니다(SHOULD).
권장: 구현자는 JSON Schema 2020-12 사용이 권장(RECOMMENDED) 됩니다.

예시 사용 (Example Usage)

기본 방언 (2020-12):

{
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "age": { "type": "integer", "minimum": 0 }
  },
  "required": ["name"]
}

명시적 방언 (draft-07):

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "age": { "type": "integer", "minimum": 0 }
  },
  "required": ["name"]
}

구현 요건 (Implementation Requirements)

클라이언트와 서버는 명시적 $schema 필드가 없는 스키마에 대해 JSON Schema 2020-12를 지원해야 합니다(MUST).
클라이언트와 서버는 선언되거나 기본이 되는 방언에 따라 스키마를 검증해야 합니다(MUST). 지원되지 않는 방언은 방언이 지원되지 않음을 나타내는 적절한 오류를 돌려주어 우아하게 처리해야 합니다(MUST).
클라이언트와 서버는 지원하는 스키마 방언을 문서화해야 합니다(SHOULD).

스키마 검증 (Schema Validation)

스키마는 선언되거나 기본이 되는 방언에 따라 유효해야 합니다(MUST).

`$ref` 해석 (`$ref` Resolution)

JSON Schema 2020-12는 $ref가 절대 URI를 가리키는 것을 허용합니다. 구현은 네트워크 URI로 해석되는 $ref 값을 자동으로 역참조하면 안 됩니다(MUST NOT).

구현은 비로컬 $ref를 가져오는 옵트인 모드를 제공할 수 있지만(MAY), 기본적으로 비활성화되어야 하며(MUST), 호스트 허용 목록을 강제하거나 최소한 루프백·링크로컬·사설 네트워크 주소를 거부하고, 타임아웃과 크기 제한을 적용하며, 역참조된 URI를 로깅해야 합니다(SHOULD).

해석되지 않은 외부 $ref 때문에 검증에 실패하는 스키마는 관대하게 취급하기보다 거부되어야 합니다(SHOULD).

구성 키워드 자원 사용 (Composition-Keyword Resource Use)

구성 키워드(anyOf, oneOf, allOf, if/then/else)와 $defs는 표현력 있는 스키마를 가능하게 하지만 검증 비용이 클 수 있어요. 구현은 최대 스키마 깊이, 하위 스키마 총수 상한, 검증별 시간 예산 같은 합리적인 한계를 적용하여(SHOULD), 악의적인 스키마가 검증기에 대한 DoS(서비스 거부) 벡터가 되지 않게 해야 합니다.

일반 필드 (General fields)

`_meta`

_meta 속성/파라미터는 클라이언트와 서버가 상호작용에 추가 메타데이터를 붙일 수 있게 MCP가 사용합니다.

일부 키 이름은 아래에 명시된 대로 프로토콜 수준 메타데이터를 위해 MCP가 예약합니다. 구현은 이 키들의 값에 대해 가정하면 안 됩니다(MUST NOT).

키 이름 형식: 유효한 _meta 키 이름은 두 세그먼트 — 선택적 접두사(prefix) 와 이름(name) — 로 이뤄집니다.

접두사 (Prefix):

지정되면 점(.)으로 구분된 레이블들 뒤에 슬래시(/)가 오는 형태여야 합니다(MUST).
- 레이블은 문자로 시작해 문자 또는 숫자로 끝나야 하며(MUST), 중간 문자는 문자, 숫자, 하이픈(-)일 수 있어요.
- 구현은 역 DNS 표기(예: example.com/ 대신 com.example/)를 사용해야 합니다(SHOULD).
두 번째 레이블이 modelcontextprotocol 또는 mcp인 어떤 접두사도 MCP 사용을 위해 예약됩니다.
- 예: io.modelcontextprotocol/, dev.mcp/, org.modelcontextprotocol.api/, com.mcp.tools/는 모두 예약입니다.
- 그러나 com.example.mcp/는 두 번째 레이블이 example이므로 예약이 아닙니다.

이름 (Name):

비어 있지 않으면 영숫자 문자([a-z0-9A-Z])로 시작하고 끝나야 합니다(MUST).
사이에 하이픈(-), 밑줄(_), 점(.), 영숫자를 포함할 수 있어요(MAY).

예약 키 (Reserved keys):

다음 _meta 키는 이 명세가 예약합니다:

키	설명	정의처
`progressToken`	요청을 진행률 알림에 옵트인	Progress
`io.modelcontextprotocol/protocolVersion`	요청의 프로토콜 버전	요청별 프로토콜 필드(아래)
`io.modelcontextprotocol/clientInfo`	클라이언트 이름과 버전	요청별 프로토콜 필드(아래)
`io.modelcontextprotocol/clientCapabilities`	요청과 관련된 클라이언트 역량	요청별 프로토콜 필드(아래)
`io.modelcontextprotocol/logLevel`	서버가 요청에 대해 방출해야 할 최소 로그 수준	Logging
`io.modelcontextprotocol/subscriptionId`	알림을 발원 구독과 대응	Subscriptions
`traceparent`, `tracestate`, `baggage`	OpenTelemetry 트레이스 컨텍스트 전파	OpenTelemetry 트레이스 컨텍스트(아래)

공식 확장은 io.modelcontextprotocol/ 접두사 아래 추가 _meta 키를 정의하고, 서드파티 확장은 자체 공급업체 접두사를 사용해요. 두 경우 모두 키는 해당 확장의 문서에 명시됩니다.

요청별 프로토콜 필드 (Per-request protocol fields):

클라이언트 요청은 _meta에 다음 io.modelcontextprotocol/* 필드를 실어 나릅니다. 필수로 표시된 필드는 모든 요청에 포함되어야 합니다(MUST). 서버는 이들을 사용해 이전 연결 상태에 의존하지 않고 사용 중인 프로토콜 버전과 역량을 식별합니다. 버전 협상 규칙은 Versioning and Compatibility를 참고하세요.

키	타입	필수	설명
`io.modelcontextprotocol/protocolVersion`	`string`	예	이 요청의 프로토콜 버전(예: `"2026-07-28"`)
`io.modelcontextprotocol/clientInfo`	`Implementation`	아니오	클라이언트 이름과 버전
`io.modelcontextprotocol/clientCapabilities`	`ClientCapabilities`	예	이 요청과 관련된 클라이언트 역량
`io.modelcontextprotocol/logLevel`	`LoggingLevel`	아니오	서버가 이 요청에 대해 방출해야 할 최소 로그 수준

필수 필드가 없는 요청은 잘못된 형식이며, 서버는 JSON-RPC 오류 코드 -32602(Invalid params)로 거부해야 합니다(MUST). HTTP에서는 응답 상태가 400 Bad Request여야 합니다(MUST).

클라이언트는 특별히 그렇게 하지 않도록 설정하지 않는 한 모든 요청에 io.modelcontextprotocol/clientInfo를 포함해야 합니다(SHOULD).

서버는 클라이언트가 선언하지 않은 역량에 의존하면 안 됩니다(MUST NOT). 요청 처리에 클라이언트가 io.modelcontextprotocol/clientCapabilities에 포함하지 않은 역량이 필요하면, 서버는 누락된 역량을 data.requiredCapabilities에 나열한 MissingRequiredClientCapabilityError(-32021)를 반환해야 합니다(MUST). HTTP에서는 응답 상태가 400 Bad Request여야 합니다(MUST).

응답별 프로토콜 필드 (Per-response protocol fields):

서버는 특별히 그렇게 하지 않도록 설정하지 않는 한, 이전 연결 상태에 의존하지 않고 자신을 식별하기 위해 모든 결과의 _meta에 다음 io.modelcontextprotocol/* 필드를 포함해야 합니다(SHOULD):

키	타입	필수	설명
`io.modelcontextprotocol/serverInfo`	`Implementation`	아니오	서버 이름과 버전

참고: io.modelcontextprotocol/clientInfo와 io.modelcontextprotocol/serverInfo는 발신자가 자체 보고하며 프로토콜이 검증하지 않아요. 표시, 로깅, 디버깅을 위한 것입니다. 구현은 이를 사용해 클라이언트·서버 동작을 바꾸면 안 되고(SHOULD NOT), 보안 결정에 의존하면 안 됩니다(SHOULD NOT).

subscriptions/listen 스트림으로 전달되는 알림에서 서버는 클라이언트가 알림을 발원 구독 요청과 대응할 수 있도록 _meta에 io.modelcontextprotocol/subscriptionId를 포함해야 합니다(MUST).

OpenTelemetry 트레이스 컨텍스트:

위 접두사 요건의 예외로, traceparent, tracestate, baggage 키는 OpenTelemetry 트레이스 컨텍스트 전파를 위해 예약됩니다. 있을 때 그 값은 각각 W3C Trace Context와 W3C Baggage 형식을 따라야 합니다(MUST).

이 예외는 기존 구현과 MCP에 대한 OpenTelemetry 시맨틱 컨벤션과의 호환성을 유지하기 위한 것입니다.

_meta의 트레이스 컨텍스트 비정규 예시:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "location": "New York"
    },
    "_meta": {
      "traceparent": "00-0af7651916cd43dd8448eb211c80319c-00f067aa0ba902b7-01"
    }
  }
}

`icons`

icons 속성은 서버가 리소스, 도구, 프롬프트, 구현에 대한 시각적 식별자를 노출하는 표준화된 방법을 제공합니다. 아이콘은 시각적 문맥을 제공하고 사용 가능한 기능의 발견성을 높여 UI를 개선해요.

아이콘은 Icon 객체 배열로 표현되며, 각 아이콘은 다음을 포함합니다:

src: 아이콘 리소스를 가리키는 URI(필수). 이는:
- 이미지 파일을 가리키는 HTTP/HTTPS URL
- base64 인코딩된 이미지 데이터를 담은 data URI
mimeType: 서버 타입이 없거나 일반적이면 선택적 MIME 타입
sizes: 선택적 크기 지정 배열(예: ["48x48"], 확장 가능한 형식인 SVG용 ["any"], 여러 크기용 ["48x48", "96x96"])
theme: 아이콘 배경의 선택적 테마 선호(light 또는 dark)

필수 MIME 타입 지원:

아이콘 렌더링을 지원하는 클라이언트는 적어도 다음 MIME 타입을 지원해야 합니다(MUST):

image/png - PNG 이미지(안전, 보편적 호환)
image/jpeg(및 image/jpg) - JPEG 이미지(안전, 보편적 호환)

아이콘 렌더링을 지원하는 클라이언트는 다음도 지원해야 합니다(SHOULD):

image/svg+xml - SVG 이미지(확장 가능하지만 아래에 언급된 보안 주의 필요)
image/webp - WebP 이미지(현대적, 효율적 형식)

보안 고려:

아이콘 메타데이터 소비자는 손상을 막기 위해 아이콘 처리 시 적절한 보안 주의를 취해야 합니다(MUST):

아이콘 메타데이터와 아이콘 바이트를 신뢰할 수 없는 입력으로 취급하고 네트워크, 프라이버시, 파싱 위험에 대비한다.
아이콘 URI가 HTTPS 또는 data: URI인지 확인한다. 클라이언트는 javascript:, file:, ftp:, ws:, 로컬 앱 URI 스킴 같은 안전하지 않은 스킴과 리다이렉트를 사용하는 아이콘 URI를 거부해야 합니다(MUST).
- 스킴 변경과 다른 오리진의 호스트로의 리다이렉트를 금지한다.
과도하게 큰 이미지, 큰 크기, 과도한 프레임(예: GIF에서)으로 인한 리소스 고갈 공격에 탄력적으로 대비한다.
- 소비자는 이미지·콘텐츠 크기 제한을 설정할 수 있어요(MAY).
자격 증명 없이 아이콘을 가져온다. 쿠키, Authorization 헤더, 클라이언트 자격 증명을 보내지 않는다.
아이콘 URI가 서버와 같은 오리진인지 확인한다. 이렇게 하면 데이터 노출이나 추적 정보가 서드파티로 새는 위험을 최소화한다.
아이콘 페이로드가 실행 가능한 콘텐츠(예: 임베디드 JavaScript나 확장된 기능을 가진 SVG)를 포함할 수 있으므로 가져오고 렌더링할 때 주의한다.
- 소비자는 특정 파일 타입을 금지하거나 렌더링 전에 아이콘 파일을 살균하기로 선택할 수 있어요(MAY).
렌더링 전에 MIME 타입과 파일 콘텐츠를 검증한다. MIME 타입 정보를 참고 사항으로 취급한다. 매직 바이트로 콘텐츠 타입을 감지하고, 불일치나 알 수 없는 타입은 거부한다.
- 엄격한 이미지 타입 허용 목록을 유지한다.

사용 (Usage):

아이콘은 다음에 붙일 수 있습니다:

Implementation: MCP 서버/클라이언트 구현의 시각적 식별자
Tool: 도구 기능의 시각적 표현
Prompt: 프롬프트 템플릿 옆에 표시할 아이콘
Resource: 다른 리소스 타입에 대한 시각적 표시

여러 아이콘을 제공해 서로 다른 표시 문맥과 해상도를 지원할 수 있어요. 클라이언트는 UI 요건에 가장 적절한 아이콘을 선택해야 합니다.

더 알아보기 (Learn more)

전송 계층 개요 — 메시지를 실어 나르는 전송
메시지 패턴 — 요청/응답, MRTR, 구독·알림
취소 패턴 — 진행 중 요청 취소
진행률 패턴 — 장기 작업 진행 보고
MRTR 패턴 — 서버→클라이언트 입력 왕복
구독·알림 패턴 — 변경 알림 스트림

MCP 기본 프로토콜