GitHub MCP Server Và MCP Stateless: Hướng Dẫn Migration

Logo GitHub. Nguồn: GitHub, Inc., qua Wikimedia Commons, public domain.

GitHub MCP Server đã sẵn sàng cho lần thay đổi nền tảng lớn nhất của MCP

GitHub vừa xác nhận GitHub MCP Server đã hỗ trợ đặc tả Model Context Protocol dự kiến phát hành chính thức ngày 28/7/2026. Tâm điểm của bản đặc tả mới là một lõi giao thức stateless: request không còn phụ thuộc vào phiên do transport duy trì, bước khởi tạo initialize bị loại bỏ, header Mcp-Session-Id không còn là điều kiện để các lời gọi tiếp theo hoạt động và mỗi request phải mang đủ thông tin để một server instance bất kỳ có thể xử lý.

Đây là thay đổi quan trọng đối với Vibe Coding và hệ sinh thái AI agent, bởi MCP đang dần trở thành lớp kết nối chung giữa model với repository, issue tracker, database, cloud, trình duyệt và công cụ nội bộ. Trong giai đoạn đầu, phần lớn demo MCP chạy cục bộ qua stdio hoặc một server đơn. Khi doanh nghiệp bắt đầu đưa MCP lên hạ tầng nhiều instance, những yêu cầu như sticky session, shared session store và routing theo kết nối trở thành chi phí vận hành rõ rệt.

GitHub cho biết việc chuyển GitHub MCP Server sang đặc tả mới đã cho phép loại bỏ Redis session, bỏ database write tại bước khởi tạo, bỏ database read khỏi mỗi lần gọi và tránh cơ chế deep packet inspection từng payload chỉ để lấy dữ liệu phục vụ logging hoặc secret scanning. Thay vào đó, gateway có thể đọc các header chuẩn như Mcp-Method và Mcp-Name, còn SDK chính thức xử lý phần protocol bên dưới.

Với developer, đây không chỉ là tin “server đã cập nhật”. Nó là tín hiệu cần rà lại toàn bộ cách xây remote MCP server: trạng thái nằm ở đâu, client nhận capability bằng cách nào, long-running task được quản lý ra sao, OAuth/OIDC có đúng issuer không, tool schema có tương thích JSON Schema 2020-12 không và observability có theo được một tool call xuyên qua gateway, server cùng dịch vụ hạ nguồn hay không.

Ảnh chụp một repository GitHub trong năm 2026 với tệp mã nguồn, commit và thông tin nhánh. — Giao diện repository GitHub năm 2026. Nguồn: Wikimedia Commons.

MCP stateless thay đổi điều gì ở cấp giao thức?

Không còn bắt buộc handshake `initialize`

Trong đặc tả MCP 2025-11-25, client thường bắt đầu bằng lời gọi initialize. Server trả về protocol version, capability và một Mcp-Session-Id; các request sau phải mang session ID này. Cách làm phù hợp với kết nối dài, nhưng remote deployment phải biết request nào thuộc session nào và route chúng về đúng instance hoặc dùng một kho session dùng chung.

Ở đặc tả 2026-07-28, protocol version, client information và capability cần thiết được truyền trong metadata của request. Client có thể dùng server/discover khi muốn đọc capability trước. Một lời gọi tool trở thành request tự chứa, có thể tới bất kỳ instance khỏe mạnh nào sau load balancer.

Stateless ở đây là stateless tại tầng protocol, không phải cấm ứng dụng giữ trạng thái. Nếu workflow cần giỏ hàng, browser session, job hoặc workspace, server có thể tạo một handle rõ ràng như browser_id, job_id hay workspace_id, rồi yêu cầu model truyền lại handle trong các tool call sau. Trạng thái trở thành dữ liệu nghiệp vụ minh bạch thay vì metadata transport bị ẩn.

Server-to-client request chuyển sang mô hình nhiều round trip

Một server stateless vẫn cần hỏi người dùng giữa tác vụ, chẳng hạn xin xác nhận trước khi xóa file. Đặc tả mới giới hạn server-initiated request trong thời gian server đang xử lý một client request. Khi cần input, server trả InputRequiredResult kèm requestState. Client thu thập câu trả lời rồi gửi lại request ban đầu với inputResponses và state đã nhận.

Nhờ vậy, không cần giữ một SSE stream mở lâu. Request tiếp theo có thể vào instance khác vì toàn bộ dữ liệu cần thiết nằm trong payload. Với agent chạy trên hạ tầng autoscaling, đây là khác biệt rất lớn về độ bền, timeout và khả năng phục hồi.

