MCP 2026-07-28 Hướng dẫn chuyển đổi: Máy chủ không trạng thái

TL;DR: MCP 2026-07-28 loại bỏ phiên ở cấp giao thức và thủ tục bắt tay khởi tạo bắt buộc. Nhóm vận hành sản xuất nên tìm các phụ thuộc phiên ẩn, áp dụng siêu dữ liệu giao thức theo từng yêu cầu, triển khai Yêu cầu Nhiều vòng khứ hồi (MRTR), cập nhật chính sách gateway, và triển khai canary giao thức mới trước khi ngừng hành vi cũ.

Bản đặc tả Model Context Protocol phát hành ngày 28 tháng 7, 2026 giới thiệu thay đổi kiến trúc lớn nhất cho MCP kể từ khi hỗ trợ transport từ xa được bổ sung.

Giao thức giờ đây sử dụng lõi yêu cầu–phản hồi không trạng thái. Trao đổi bắt buộc initialize và notifications/initialized đã bị loại bỏ, Mcp-Session-Id đã bị gỡ, và mỗi yêu cầu mang theo thông tin giao thức cần thiết để xử lý.

Bản phát hành cũng giới thiệu Yêu cầu Nhiều vòng khứ hồi (MRTR), header định tuyến HTTP, phản hồi danh sách có thể cache, hành vi uỷ quyền nghiêm ngặt hơn, framework tiện ích mở rộng, và vòng đời ngừng hỗ trợ chính thức. Xem thông báo phát hành MCP 2026-07-28 chính thức và nhật ký thay đổi đặc tả đầy đủ để biết chi tiết cấp giao thức.

Những thay đổi này giúp máy chủ MCP từ xa dễ dàng mở rộng sau hạ tầng HTTP tiêu chuẩn. Chúng không tự động khiến ứng dụng hiện có trở nên không trạng thái.

Một máy chủ sản xuất vẫn có thể dựa vào workspace trong bộ nhớ, định tuyến dính, thông tin xác thực gắn với phiên, luồng sống lâu, hoặc tương tác do máy chủ khởi tạo. Hướng dẫn này tập trung vào việc tìm và thay thế các phụ thuộc đó.

Để có hướng dẫn triển khai mang tính nhập môn hơn, hãy đọc Cách tạo một MCP Server cho Claude Code trước khi bắt đầu di trú.

Ai cần di trú?

Mức độ nỗ lực phụ thuộc vào cách MCP được sử dụng trong hệ thống của bạn.

Máy chủ cục bộ không giữ trạng thái giữa các yêu cầu có thể chỉ cần nâng cấp SDK và kiểm thử khả năng tương thích.

Triển khai từ xa dùng phiên, OAuth, streaming, hoặc yêu cầu do máy chủ khởi tạo cần di trú theo giai đoạn.

MCP 2026-07-28 thay đổi gì?

1. Kiểm toán triển khai hiện có

Trước khi nâng cấp, hãy tìm trong client, server, gateway, và cấu hình triển khai các giả định giao thức cũ.

Mcp-Session-Id
initialize
notifications/initialized
sessionId
ctx.sessionId
extra.sessionId
sticky_session
sticky-session
elicitation/create
sampling/createMessage
roots/list
resources/subscribe
resources/unsubscribe
logging/setLevel
tasks/result
tasks/list
Last-Event-ID

Sau đó trả lời các câu hỏi sau:

1. Máy chủ có từ chối cuộc gọi cho đến khi hoàn tất khởi tạo không?
2. Một session ID có chọn người dùng, thông tin xác thực, workspace, hay cuộc hội thoại không?
3. Một instance máy chủ khác có thể tiếp tục quy trình công việc bắt đầu bởi instance đầu tiên không?
4. Load balancer có yêu cầu dính phiên không?
5. Một công cụ có thực hiện tác dụng phụ trước khi yêu cầu xác nhận không?
6. Gateway có phân tích body để xác định method hay tool không?
7. Thông tin xác thực OAuth có được lưu mà không kèm máy chủ uỷ quyền phát hành (issuer) của chúng không?
8. Client có phụ thuộc vào kết nối lại SSE hoặc phát lại thông điệp không?
9. Danh sách công cụ hay resource có thay đổi theo kết nối không?
10. Những tính năng bị ngừng hỗ trợ nào vẫn nhận traffic sản xuất?

