좋습니다! 이 영상과 설명에는 **MCP(Model Context Protocol)**의 기본 개념과 아키텍처가 담겨 있습니다. 초심자도 이해할 수 있도록 아래에 핵심 개념들을 하나씩 자세히 풀어 설명드릴게요.

---

🧠 1. MCP란?

**Model Context Protocol (MCP)**은 대형 언어 모델(LLM)이 외부의 데이터나 도구와 상호작용할 수 있도록 도와주는 **공식적인 통신 규약(protocol)**입니다.

🎯 목표는?

• 다양한 **LLM 애플리케이션(AI 앱)**이 외부 리소스를 쉽게 활용하도록 표준화된 방식을 제공
• USB-C처럼 “어떤 도구든 호환되게 하는 통로”가 되는 게 목적이에요.

---

🧩 2. MCP 아키텍처 구성요소

MCP의 핵심 구성은 크게 세 가지로 나눌 수 있어요.

(1) MCP Host (왼쪽)

• MCP를 사용하는 AI 애플리케이션입니다.

• 예시:

  • Claude Desktop
  • Cursor IDE
  • Windsurf
  • 또는 여러분이 만든 AI 앱

• 이 Host는 MCP를 통해 새로운 기능(툴, 데이터, 프롬프트 등)을 “연결” 받을 수 있어요.

(2) MCP Server (오른쪽)

• 외부 기능/리소스를 실제로 제공하는 서버입니다.

• 예시:

  • 날씨 조회 서버
  • 음식 주문 서버 (Uber Eats와 연동)
  • 특정 데이터베이스 검색
  • 사전 정의된 프롬프트 목록 제공 등

서버는 MCP Host에 도구를 제공하는 역할.
즉, “AI 앱이 사용할 수 있는 도구를 노출하는 API 서버” 라고 생각하면 됩니다.

(3) MCP Client (중간의 다리 역할)

• MCP Host 안에 내장되어 있는 클라이언트 컴포넌트
• 이 Client가 MCP Server와 통신하며, 양쪽을 연결해줍니다.
• 중요한 규칙: MCP Client 하나는 하나의 MCP Server만 연결할 수 있음 (1:1 연결)

---

🛠 3. MCP의 "Context" 개념

MCP는 LLM에게 줄 수 있는 “맥락(Context)” 을 다음과 같이 정의합니다:

• 추가 정보 (e.g., 현재 사용자 위치)
• 어떤 툴을 쓸지 결정
• 심지어 프롬프트 자체도 Context일 수 있어요

즉, MCP는 단순한 툴 호출 뿐 아니라 다양한 맥락을 LLM에게 전달하는데 사용됩니다.

---

🕹 4. 실제 사용 예시

🍩 음식 주문 예시

1. 사용자가 Cursor에 “I want Fika. Where can I get kane?” 라고 말함.
2. MCP Host (Cursor)가 MCP Client를 통해
3. MCP Server (Uber Eats 연동 서버)에 연결 → 메뉴 검색
4. AI가 음식 정보를 보고 “주문할까요?”라고 제안
5. 사용자가 OK 하면 OrderFood 툴 실행 → 실제로 주문함

👉 이 모든 흐름이 MCP 프로토콜에 의해 통신됨.

---

🔌 5. MCP의 장점 요약

1. Plug & Play

   • 한 번 MCP 서버를 만들면, 여러 AI 앱(Claude, Cursor 등)에 연결할 수 있음
   • USB-C처럼 다양한 곳에 꽂기만 하면 됨

2. LLM 벤더 독립성

   • 특정 LLM(OpenAI, Anthropic 등)에 종속되지 않음
   • 한 번 만든 툴이나 서버를 다양한 플랫폼에서 재사용 가능

3. 확장성

   • 데이터(PDF, API, DB) + 툴(날씨, 음식주문, 검색 등) + 프롬프트까지 확장 가능

---

