Khoá MCP của DeepLearning.AI và Anthropic: học nhanh, rồi tự viết lại theo spec mới

Ngày 25/11/2024, Anthropic công bố MCP như một chuẩn mới để nối trợ lý AI với nơi dữ liệu thật sự nằm. Chưa đầy sáu tháng sau, ngày 19/05/2025, DeepLearning.AI ra mắt khoá học ngắn “MCP: Build Rich-Context AI Apps with Anthropic”. Từ đó tới nay, giao thức đã có bản spec 2026-07-28 với những thay đổi ở tận lõi.

Nghe như một điểm trừ, nhưng chính khoảng lệch đó khiến khoá học có ích cho FDE. Phần lớn công việc ở site khách hàng là nối model với hệ thống sẵn có của họ: ticket, tài liệu, database. MCP sinh ra để giải đúng bài toán đó, và cách học tốt nhất là xem video rồi tự viết lại từng phần theo spec hiện hành.

Ai dạy, dạy những gì?

Khoá do DeepLearning.AI làm cùng Anthropic, người giảng là Elie Schoppik. Trang khoá học ghi trình độ Intermediate, 11 bài video, tổng thời lượng khoảng hai tiếng hoặc ít hơn.

Bạn chỉ cần quen Python và hiểu cơ bản về prompting cũng như cách xây ứng dụng LLM. Danh sách bài có phần về kiến trúc nhiều client, mỗi client một kết nối, phần thêm prompt và resource cho server, và phần tạo và deploy remote server.

Các phần này khớp với những bước của một engagement thật: hiểu vấn đề, dựng prototype, nối vào hệ thống khách hàng, rồi đưa lên môi trường dùng chung.

Mỗi client một kết nối: vì sao điều đó quyết định cách debug?

Theo tài liệu kiến trúc chính thức của MCP, mỗi client giữ một kết nối riêng với server tương ứng của nó. Nghe thì đơn giản, nhưng nó quyết định cách bạn tìm lỗi.

Thử hình dung một công ty logistics muốn có trợ lý tra cứu được hệ thống ticket nội bộ và kho tài liệu quy trình. Đó là hai server. Host của bạn sẽ có hai client với hai kết nối tách rời.

Khi kho tài liệu bị timeout, chỉ một kết nối hỏng, phần tra ticket vẫn chạy. Khi khách hàng báo lỗi, việc đầu tiên là xác định kết nối nào gặp sự cố.

Các bài viết client trong khoá là chỗ nên tự làm lại bằng tay. Nếu chỉ chạy code mẫu, bạn sẽ không biết vòng đời của kết nối nằm ở đâu.

Tool, resource, prompt là ba câu hỏi khi làm discovery

Ngoài tool, khoá có riêng bài “Adding Prompt and Resource Features” để server cung cấp thêm prompt và resource. Với FDE, cách chia này cũng là cách chia nhỏ yêu cầu của khách hàng.

Quay lại công ty logistics. Tìm ticket theo mã đơn là một thao tác model gọi khi cần, nên làm thành tool. Bộ tài liệu quy trình xử lý hàng hỏng là dữ liệu để model đọc, nên làm thành resource. Mẫu “tóm tắt sự cố cho quản lý ca” mà nhân viên dùng mỗi ngày nên làm thành prompt.

Để tự kiểm tra, hãy che cột giữa của bảng dưới đây và tự xếp bốn yêu cầu giả định của cùng công ty logistics, rồi mới so đáp án.

Yêu cầu của khách hàng	Loại	Câu hỏi giúp quyết định
Tạo ticket mới khi kho báo hàng hỏng	Tool	Model có cần thực hiện một thao tác không?
Bảng quy định đóng gói hàng dễ vỡ	Resource	Đây có phải dữ liệu chỉ để đọc không?
Mẫu báo cáo cuối ca gửi quản lý	Prompt	Người dùng có lặp lại đúng mẫu này mỗi ngày không?
Tra trạng thái đơn theo mã vận đơn	Tool	Kết quả có phụ thuộc vào tham số model truyền vào không?

