Khoá MCP Advanced Topics của Anthropic: học sampling và transport, rồi tự kiểm lại theo đặc tả

Ngày 19/04/2026, một issue được mở trên kho Python SDK của MCP. Nội dung khá ngắn: server Streamable HTTP đã cấu hình stateless_http=True mà vẫn chấp nhận GET /mcp, lệch so với đặc tả. Lỗi không lớn, nhưng cho thấy ngay thư viện chính thức cũng có chỗ chưa làm đúng đặc tả.

Đó cũng là cách nên đọc khoá “Model Context Protocol: Advanced Topics” của Anthropic, đăng trên Anthropic Academy (nền tảng Skilljar). Khoá học xoay quanh giao tiếp server-client, cơ chế transport và những điều cần lưu ý khi triển khai production. Trang khoá học chỉ ghi © 2026, không nêu ngày phát hành hay thời lượng.

Với một FDE, đây là những câu hỏi thật ở chỗ khách hàng. Server MCP chạy ở đâu? Ai giữ key của mô hình? Chuyện gì xảy ra khi bạn đặt nó sau load balancer? Khoá học trả lời được phần lớn. Phần còn lại bạn phải tự làm theo đặc tả.

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

Khoá học yêu cầu biết trước Python, lập trình async, JSON/HTTP và kiến thức cơ bản về SSE. Nếu bạn chưa quen viết code async trong Python, hãy học phần đó trước. Nếu không, các bài về transport sẽ khó theo vì bạn phải vừa học giao thức vừa học cú pháp.

Thứ tự hợp lý là học xong khoá, rồi đọc hai trang Sampling và Transports của đặc tả bản 2025-06-18, sau đó mới mở issue SDK nói trên. Học theo thứ tự này, bạn đi từ hiểu khái niệm sang đọc quy tắc bắt buộc, rồi tới chỗ code thật còn chưa khớp với quy tắc. Ba ý dưới đây đáng giữ lại nhất.

Server mượn mô hình của client

Theo khoá học, sampling là cơ chế để MCP server yêu cầu gọi mô hình ngôn ngữ thông qua client đang kết nối với nó. Đặc tả MCP nói rõ cái lợi: server dùng được khả năng AI mà không cần API key riêng, còn client giữ quyền kiểm soát truy cập, chọn mô hình và cấp quyền.

Server cũng không chỉ định cứng tên mô hình. Nó cho client biết mình coi trọng chi phí, tốc độ hay chất lượng của mô hình đến đâu, kèm vài gợi ý tên mô hình. Đặc tả nhấn mạnh rằng gợi ý chỉ để tham khảo, quyết định cuối cùng thuộc về client.

Thử hình dung bạn dựng một server tóm tắt ticket hỗ trợ cho khách hàng. Nhờ sampling, bạn không phải xin khách cấp thêm một key riêng cho server, và đội bảo mật của họ vẫn tự quyết dùng mô hình nào.

Nhưng đặc tả có kèm một khuyến nghị: lúc nào cũng nên có một người được quyền từ chối yêu cầu sampling. Nếu bạn là người viết client, bước duyệt này là việc của bạn.

stdout chỉ dành cho message MCP

Đặc tả định nghĩa hai transport chuẩn là stdio và Streamable HTTP, và khuyến nghị client hỗ trợ stdio khi có thể. Với stdio có một quy tắc bắt buộc: server không được ghi ra stdout bất cứ thứ gì không phải message MCP hợp lệ. Log phải đi qua stderr.

Lỗi này rất dễ mắc khi bạn tự viết server. Chỉ cần một dòng print để debug là luồng message bị lẫn rác, và client nhận được dữ liệu nó không hiểu. Vì thế, việc đầu tiên nên làm khi khởi tạo server là cấu hình logger, trước khi viết bất kỳ tool nào:

import logging, sys