Request trở nên routable, cacheable và traceable

Streamable HTTP mới yêu cầu các header như Mcp-Method và Mcp-Name. Gateway có thể định tuyến, áp rate limit, logging hoặc secret scanning dựa trên loại thao tác mà không phải parse toàn bộ JSON-RPC body. Kết quả đọc danh sách tool và resource có thêm ttlMs cùng cacheScope, giúp client biết dữ liệu có thể cache bao lâu và có an toàn khi dùng chung giữa người dùng hay không.

Đặc tả cũng chuẩn hóa W3C Trace Context trong metadata, gồm traceparent, tracestate và baggage. Một trace có thể bắt đầu từ host, đi qua MCP client, gateway, MCP server, GitHub API và dịch vụ nội bộ rồi xuất hiện thành một cây span thống nhất trong hệ thống tương thích OpenTelemetry.

Sơ đồ kiến trúc load balancer minh họa cách MCP stateless cho phép phân phối request tới nhiều server instance. — Sơ đồ load balancer. Ảnh: Alesker Abdullayev MWA1/Wikimedia Commons, CC BY-SA 3.0.

Ba thay đổi cụ thể trong GitHub MCP Server

1. GitHub loại bỏ Redis sessions

GitHub cho biết database write tại initialize đã biến mất và database read trên mỗi request cũng được loại bỏ. Trước đây, session store giúp nhiều instance biết client đã khởi tạo capability gì và session thuộc về ai. Khi mỗi request tự chứa đủ metadata, việc đọc Redis ở đường nóng không còn cần thiết.

Lợi ích trực tiếp là giảm latency, giảm một dependency production và thu nhỏ failure domain. Nếu Redis chậm hoặc mất kết nối, tool call không còn phải thất bại chỉ vì tầng protocol cần tra session. Doanh nghiệp cũng bớt phải thiết kế TTL, cleanup, replication và disaster recovery cho dữ liệu session vốn không phải trạng thái nghiệp vụ thực sự.

Tuy nhiên, không nên hiểu rằng mọi state đều biến mất. GitHub vẫn phải giữ token, quyền, audit, rate limit và trạng thái nghiệp vụ cần thiết ở đúng lớp. Bài học cho custom MCP server là phân loại rõ: state nào chỉ tồn tại vì protocol cũ, state nào thuộc workflow và cần handle rõ ràng.

Logo Redis. Ảnh: Liran.amir/Wikimedia Commons, CC BY-SA 4.0.

2. Không còn deep packet inspection cho mọi request

GitHub cần đọc một số thuộc tính của request để logging và secret scanning. Ở kiến trúc cũ, tầng trước SDK có thể phải parse payload để biết tool nào đang được gọi. Đặc tả mới đưa method và name lên header chuẩn, nên proxy hoặc middleware đọc được thông tin định tuyến mà không cần can thiệp sâu vào body.

Thay đổi này giúp tách trách nhiệm rõ hơn. Gateway quản lý route, quota và policy theo header; SDK xử lý JSON-RPC và validation; tool implementation xử lý nghiệp vụ. Việc giảm parser trùng lặp cũng giảm nguy cơ gateway và SDK hiểu payload khác nhau.

3. Nâng cấp URL elicitation nhưng vẫn tương thích client cũ

GitHub MCP Server dùng URL elicitation trong bản stdio để người dùng đăng nhập dễ hơn. Với protocol mới, mỗi bước tương tác trở thành một HTTP request riêng. GitHub sử dụng wrapper từ Go SDK để cùng một implementation có thể làm việc với client cũ và client mới.

Đây là điểm đáng chú ý cho team đang migration. Không nhất thiết phải fork hai code path hoàn toàn. Nếu Tier 1 SDK cung cấp compatibility layer, server có thể nâng SDK, chạy conformance test và triển khai canary trước khi bỏ hỗ trợ phiên bản cũ theo lộ trình rõ ràng.

Logo Go. Nguồn: The Go Authors, qua Wikimedia Commons.

Vì sao GitHub nói người dùng hiện tại chưa cần làm gì ngay?

GitHub cho biết tất cả Tier 1 SDK đã giữ backward compatibility và đã phát hành beta support cho đặc tả mới. GitHub MCP Server dùng Go SDK chính thức, nên người đang kết nối bằng client được hỗ trợ không phải thay cấu hình chỉ để duy trì khả năng hoạt động.

