Mở đầu

Tìm hiểu lý thuyết về Model Context Protocol (MCP), chắc hẳn các bạn sẽ gặp phải các keywords như Resources, Prompts, Tools, Sampling, Roots, Transports, ... Để có thể sử dụng MCP cho dự án của mình thì mình nghĩ càng cần thiết cho việc hiểu rõ các khái niệm này Không lòng vòng nữa, cùng trao đổi về các vấn đề này thôi. Gét gô

"Resources" - Nền tảng cung cấp ngữ cảnh đa dạng cho AI

Resources đóng vai trò như những "thư viện dữ liệu" phong phú mà các servers trang bị cho các clients. Mục đích của chúng là cung cấp ngữ cảnh (context) - nền tảng kiến thức giúp LLMs hiểu rõ hơn về thông tin liên quan đến yêu cầu của người dùng hoặc nhiệm vụ đang thực hiện. Hãy tưởng tượng, Resources chính là những trang sách, tài liệu, hình ảnh, hay thậm chí là dữ liệu trực tiếp từ hệ thống, giúp AI có cái nhìn toàn diện hơn.

Sự linh hoạt trong quản lý: "Application-Controlled"

Một trong những điểm mạnh của Resources là tính application-controlled. Điều này thể hiện ở việc bên quyết định cách thức và thời điểm sử dụng các Resources này là Client, chứ không phải server hay chính mô hình AI. Sự linh hoạt này mở ra nhiều khả năng cho các nhà phát triển ứng dụng:

• Kiểm soát ngữ cảnh: Ứng dụng có thể lựa chọn những Resources phù hợp nhất với ngữ cảnh hiện tại của người dùng hoặc tác vụ.
• Tối ưu hóa hiệu suất: Việc lựa chọn Resources một cách thông minh giúp tránh việc cung cấp quá nhiều thông tin không liên quan cho mô hình, từ đó cải thiện tốc độ xử lý và hiệu quả.
• Trải nghiệm người dùng đa dạng: Các ứng dụng khác nhau có thể có những chiến lược sử dụng Resources riêng, tạo ra những trải nghiệm độc đáo cho người dùng.

Ví dụ, một ứng dụng hỗ trợ viết email có thể cho phép người dùng chọn các tài liệu liên quan đến chủ đề email làm Resources. Trong khi đó, một ứng dụng trợ lý ảo có thể tự động tìm kiếm và sử dụng các Resources như lịch hẹn, thông tin liên lạc dựa trên ngữ cảnh cuộc trò chuyện.

Resources - "Kho tàng" dữ liệu đa dạng

Resources không bị giới hạn ở một loại dữ liệu cụ thể nào. Chúng có thể bao gồm:

• File contents: Văn bản, tài liệu PDF, mã nguồn, tệp cấu hình...
• Database records: Bản ghi khách hàng, thông tin sản phẩm...
• API responses: Dữ liệu thời tiết, kết quả tìm kiếm...
• Live system data: Thông tin về hiệu suất máy chủ, trạng thái thiết bị...
• Screenshots and images: Hỗ trợ các tác vụ liên quan đến thị giác...
• Log files: Cung cấp thông tin về hoạt động của hệ thống...
• Và nhiều định dạng dữ liệu khác.

Mỗi Resource được định danh bằng một URI (Uniform Resource Identifier) duy nhất, giống như một địa chỉ web cụ thể. URI này giúp ứng dụng khách xác định và yêu cầu nội dung của Resource. Cấu trúc của URI bao gồm

• Giao thức ([protocol])
• Máy chủ ([host])
• Đường dẫn ([path])

Điều này cho phép máy chủ tự định nghĩa cách tổ chức và quản lý các Resources của mình.

Hai dạng nội dung chính của Resources

1. Text Resources (Tài nguyên văn bản): Chứa dữ liệu văn bản được mã hóa theo chuẩn UTF-8. Đây là lựa chọn phù hợp cho các loại dữ liệu có cấu trúc rõ ràng hoặc đơn giản là văn bản thuần túy.

2. Binary Resources (Tài nguyên nhị phân): Chứa dữ liệu ở dạng thô (raw binary data) đã được mã hóa bằng base64. Việc mã hóa này giúp truyền tải dữ liệu nhị phân một cách an toàn và hiệu quả qua các kênh truyền thông dựa trên văn bản. Loại Resource này thích hợp cho hình ảnh, âm thanh, video và các định dạng tệp tin không phải văn bản khác.