📦 6. MCP 서버가 해야 할 일들

MCP 서버는 다음과 같은 기능들을 구현해야 MCP Host가 사용할 수 있어요.

기능 이름	설명
list_prompts	사용 가능한 프롬프트 목록 제공
call_tool	특정 툴 실행 (예: get_weather, order_food)
list_tools	제공 가능한 툴 목록 제공
list_resource_templates	사용할 수 있는 리소스 템플릿 제공
progress_notification	툴 실행 상태 중간 보고

---

💡 마무리 요약

• MCP는 AI와 외부 도구·데이터를 USB-C처럼 쉽게 연결해주는 표준 프로토콜입니다.
• Host (AI 앱) + Client (중계자) + Server (외부 리소스 제공) 세 가지로 구성되어 있고,
• 하나의 MCP Server를 만들면 여러 Host에 쉽게 연결할 수 있어 확장성과 재사용성이 매우 뛰어납니다.

---

이해에 도움이 되는 다이어그램이 필요하신가요? 원하시면 시각적으로 MCP 구조를 그려드릴게요.

Core architecture

Understand how MCP connects clients, servers, and LLMs

The Model Context Protocol (MCP) is built on a flexible, extensible architecture that enables seamless communication between LLM applications and integrations. This document covers the core architectural components and concepts.

Overview

MCP follows a client-server architecture where:

• Hosts are LLM applications (like Claude Desktop or IDEs) that initiate connections
• Clients maintain 1:1 connections with servers, inside the host application
• Servers provide context, tools, and prompts to clients

flowchart LR
    subgraph "Host"
        client1[MCP Client]
        client2[MCP Client]
    end
    subgraph "Server Process"
        server1[MCP Server]
    end
    subgraph "Server Process"
        server2[MCP Server]
    end

    client1 <-->|Transport Layer| server1
    client2 <-->|Transport Layer| server2

Core components

Protocol layer

The protocol layer handles message framing, request/response linking, and high-level communication patterns.

```typescript class Protocol { // Handle incoming requests setRequestHandler(schema: T, handler: (request: T, extra: RequestHandlerExtra) => Promise): void

    // Handle incoming notifications
    setNotificationHandler<T>(schema: T, handler: (notification: T) => Promise<void>): void

    // Send requests and await responses
    request<T>(request: Request, schema: T, options?: RequestOptions): Promise<T>

    // Send one-way notifications
    notification(notification: Notification): Promise<void>
}
```

```python class Session(BaseSession[RequestT, NotificationT, ResultT]): async def send_request( self, request: RequestT, result_type: type[Result] ) -> Result: """Send request and wait for response. Raises McpError if response contains error.""" # Request handling implementation

    async def send_notification(
        self,
        notification: NotificationT
    ) -> None:
        """Send one-way notification that doesn't expect response."""
        # Notification handling implementation

    async def _received_request(
        self,
        responder: RequestResponder[ReceiveRequestT, ResultT]
    ) -> None:
        """Handle incoming request from other side."""
        # Request handling implementation

    async def _received_notification(
        self,
        notification: ReceiveNotificationT
    ) -> None:
        """Handle incoming notification from other side."""
        # Notification handling implementation
```

Key classes include:

• Protocol
• Client
• Server

Transport layer

The transport layer handles the actual communication between clients and servers. MCP supports multiple transport mechanisms:

1. Stdio transport

   • Uses standard input/output for communication
   • Ideal for local processes

2. HTTP with SSE transport

   • Uses Server-Sent Events for server-to-client messages
   • HTTP POST for client-to-server messages

All transports use JSON-RPC 2.0 to exchange messages. See the specification for detailed information about the Model Context Protocol message format.

Message types

MCP has these main types of messages:

1. Requests expect a response from the other side:

   interface Request {
     method: string;
     params?: { ... };
   }

2. Results are successful responses to requests:

   interface Result {
     [key: string]: unknown;
   }