Hai lỗi hay gặp khi làm bài tập này cũng đáng nhớ. Một là biến mọi thứ thành tool, kể cả tài liệu chỉ cần đọc, khiến model phải đoán khi nào nên gọi. Hai là nhét mẫu báo cáo vào system prompt của host thay vì để server cung cấp nó như một prompt, nên khách hàng không tự sửa được mẫu của mình.

Ở buổi discovery đầu tiên, bạn có thể ghi danh sách việc khách hàng muốn làm và xếp mỗi dòng vào một trong ba cột này. Khi xếp xong, bản thiết kế server gần như đã có.

Từ laptop lên server dùng chung

Khoá có phần tạo và deploy remote server. Tài liệu spec hiện hành nhắc tới transport stdio khi bàn về logging, và Streamable HTTP khi bàn về việc bỏ session.

Ở site khách hàng, bản prototype chạy stdio trên laptop của bạn thường đủ để demo. Khi cả đội vận hành cần dùng, server phải chạy remote, chẳng hạn qua Streamable HTTP. Lúc đó các câu hỏi về xác thực, mạng nội bộ và người chịu trách nhiệm vận hành mới bắt đầu, nên hãy hỏi những chuyện này từ sớm.

Làm lại những gì bằng tay?

Theo tài liệu chính thức, spec 2026-07-28 biến MCP thành giao thức stateless: bỏ session cấp giao thức cùng header Mcp-Session-Id, bỏ cả bước bắt tay initialize, để mỗi request tự mang phiên bản giao thức và capability. Sampling và logging qua giao thức cũng bị deprecate.

Trang bài học không có bài riêng nào về sampling, session hay logging, nên đừng mặc định code mẫu dựa vào chúng. Nhưng code bạn tự viết thêm, hoặc code cũ ở dự án khách hàng, thì có thể. Các tính năng này vẫn chạy trong thời gian deprecate, chỉ là không nên thêm vào code mới.

Thử áp vào server tra ticket của công ty logistics. Giả sử bạn viết tool “tóm tắt ticket” theo kiểu server nhờ client gọi model qua sampling. Spec mới khuyên gọi thẳng API của nhà cung cấp LLM; khi viết lại, một cách làm hợp lý là để tool chỉ trả dữ liệu ticket và để host tự gọi model tóm tắt.

Chuyện stateless cũng cần rà tương tự. Nếu server của bạn nhớ “ticket đang xem” giữa hai lần gọi, spec mới yêu cầu dùng handle tường minh truyền qua tham số tool, chẳng hạn truyền mã đơn vào mọi lời gọi. Log thì ghi ra stderr với stdio, hoặc dùng OpenTelemetry.

Học theo thứ tự nào, và ai nên học?

Hãy đọc trang giới thiệu và trang kiến trúc trên modelcontextprotocol.io trước. Sau đó xem khoá học từ đầu đến cuối, rồi tắt video, tự viết lại client và remote server, và đối chiếu từng chỗ với changelog spec 2026-07-28.

Khoá hợp với kỹ sư đã gọi API của LLM nhưng chưa từng nối model với hệ thống bên ngoài. Nếu bạn đã viết MCP server cho production, có thể bỏ qua video và chỉ đọc changelog của spec.

Biến bài tập thành bằng chứng khi xin việc

Xem hết 11 video chỉ cho thấy bạn đã học. Người phỏng vấn FDE sẽ chú ý hơn tới một repo GitHub có remote server chạy Streamable HTTP, kèm README ghi rõ phiên bản spec và lý do bạn chọn tool, resource hay prompt cho từng năng lực.

Khi đọc JD của các vị trí FDE, hãy để ý những chỗ nhắc tới MCP hoặc tích hợp với hệ thống khách hàng, rồi mang đúng repo đó vào buổi phỏng vấn.

Hiểu kiến trúc thì xem video là đủ. Nhưng chỉ khi tự viết lại theo spec mới, bạn mới thấy được những gì đã thay đổi.