Cách Client khám phá và tiếp cận Resources

MCP cung cấp hai cơ chế chính để Client khám phá các Resources mà Server cung cấp:

1. Direct Resources: Server công khai một danh sách cụ thể các Resources hiện có thông qua một endpoint có địa chỉ /resources/list. Mỗi mục trong danh sách này bao gồm các thông tin quan trọng như:

   • uri: Địa chỉ duy nhất của Resource.
   • name: Tên thân thiện, dễ hiểu để người dùng hoặc ứng dụng có thể nhận biết.
   • description (tùy chọn): Mô tả chi tiết hơn về nội dung hoặc mục đích của Resource.
   • mimeType (tùy chọn): Loại định dạng của dữ liệu (ví dụ: text/plain, application/pdf, image/jpeg).

2. Resource Templates: Đối với các loại dữ liệu có tính dynamic cao hoặc được tạo ra theo yêu cầu, Server có thể cung cấp các URI templates. Đây là các mẫu địa chỉ tuân theo tiêu chuẩn RFC 6570, cho phép Client tự xây dựng các URI hợp lệ dựa trên các tham số cụ thể. Điều này rất hữu ích khi máy chủ cung cấp các dịch vụ như truy vấn cơ sở dữ liệu hoặc truy cập các tài nguyên dựa trên thời gian. Mỗi template cũng đi kèm với name, description (tùy chọn), và mimeType (tùy chọn) cho loại tài nguyên mà nó đại diện.

Để đọc nội dung của một Resource, Client sẽ gửi một yêu cầu /resources/read đến máy chủ, kèm theo URI của Resource cần đọc. Máy chủ sẽ phản hồi bằng một danh sách chứa nội dung của Resource (có thể là văn bản hoặc dữ liệu nhị phân đã mã hóa base64), cùng với URI và kiểu MIME của nó. Một yêu cầu /resources/read có thể trả về nội dung của nhiều Resource cùng lúc, ví dụ như khi đọc một thư mục.

Cập nhật dữ liệu theo thời gian thực - giữ cho Context luôn mới:

MCP hỗ trợ hai cơ chế để đảm bảo Client luôn có được thông tin mới nhất từ các Resources:

1. List Changes (Thay đổi danh sách): Server có thể chủ động thông báo cho Client khi danh sách các Resources khả dụng có sự thay đổi (thêm, xóa, sửa đổi) thông qua một loại thông báo đặc biệt /notifications/resources/list_changed.

2. Content Changes (Thay đổi nội dung): ỨClient có thể "đăng ký" (subscribe) để nhận thông báo về những thay đổi nội dung của một Resource cụ thể bằng cách gửi yêu cầu /resources/subscribe kèm theo URI của Resource. Khi nội dung của Resource đó thay đổi, Server sẽ gửi thông báo /notifications/resources/updated (Cơ chế này khá giống MQTT trong môn IoT mình từng học). Sau đó,Client có thể gửi yêu cầu /resources/read để lấy nội dung mới nhất. Nếu không còn quan tâm đến việc cập nhật, Client có thể hủy đăng ký bằng yêu cầu /resources/unsubscribe.

Ví Dụ Minh Họa:

Hãy tưởng tượng một ứng dụng trợ lý AI có khả năng tóm tắt nội dung các cuộc họp. Server có thể cung cấp các bản ghi âm cuộc họp dưới dạng Binary Resources (với mimeType là audio/mpeg) và bản ghi văn bản (nếu có) dưới dạng Text Resources (mimeType là text/plain). Client có thể:

• Sử dụng /resources/list để hiển thị danh sách các bản ghi âm và bản ghi văn bản có sẵn.
• Sử dụng Resource Templates để cho phép người dùng chỉ định một khoảng thời gian cụ thể và truy xuất các bản ghi liên quan.
• Gửi yêu cầu /resources/read với URI của bản ghi âm để lấy nội dung và chuyển cho mô hình AI để tóm tắt.
• Đăng ký nhận thông báo /notifications/resources/updated nếu bản ghi văn bản được cập nhật trong thời gian thực.

Những nguyên tắc vàng khi triển khai Resources

Để việc sử dụng Resources hiệu quả và an toàn, các nhà phát triển Server nên tuân theo những nguyên tắc sau:

• Đặt tên và URI rõ ràng: Giúp cả Client và mô hình AI dễ dàng hiểu và phân biệt các Resources.
• Cung cấp mô tả hữu ích: Giải thích rõ ràng mục đích và nội dung của từng Resource.
• Sử dụng đúng kiểu MIME: Giúp Client xử lý dữ liệu một cách chính xác.
• Triển khai Resource Templates cho nội dung động: Tăng tính linh hoạt và khả năng tùy biến.
• Sử dụng Subscriptions cho dữ liệu thường xuyên thay đổi: Đảm bảo Client luôn có thông tin mới nhất.
• Xử lý lỗi một cách trang nhã: Cung cấp thông báo lỗi rõ ràng khi có sự cố xảy ra.
• Cân nhắc phân trang cho danh sách lớn: Cải thiện hiệu suất khi có quá nhiều Resources.
• Lưu trữ tạm (Cache) nội dung khi phù hợp: Giảm tải cho Server và tăng tốc độ truy cập.
• Xác thực URI cẩn thận: Ngăn chặn các truy cập trái phép.
• Ghi lại (Document) các lược đồ URI tùy chỉnh: Giúp các nhà phát triển ứng dụng hiểu cách sử dụng.

Vấn đề bảo mật luôn được ưu tiên

Khi chia sẻ Resources, bảo mật là yếu tố sống còn. Các biện pháp cần được thực hiện bao gồm:

• Xác thực tất cả URI: Đảm bảo chỉ những yêu cầu hợp lệ mới được xử lý.
• Kiểm soát truy cập: Chỉ cho phép các ứng dụng hoặc người dùng được ủy quyền truy cập vào các Resources nhất định.
• Xử lý đường dẫn tệp tin an toàn: Ngăn chặn các tấn công lợi dụng lỗ hổng đường dẫn.
• Thận trọng với dữ liệu nhị phân: Kiểm tra kỹ lưỡng để tránh các nguy cơ tiềm ẩn.
• Giới hạn tốc độ yêu cầu: Ngăn chặn các cuộc tấn công từ chối dịch vụ (DoS).
• Kiểm tra nhật ký truy cập: Theo dõi việc sử dụng Resources để phát hiện các hoạt động bất thường.
• Mã hóa dữ liệu nhạy cảm: Bảo vệ thông tin trong quá trình truyền tải.
• Xác thực kiểu MIME: Đảm bảo dữ liệu được xử lý đúng cách.
• Thiết lập thời gian chờ: Tránh các yêu cầu kéo dài gây quá tải hệ thống.
• Quản lý việc dọn dẹp tài nguyên: Đảm bảo các tài nguyên tạm thời được giải phóng đúng cách.

"Prompts" - định nghĩa tương tác tiêu chuẩn với LLMs

Trong Model Context Protocol (MCP), Prompts là các template tương tác được định nghĩa bởi Server, cho phép Client cung cấp các yêu cầu tiêu chuẩn và tái sử dụng được cho các Mô hình Ngôn ngữ Lớn (LLMs). Prompts là một cơ chế mạnh mẽ để hệ thống hóa và chia sẻ các mẫu tương tác LLM phổ biến.

Hãy tưởng tượng bạn là một đầu bếp (Client) và bạn muốn "ra lệnh" cho một trợ lý bếp ảo (mô hình AI) thực hiện một món ăn (Task). Thay vì phải tự mình nghĩ ra từng bước và nguyên liệu (câu lệnh phức tạp), bạn có sẵn một quyển sách dạy nấu ăn (Prompts) với đầy đủ các "công thức" đã được tạo ra bởi các nhà hàng (Servers)

Tính Chất Hướng Đến Người Dùng (User-Controlled): Prompts được thiết kế để Server cung cấp cho Client, và người dùng cuối sẽ là người chủ động lựa chọn và kích hoạt chúng thông qua giao diện ứng dụng.

Khái Niệm Cơ Bản:

Prompts trong MCP là các template được xác định trước, có khả năng:

• Chấp nhận tham số động (Dynamic arguments): Cho phép client truyền các giá trị cụ thể khi sử dụng Prompt.
• Tích hợp ngữ cảnh từ Resources: Tham chiếu hoặc nhúng dữ liệu từ các Resources vào Prompt.
• Xây dựng quy trình nhiều bước (Chain multiple interactions): Định nghĩa các chuỗi tương tác tuần tự.
• Hướng dẫn các workflow cụ thể: Cung cấp khuôn khổ cho các tác vụ phức tạp.
• Hiển thị dưới dạng UI elements: Tích hợp vào giao diện người dùng như lệnh gọi, nút bấm, v.v.

