Đặc tả MCP – Các thay đổi trong phiên bản 2025-06-18

• Bản cập nhật mới của đặc tả MCP tập trung vào siêu dữ liệu có cấu trúc và quản lý ngữ cảnh. Mục tiêu là cải thiện khả năng mở rộng và tăng cường khả năng tương tác giữa nhiều hệ thống
• Các trường dữ liệu mới được bổ sung, đồng thời các trường bắt buộc hiện có được định nghĩa cụ thể hơn. Việc phân tầng cấu trúc siêu dữ liệu giúp hỗ trợ các cách mở rộng riêng theo từng hệ thống
• Đưa ra các quy tắc rõ ràng cho theo dõi ngữ cảnh và cập nhật thuộc tính, nhấn mạnh khả năng quản lý thông tin trạng thái nhất quán hơn so với trước đây
• Các quy trình quản lý quyền hạn và xác thực dữ liệu được nêu rõ trong đặc tả giao thức. Một số trường mới được thêm vào có tính đến khả năng tương thích với các phiên bản giao thức trong tương lai
• Hỗ trợ tích hợp đa nền tảng: cung cấp nền tảng để trao đổi dữ liệu ngữ cảnh theo cách nhất quán ngay cả trong nhiều nền tảng AI và môi trường dịch vụ đám mây

---

• MCP(Model Context Protocol) là giao thức để trao đổi siêu dữ liệu ngữ cảnh giữa nhiều hệ thống AI khác nhau như mô hình máy học hoặc mô hình ngôn ngữ lớn

Major changes

