The Model Context Protocol (MCP) is a powerful, standardized framework that optimizes communication between Large Language Models (LLMs) and external tools, applications, and data sources.
This guide will walk you through the core concepts of MCP. You will learn about its client-server architecture, essential components, communication mechanics, and implementation best practices.
This lesson explores the fundamental architecture and components that make up the Model Context Protocol (MCP) ecosystem. You'll learn about the client-server architecture, key components, and communication mechanisms that power MCP interactions.
By the end of this lesson, you will:
The MCP ecosystem is built on a client-server model. This modular structure allows AI applications to interact with tools, databases, APIs, and contextual resources efficiently. Let's break down this architecture into its core components.
At its core, MCP follows a client-server architecture where a host application can connect to multiple servers:
flowchart LR
subgraph "Your Computer"
Host["Host with MCP (Visual Studio, VS Code, IDEs, Tools)"]
S1["MCP Server A"]
S2["MCP Server B"]
S3["MCP Server C"]
Host <-->|"MCP Protocol"| S1
Host <-->|"MCP Protocol"| S2
Host <-->|"MCP Protocol"| S3
S1 <--> D1[("Local\Data Source A")]
S2 <--> D2[("Local\Data Source B")]
end
subgraph "Internet"
S3 <-->|"Web APIs"| D3[("Remote\Services")]
end
The MCP Protocol is an evolving standard using date-based versioning (YYYY-MM-DD format).
The current protocol version is 2025-11-25.
You can see the latest updates to the protocol specification
In the Model Context Protocol (MCP), Hosts are AI applications that serve as the primary interface through which users interact with the protocol.
Hosts coordinate and manage connections to multiple MCP servers by creating dedicated MCP clients for each server connection.
Examples of Hosts include:
Hosts are applications that coordinate AI model interactions. They:
Clients are essential components that maintain dedicated one-to-one connections between Hosts and MCP servers.
Each MCP client is instantiated by the Host to connect to a specific MCP server, ensuring organized and secure communication channels.
Multiple clients enable Hosts to connect to multiple servers simultaneously.
Clients are connector components within the host application. They:
Servers are programs that provide context, tools, and capabilities to MCP clients.
They can execute locally (same machine as the Host) or remotely (on external platforms), and are responsible for handling client requests and providing structured responses.
Servers expose specific functionality through the standardized Model Context Protocol.
Servers are services that provide context and capabilities. They:
Servers can be developed by anyone to extend model capabilities with specialized functionality, and they support both local and remote deployment scenarios.
Servers in the Model Context Protocol (MCP) provide three core primitives that define the fundamental building blocks for rich interactions between clients, hosts, and language models.
These primitives specify the types of contextual information and actions available through the protocol.
MCP servers can expose any combination of the following three core primitives:
Resources are data sources that provide contextual information to AI applications. They represent static or dynamic content that can enhance model understanding and decision-making:
Resources are identified by URIs and support discovery through resources/list and retrieval through resources/read methods:
file://documents/project-spec.md
database://production/users/schema
api://weather/current
Prompts are reusable templates that help structure interactions with language models. They provide standardized interaction patterns and templated workflows:
Prompts support variable substitution and can be discovered via prompts/list and retrieved with prompts/get:
Generate a {{task_type}} for {{product}} targeting {{audience}} with the following requirements: {{requirements}}
Tools are executable functions that AI models can invoke to perform specific actions. They represent the "verbs" of the MCP ecosystem, enabling models to interact with external systems:
Tools are defined with JSON Schema for parameter validation and discovered through tools/list and executed via tools/call.
Tools can also include icons as additional metadata for better UI presentation.
Tool Annotations: Tools support behavioral annotations (e.g., readOnlyHint, destructiveHint) that describe whether a tool is read-only or destructive, helping clients make informed decisions about tool execution.
Example tool definition:
server.tool(
"search_products",
{
query: z.string().describe("Search query for products"),
category: z.string().optional().describe("Product category filter"),
max_results: z.number().default(10).describe("Maximum results to return")
},
async (params) => {
// Execute search and return structured results
return await productService.search(params);
}
);
In the Model Context Protocol (MCP), clients can expose primitives that enable servers to request additional capabilities from the host application.
These client-side primitives allow for richer, more interactive server implementations that can access AI model capabilities and user interactions.
Sampling allows servers to request language model completions from the client's AI application. This primitive enables servers to access LLM capabilities without embedding their own model dependencies:
tools and toolChoice parameters to enable the client's model to invoke tools during samplingSampling is initiated through the sampling/complete method, where servers send completion requests to clients.
Roots provide a standardized way for clients to expose filesystem boundaries to servers, helping servers understand which directories and files they have access to:
file:// URIs to identify accessible directories and filesRoots are discovered through the roots/list method, with clients sending notifications/roots/list_changed when roots change.
Elicitation enables servers to request additional information or confirmation from users through the client interface:
Elicitation requests are made using the elicitation/request method to collect user input through the client's interface.
URL Mode Elicitation: Servers can also request URL-based user interactions, allowing servers to direct users to external web pages for authentication, confirmation, or data entry.
Logging allows servers to send structured log messages to clients for debugging, monitoring, and operational visibility:
Logging messages are sent to clients to provide transparency into server operations and facilitate debugging.
The Model Context Protocol (MCP) defines a structured flow of information between hosts, clients, servers, and models.
Understanding this flow helps clarify how user requests are processed and how external tools and data are integrated into model responses.
The host application (such as an IDE or chat interface) establishes a connection to an MCP server, typically via STDIO, WebSocket, or another supported transport.
The client (embedded in the host) and the server exchange information about their supported features, tools, resources, and protocol versions. This ensures both sides understand what capabilities are available for the session.
The user interacts with the host (e.g., enters a prompt or command). The host collects this input and passes it to the client for processing.
- The client may request additional context or resources from the server (such as files, database entries, or knowledge base articles) to enrich the model's understanding.
- If the model determines that a tool is needed (e.g., to fetch data, perform a calculation, or call an API), the client sends a tool invocation request to the server, specifying the tool name and parameters.
The server receives the resource or tool request, executes the necessary operations (such as running a function, querying a database, or retrieving a file), and returns the results to the client in a structured format.
The client integrates the server's responses (resource data, tool outputs, etc.) into the ongoing model interaction. The model uses this information to generate a comprehensive and contextually relevant response.
The host receives the final output from the client and presents it to the user, often including both the model's generated text and any results from tool executions or resource lookups.
This flow enables MCP to support advanced, interactive, and context-aware AI applications by seamlessly connecting models with external tools and data sources.
MCP consists of two distinct architectural layers that work together to provide a complete communication framework:
The Data Layer implements the core MCP protocol using JSON-RPC 2.0 as its foundation. This layer defines the message structure, semantics, and interaction patterns:
The Transport Layer manages communication channels, message framing, and authentication between MCP participants:
1. STDIO Transport:
- Uses standard input/output streams for direct process communication
- Optimal for local processes on the same machine with no network overhead
- Commonly used for local MCP server implementations
2. Streamable HTTP Transport:
- Uses HTTP POST for client-to-server messages
- Optional Server-Sent Events (SSE) for server-to-client streaming
- Enables remote server communication across networks
- Supports standard HTTP authentication (bearer tokens, API keys, custom headers)
- MCP recommends OAuth for secure token-based authentication
The transport layer abstracts communication details from the data layer, enabling the same JSON-RPC 2.0 message format across all transport mechanisms. This abstraction allows applications to switch between local and remote servers seamlessly.
MCP implementations must adhere to several critical security principles to ensure safe, trustworthy, and secure interactions across all protocol operations:
By following these security principles, MCP ensures user trust, privacy, and safety are maintained across all protocol interactions while enabling powerful AI integrations.
Below are code examples in several popular programming languages that illustrate how to implement key MCP server components and tools.
Here is a practical .NET code example demonstrating how to implement a simple MCP server with custom tools. This example showcases how to define and register tools, handle requests, and connect the server using the Model Context Protocol.
using System;
using System.Threading.Tasks;
using ModelContextProtocol.Server;
using ModelContextProtocol.Server.Transport;
using ModelContextProtocol.Server.Tools;
public class WeatherServer
{
public static async Task Main(string[] args)
{
// Create an MCP server
var server = new McpServer(
name: "Weather MCP Server",
version: "1.0.0"
);
// Register our custom weather tool
server.AddTool<string, WeatherData>("weatherTool",
description: "Gets current weather for a location",
execute: async (location) => {
// Call weather API (simplified)
var weatherData = await GetWeatherDataAsync(location);
return weatherData;
});
// Connect the server using stdio transport
var transport = new StdioServerTransport();
await server.ConnectAsync(transport);
Console.WriteLine("Weather MCP Server started");
// Keep the server running until process is terminated
await Task.Delay(-1);
}
private static async Task<WeatherData> GetWeatherDataAsync(string location)
{
// This would normally call a weather API
// Simplified for demonstration
await Task.Delay(100); // Simulate API call
return new WeatherData {
Temperature = 72.5,
Conditions = "Sunny",
Location = location
};
}
}
public class WeatherData
{
public double Temperature { get; set; }
public string Conditions { get; set; }
public string Location { get; set; }
}
This example demonstrates the same MCP server and tool registration as the .NET example above, but implemented in Java.
import io.modelcontextprotocol.server.McpServer;
import io.modelcontextprotocol.server.McpToolDefinition;
import io.modelcontextprotocol.server.transport.StdioServerTransport;
import io.modelcontextprotocol.server.tool.ToolExecutionContext;
import io.modelcontextprotocol.server.tool.ToolResponse;
public class WeatherMcpServer {
public static void main(String[] args) throws Exception {
// Create an MCP server
McpServer server = McpServer.builder()
.name("Weather MCP Server")
.version("1.0.0")
.build();
// Register a weather tool
server.registerTool(McpToolDefinition.builder("weatherTool")
.description("Gets current weather for a location")
.parameter("location", String.class)
.execute((ToolExecutionContext ctx) -> {
String location = ctx.getParameter("location", String.class);
// Get weather data (simplified)
WeatherData data = getWeatherData(location);
// Return formatted response
return ToolResponse.content(
String.format("Temperature: %.1f°F, Conditions: %s, Location: %s",
data.getTemperature(),
data.getConditions(),
data.getLocation())
);
})
.build());
// Connect the server using stdio transport
try (StdioServerTransport transport = new StdioServerTransport()) {
server.connect(transport);
System.out.println("Weather MCP Server started");
// Keep server running until process is terminated
Thread.currentThread().join();
}
}
private static WeatherData getWeatherData(String location) {
// Implementation would call a weather API
// Simplified for example purposes
return new WeatherData(72.5, "Sunny", location);
}
}
class WeatherData {
private double temperature;
private String conditions;
private String location;
public WeatherData(double temperature, String conditions, String location) {
this.temperature = temperature;
this.conditions = conditions;
this.location = location;
}
public double getTemperature() {
return temperature;
}
public String getConditions() {
return conditions;
}
public String getLocation() {
return location;
}
}
This example uses fastmcp, so please ensure you install it first:
pip install fastmcp
Code Sample:
#!/usr/bin/env python3
import asyncio
from fastmcp import FastMCP
from fastmcp.transports.stdio import serve_stdio
# Create a FastMCP server
mcp = FastMCP(
name="Weather MCP Server",
version="1.0.0"
)
@mcp.tool()
def get_weather(location: str) -> dict:
"""Gets current weather for a location."""
return {
"temperature": 72.5,
"conditions": "Sunny",
"location": location
}
# Alternative approach using a class
class WeatherTools:
@mcp.tool()
def forecast(self, location: str, days: int = 1) -> dict:
"""Gets weather forecast for a location for the specified number of days."""
return {
"location": location,
"forecast": [
{"day": i+1, "temperature": 70 + i, "conditions": "Partly Cloudy"}
for i in range(days)
]
}
# Register class tools
weather_tools = WeatherTools()
# Start the server
if __name__ == "__main__":
asyncio.run(serve_stdio(mcp))
This example shows MCP server creation in JavaScript and how to register two weather-related tools.
// Using the official Model Context Protocol SDK
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod"; // For parameter validation
// Create an MCP server
const server = new McpServer({
name: "Weather MCP Server",
version: "1.0.0"
});
// Define a weather tool
server.tool(
"weatherTool",
{
location: z.string().describe("The location to get weather for")
},
async ({ location }) => {
// This would normally call a weather API
// Simplified for demonstration
const weatherData = await getWeatherData(location);
return {
content: [
{
type: "text",
text: `Temperature: ${weatherData.temperature}°F, Conditions: ${weatherData.conditions}, Location: ${weatherData.location}`
}
]
};
}
);
// Define a forecast tool
server.tool(
"forecastTool",
{
location: z.string(),
days: z.number().default(3).describe("Number of days for forecast")
},
async ({ location, days }) => {
// This would normally call a weather API
// Simplified for demonstration
const forecast = await getForecastData(location, days);
return {
content: [
{
type: "text",
text: `${days}-day forecast for ${location}: ${JSON.stringify(forecast)}`
}
]
};
}
);
// Helper functions
async function getWeatherData(location) {
// Simulate API call
return {
temperature: 72.5,
conditions: "Sunny",
location: location
};
}
async function getForecastData(location, days) {
// Simulate API call
return Array.from({ length: days }, (_, i) => ({
day: i + 1,
temperature: 70 + Math.floor(Math.random() * 10),
conditions: i % 2 === 0 ? "Sunny" : "Partly Cloudy"
}));
}
// Connect the server using stdio transport
const transport = new StdioServerTransport();
server.connect(transport).catch(console.error);
console.log("Weather MCP Server started");
This JavaScript example demonstrates how to create an MCP server using the Model Context Protocol SDK.
It shows how to register two tools named weatherTool and forecastTool and make them available to MCP clients through the StdioServerTransport.
MCP includes several built-in concepts and mechanisms for managing security and authorization throughout the protocol:
1. Tool Permission Control:
Clients can specify which tools a model is allowed to use during a session.
This ensures that only explicitly authorized tools are accessible, reducing the risk of unintended or unsafe operations.
Permissions can be configured dynamically based on user preferences, organizational policies, or the context of the interaction.
2. Authentication:
Servers can require authentication before granting access to tools, resources, or sensitive operations.
This may involve API keys, OAuth tokens, or other authentication schemes.
Proper authentication ensures that only trusted clients and users can invoke server-side capabilities.
3. Validation:
Parameter validation is enforced for all tool invocations.
Each tool defines the expected types, formats, and constraints for its parameters, and the server validates incoming requests accordingly.
This prevents malformed or malicious input from reaching tool implementations and helps maintain the integrity of operations.
4. Rate Limiting:
To prevent abuse and ensure fair usage of server resources, MCP servers can implement rate limiting for tool calls and resource access.
Rate limits can be applied per user, per session, or globally, and help protect against denial-of-service attacks or excessive resource consumption.
By combining these mechanisms, MCP provides a secure foundation for integrating language models with external tools and data sources, while giving users and developers fine-grained control over access and usage.
MCP communication uses structured JSON-RPC 2.0 messages to facilitate clear and reliable interactions between hosts, clients, and servers. The protocol defines specific message patterns for different types of operations:
initialize Request: Establishes connection and negotiates protocol version and capabilitiesinitialize Response: Confirms supported features and server information notifications/initialized: Signals that initialization is complete and the session is readytools/list Request: Discovers available tools from the serverresources/list Request: Lists available resources (data sources)prompts/list Request: Retrieves available prompt templatestools/call Request: Executes a specific tool with provided parametersresources/read Request: Retrieves content from a specific resourceprompts/get Request: Fetches a prompt template with optional parameterssampling/complete Request: Server requests LLM completion from the clientelicitation/request: Server requests user input through the client interfacenotifications/tools/list_changed: Server notifies client of tool changesnotifications/resources/list_changed: Server notifies client of resource changes notifications/prompts/list_changed: Server notifies client of prompt changesAll MCP messages follow JSON-RPC 2.0 format with:
id, method, and optional paramsid and either result or error method and optional params (no id or response expected)This structured communication ensures reliable, traceable, and extensible interactions supporting advanced scenarios like real-time updates, tool chaining, and robust error handling.
Tasks are an experimental feature that provides durable execution wrappers enabling deferred result retrieval and status tracking for MCP requests:
Tasks wrap standard MCP requests to enable asynchronous execution patterns for operations that cannot complete immediately.
Design a simple MCP tool that would be useful in your domain. Define:
1. What the tool would be named
2. What parameters it would accept
3. What output it would return
4. How a model might use this tool to solve user problems
---
Next: Chapter 2: Security
_(위 이미지를 클릭하여 이 강의의 영상을 시청하세요)_
이 가이드에서는 MCP의 핵심 개념을 안내합니다. 클라이언트-서버 아키텍처, 주요 구성 요소, 통신 메커니즘 및 구현 모범 사례에 대해 배우게 됩니다.
이 강의에서는 Model Context Protocol(MCP) 생태계를 구성하는 기본 아키텍처와 구성 요소를 탐구합니다. MCP 상호작용을 지원하는 클라이언트-서버 아키텍처, 주요 구성 요소 및 통신 메커니즘에 대해 배우게 됩니다.
이 강의가 끝나면 다음을 이해할 수 있습니다:
MCP 생태계는 클라이언트-서버 모델로 구축되어 있습니다. 이 모듈식 구조는 AI 애플리케이션이 도구, 데이터베이스, API 및 컨텍스트 리소스와 효율적으로 상호작용할 수 있게 합니다. 이 아키텍처를 핵심 구성 요소로 나누어 살펴보겠습니다.
기본적으로 MCP는 하나의 호스트 애플리케이션이 여러 서버에 연결할 수 있는 클라이언트-서버 아키텍처를 따릅니다:
flowchart LR
subgraph "당신의 컴퓨터"
Host["MCP가 있는 호스트 (Visual Studio, VS Code, IDE, 도구)"]
S1["MCP 서버 A"]
S2["MCP 서버 B"]
S3["MCP 서버 C"]
Host <-->|"MCP 프로토콜"| S1
Host <-->|"MCP 프로토콜"| S2
Host <-->|"MCP 프로토콜"| S3
S1 <--> D1[("로컬\데이터 소스 A")]
S2 <--> D2[("로컬\데이터 소스 B")]
end
subgraph "인터넷"
S3 <-->|"웹 API"| D3[("원격\서비스")]
end
MCP 프로토콜은 날짜 기반 버전 관리(YYYY-MM-DD 형식)를 사용하는 진화하는 표준입니다. 현재 프로토콜 버전은 2025-11-25입니다. 최신 업데이트는 프로토콜 명세에서 확인할 수 있습니다.
Model Context Protocol(MCP)에서 호스트는 사용자가 프로토콜과 상호작용하는 주요 인터페이스 역할을 하는 AI 애플리케이션입니다. 호스트는 각 서버 연결을 위해 전용 MCP 클라이언트를 생성하여 여러 MCP 서버와의 연결을 조율하고 관리합니다. 호스트의 예시는 다음과 같습니다:
호스트는 AI 모델 상호작용을 조율하는 애플리케이션입니다. 그들은:
클라이언트는 호스트와 MCP 서버 간의 전용 1:1 연결을 유지하는 핵심 구성 요소입니다. 각 MCP 클라이언트는 호스트에 의해 특정 MCP 서버에 연결하기 위해 인스턴스화되어 조직적이고 안전한 통신 채널을 보장합니다. 여러 클라이언트는 호스트가 동시에 여러 서버에 연결할 수 있게 합니다.
클라이언트는 호스트 애플리케이션 내 연결자 역할 구성 요소입니다. 그들은:
서버는 MCP 클라이언트에 컨텍스트, 도구, 기능을 제공하는 프로그램입니다. 로컬(호스트와 같은 머신) 또는 원격(외부 플랫폼)으로 실행 가능하며, 클라이언트 요청을 처리하고 구조화된 응답을 제공합니다. 서버는 표준화된 Model Context Protocol을 통해 특정 기능을 노출합니다.
서버는 컨텍스트 및 기능을 제공하는 서비스입니다. 그들은:
서버는 누구나 특화된 기능으로 모델 역량을 확장하기 위해 개발할 수 있으며, 로컬 및 원격 배포 시나리오를 모두 지원합니다.
Model Context Protocol(MCP) 내 서버는 클라이언트, 호스트 및 언어 모델 간의 풍부한 상호작용을 위한 기본 구성 요소인 세 가지 핵심 원시 기능을 제공합니다. 이 원시 기능은 프로토콜을 통해 제공되는 컨텍스트 정보와 가능한 동작 유형을 정의합니다.
MCP 서버는 다음 세 가지 핵심 원시 기능 중 임의의 조합을 노출할 수 있습니다:
리소스는 AI 애플리케이션에 컨텍스트 정보를 제공하는 데이터 소스입니다. 정적 또는 동적 콘텐츠로서 모델의 이해력과 의사결정을 향상시킵니다:
리소스는 URI로 식별되며 resources/list를 통한 검색 및 resources/read를 통한 조회를 지원합니다:
file://documents/project-spec.md
database://production/users/schema
api://weather/current
프롬프트는 언어 모델과의 상호작용을 구조화하는 재사용 가능한 템플릿입니다. 표준화된 상호작용 패턴과 템플릿화된 워크플로를 제공합니다:
프롬프트는 변수 치환을 지원하며 prompts/list를 통해 검색, prompts/get으로 조회할 수 있습니다:
Generate a {{task_type}} for {{product}} targeting {{audience}} with the following requirements: {{requirements}}
도구는 AI 모델이 특정 작업을 수행하기 위해 호출할 수 있는 실행 가능한 함수입니다. MCP 생태계 내 "동사" 역할을 하며 모델이 외부 시스템과 상호작용할 수 있게 합니다:
도구는 매개변수 검증을 위한 JSON Schema로 정의되며 tools/list로 검색, tools/call로 실행됩니다.
도구는 UI 표현 강화를 위해 아이콘을 부가 메타데이터로 포함할 수 있습니다.
도구 주석: 도구는 읽기 전용(readOnlyHint), 파괴적(destructiveHint) 등 행태 주석을 지원하여 도구 실행에 관한 클라이언트의 정보 기반 판단을 돕습니다.
도구 정의 예시:
server.tool(
"search_products",
{
query: z.string().describe("Search query for products"),
category: z.string().optional().describe("Product category filter"),
max_results: z.number().default(10).describe("Maximum results to return")
},
async (params) => {
// 검색을 실행하고 구조화된 결과를 반환합니다
return await productService.search(params);
}
);
Model Context Protocol(MCP)에서 클라이언트는 서버가 호스트 애플리케이션에 추가 기능을 요청할 수 있도록 원시 기능을 노출할 수 있습니다. 이 클라이언트 측 원시 기능은 AI 모델 기능 및 사용자 상호작용에 접근하는 더 풍부하고 상호작용적인 서버 구현을 가능하게 합니다.
샘플링은 서버가 클라이언트의 AI 애플리케이션에서 언어 모델 완성을 요청할 수 있게 합니다. 이 원시 기능은 서버가 자체 모델 종속성을 포함하지 않고도 LLM 기능에 접근할 수 있게 합니다:
tools 및 toolChoice 매개변수 포함 가능샘플링은 sampling/complete 메서드를 통해 서버가 클라이언트에 완성 요청을 전송하는 것으로 시작됩니다.
루트는 클라이언트가 파일 시스템 경계를 서버에 노출하는 표준화된 방법을 제공합니다. 이를 통해 서버가 접근 가능한 디렉터리 및 파일 범위를 이해할 수 있습니다:
file:// URI를 사용하여 접근 가능한 디렉터리 및 파일 식별루트는 roots/list를 통해 검색하며, 클라이언트는 루트 변경 시 notifications/roots/list_changed를 보냅니다.
정보 요청은 서버가 클라이언트 인터페이스를 통해 사용자로부터 추가 정보나 확인을 요청할 수 있도록 합니다:
정보 요청은 클라이언트 인터페이스를 통해 사용자 입력을 수집하는 elicitation/request 메서드를 사용합니다.
URL 모드 정보 요청: 서버는 URL 기반 사용자 상호작용도 요청할 수 있어, 인증, 승인 또는 데이터 입력을 위해 사용자를 외부 웹페이지로 안내할 수 있습니다.
로깅은 서버가 디버깅, 모니터링, 운영 투명성을 위해 클라이언트에 구조화된 로그 메시지를 전송할 수 있게 합니다:
로깅 메시지는 서버 운영의 투명성을 제공하고 디버깅을 용이하게 하기 위해 클라이언트에 전송됩니다.
Model Context Protocol(MCP)은 호스트, 클라이언트, 서버, 모델 간에 구조화된 정보 흐름을 정의합니다.
이 흐름을 이해하면 사용자의 요청이 처리되는 방식과 외부 도구 및 데이터가 모델 응답에 통합되는 방식을 명확히 알 수 있습니다.
호스트 애플리케이션(IDE나 채팅 인터페이스 등)이 보통 STDIO, WebSocket 또는 기타 지원되는 전송 방식을 통해 MCP 서버에 연결을 설정합니다.
클라이언트(호스트에 내장됨)와 서버는 지원되는 기능, 도구, 리소스 및 프로토콜 버전에 관한 정보를 교환합니다. 이를 통해 양측이 세션에서 사용 가능한 기능을 확실히 이해합니다.
사용자가 호스트와 상호작용합니다(예: 프롬프트나 명령어 입력). 호스트는 이 입력을 수집하여 처리용으로 클라이언트에 전달합니다.
- 클라이언트는 모델의 이해를 돕기 위해 서버에 추가 컨텍스트나 리소스(파일, 데이터베이스 항목, 지식베이스 문서 등)를 요청할 수 있습니다.
- 모델이 도구 사용이 필요하다고 판단하면(예: 데이터 조회, 계산 수행, API 호출) 클라이언트는 도구 이름과 매개변수를 명시하여 도구 호출 요청을 서버에 보냅니다.
서버는 리소스나 도구 요청을 받고 필요한 작업(함수 실행, 데이터베이스 쿼리, 파일 조회 등)을 수행한 뒤 결과를 구조화된 형식으로 클라이언트에 반환합니다.
클라이언트는 서버의 응답(리소스 데이터, 도구 출력 등)을 모델 상호작용에 통합합니다. 모델은 이 정보를 활용해 포괄적이고 문맥에 맞는 응답을 생성합니다.
호스트는 클라이언트로부터 최종 출력을 받아 사용자에게 제공합니다. 여기에는 모델이 생성한 텍스트와 도구 실행 또는 리소스 조회 결과가 포함될 수 있습니다.
이 흐름은 모델과 외부 도구 및 데이터 소스를 원활히 연결하여 MCP가 고급 인터랙티브, 컨텍스트 인지 AI 애플리케이션을 지원하도록 합니다.
MCP는 완전한 통신 프레임워크를 제공하기 위해 함께 작동하는 두 가지 뚜렷한 아키텍처 계층으로 구성됩니다:
데이터 계층은 JSON-RPC 2.0을 기반으로 MCP 프로토콜의 핵심을 구현합니다. 이 계층은 메시지 구조, 의미론, 상호작용 패턴을 정의합니다:
전송 계층은 MCP 참가자 간 통신 채널, 메시지 프레이밍, 인증을 관리합니다:
1. STDIO 전송:
- 표준 입력/출력 스트림을 사용해 직접 프로세스 간 통신
- 네트워크 오버헤드가 없는 동일 머신의 로컬 프로세스에 최적화
- 로컬 MCP 서버 구현에서 흔히 사용됨
2. 스트리밍 HTTP 전송:
- 클라이언트에서 서버로 HTTP POST 방식 사용
- 선택적 서버-발행 이벤트(SSE)를 통해 서버에서 클라이언트로 스트리밍 가능
- 네트워크를 통한 원격 서버 통신 지원
- 표준 HTTP 인증(Bearer 토큰, API 키, 커스텀 헤더) 지원
- MCP는 보안 토큰 인증을 위해 OAuth 사용 권장
전송 계층은 데이터 계층과 별개로 통신 세부사항을 추상화하여 모든 전송 방식에서 동일한 JSON-RPC 2.0 메시지 형식을 사용할 수 있게 합니다. 이를 통해 응용 프로그램이 로컬과 원격 서버 간 전환을 원활히 수행할 수 있습니다.
MCP 구현체는 모든 프로토콜 작업에서 안전하고 신뢰할 수 있으며 보안을 보장하기 위한 여러 중요한 보안 원칙을 준수해야 합니다:
이 보안 원칙을 준수함으로써 MCP는 강력한 AI 통합 기능을 제공하면서도 사용자 신뢰, 프라이버시, 안전을 보장합니다.
아래는 여러 인기 프로그래밍 언어로 MCP 서버 핵심 구성 요소와 도구 구현 방법을 보여주는 코드 예제입니다.
아래는 맞춤 도구 정의, 등록, 요청 처리, 그리고 Model Context Protocol을 사용해 서버와 연결하는 간단한 MCP 서버 구현 예제입니다.
using System;
using System.Threading.Tasks;
using ModelContextProtocol.Server;
using ModelContextProtocol.Server.Transport;
using ModelContextProtocol.Server.Tools;
public class WeatherServer
{
public static async Task Main(string[] args)
{
// Create an MCP server
var server = new McpServer(
name: "Weather MCP Server",
version: "1.0.0"
);
// Register our custom weather tool
server.AddTool<string, WeatherData>("weatherTool",
description: "Gets current weather for a location",
execute: async (location) => {
// Call weather API (simplified)
var weatherData = await GetWeatherDataAsync(location);
return weatherData;
});
// Connect the server using stdio transport
var transport = new StdioServerTransport();
await server.ConnectAsync(transport);
Console.WriteLine("Weather MCP Server started");
// Keep the server running until process is terminated
await Task.Delay(-1);
}
private static async Task<WeatherData> GetWeatherDataAsync(string location)
{
// This would normally call a weather API
// Simplified for demonstration
await Task.Delay(100); // Simulate API call
return new WeatherData {
Temperature = 72.5,
Conditions = "Sunny",
Location = location
};
}
}
public class WeatherData
{
public double Temperature { get; set; }
public string Conditions { get; set; }
public string Location { get; set; }
}
이 예제는 위 .NET 예제와 동일한 MCP 서버 및 도구 등록을 Java로 구현한 것입니다.
import io.modelcontextprotocol.server.McpServer;
import io.modelcontextprotocol.server.McpToolDefinition;
import io.modelcontextprotocol.server.transport.StdioServerTransport;
import io.modelcontextprotocol.server.tool.ToolExecutionContext;
import io.modelcontextprotocol.server.tool.ToolResponse;
public class WeatherMcpServer {
public static void main(String[] args) throws Exception {
// MCP 서버 생성
McpServer server = McpServer.builder()
.name("Weather MCP Server")
.version("1.0.0")
.build();
// 날씨 도구 등록
server.registerTool(McpToolDefinition.builder("weatherTool")
.description("Gets current weather for a location")
.parameter("location", String.class)
.execute((ToolExecutionContext ctx) -> {
String location = ctx.getParameter("location", String.class);
// 날씨 데이터 가져오기 (단순화됨)
WeatherData data = getWeatherData(location);
// 형식화된 응답 반환
return ToolResponse.content(
String.format("Temperature: %.1f°F, Conditions: %s, Location: %s",
data.getTemperature(),
data.getConditions(),
data.getLocation())
);
})
.build());
// stdio 전송을 사용하여 서버에 연결
try (StdioServerTransport transport = new StdioServerTransport()) {
server.connect(transport);
System.out.println("Weather MCP Server started");
// 프로세스가 종료될 때까지 서버 실행 유지
Thread.currentThread().join();
}
}
private static WeatherData getWeatherData(String location) {
// 구현 시 날씨 API 호출
// 예제 목적으로 단순화됨
return new WeatherData(72.5, "Sunny", location);
}
}
class WeatherData {
private double temperature;
private String conditions;
private String location;
public WeatherData(double temperature, String conditions, String location) {
this.temperature = temperature;
this.conditions = conditions;
this.location = location;
}
public double getTemperature() {
return temperature;
}
public String getConditions() {
return conditions;
}
public String getLocation() {
return location;
}
}
이 예제는 fastmcp를 사용하므로 먼저 설치해 주세요:
pip install fastmcp
코드 샘플:
#!/usr/bin/env python3
import asyncio
from fastmcp import FastMCP
from fastmcp.transports.stdio import serve_stdio
# FastMCP 서버 생성
mcp = FastMCP(
name="Weather MCP Server",
version="1.0.0"
)
@mcp.tool()
def get_weather(location: str) -> dict:
"""Gets current weather for a location."""
return {
"temperature": 72.5,
"conditions": "Sunny",
"location": location
}
# 클래스를 사용하는 대체 방법
class WeatherTools:
@mcp.tool()
def forecast(self, location: str, days: int = 1) -> dict:
"""Gets weather forecast for a location for the specified number of days."""
return {
"location": location,
"forecast": [
{"day": i+1, "temperature": 70 + i, "conditions": "Partly Cloudy"}
for i in range(days)
]
}
# 클래스 도구 등록
weather_tools = WeatherTools()
# 서버 시작
if __name__ == "__main__":
asyncio.run(serve_stdio(mcp))
이 예제는 JavaScript로 MCP 서버를 생성하고 두 개의 날씨 관련 도구를 등록하는 방법을 보여줍니다.
// 공식 모델 컨텍스트 프로토콜 SDK 사용
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod"; // 매개변수 유효성 검사용
// MCP 서버 생성
const server = new McpServer({
name: "Weather MCP Server",
version: "1.0.0"
});
// 날씨 도구 정의
server.tool(
"weatherTool",
{
location: z.string().describe("The location to get weather for")
},
async ({ location }) => {
// 일반적으로 날씨 API를 호출함
// 데모를 위해 단순화됨
const weatherData = await getWeatherData(location);
return {
content: [
{
type: "text",
text: `Temperature: ${weatherData.temperature}°F, Conditions: ${weatherData.conditions}, Location: ${weatherData.location}`
}
]
};
}
);
// 예보 도구 정의
server.tool(
"forecastTool",
{
location: z.string(),
days: z.number().default(3).describe("Number of days for forecast")
},
async ({ location, days }) => {
// 일반적으로 날씨 API를 호출함
// 데모를 위해 단순화됨
const forecast = await getForecastData(location, days);
return {
content: [
{
type: "text",
text: `${days}-day forecast for ${location}: ${JSON.stringify(forecast)}`
}
]
};
}
);
// 도우미 함수들
async function getWeatherData(location) {
// API 호출 시뮬레이션
return {
temperature: 72.5,
conditions: "Sunny",
location: location
};
}
async function getForecastData(location, days) {
// API 호출 시뮬레이션
return Array.from({ length: days }, (_, i) => ({
day: i + 1,
temperature: 70 + Math.floor(Math.random() * 10),
conditions: i % 2 === 0 ? "Sunny" : "Partly Cloudy"
}));
}
// stdio 전송을 사용하여 서버 연결
const transport = new StdioServerTransport();
server.connect(transport).catch(console.error);
console.log("Weather MCP Server started");
이 JavaScript 예제는 Model Context Protocol SDK를 사용해 MCP 서버를 만드는 방법을 설명합니다. weatherTool과 forecastTool이라는 두 도구를 등록하고 StdioServerTransport를 통해 MCP 클라이언트에 제공하는 과정이 나와 있습니다.
MCP는 프로토콜 전반에 걸쳐 보안 및 권한 관리용 기본 개념과 메커니즘을 다음과 같이 포함합니다:
1. 도구 권한 제어
클라이언트는 세션 동안 모델이 사용할 수 있는 도구를 지정할 수 있습니다. 이를 통해 명시적으로 허가된 도구만 접근 가능하게 하여 의도하지 않았거나 안전하지 않은 작업 위험을 줄입니다. 권한은 사용자 설정, 조직 정책 또는 상호작용 문맥에 따라 동적으로 구성할 수 있습니다.
2. 인증
서버는 도구, 리소스, 민감한 작업 접근 권한 부여 전에 인증을 요구할 수 있습니다. API 키, OAuth 토큰, 기타 인증 방식을 사용할 수 있습니다. 올바른 인증은 신뢰할 수 있는 클라이언트와 사용자만 서버 기능을 호출할 수 있게 보장합니다.
3. 검증
모든 도구 호출에 대해 매개변수 검증을 수행합니다. 각 도구는 예상 타입, 형식, 제약 조건을 정의하며 서버는 들어오는 요청을 이에 맞게 검증합니다. 이를 통해 잘못되거나 악의적인 입력이 도구 구현에 도달하지 않게 하고 작업 무결성을 유지합니다.
4. 요율 제한
오용 방지와 공정한 서버 자원 사용을 위해 MCP 서버는 도구 호출 및 리소스 접근에 대해 요율 제한을 구현할 수 있습니다. 사용자별, 세션별, 전체 단위로 제한을 적용하며 서비스 거부 공격이나 과도한 자원 소비를 방지합니다.
이 메커니즘을 통합해 MCP는 언어 모델과 외부 도구 및 데이터 소스 통합을 위한 안전한 기반을 제공하며, 사용자와 개발자가 접근 및 사용을 세밀하게 제어할 수 있도록 합니다.
MCP 통신은 명확하고 신뢰할 수 있는 상호작용을 위해 구조화된 JSON-RPC 2.0 메시지를 사용합니다. 프로토콜은 다양한 작업 유형별로 특정 메시지 패턴을 정의합니다:
initialize 요청: 연결 수립 및 프로토콜 버전과 기능 협상 initialize 응답: 지원하는 기능 및 서버 정보 확인 notifications/initialized: 초기화 완료 및 세션 준비 완료 신호tools/list 요청: 서버에서 사용 가능한 도구 조회 resources/list 요청: 사용 가능한 리소스(데이터 소스) 목록 요청 prompts/list 요청: 사용 가능한 프롬프트 템플릿 조회tools/call 요청: 특정 도구를 매개변수와 함께 실행 resources/read 요청: 특정 리소스의 내용 조회 prompts/get 요청: 선택적 매개변수와 함께 프롬프트 템플릿 가져오기sampling/complete 요청: 서버가 클라이언트에 LLM 완료를 요청 elicitation/request: 서버가 클라이언트를 통해 사용자 입력 요청 notifications/tools/list_changed: 서버가 도구 변경 사항을 클라이언트에 알림 notifications/resources/list_changed: 서버가 리소스 변경 사항을 클라이언트에 알림 notifications/prompts/list_changed: 서버가 프롬프트 변경 사항을 클라이언트에 알림모든 MCP 메시지는 JSON-RPC 2.0 형식을 따르며:
id, method, 선택적 params 포함 id 및 result 또는 error 포함 method 및 선택적 params 포함(id 없음, 응답 기대 안함)이 구조화된 통신은 실시간 업데이트, 도구 체인, 견고한 오류 처리 등 고급 시나리오를 지원하면서 신뢰성 있고 추적 가능하며 확장 가능한 상호작용을 보장합니다.
작업(tasks)은 MCP 요청에 대해 결과 지연 수령과 상태 추적이 가능한 지속적 실행 래퍼를 제공하는 실험적 기능입니다:
작업은 즉시 완료되지 않는 작업에 대해 비동기 실행 패턴을 가능하게 하도록 표준 MCP 요청을 래핑합니다.
당신의 영역에서 유용할 간단한 MCP 도구를 설계해 보십시오. 정의할 내용:
1. 도구 이름
2. 수락할 매개변수
3. 반환할 출력
4. 모델이 이 도구를 사용해 사용자 문제를 해결하는 방법
---
다음: 2장: 보안
---
면책 조항:
이 문서는 AI 번역 서비스 Co-op Translator를 사용하여 번역되었습니다.
정확성을 위해 노력하고 있으나, 자동 번역에는 오류나 부정확한 내용이 포함될 수 있음을 유의하시기 바랍니다.
원본 문서의 원어 버전을 권위 있는 자료로 간주해야 합니다.
중요한 정보의 경우 전문 인력에 의한 번역을 권장합니다.
본 번역 사용으로 인한 오해나 잘못된 해석에 대해서는 책임을 지지 않습니다.