“Không cần làm gì” chỉ áp dụng cho khả năng tiếp tục sử dụng GitHub MCP Server. Nếu bạn tự xây client, server, proxy hoặc middleware, vẫn cần audit. Các integration dựa trực tiếp vào initialize, Mcp-Session-Id, SSE dài hạn, error code cũ hoặc experimental Tasks API có thể bị ảnh hưởng.

Team cũng nên kiểm tra dependency pinning. Một SDK beta hỗ trợ spec mới không có nghĩa mọi host đã bật protocol version mới theo mặc định. Trong giai đoạn chuyển tiếp, log protocol version thực tế và kiểm thử cả client cũ lẫn client mới sẽ an toàn hơn giả định.

Conformance suite biến AI-assisted development thành workflow có thể kiểm chứng

Đặc tả mới đi kèm conformance test chính thức. GitHub gợi ý cho Copilot quyền đọc codebase, conformance suite, draft spec documentation và một Tier 1 SDK implementation. Agent có thể so sánh implementation với scenario chuẩn, tạo patch và chạy test thay vì chỉ đọc tài liệu rồi đoán.

Đây là một ứng dụng Vibe Coding đáng chú ý: AI hỗ trợ migration protocol, nhưng kết quả được khóa bằng test máy đọc được. Prompt tốt không chỉ là “nâng MCP lên bản mới”; nó cần nói rõ phiên bản đích, SDK tham chiếu, conformance suite, compatibility matrix và tiêu chí không làm hỏng client cũ.

Một workflow thực tế có thể gồm:

Chạy test hiện tại và lưu baseline.
Nâng SDK trong branch riêng.
Loại bỏ dependency session ở tầng protocol.
Thêm header routing và validation.
Migration elicitation cùng long-running task.
Chạy conformance suite cho cả protocol cũ và mới nếu có compatibility mode.
Thực hiện load test qua nhiều instance không sticky session.
Canary rollout, theo dõi error rate, latency và fallback.

Ảnh chụp Visual Studio Code với terminal và mã nguồn trong một quy trình phát triển phần mềm. — Visual Studio Code với terminal. Ảnh: Cycling2/Wikimedia Commons.

MCP Apps, Tasks và Extensions thay đổi cách xây AI product

MCP Apps đưa giao diện tương tác vào server

MCP Apps cho phép server cung cấp HTML UI để host render trong sandboxed iframe. Tool khai báo template trước để host có thể prefetch, cache và security review. Hành động từ UI vẫn đi qua JSON-RPC, audit và consent path giống tool call thông thường.

Điều này mở ra một lớp trải nghiệm mới cho Vibe Coding. Thay vì agent chỉ trả JSON hoặc markdown, một GitHub tool có thể cung cấp giao diện review pull request, chọn issue, so sánh diff hoặc xác nhận deployment. Nhưng UI từ server phải được sandbox, giới hạn quyền và kiểm tra nguồn tài nguyên để tránh trở thành đường vòng vượt consent.

Tasks chuyển từ core thử nghiệm thành extension

Long-running task không biến mất, nhưng lifecycle đổi. Server có thể trả task handle từ tools/call; client quản lý bằng tasks/get, tasks/update và tasks/cancel. tasks/list bị loại bỏ vì khó scope an toàn khi không còn session.

Nếu server từng dùng experimental Tasks API 2025-11-25, đây là migration bắt buộc. Không nên chỉ đổi tên method. Team cần thiết kế lại ownership, authorization, retention, cancellation, idempotency và cách user tìm lại task khi protocol không cung cấp list toàn cục.

Authorization hardening: phần dễ bị bỏ qua nhưng có rủi ro cao nhất

MCP kết nối một client với nhiều server, nên OAuth mix-up attack đáng lo hơn mô hình web truyền thống. Bản mới yêu cầu client xác minh tham số iss trong authorization response theo RFC 9207. Authorization server nên bắt đầu cung cấp issuer ngay cả khi client hiện tại chưa bắt buộc từ chối response thiếu trường này.

Client cũng khai báo application_type khi Dynamic Client Registration, giúp hệ thống không mặc định nhầm desktop hoặc CLI client thành web app rồi từ chối localhost redirect URI. Credentials phải gắn với authorization server đã cấp; nếu resource chuyển issuer, client cần đăng ký lại thay vì tái sử dụng credential cũ.