1. Loại bỏ hỗ trợ JSON-RPC batching (PR #416)
2. Bổ sung hỗ trợ structured tool output (PR #371)
3. Phân loại máy chủ MCP là OAuth resource server, đồng thời bổ sung protected resource metadata để cải thiện khả năng tìm máy chủ Authorization liên kết (PR #338)
4. MCP client bắt buộc triển khai Resource Indicator của RFC 8707 (nhằm ngăn máy chủ độc hại lấy access token) (PR #734)
5. Làm rõ security considerations và best practices trong đặc tả Authorization, đồng thời bổ sung riêng trang hướng dẫn bảo mật
6. Bổ sung tính năng Elicitation (yêu cầu truy vấn), cho phép máy chủ yêu cầu thêm thông tin từ người dùng (PR #382)
7. Bổ sung hỗ trợ Resource Links, cho phép bao gồm liên kết tài nguyên trong kết quả gọi công cụ (PR #603)
8. Khi thương lượng phiên bản giao thức, bắt buộc header MCP-Protocol-Version trên HTTP (PR #548)
9. Thay đổi SHOULD thành MUST trong Lifecycle Operation (tham khảo)

---

Other schema changes

1. Trường _meta được bổ sung vào nhiều kiểu interface hơn (PR #710), nêu rõ cách sử dụng phù hợp
2. Bổ sung trường context vào CompletionRequest, có thể bao gồm các biến đã được diễn giải trước đó (PR #598)
3. Bổ sung trường title để hiển thị thân thiện với người dùng, tách biệt với định danh dùng cho chương trình (name dùng làm định danh mã, title dùng để hiển thị) (PR #663)

[kernel00]

Bình luận trên Hacker News hơi đáng tiếc nhỉ. Có vẻ họ chỉ nhìn mỗi stdio, trong khi giờ các remote MCP server hay các registry làm trung gian cho chúng đang mọc lên như nấm....

[GN⁺]

Ý kiến trên Hacker News

• Điều lớn nhất tôi học được từ làn sóng MCP (Machine Context Protocol) là trong phát triển phần mềm backend, thực ra không nhất thiết phải dùng MCP. Có những điểm không phù hợp về mặt kiến trúc. Đặc biệt trong môi trường như Elixir thì lại càng như vậy. Nếu mỗi API lại có một server riêng, thì tức là với 500 API bạn sẽ phải chạy 500 microservice. Chỉ sau khi tự dùng thử 20 loại MCP server tôi mới nhận ra rằng, rốt cuộc MCP cũng chỉ là lớp vỏ bọc cho function calling. Mỗi API chỉ cần được tạo thành một module riêng chứ không cần là một server. Cũng chẳng cần chạy theo đặc tả MCP mới nhất, hay phải cập nhật hàng trăm microservice mỗi khi đặc tả thay đổi. Kết luận là đây chỉ là sự phức tạp không cần thiết
  • Trừ khi client kết nối thẳng đến từng microservice mà không đi qua gateway hay BFF, còn không thì chỉ cần đặt MCP ở phía trước toàn bộ dịch vụ và phơi bày chức năng như các cách làm sẵn có như API, GraphQL, RPC là được. Về bản chất nó giống như một giao diện chuyên biệt cho LLM. Tool call dựa trên đặc tả OpenAPI cũng hoàn toàn dùng được. Dù sao thì việc bắt tất cả microservice chỉ giao tiếp với nhau bằng MCP là một hình dung quá mức
  • Tôi chỉ xem MCP như một giải pháp tích hợp kiểu plugin, cho phép function call mà không tốn chi phí API như Claude. Nếu bạn đang dùng API và không có nhu cầu gấp, thì đây không phải lựa chọn cần thiết
  • Thực ra tôi nghĩ MCP là một giao thức tiêu chuẩn để kết nối client và model. Nó không chỉ là cái vỏ bọc cho tool calling
  • Đúng vậy, đặt một MCP server cho mỗi API là kiến trúc không thể mở rộng. Nếu dùng thứ như nango.dev thì một server có thể bao phủ hơn 400 API. Nó cũng cung cấp xử lý xác thực, khả năng quan sát, và nhiều giao diện khác nhau để tool call trực tiếp. (Nói trước là tôi là nhà sáng lập)
  • Tôi còn đi xa hơn và cho rằng cả văn hóa ép LLM xuất JSON vốn đã là điều ngớ ngẩn. Người ta tốn quá nhiều thời gian và công sức để ép nó vào một định dạng khó chịu mà bản thân LLM cũng không thật sự thích. Một DSL dạng văn bản với ràng buộc nhiều hơn lại là phương án tốt hơn hẳn. Hồi thời GPT 3.5, chỉ cần đưa vài ví dụ đơn giản trong prompt là đã có thể khiến nó xuất ra DSL tiếng Anh khá đáng tin cậy. Thế mà ngay cả các model mới nhất đôi khi vẫn được cảnh báo là sẽ bỏ qua một phần của JSON schema. Cảm giác như cố đóng cái chốt tròn vào lỗ vuông, tôi mong mọi người đừng cố ép nữa
• Tôi thật sự rất vui vì giờ đã có một con đường đơn giản để đi tới các MCP server đã được xác thực. Tôi muốn bày tỏ lời cảm ơn chân thành tới cộng đồng MCP và đội ngũ Anthropic
  • Tôi không hiểu lắm vì sao lại cần MCP server. Nếu agent muốn làm RPC thì cứ dùng RPC là đủ chẳng phải sao
• Tôi thấy khá lạ khi đặc tả cốt lõi lại được viết bằng TypeScript thay vì OpenAPI hay thứ gì khác. Chắc hẳn có lý do hợp lý, nhưng vẫn tạo cảm giác bất ngờ
  • Tôi tò mò vì sao điều này lại gây ngạc nhiên. Tôi cũng dùng TypeScript rất nhiều, nhưng chưa từng nghĩ theo góc độ đó, nên muốn biết đã có quyết định nào ở phía thiết kế ngôn ngữ hay không
• Việc đưa vào WWW-Authenticate challenge là một tin quá đáng mừng. Giờ bức tranh đã rõ ràng hơn: MCP server có thể chuyển client sang OAuth flow của nhà cung cấp tài nguyên, rồi chỉ cần nhận header Authorization: Bearer ... là xong
• Tôi nghĩ đây <i>phần lớn</i> đúng là sự phức tạp không cần thiết, nhưng việc thiếu khả năng batch execution thì hơi đáng tiếc. Việc triển khai kiểu “làm xong toàn bộ đống việc này rồi trả kết quả trong một lần” từng rất thú vị. Tất nhiên client cũng có thể tự gom phản hồi batch lại, nhưng dù vậy nó vẫn khá hay
  • Đúng vậy. Tính năng batch của JSON-RPC thực sự từng khiến tôi có cảm giác kiểu “wow, cái này hay đấy”. Việc nó bị loại khỏi đặc tả thì đáng tiếc, nhưng cuối cùng tôi cũng hiểu vì nó chỉ làm tăng thêm độ phức tạp
• Tôi nghĩ elicitation (xử lý prompt dựa trên suy luận) là thành quả lớn. Một trong những MCP server tôi thích nhất là SSH server do chính tôi tự làm. Nó có thể tự động hóa 90% công việc quản trị server. Tôi quản lý xác thực bằng file cấu hình, nhưng mỗi khi cần kết nối đến một server mới lại phải tự sửa thủ công nên hơi bất tiện
  • Trong trường hợp này có thể dùng thứ như fabfile.org. Nếu đó là kiểu trao đổi mà không nhất thiết phải đưa LLM vào thì theo tôi cứ để riêng tư sẽ tốt hơn
• Trong vài ngày qua tôi đã nghịch thử làm một dataset wrapper bằng MCP

1. Tôi nghĩ đây là một trong những thử nghiệm thú vị nhất trong lĩnh vực LLM. Dĩ nhiên có thể làm chuyện tương tự bằng API & tool call hiện có, nhưng việc chỉ cần đưa cho một người bạn không rành công nghệ một URL MCP cho Claude rồi họ có thể bấm vài cái là dùng được đã khiến tôi rất ấn tượng
2. Tôi đang dùng csharp SDK, mà tính năng xác thực hiện vẫn chỉ nằm trên branch nên còn ở giai đoạn rất sơ khai. 95% thời gian tích hợp MCP của tôi dồn cả vào việc triển khai xác thực (nếu không phải build cục bộ thì đây là bắt buộc). Có lẽ khi tài liệu đầy đủ hơn thì sẽ khá hơn, nhưng hiện tại vẫn là một quá trình khá tốn công
3. Một vấn đề nữa là thiếu log cho phía developer. Tôi muốn Claude trên web (không phải desktop) hiển thị log request/response ở chế độ developer để biết nó đang gửi nhận gì và lỗi phát sinh ở đâu. Tôi đã loay hoay rất lâu với vấn đề làm mới xác thực, rồi mãi sau mới phát hiện là mình đang log nhầm endpoint. Nếu có logging MCP tốt hơn thì chuyện đó chỉ mất vài phút là xong. Trên desktop và MCP inspector thì lại hoạt động tốt
4. Điều khiến tôi băn khoăn nhất là xử lý tác vụ dài hạn. Dataset tôi cung cấp là nhiều tài liệu PDF. Có vẻ Claude không thể tự xử lý PDF (nếu ai biết cách thì mong chỉ giúp!), nên hiện tôi đưa chúng qua gemini để chuyển thành văn bản rồi mới chuyển vào MCP. Với tài liệu đơn giản thì ổn, nhưng tài liệu dài sẽ mất khá nhiều thời gian xử lý. Hiện tại tôi chỉ gửi thông báo kiểu “đang xử lý, vui lòng thử lại sau”. Có progress API, nhưng vì phải giữ kết nối liên tục với server (trên Cloudflare thì sau một thời gian sẽ bị ngắt) nên có vẻ tính thực tiễn bị hạn chế. Sẽ rất tuyệt nếu có cách để LLM quay lại kiểm tra sau x giây, làm việc khác trong lúc chờ, rồi được “tạm dừng thực thi” cho đến khi bộ đếm thời gian kết thúc. Hiện giờ nếu giữ kết nối thì LLM chỉ có thể đứng chờ mà không làm gì, còn nếu trả về kèm job ID thì phản hồi thường không đầy đủ và bị mất toàn bộ ngữ cảnh. Tôi nghĩ đây có thể là trở ngại lớn với những tác vụ cần hơn 10 phút

• Tác vụ chạy dài vẫn là chủ đề đang được thảo luận công khai. Theo tôi biết thì MCP cũng có ý định giải quyết việc này trong tương lai. Có nhiều đề xuất đang được đưa ra, và vì không phải lúc nào cũng biết trước tác vụ sẽ kéo dài, nên chỉ tách riêng long-running API thôi cũng không phải lời giải. Tôi cũng có một đề xuất nhằm giải quyết việc này theo hướng tích hợp liên kết thảo luận
• Tôi rất vui khi thấy đặc tả MCP được cải thiện nhanh chóng. Mỗi lần có bản phát hành mới, tôi lại thấy một điểm từng khiến tôi tiếc nuối trong quá trình tích hợp MCP được lấp đầy dần
• Tôi thấy khá thú vị khi thay đổi trong đặc tả chỉ cần đúng một lần phê duyệt là có thể được hợp nhất
• Tôi không rõ MCP thực sự giải quyết vấn đề gì. Cá nhân tôi chỉ nghĩ đến vai trò của nó khi cần prototype thật nhanh trên laptop. Nếu làm một chương trình cục bộ, tôi muốn kiểm soát bộ công cụ mà LLM có thể truy cập chặt chẽ hơn nhiều. Ví dụ nghĩ đến một MCP server cho Google Calendar, tôi không thấy MCP tiết kiệm được bao nhiêu thời gian. Tôi hoàn toàn có thể tự dùng chính API đó, và vì vẫn phải nói rõ cho LLM biết khi nào, bằng cách nào cần gọi Google Calendar, nên tôi không muốn ủy quyền cho bên thứ ba. Ngoài ra, việc tùy tiện khởi chạy một process trong môi trường của tôi chỉ vì MCP được viết bằng ngôn ngữ nào đó cũng là điều đáng ngại. Phía tôi dùng Python, mà nếu phải yêu cầu người dùng cài thêm TypeScript runtime thì sẽ rất phiền. Nếu wrapper MCP có lỗ hổng thì tôi cũng lo về bảo mật. Trong môi trường server thì việc biện minh cho chuyện đó lại càng khó hơn. Với việc gọi qua các máy khác nhau mà không cần biết chi tiết triển khai, RPC vốn đã là một cách rất tốt rồi. MCP tạo cảm giác chỉ đang chồng thêm middleware đầy tính áp đặt và thêm vấn đề bảo mật lên trên đó
  • Điều tôi không hiểu là vì sao tất cả những MCP tôi từng thấy đến giờ đều dựa trên command thay vì dùng giao diện HTTP. Nếu là HTTP thì chỉ cần chạy một server là cả tổ chức có thể dùng chung, không cần mỗi người tự thiết lập toolchain riêng
  • Khác với cách làm truyền thống nơi backend áp đặt một luồng cố định, ưu điểm của MCP là để chính LLM tự thực hiện orchestration. Ví dụ khi tìm kiếm trên web, nó có thể tự sửa lại truy vấn và thử lại cho đến khi tìm được thông tin mong muốn. Khi giải các vấn đề đặc thù bằng CLI, nó cũng có thể tận dụng nhiều công cụ theo đúng thứ tự thích hợp. Đây là kiểu điều phối mà luồng cố định không làm được
  • Điều MCP giải quyết là từ góc nhìn lấy LLM làm trung tâm, nó giúp kết nối agent với tool và nhiều chức năng khác qua một giao thức chuẩn hóa
  • Tôi cũng rất đồng cảm với nhận xét này. Dùng thực tế sẽ thấy nó rất chậm. Tôi đã nghỉ việc từ 2 năm trước để làm client LLM mà đến giờ vẫn chưa tích hợp được Google Calendar. Dù vậy, từ góc độ người dùng, MCP vẫn có ích ở chỗ nó có thể lấp những khoảng trống tạm thời kiểu này. Tôi nhớ câu chuyện ngày xưa là 3 hàng đầu trên màn hình chính của iPhone thì khá giống nhau, nhưng hàng cuối cùng thì mỗi người lại hoàn toàn khác. Tôi có cảm giác trong tương lai, các bộ phận IT và đội phát triển vẫn sẽ tiếp tục tự làm các MCP server phù hợp với công việc của riêng họ