Cấu Trúc Dữ Liệu Của Prompt: Mỗi Prompt được định nghĩa bằng một object JSON với các thuộc tính sau:

{ name: string; // Mã định danh duy nhất của Prompt description?: string; // Mô tả ngắn gọn về chức năng của Prompt arguments?: [ // Mảng tùy chọn các tham số mà Prompt chấp nhận { name: string; // Tên của tham số description?: string; // Mô tả về tham số required?: boolean; // Xác định tham số là bắt buộc hay không } ]
}

Sử dụng Prompts

Client sử dụng endpoint /prompts/list để lấy danh sách các Prompts khả dụng từ Server. Phản hồi là một mảng các đối tượng Prompt như cấu trúc trên.

Ví dụ

// Request
{ method: "prompts/list"
} // Response
{ prompts: [ { name: "analyze-code", description: "Analyze code for potential improvements", arguments: [ { name: "language", description: "Programming language", required: true } ] } ]
}

Để kích hoạt một Prompt, Client gửi yêu cầu /prompts/get kèm theo tên của Prompt và một object chứa các giá trị cho các tham số đã được định nghĩa. Phản hồi thường là một mảng các đối tượng message theo định dạng tiêu chuẩn của LLM API, chứa nội dung prompt đã được điền các tham số.

Ví dụ

// Request
{ method: "prompts/get", params: { name: "analyze-code", arguments: { language: "python" } }
} // Response
{ description: "Analyze Python code for potential improvements", messages: [ { role: "user", content: { type: "text", text: "Please analyze the following Python code for potential improvements:" } } ]
}

Dynamic Prompt và Tích Hợp Resources:

Prompts có thể tham chiếu đến Resources bằng cách sử dụng thuộc tính content.type: "resource" trong phần messages của phản hồi /prompts/get. Thuộc tính resource.uri chỉ định URI của Resource cần nhúng nội dung.

Ví dụ

{ "name": "analyze-project", "description": "Analyze project code", "arguments": [ { "name": "fileUri", "description": "URI of code file to review", "required": true } ]
}

Khi handle prompts/get request

// Request
{ method: "prompts/get", params: { name: "analyze-project", arguments: { fileUri: "file:///path/to/code.py" } }
} // Response
{ "messages": [ { "role": "user", "content": { "type": "text", "text": "Analyze the code file for any issues:" } }, { "role": "user", "content": { "type": "resource", "resource": { "uri": "file:///path/to/code.py", "text": "def connect_to_service(timeout=30):\n retries = 3\n for attempt in range(retries):\n try:\n return establish_connection(timeout)\n except TimeoutError:\n if attempt == retries - 1:\n raise\n time.sleep(5)\n\ndef establish_connection(timeout):\n # Connection implementation\n pass", "mimeType": "text/x-python" } } } ]
}

Ví dụ về implement prompts phía MCP server

Đoạn code này mình lấy từ trang chủ MCP vì chưa có thời gian ngồi tự build và phát triển

from mcp.server import Server
import mcp.types as types # Define available prompts
PROMPTS = { "git-commit": types.Prompt( name="git-commit", description="Generate a Git commit message", arguments=[ types.PromptArgument( name="changes", description="Git diff or description of changes", required=True ) ], ), "explain-code": types.Prompt( name="explain-code", description="Explain how code works", arguments=[ types.PromptArgument( name="code", description="Code to explain", required=True ), types.PromptArgument( name="language", description="Programming language", required=False ) ], )
} # Initialize server
app = Server("example-prompts-server") @app.list_prompts()
async def list_prompts() -> list[types.Prompt]: return list(PROMPTS.values()) @app.get_prompt()
async def get_prompt( name: str, arguments: dict[str, str] | None = None
) -> types.GetPromptResult: if name not in PROMPTS: raise ValueError(f"Prompt not found: {name}") if name == "git-commit": changes = arguments.get("changes") if arguments else "" return types.GetPromptResult( messages=[ types.PromptMessage( role="user", content=types.TextContent( type="text", text=f"Generate a concise but descriptive commit message " f"for these changes:\n\n{changes}" ) ) ] ) if name == "explain-code": code = arguments.get("code") if arguments else "" language = arguments.get("language", "Unknown") if arguments else "Unknown" return types.GetPromptResult( messages=[ types.PromptMessage( role="user", content=types.TextContent( type="text", text=f"Explain how this {language} code works:\n\n{code}" ) ) ] ) raise ValueError("Prompt implementation not found")