Với GitHub MCP Server, nguyên tắc quyền tối thiểu vẫn quan trọng hơn việc kết nối thành công. Repository read, issue write, pull request write, Actions và code security là các toolset có mức ảnh hưởng khác nhau. Server chính thức hỗ trợ --read-only, allow-list toolsets và chọn tool riêng. Một agent nghiên cứu repository không cần quyền merge hoặc chỉnh workflow.

Sơ đồ luồng OAuth minh họa các bước ủy quyền được MCP 2026-07-28 siết chặt. — Sơ đồ OAuth. Ảnh: FoxGray/Wikimedia Commons, CC BY-SA 3.0.

Cấu hình GitHub MCP Server an toàn cho workflow Vibe Coding

Bắt đầu ở read-only

Trong giai đoạn khám phá, hãy chạy server với --read-only. Agent vẫn có thể đọc file, issue, pull request và metadata phù hợp nhưng write tool bị loại bỏ ngay cả khi đã được liệt kê. Cách này giảm hậu quả của prompt injection từ issue hoặc comment công khai.

Chỉ bật toolset cần dùng

GitHub MCP Server cho phép cấu hình --toolsets hoặc biến môi trường GITHUB_TOOLSETS. Default toolsets gồm context, repos, issues, pull requests và users. Với workflow CI, có thể thêm Actions; với security triage, thêm code security. Không nên bật all chỉ vì tiện.

docker run -i --rm \
  -e GITHUB_PERSONAL_ACCESS_TOKEN="$GITHUB_TOKEN" \
  -e GITHUB_TOOLSETS="context,repos,issues,pull_requests" \
  -e GITHUB_READ_ONLY=1 \
  ghcr.io/github/github-mcp-server

Ưu tiên GitHub App hoặc fine-grained token

Token nên giới hạn repository, organization và permission. Không dùng personal access token cổ điển có quyền rộng cho agent chạy trên máy chia sẻ hoặc môi trường CI. Nếu cần write, tách một credential riêng cho workflow đã được phê duyệt.

Bật lockdown mode khi đọc nội dung công khai

Lockdown mode giới hạn nội dung được surface từ public repository theo quyền push của tác giả đối với một số tool. Đây là lớp giảm rủi ro prompt injection từ comment hoặc issue của người ngoài. Nó không thay thế review, nhưng giảm lượng dữ liệu không đáng tin được đưa vào context agent.

Logo Docker. Nguồn: Docker, qua Wikimedia Commons.

Checklist migration cho custom MCP server trước ngày 28/7

Hạng mục	Cần kiểm tra	Rủi ro nếu bỏ qua
Protocol version	Client và server negotiate đúng 2026-07-28 hoặc compatibility mode	Request bị từ chối hoặc capability sai
Initialize/session	Không phụ thuộc `initialize` và `Mcp-Session-Id`	Không scale ngang, client mới lỗi
Application state	Dùng explicit handle cho job/browser/workspace	Mất state hoặc rò state giữa người dùng
Multi round trip	Hỗ trợ `InputRequiredResult`, `requestState`, retry	Elicitation và approval bị treo
Headers	Kiểm tra `Mcp-Method`, `Mcp-Name` khớp body	Routing và policy sai
Caching	Tôn trọng `ttlMs` và `cacheScope`	Dùng danh sách tool lỗi thời hoặc lộ dữ liệu
Tracing	Truyền W3C Trace Context qua SDK và downstream	Không điều tra được lỗi agent
Tasks	Migration sang extension lifecycle mới	Long-running task không tương thích
OAuth/OIDC	Issuer validation, application type, credential binding	Mix-up attack hoặc redirect lỗi
Tool schema	Validation JSON Schema 2020-12, giới hạn độ sâu và external ref	Schema DoS hoặc output sai
Error code	Không hard-code resource missing là `-32002`	Client xử lý lỗi sai
Conformance	Chạy suite chính thức trong CI	Regression khó phát hiện

Quy trình rollout production đề xuất

Giai đoạn 1: Inventory dependency

Liệt kê host, SDK, transport, proxy, auth server, session store, task store và monitoring. Tìm nơi code kiểm tra session ID, initialize, SSE hoặc error code cũ.

Giai đoạn 2: Dual-version test

Chạy server mới với client cũ và client mới. Ghi protocol version, tool call success rate, latency, số lần elicitation retry và lỗi auth. Không chỉ kiểm tra happy path; cần test timeout, instance restart và request chuyển instance.

Giai đoạn 3: Load test không sticky session