3. Errors indicate that a request failed:

   interface Error {
     code: number;
     message: string;
     data?: unknown;
   }

4. Notifications are one-way messages that don't expect a response:

   interface Notification {
     method: string;
     params?: { ... };
   }

Connection lifecycle

1. Initialization

sequenceDiagram
    participant Client
    participant Server

    Client->>Server: initialize request
    Server->>Client: initialize response
    Client->>Server: initialized notification

    Note over Client,Server: Connection ready for use

1. Client sends initialize request with protocol version and capabilities
2. Server responds with its protocol version and capabilities
3. Client sends initialized notification as acknowledgment
4. Normal message exchange begins

2. Message exchange

After initialization, the following patterns are supported:

• Request-Response: Client or server sends requests, the other responds
• Notifications: Either party sends one-way messages

3. Termination

Either party can terminate the connection:

• Clean shutdown via close()
• Transport disconnection
• Error conditions

Error handling

MCP defines these standard error codes:

enum ErrorCode {
  // Standard JSON-RPC error codes
  ParseError = -32700,
  InvalidRequest = -32600,
  MethodNotFound = -32601,
  InvalidParams = -32602,
  InternalError = -32603
}

SDKs and applications can define their own error codes above -32000.

Errors are propagated through:

• Error responses to requests
• Error events on transports
• Protocol-level error handlers

Implementation example

Here's a basic example of implementing an MCP server:

```typescript import { Server } from "@modelcontextprotocol/sdk/server/index.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new Server({
  name: "example-server",
  version: "1.0.0"
}, {
  capabilities: {
    resources: {}
  }
});

// Handle requests
server.setRequestHandler(ListResourcesRequestSchema, async () => {
  return {
    resources: [
      {
        uri: "example://resource",
        name: "Example Resource"
      }
    ]
  };
});

// Connect transport
const transport = new StdioServerTransport();
await server.connect(transport);
```

```python import asyncio import mcp.types as types from mcp.server import Server from mcp.server.stdio import stdio_server

app = Server("example-server")

@app.list_resources()
async def list_resources() -> list[types.Resource]:
    return [
        types.Resource(
            uri="example://resource",
            name="Example Resource"
        )
    ]

async def main():
    async with stdio_server() as streams:
        await app.run(
            streams[0],
            streams[1],
            app.create_initialization_options()
        )

if __name__ == "__main__":
    asyncio.run(main())
```

Best practices

Transport selection

1. Local communication

   • Use stdio transport for local processes
   • Efficient for same-machine communication
   • Simple process management

2. Remote communication

   • Use SSE for scenarios requiring HTTP compatibility
   • Consider security implications including authentication and authorization

Message handling

1. Request processing

   • Validate inputs thoroughly
   • Use type-safe schemas
   • Handle errors gracefully
   • Implement timeouts

2. Progress reporting

   • Use progress tokens for long operations
   • Report progress incrementally
   • Include total progress when known

3. Error management

   • Use appropriate error codes
   • Include helpful error messages
   • Clean up resources on errors

Security considerations

1. Transport security

   • Use TLS for remote connections
   • Validate connection origins
   • Implement authentication when needed

2. Message validation

   • Validate all incoming messages
   • Sanitize inputs
   • Check message size limits
   • Verify JSON-RPC format

3. Resource protection

   • Implement access controls
   • Validate resource paths
   • Monitor resource usage
   • Rate limit requests

4. Error handling

   • Don't leak sensitive information
   • Log security-relevant errors
   • Implement proper cleanup
   • Handle DoS scenarios

Debugging and monitoring

1. Logging

   • Log protocol events
   • Track message flow
   • Monitor performance
   • Record errors

2. Diagnostics

   • Implement health checks
   • Monitor connection state
   • Track resource usage
   • Profile performance

3. Testing

   • Test different transports
   • Verify error handling
   • Check edge cases
   • Load test servers