Đọc code example, chúng ta có thể thấy các bước cơ bản để implement prompts phía MCP server như sau

• Define prompts: Chúng ta cần define các prompts phía MCP Server với cấu trúc mỗi prompt mình đã viết bên trên
• Khởi tạo MCP server
• Cài đặt phương thức list_prompt(), get_prompt()

Về cơ bản thì việc implement prompts chưa phải là khó hiểu, mình nghĩ khó hiểu sẽ ở đoạn chúng ta kết hợp nhiều thứ vào để xây dựng kiến trúc gồm MCP server, Host và Client. Mình sẽ có bài viết chi tiết này sau nhé

Tools - "Trao quyền" cho LLM hành động

Tools là gì?

Mọi người nếu đã từng sử dụng kỹ thuật Function Calling thì không còn xa lạ với khái niệm Tools. Vậy với MCP thì có gì khác nhau không?

Về cơ bản thì là giống, đều mục đích mở rộng khả năng của LLM, ví dụ như thay vì chỉ biết hỏi đáp dựa trên context cung cấp hoặc được training, nó có thể kết nối tới các dữ liệu bên ngoài như realtime news, database, ....

Trong MCP, hiểu một cách đơn giản, Tools là các chức năng có thể thực thi (executable functionality) mà một server cung cấp cho client. Thông qua Tools, LLM có thể:

• Tương tác với các hệ thống bên ngoài: Ví dụ như gọi một API của dịch vụ khác (như GitHub, dịch vụ thời tiết).
• Thực hiện các phép tính toán: Ví dụ, tính tổng hai số, phân tích dữ liệu.
• Thực hiện hành động trong thế giới thực: Ví dụ, gửi email, tạo một mục trong lịch.

Một điểm khác biệt quan trọng so với "Prompts" (mà chúng ta đã thảo luận trước đó là "user-controlled") là Tools được thiết kế để "model-controlled" (do mô hình kiểm soát). Điều này có nghĩa là server cung cấp Tools với ý định rằng mô hình AI (LLM) có thể tự động gọi chúng để hoàn thành một tác vụ. Tuy nhiên, thường sẽ có một bước human in the loop để phê duyệt hành động trước khi nó được thực thi, đặc biệt với các tác vụ quan trọng.

Tổng quan về cách hoạt động của Tools:

• Khám phá (Discovery): Client có thể liệt kê các Tools có sẵn từ server thông qua endpoint tools/list. Điều này cho phép client (và LLM thông qua client) biết được những hành động nào có thể được thực hiện.
• Gọi (Invocation): Khi LLM quyết định cần sử dụng một Tool, client sẽ gọi Tool đó bằng cách sử dụng endpoint tools/call. Server sẽ thực hiện thao tác được yêu cầu và trả về kết quả.
• Linh hoạt: Tools có thể rất đa dạng, từ những hàm tính toán đơn giản (ví dụ: cộng hai số) đến những tương tác API phức tạp (ví dụ: tạo một issue trên GitHub).

So sánh nhanh với "Resources" (Tài nguyên) trong MCP: Cả Tools và Resources đều được xác định bằng tên duy nhất và có thể bao gồm mô tả. Tuy nhiên:

• Resources đại diện cho dữ liệu, ngữ cảnh (ví dụ: nội dung file, log hệ thống).
• Tools đại diện cho các hoạt động động (dynamic operations), có khả năng thay đổi trạng thái hoặc tương tác với các hệ thống bên ngoài.

Cấu trúc Định nghĩa một Tool:

Mỗi Tool trong MCP được định nghĩa với một cấu thường là JSON:

{ "name": "string", // Định danh duy nhất cho Tool (ví dụ: "calculate_sum") "description": "string", // Mô tả dễ hiểu (ví dụ: "Cộng hai số với nhau") "inputSchema": { // JSON Schema định nghĩa các tham số đầu vào của Tool "type": "object", "properties": { ... } // Các tham số cụ thể của Tool (ví dụ: "a": {"type": "number"}, "b": {"type": "number"}) }, "annotations": { // (Tùy chọn) Các gợi ý bổ sung về hành vi của Tool "title": "string", // Tiêu đề dễ hiểu cho Tool, dùng trong UI "readOnlyHint": "boolean", // Gợi ý Tool có chỉnh sửa môi trường không (mặc định: false) "destructiveHint": "boolean",// Gợi ý Tool có thể thực hiện cập nhật mang tính phá hủy không (mặc định: true, chỉ có ý nghĩa nếu readOnlyHint là false) "idempotentHint": "boolean", // Gợi ý việc gọi Tool nhiều lần với cùng đối số có gây thêm hiệu ứng không (mặc định: false, chỉ có ý nghĩa nếu readOnlyHint là false) "openWorldHint": "boolean" // Gợi ý Tool có tương tác với các thực thể bên ngoài không (mặc định: true) }
}

Ví dụ về định nghĩa Tool calculate_sum:

{ "name": "calculate_sum", "description": "Add two numbers together", "inputSchema": { "type": "object", "properties": { "a": { "type": "number" }, "b": { "type": "number" } }, "required": ["a", "b"] // Khai báo a và b là bắt buộc }, "annotations": { "title": "Calculate Sum", "readOnlyHint": true, // Phép cộng không thay đổi môi trường "openWorldHint": false // Không tương tác với bên ngoài }
}

Triển khai Tools trên Server:

Server MCP cần phải:

1. Định nghĩa danh sách các Tools có sẵn: Khi nhận yêu cầu tools/list, server sẽ trả về danh sách các định nghĩa Tool.
2. Xử lý việc gọi Tool: Khi nhận yêu cầu tools/call (bao gồm tên Tool và các đối số đầu vào), server sẽ:
   • Tìm Tool tương ứng.
   • Xác thực các đối số dựa trên inputSchema.
   • Thực thi logic của Tool.
   • Trả về kết quả (hoặc lỗi nếu có).

Sức mạnh của Tool Annotations

Annotations cung cấp metadata quý giá về hành vi của một Tool, giúp client và người dùng hiểu rõ hơn về Tool đó.

• Mục đích chính của Annotations:
  • Cung cấp thông tin cho giao diện người dùng (UX) mà không làm ảnh hưởng đến cách LLM hiểu Tool.
  • Giúp client phân loại và hiển thị Tools một cách phù hợp (ví dụ: cảnh báo nếu Tool có tính phá hủy).
  • Truyền tải thông tin về các tác dụng phụ tiềm ẩn.
  • Hỗ trợ việc xây dựng giao diện trực quan cho việc người dùng phê duyệt sử dụng Tool.

Xử lý lỗi trong Tools:

Khi một Tool gặp lỗi trong quá trình thực thi, việc báo lỗi phải được thực hiện một cách cẩn thận để LLM có thể hiểu và có thể phản ứng lại.

• Lỗi của Tool nên được báo cáo bên trong đối tượng kết quả (result object) của lệnh gọi tools/call, chứ không phải là một lỗi ở cấp độ giao thức MCP.

• Cách báo lỗi:

  • Đặt trường isError: true trong đối tượng kết quả.
  • Bao gồm chi tiết lỗi (ví dụ: thông báo lỗi) trong mảng content.

  // Ví dụ phản hồi khi Tool bị lỗi
  { "isError": true, "content": [ { "type": "text", "text": "Error: Could not connect to the specified API endpoint." } ]
  }
  

• Tại sao lại quan trọng? Cách tiếp cận này cho phép LLM "nhìn thấy" rằng một lỗi đã xảy ra, nội dung của lỗi, và có thể quyết định các bước tiếp theo (ví dụ: thử lại với tham số khác, thông báo cho người dùng, hoặc yêu cầu sự can thiệp của con người).

8. Khám phá và Cập nhật Tool:

MCP hỗ trợ việc khám phá Tool một cách dynamic:

• Client có thể gọi tools/list bất cứ lúc nào để lấy danh sách Tools mới nhất.
• Server có thể thông báo cho client khi danh sách Tools thay đổi thông qua một notification đặc biệt: notifications/tools/list_changed.
• Tools có thể được thêm vào hoặc gỡ bỏ khỏi server trong quá trình chạy.
• Định nghĩa của một Tool (ví dụ: description hoặc inputSchema) có thể được cập nhật, nhưng việc này cần được thực hiện cẩn thận để tránh phá vỡ các client đang phụ thuộc vào định nghĩa cũ.

References

• https://modelcontextprotocol.io/docs/concepts/architecture#python
• https://modelcontextprotocol.io/llms-full.txt