Không gỡ Mcp-Session-Id cho đến khi bạn hiểu ứng dụng đang lưu gì phía sau nó.

Một máy chủ gỡ header này nhưng vẫn giữ trạng thái trong bộ nhớ cục bộ có thể hoạt động trong phát triển và lỗi ngắt quãng khi yêu cầu được phân phối qua nhiều instance.

2. Thay thế trạng thái phiên ẩn

MCP 2026-07-28 gỡ các phiên ở cấp giao thức, không phải trạng thái ứng dụng.

Trạng thái cần qua nhiều cuộc gọi nên dùng một trong ba mẫu.

Handle tường minh

Trả về handle do máy chủ cấp từ một công cụ và yêu cầu nó trong các cuộc gọi sau.

{
  "resultType": "complete",
  "content": [
    {
      "type": "text",
      "text": "Workspace created."
    }
  ],
  "structuredContent": {
    "workspaceHandle": "ws_7f93a2"
  }
}

Yêu cầu sau truyền handle như một tham số thông thường:

{
  "name": "update_workspace",
  "arguments": {
    "workspaceHandle": "ws_7f93a2",
    "status": "approved"
  }
}

Điều này làm cho phụ thuộc trở nên hiển thị trong hợp đồng công cụ và cho phép bất kỳ instance máy chủ tương thích nào xử lý yêu cầu.

Lưu trữ chia sẻ

Dùng cơ sở dữ liệu, cache phân tán, object store, hoặc hệ thống tác vụ bền bỉ khi:

• nhiều worker cần cùng trạng thái;
• quy trình phải sống sót qua khởi động lại;
• trạng thái quá lớn cho một handle;
• quy trình kéo dài hơn một yêu cầu;
• yêu cầu hành vi giao dịch hoặc sử dụng một lần.

requestState được bảo vệ

MRTR có thể trả về giá trị requestState mờ đục để client phản hồi lại khi retry yêu cầu gốc.

Vì giá trị đi qua client, hãy bảo vệ nó bằng HMAC hoặc mã hoá xác thực. Ràng buộc nó với chủ thể đã xác thực, thao tác gốc, tham số quan trọng, thời hạn, và một nonce khi cần chống replay.

Không bao giờ tin giá trị requestState chưa ký chỉ vì client trả lại nguyên vẹn.

3. Áp dụng yêu cầu tự chứa và khám phá

Yêu cầu MCP hiện đại bao gồm ngữ cảnh giao thức trong _meta.