Đặt nhiều instance sau round-robin load balancer, tắt sticky route và xác minh tool call liên tiếp vẫn hoạt động. Với stateful workflow, kiểm tra handle được scope theo tenant, không thể đoán và có TTL hợp lý.

Giai đoạn 4: Canary và rollback

Cho một tỷ lệ nhỏ traffic dùng protocol mới. Giữ khả năng quay lại SDK hoặc server version cũ. Dashboard cần phân tách lỗi theo protocol version, client, tool, authorization issuer và server instance.

Giai đoạn 5: Thu hồi session infrastructure cũ

Chỉ xóa Redis/session table khi log xác nhận không còn client phụ thuộc. Dọn credential, metric, alert và runbook liên quan; tránh để hạ tầng cũ tiếp tục tiêu chi phí hoặc tạo một đường truy cập không được giám sát.

Giao diện cấp quyền OAuth minh họa bước người dùng xem và chấp thuận quyền truy cập của MCP client. — Giao diện cấp quyền OAuth. Nguồn: Wikimedia Commons.

Ý nghĩa đối với developer, AI Creator và doanh nghiệp

Developer có thể xây server đơn giản hơn

Remote MCP server không còn cần session store chỉ để phục vụ protocol. Một service stateless dễ deploy trên serverless, container autoscaling hoặc Kubernetes. Tool call cũng dễ trace và rate-limit hơn nhờ header chuẩn.

AI Creator và solopreneur giảm chi phí vận hành integration

Người xây nhiều agent nhỏ có thể tránh Redis, sticky session và connection lifecycle phức tạp. Tuy nhiên, không nên biến sự đơn giản thành cấp quyền rộng. GitHub MCP Server cần được giới hạn repository và toolset theo từng workflow.

Doanh nghiệp có nền tảng governance rõ hơn

Extensions, conformance suite, feature lifecycle và deprecation window giúp team lập kế hoạch nâng cấp. W3C tracing, OAuth hardening và tool schema đầy đủ tạo điều kiện đưa MCP vào hệ thống có audit, policy và observability thay vì chỉ chạy demo trong IDE.

MCP stateless cũng phù hợp với xu hướng multi-agent. Nhiều agent có thể gọi cùng server qua hạ tầng phân tán mà không bị buộc vào một session transport. State nghiệp vụ trở thành handle có thể kiểm soát, truyền giao và kiểm toán.

Những điều không nên hiểu sai

Stateless không có nghĩa không lưu dữ liệu: application state vẫn tồn tại, nhưng phải được thiết kế rõ.
Không cần migration ngay không có nghĩa custom server an toàn: compatibility của SDK không sửa code tự viết phụ thuộc session cũ.
Header mới không thay thế authorization: Mcp-Method chỉ giúp route và policy, không chứng minh người gọi có quyền.
Conformance test không thay thế security test: server đúng spec vẫn có thể cấp tool quá rộng hoặc xử lý input không an toàn.
MCP Apps không phải iframe tùy ý: UI cần sandbox, template declaration và consent path.
AI migration không nên tự merge: agent có thể viết patch và test, nhưng thay đổi protocol/auth cần review con người.

Kết luận

GitHub MCP Server hỗ trợ MCP 2026-07-28 trước ngày phát hành chính thức là một mốc quan trọng cho hệ sinh thái AI coding. GitHub đã chứng minh thay đổi stateless không chỉ đẹp trên tài liệu: nó có thể loại bỏ Redis session, giảm database access, bỏ deep packet inspection và làm elicitation tương thích qua SDK.

Với team đang dùng GitHub MCP Server chính thức qua client và SDK được hỗ trợ, khả năng tương thích ngược giúp quá trình chuyển đổi tương đối nhẹ. Với người tự xây MCP server, đây là lúc cần audit kỹ: session, task, routing, cache, trace, OAuth, schema và conformance.

Giá trị lớn nhất của đặc tả mới là đưa MCP gần hơn với cách hạ tầng web hiện đại được vận hành: request tự chứa, scale ngang, cache có quy tắc, trace xuyên hệ thống và capability mở rộng qua extension. Điều đó khiến MCP phù hợp hơn với production agent, không chỉ Vibe Coding demo.

Nguồn tham khảo chính: GitHub Changelog, MCP 2026-07-28 Release Candidate, repository GitHub MCP Server và MCP TypeScript SDK.

Xem thêm trên NextGZ: GitHub Copilot cloud agent tích hợp Linear, Claude Opus 5 cho coding agent và chuyên mục Vibe Coding.