logging.basicConfig(stream=sys.stderr, level=logging.INFO)
log = logging.getLogger("mcp-server")
log.info("server khởi động")  # đi ra stderr, không chạm vào stdout

Kết quả mong đợi: mọi dòng log hiện ở stderr, còn stdout chỉ chứa message MCP. Muốn chắc chắn, hãy cố ý thêm một lệnh print("debug") rồi xem client phản ứng thế nào, để lần sau bạn nhận ra triệu chứng ngay.

State quyết định cách bạn mở rộng

Phần giá trị nhất của khoá học là dạy chọn transport theo yêu cầu triển khai, chức năng cần có và giới hạn mở rộng, kèm khi nào nên dùng stateless HTTP để mở rộng ngang sau load balancer.

Theo đặc tả, session trong Streamable HTTP là tuỳ chọn. Server có thể cấp ID qua header Mcp-Session-Id khi khởi tạo, và từ đó client phải gửi lại ID này ở mọi request.

Thử hình dung khách hàng chạy ba instance sau một load balancer. Instance A cấp session và giữ state, nhưng request tiếp theo lại rơi vào instance B, vốn không biết gì về session đó. Chạy stateless thì tránh được chuyện này, nhưng không miễn phí.

Khoá học chỉ ra rằng các cờ cấu hình ảnh hưởng tới request do server khởi tạo và tới khả năng streaming. Sampling chính là server chủ động gửi yêu cầu, nên bạn cần kiểm tra nó còn chạy được trong cấu hình đã chọn hay không.

Có hai quy tắc nữa nên đưa thẳng vào bộ test, mỗi quy tắc một lệnh riêng để khi request bị từ chối, bạn biết chắc quy tắc nào đã chặn nó. Thay địa chỉ dưới đây bằng server của bạn.

Lệnh đầu tiên kiểm tra chỗ lệch mà issue SDK nêu ra: gửi GET vào server đang chạy stateless_http=True, không kèm header nào khác.

curl -i -X GET http://localhost:8000/mcp

Issue trên đề xuất server stateless trả về mã 405 cho request này. Nếu server của bạn vẫn nhận request bình thường, hãy ghi lại và chặn nó ở tầng của bạn, thay vì tin rằng thư viện đã xử lý đúng.

Lệnh thứ hai kiểm tra quy tắc bắt buộc về header Origin, thứ server Streamable HTTP phải xác thực trên mọi kết nối để chống tấn công DNS rebinding. Dùng POST để không lẫn với phép thử GET ở trên:

curl -i -X POST http://localhost:8000/mcp \
  -H "Origin: http://evil.example" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"ping"}'

Kết quả bạn cần thấy là request bị từ chối. Sau đó chạy lại đúng lệnh này nhưng bỏ dòng Origin: nếu chỉ bản có Origin lạ bị chặn, bạn biết phần kiểm tra Origin đang hoạt động chứ không phải request bị lỗi vì lý do khác.

Biến khoá học thành bằng chứng trong CV

Đừng chỉ ghi chứng chỉ hoàn thành khoá học vào CV; hãy kèm một repo nhỏ chứng minh bạn đã làm thật.

Dựng một server chạy được cả stdio lẫn Streamable HTTP, có log ra stderr, có test từ chối Origin lạ, có cấu hình stateless chạy sau hai instance, và một client có bước duyệt sampling.

Trong README, viết một đoạn ngắn giải thích vì sao bạn chọn stateful hay stateless.

Khi đọc mô tả công việc FDE có nhắc tới MCP, agent integration hay production deployment, đó chính là đoạn bạn nên mang vào phỏng vấn. Hãy chuẩn bị kể lại các đánh đổi, chẳng hạn vì sao session ID làm khó load balancer, chứ không chỉ liệt kê API bạn đã gọi.

Nhiều người sẽ học xong khoá này. Số người từng tự gửi GET /mcp vào server của mình để xem nó trả về gì sẽ ít hơn nhiều.