Một cuộc gọi công cụ qua Streamable HTTP có thể trông như sau:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
Authorization: Bearer <token>
{
  "jsonrpc": "2.0",
  "id": "req-101",
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "query": "stateless MCP migration"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "2.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}

Máy chủ nhắm tới giao thức mới phải triển khai server/discover, quảng bá phiên bản được hỗ trợ, khả năng, và định danh máy chủ. Client có thể gọi trước một thao tác khác hoặc dùng để xác định có cần fallback cũ không.

Đọc server/discover documentation chính thức để biết hợp đồng phản hồi.

Thương lượng phiên bản SDK TypeScript

Chỉ nâng cấp SDK TypeScript không tự động chuyển client sang giao thức mới.

Client dùng SDK v2 phải bật rõ ràng:

const client = new Client(
  {
    name: "my-client",
    version: "1.0.0"
  },
  {
    versionNegotiation: {
      mode: "auto"
    }
  }
);

await client.connect(transport);

Ở chế độ tự động, SDK thăm dò bằng server/discover và có thể fallback sang luồng khởi tạo cũ khi gặp máy chủ kế thừa.

Nhóm vẫn dùng @modelcontextprotocol/sdk v1 nên trước tiên làm theo hướng dẫn di trú SDK TypeScript từ v1 lên v2 chính thức. Nhóm đã dùng v2 nên dùng hướng dẫn hỗ trợ giao thức 2026-07-28 riêng.

4. Thay thế yêu cầu do máy chủ khởi tạo bằng MRTR

Triển khai MCP trước đây có thể gửi các yêu cầu như elicitation/create, sampling/createMessage, hoặc roots/list từ máy chủ tới client.

Giao thức mới thay thế mô hình đó bằng Yêu cầu Nhiều vòng khứ hồi.

Luồng như sau:

1. Client gửi yêu cầu gốc.
2. Máy chủ trả về resultType: "input_required".
3. Client thu thập thông tin hoặc phê duyệt được yêu cầu.
4. Client retry thao tác gốc bằng một JSON-RPC ID mới.
5. Lần retry bao gồm inputResponses và requestState gốc.
6. Máy chủ hoàn tất yêu cầu hoặc bắt đầu vòng mới.

Phản hồi ví dụ:

{
  "jsonrpc": "2.0",
  "id": "delete-1",
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "confirm_delete": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Delete project project_123?",
          "requestedSchema": {
            "type": "object",
            "properties": {
              "confirmed": {
                "type": "boolean"
              }
            },
            "required": ["confirmed"]
          }
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

Client retry thao tác gốc:

{
  "jsonrpc": "2.0",
  "id": "delete-2",
  "method": "tools/call",
  "params": {
    "name": "delete_project",
    "arguments": {
      "projectId": "project_123"
    },
    "inputResponses": {
      "confirm_delete": {
        "action": "accept",
        "content": {
          "confirmed": true
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

Một triển khai MRTR sản xuất nên xác định:

• số vòng tối đa;
• thời hạn của request-state;
• hành vi huỷ và từ chối;
• kiểm tra hợp lệ schema phản hồi;
• kiểm tra uỷ quyền ở mỗi lần retry;
• bảo vệ chống replay;
• tính idempotent cho tác dụng phụ;
• hành vi khi client không hỗ trợ khả năng được yêu cầu.

Tránh hoàn tất mua hàng, xoá, trừ tín dụng, hoặc ghi ra ngoài trước khi trả input_required.

Dùng thao tác theo giai đoạn hoặc khoá idempotency để các lần retry không thể nhân đôi hành động. Xem đặc tả MRTR chính thức để biết mô hình tương tác đầy đủ.

5. Cập nhật gateway, cache, và uỷ quyền

Các thay đổi hạ tầng có liên quan chặt chẽ và nên được kiểm thử cùng nhau.

Xác thực header định tuyến MCP

Yêu cầu POST Streamable HTTP giờ bao gồm:

• MCP-Protocol-Version
• Mcp-Method
• Mcp-Name

Các header này cho phép gateway định tuyến, đo đạc, uỷ quyền, và giới hạn tốc mà không cần phân tích mọi body JSON.

Chúng có thể hỗ trợ các kiểm soát như:

• giới hạn tốc độ theo từng công cụ;
• chính sách riêng cho phương thức liệt kê và thực thi;
• pool worker chuyên biệt cho công cụ tốn kém;
• truy cập hạn chế cho thao tác rủi ro cao;
• số liệu độ trễ và lỗi theo công cụ;
• quy trách nhiệm chi phí hạ tầng.

Giá trị vẫn do client cung cấp. So sánh chúng với body JSON-RPC trước khi áp dụng chính sách.

Một yêu cầu không được phép khai báo công cụ rủi ro thấp trong Mcp-Name trong khi gọi công cụ khác trong body. Sai lệch giữa header và body nên bị từ chối và ghi log.

Dùng khoá cache nhận thức uỷ quyền

Giao thức mới thêm ttlMs và cacheScope cho các kết quả có thể cache bao gồm:

• tools/list
• prompts/list
• resources/list
• resources/templates/list
• resources/read

Khoá cache thông thường nên bao gồm:

protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version

Không tái sử dụng mục cache riêng tư giữa người dùng hoặc tenant chỉ vì TTL chưa hết hạn.

Sắp xếp công cụ quyết định được cũng quan trọng. Danh mục ổn định tránh miss cache không cần thiết và có thể cải thiện tái sử dụng prompt-cache của mô hình khi định nghĩa công cụ được chèn vào prompt.

Tăng cường xử lý issuer của OAuth

Trong quá trình di trú uỷ quyền:

• xác thực giá trị iss trả về với issuer được ghi nhận cho luồng;
• khoá thông tin xác thực client được lưu theo issuer;
• không bao giờ tái sử dụng thông tin xác thực với máy chủ uỷ quyền khác;
• đặt application_type phù hợp trong DCR;
• chuẩn bị tích hợp mới cho Client ID Metadata Documents.

Dynamic Client Registration vẫn khả dụng cho tương thích ngược, nhưng bị ngừng ưu tiên như phương thức đăng ký ưa dùng.

6. Di trú thông báo, Tasks, và tính năng ngừng hỗ trợ

Đường thông báo HTTP GET cũ và luồng resources/subscribe hoặc resources/unsubscribe đã được thay bằng subscriptions/listen.

Client mở một luồng phản hồi POST sống lâu và chọn tham gia các nhóm thông báo cần thiết. Thông báo tiến trình và log theo yêu cầu vẫn gắn với luồng phản hồi cho yêu cầu mà chúng mô tả.

Đối với triển khai nhiều instance, dùng bus sự kiện chia sẻ khi thông báo sinh ra ở một instance phải đến một đăng ký kết nối với instance khác.

Tiện ích mở rộng Tasks

Công việc dài hạn đã được chuyển khỏi core thử nghiệm sang:

io.modelcontextprotocol/tasks

Tiện ích mở rộng dùng:

• tasks/get để polling;
• tasks/update cho cập nhật từ client đến server;
• handle tác vụ bền bỉ;
• subscriptions/listen cho cập nhật đã opt-in.

Mẫu tasks/result và tasks/list cũ không nên được mang sang triển khai mới.

Tính năng bị ngừng hỗ trợ

Các tính năng sau bị ngừng hỗ trợ:

Chức năng bị ngừng hỗ trợ vẫn khả dụng trong cửa sổ ngừng hỗ trợ, nhưng triển khai mới không nên áp dụng. Chính sách vòng đời MCP cung cấp tối thiểu mười hai tháng ngừng hỗ trợ; không có nghĩa mọi tính năng đều có ngày gỡ bỏ xác nhận như nhau.

Xem sổ đăng ký tính năng bị ngừng hỗ trợ chính thức trước khi đặt hạn nghỉ hưu.

7. Triển khai di trú an toàn

Không thay đổi client, server, gateway, cache, và uỷ quyền trong một bản phát hành thiếu quan sát.

Thứ tự di trú khuyến nghị

1. Kiểm kê phiên bản giao thức, SDK, phiên, traffic SSE, client DCR, và phương thức lỗi thời.
2. Nâng cấp SDK môi trường không sản xuất.
3. Thêm server/discover và thương lượng phiên bản.
4. Thay thế phụ thuộc phiên ẩn.
5. Triển khai và bảo mật MRTR.
6. Thêm header định tuyến được xác thực và cache theo phạm vi.
7. Kiểm thử ranh giới issuer uỷ quyền.
8. Canary giao thức hiện đại song song đường cũ.
9. Chỉ nghỉ hưu hành vi cũ sau khi xem xét telemetry.

Khả năng tương thích trong giai đoạn canary

Modern client + modern server
→ Use MCP 2026-07-28

Modern client + legacy server
→ Probe and fall back when supported

Legacy client + dual-version server
→ Continue on the legacy path

Unsupported combination
→ Return a clear protocol-version error

Phát hành một đặc tả MCP mới không phải là công tắc cho toàn hệ sinh thái. Client, server, SDK, và nền tảng hosted sẽ di trú với tốc độ khác nhau.

Telemetry cần ghi

Các yêu cầu tools/call one-shot thành công là chưa đủ để đo di trú. Một quy trình lặp lại hết hạn, yêu cầu input không cần thiết, hoặc nhân đôi ghi ra ngoài vẫn là thất bại sản xuất.

CometAPI phù hợp với kiến trúc MCP như thế nào

MCP không thay thế API mô hình. Hai lớp giải quyết các vấn đề tích hợp khác nhau.

Kiến trúc sản xuất điển hình trông như sau:

Application or agent
        ↓
MCP clients and servers
Tools, resources, approvals, tasks
        ↓
Unified model API
GPT, Claude, Gemini, DeepSeek, and other models

MCP tiêu chuẩn hoá cách agent tương tác với công cụ và ngữ cảnh. MCP không tiêu chuẩn hoá giá mô hình, thông tin xác thực nhà cung cấp, endpoint suy luận, hoặc failover nhà cung cấp.

Sự phân tách này đặc biệt hữu ích khi di trú khỏi khả năng Sampling bị ngừng hỗ trợ. Nếu một máy chủ MCP hoặc agent tiêu thụ nó vẫn cần suy luận mô hình, ứng dụng có thể gọi API mô hình trực tiếp thay vì phụ thuộc vào luồng Sampling cũ của MCP.

Khi nào một cổng mô hình hợp nhất hữu ích

Cổng mô hình hợp nhất có thể giảm công việc vận hành khi:

• nhiều máy chủ MCP cần truy cập các nhà cung cấp mô hình khác nhau;
• các công cụ khác nhau cần mô hình khác nhau;
• đội muốn chuyển đổi mô hình mà không viết lại tích hợp đặc thù nhà cung cấp;
• thông tin xác thực, sử dụng, và tính phí cần được quản lý tập trung;
• truy cập mô hình nên độc lập với thay đổi transport MCP.

CometAPI cung cấp endpoint tương thích OpenAI có thể dùng làm lớp truy cập mô hình phía sau ứng dụng MCP. Điều này giữ logic nhà cung cấp mô hình tách biệt khỏi công cụ, resource, và điều phối tác vụ của MCP.

Ví dụ, một công cụ MCP có thể gọi mô hình qua cùng client tương thích OpenAI dùng ở nơi khác trong ứng dụng:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.COMETAPI_KEY,
  baseURL: "https://api.cometapi.com/v1"
});

export async function summarizeResource(content: string) {
  const response = await client.chat.completions.create({
    model: "your-selected-model",
    messages: [
      {
        role: "system",
        content: "Summarize the supplied resource clearly and concisely."
      },
      {
        role: "user",
        content
      }
    ]
  });

  return response.choices[0]?.message?.content ?? "";
}

Máy chủ MCP vẫn chịu trách nhiệm cho hợp đồng công cụ, uỷ quyền, trạng thái, và xử lý kết quả. Cổng mô hình xử lý lựa chọn mô hình, truy cập nhà cung cấp, và phản hồi suy luận.

Giữ các lớp này tách biệt mang lại hai lợi ích thực tế:

1. Client và server MCP có thể di trú sang giao thức mới mà không thay đổi lớp tích hợp mô hình.
2. Nhà cung cấp mô hình có thể được thay đổi mà không phải thiết kế lại công cụ MCP hoặc hành vi transport.

Để biết thêm chi tiết triển khai, xem CometAPI Quickstart, Tài liệu API, và hướng dẫn ứng dụng AI đa mô hình.

Danh sách kiểm tra di trú MCP 2026-07-28

Client

• Nâng cấp lên SDK tương thích.
• Bật thương lượng phiên bản hiện đại.
• Hỗ trợ server/discover.
• Bao gồm siêu dữ liệu giao thức trong mọi yêu cầu.
• Xử lý resultType.
• Hỗ trợ hoặc từ chối rõ ràng MRTR.
• Dùng JSON-RPC ID mới cho các lần retry.
• Bảo tồn và trả lại requestState.
• Xác thực issuer OAuth.
• Lưu trữ thông tin xác thực theo issuer.
• Tôn trọng gợi ý cache.
• Hỗ trợ subscriptions/listen khi cần.

Server

• Gỡ cổng khởi tạo cho yêu cầu hiện đại.
• Gỡ phụ thuộc vào Mcp-Session-Id.
• Triển khai server/discover.
• Thay thế trạng thái ẩn bằng handle hoặc lưu trữ chia sẻ.
• Trả về resultType.
• Thay yêu cầu do máy chủ khởi tạo bằng MRTR.
• Bảo vệ requestState.
• Xác thực mọi inputResponses.
• Thêm tính idempotent cho tác dụng phụ.
• Trả về danh sách quyết định được.
• Công bố gợi ý cache thận trọng.
• Di trú công việc dài hạn sang tiện ích mở rộng Tasks.

Gateway và hạ tầng

• Xác thực header yêu cầu MCP.
• So sánh header với body yêu cầu.
• Gỡ định tuyến dính không cần thiết.
• Kiểm thử yêu cầu qua nhiều instance.
• Phân vùng cache theo ranh giới uỷ quyền.
• Thêm bus thông báo chia sẻ khi cần.
• Theo dõi traffic kế thừa và lỗi thời.
• Duy trì đường rollback trong giai đoạn canary.

Câu hỏi thường gặp

MCP 2026-07-28 là gì?

MCP 2026-07-28 là đặc tả Model Context Protocol phát hành ngày 28 tháng 7, 2026. Nó giới thiệu lõi giao thức không trạng thái, Yêu cầu Nhiều vòng khứ hồi, header định tuyến HTTP, kết quả có thể cache, thay đổi uỷ quyền, tiện ích mở rộng, và vòng đời ngừng hỗ trợ chính thức.

Mcp-Session-Id có bị gỡ không?

Có. Giao thức Streamable HTTP mới không còn dùng Mcp-Session-Id.

Ứng dụng vẫn có thể bảo tồn trạng thái qua handle tường minh, lưu trữ chia sẻ, tác vụ bền bỉ, hoặc giá trị request-state được bảo vệ.

Thủ tục bắt tay khởi tạo MCP có bị gỡ không?

Có. Yêu cầu hiện đại không còn bắt buộc trao đổi initialize và notifications/initialized.

Máy chủ phải triển khai server/discover, mặc dù client không cần gọi trước mọi thao tác.

MCP không trạng thái có nghĩa công cụ không thể bảo tồn trạng thái?

Không. Không trạng thái đề cập đến lớp giao thức.

Một công cụ vẫn có thể lưu trạng thái, nhưng xử lý yêu cầu không nên phụ thuộc vào affinity transport ẩn hoặc một tiến trình máy chủ cụ thể.

MRTR là gì?

Yêu cầu Nhiều vòng khứ hồi cho phép máy chủ yêu cầu thêm đầu vào từ client hoặc người dùng mà không gửi yêu cầu do máy chủ khởi tạo qua kết nối hai chiều mở liên tục.

Máy chủ trả về input_required, và client retry thao tác gốc với phản hồi được yêu cầu.

HTTP+SSE có bị gỡ ngay không?

Không. Nó bị ngừng hỗ trợ thay vì gỡ ngay.

Máy chủ mới nên dùng Streamable HTTP, trong khi hệ thống hiện có nên đo lường và di trú traffic HTTP+SSE còn lại.

Client SDK TypeScript v2 có tự động dùng MCP 2026-07-28 không?

Không. SDK v2 cần cấu hình thương lượng phiên bản rõ ràng để dùng giao thức hiện đại.

Dùng thương lượng tự động khi client phải hoạt động với cả máy chủ hiện đại và kế thừa.

Khuyến nghị cuối cùng

MCP 2026-07-28 giúp hạ tầng MCP từ xa dễ mở rộng, định tuyến, cache, và quan sát. Rủi ro di trú chính không chỉ là gỡ một header hay thủ tục bắt tay. Đó là trạng thái ứng dụng ẩn và logic tương tác có thể vẫn phụ thuộc vào chúng.

Trước khi triển khai giao thức mới:

Tìm mọi phụ thuộc vào khởi tạo và Mcp-Session-Id.

1. Chuyển trạng thái bắt buộc vào handle tường minh hoặc lưu trữ chia sẻ.
2. Triển khai MRTR với hết hạn, bảo vệ chống replay, và tính idempotent.
3. Xác thực header MCP với body JSON-RPC.
4. Phân vùng cache theo tenant và phạm vi uỷ quyền.
5. Củng cố xác thực issuer của OAuth.
6. Đo các phương thức bị ngừng hỗ trợ và traffic transport kế thừa.
7. Canary đường giao thức hiện đại và cũ trước khi nghỉ hưu.

Hãy coi di trú là thay đổi hạ tầng thay vì nâng cấp SDK thường lệ.

Khi lớp MCP đã không trạng thái và quan sát được, hãy giữ truy cập mô hình phía sau một giao diện riêng. Điều này cho phép giao thức công cụ và lớp nhà cung cấp mô hình phát triển độc lập.