MCP 2026-07-28 คู่มือการย้าย: เซิร์ฟเวอร์แบบไร้สถานะ

TL;DR: MCP 2026-07-28 ยกเลิกเซสชันในระดับโปรโตคอลและการจับมือเริ่มต้นที่บังคับ ทีมโปรดักชันควรค้นหาการพึ่งพาเซสชันที่ซ่อนอยู่ ปรับใช้เมทาดาตาโปรโตคอลต่อคำขอ ดำเนินการ Multi Round-Trip Requests ปรับนโยบายเกตเวย์ และทำแคนารีโปรโตคอลใหม่ก่อนเลิกใช้พฤติกรรมแบบเดิม

สเปก Model Context Protocol ที่ออกเมื่อวันที่ 28 กรกฎาคม 2026 นำเสนอการเปลี่ยนแปลงสถาปัตยกรรมครั้งใหญ่ที่สุดของ MCP นับตั้งแต่มีการเพิ่มการรองรับ remote transport

โปรโตคอลตอนนี้ใช้แกนกลางแบบไร้สถานะในรูปแบบคำขอ-คำตอบ ข้อมูลแลกเปลี่ยน initialize และ notifications/initialized ที่เคยบังคับถูกยกเลิก Mcp-Session-Id ถูกถอดออก และแต่ละคำขอจะพกข้อมูลโปรโตคอลที่จำเป็นต่อการประมวลผลมาด้วย

รุ่นนี้ยังเพิ่ม Multi Round-Trip Requests เฮดเดอร์สำหรับการทำเส้นทาง HTTP การตอบกลับแบบรายการที่แคชได้ พฤติกรรมการอนุญาตที่เข้มงวดขึ้น เฟรมเวิร์กส่วนขยาย และวัฏจักรการเลิกใช้อย่างเป็นทางการ ดู ประกาศเผยแพร่ MCP 2026-07-28 อย่างเป็นทางการ และ บันทึกการเปลี่ยนแปลงสเปกฉบับสมบูรณ์ สำหรับรายละเอียดในระดับโปรโตคอล

การเปลี่ยนแปลงเหล่านี้ทำให้เซิร์ฟเวอร์ MCP แบบรีโมตปรับขนาดได้ง่ายขึ้นหลังโครงสร้างพื้นฐาน HTTP มาตรฐาน แต่ไม่ได้ทำให้แอปพลิเคชันที่มีอยู่กลายเป็นไร้สถานะโดยอัตโนมัติ

ในสภาพโปรดักชัน เซิร์ฟเวอร์อาจยังพึ่งพาเวิร์กสเปซในหน่วยความจำ การรูตแบบ sticky ครับเดนเชียลที่ผูกกับเซสชัน สตรีมแบบยาว หรือปฏิสัมพันธ์ที่เริ่มโดยเซิร์ฟเวอร์ คู่มือนี้มุ่งเน้นที่การค้นหาและแทนที่การพึ่งพาเหล่านั้น

สำหรับบทนำเชิงปฏิบัติ ดู วิธีสร้าง MCP Server สำหรับ Claude Code ก่อนเริ่มย้าย

ใครต้องย้ายเวอร์ชัน?

ระดับความยากขึ้นอยู่กับการใช้งาน MCP ในระบบของคุณ

เซิร์ฟเวอร์โลคัลที่ไม่เก็บสถานะข้ามคำขออาจต้องการแค่อัปเกรด SDK และทดสอบความเข้ากันได้

การดีพลอยรีโมตที่ใช้เซสชัน OAuth การสตรีม หรือคำขอที่เริ่มจากเซิร์ฟเวอร์ ต้องการการย้ายเป็นช่วงๆ

มีอะไรเปลี่ยนใน MCP 2026-07-28?

1. ตรวจสอบการใช้งานที่มีอยู่

ก่อนอัปเกรด ค้นหาในไคลเอนต์ เซิร์ฟเวอร์ เกตเวย์ และคอนฟิกดีพลอยสำหรับสมมติฐานโปรโตคอลแบบเก่า

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

จากนั้นตอบคำถามต่อไปนี้:

1. เซิร์ฟเวอร์ปฏิเสธการเรียกจนกว่าจะ initialize เสร็จหรือไม่?
2. session ID ใช้เลือกผู้ใช้ ครับเดนเชียล เวิร์กสเปซ หรือบทสนทนาหรือไม่?
3. อินสแตนซ์เซิร์ฟเวอร์อื่นสามารถทำต่อจากเวิร์กโฟลว์ที่อินสแตนซ์แรกเริ่มไว้ได้หรือไม่?
4. ตัวโหลดบาลานเซอร์ต้องใช้ session affinity หรือไม่?
5. เครื่องมือทำผลข้างเคียงก่อนขอคอนเฟิร์มหรือไม่?
6. เกตเวย์แยก body เพื่อระบุเมธอดหรือทูลหรือไม่?
7. เก็บ OAuth credentials โดยไม่มีข้อมูล authorization server ที่ออกให้หรือไม่?
8. ไคลเอนต์พึ่งพา SSE reconnection หรือการส่งข้อความซ้ำหรือไม่?
9. รายการเครื่องมือหรือทรัพยากรแตกต่างกันตามคอนเนกชันหรือไม่?
10. ฟีเจอร์ที่เลิกใช้ใดบ้างยังมีทราฟฟิกโปรดักชัน?

อย่าถอด Mcp-Session-Id ออกจนกว่าจะเข้าใจว่ามีการเก็บอะไรไว้หลังมันในแอปพลิเคชัน

เซิร์ฟเวอร์ที่ถอดเฮดเดอร์นี้ออกแต่ยังคงสถานะไว้ในหน่วยความจำโลคัลอาจใช้งานได้ระหว่างพัฒนา แต่ล้มเหลวเป็นครั้งคราวเมื่อคำขอกระจายไปยังหลายอินสแตนซ์

2. แทนที่สถานะเซสชันที่ซ่อนอยู่

MCP 2026-07-28 ยกเลิกเซสชันระดับโปรโตคอล ไม่ใช่สถานะแอปพลิเคชัน

สถานะที่ต้องใช้ข้ามการเรียกควรใช้หนึ่งในสามแพทเทิร์นนี้

แฮนเดิลแบบชัดเจน

คืนแฮนเดิลที่สร้างโดยเซิร์ฟเวอร์จากทูลหนึ่ง แล้วต้องใช้ในคำเรียกถัดไป

{
  "resultType": "complete",
  "content": [
    {
      "type": "text",
      "text": "สร้างเวิร์กสเปซแล้ว"
    }
  ],
  "structuredContent": {
    "workspaceHandle": "ws_7f93a2"
  }
}

คำขอภายหลังจะส่งแฮนเดิลเป็นอาร์กิวเมนต์ปกติ:

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

วิธีนี้ทำให้การพึ่งพาปรากฏชัดในสัญญาของทูล และให้เซิร์ฟเวอร์ใดๆ ที่เข้ากันได้ประมวลผลคำขอได้

สตอเรจที่แชร์

ใช้ฐานข้อมูล แคชกระจาย ออบเจ็กต์สโตร์ หรือระบบงานที่ทนทานเมื่อ:

• คนงานหลายตัวต้องใช้สถานะเดียวกัน
• เวิร์กโฟลว์ต้องอยู่รอดจากการรีสตาร์ต
• สถานะใหญ่เกินกว่าจะเป็นแฮนเดิล
• เวิร์กโฟลว์นานเกินคำขอเดียว
• ต้องการพฤติกรรมแบบทรานแซกชันหรือใช้ครั้งเดียว

requestState ที่ได้รับการป้องกัน

MRTR สามารถส่งคืนค่า requestState แบบทึบที่ไคลเอนต์สะท้อนคืนเมื่อรีไทรคำขอเดิม

เนื่องจากค่านี้ผ่านไคลเอนต์ ควรป้องกันด้วย HMAC หรือการเข้ารหัสที่พิสูจน์ความถูกต้อง ผูกมันเข้ากับ principal ที่ยืนยันตัวตน เมธอดเดิม พารามิเตอร์สำคัญ เวลา expiration และ nonce เมื่อต้องการการป้องกันการเล่นซ้ำ

อย่าเชื่อถือค่า requestState ที่ไม่มีลายเซ็นเพียงเพราะไคลเอนต์ส่งคืนมาแบบไม่เปลี่ยน

3. ใช้คำขอแบบพึ่งพาตนเองและ Discovery

คำขอ MCP สมัยใหม่มีบริบทโปรโตคอลอยู่ใน _meta

คำเรียกทูลผ่าน Streamable HTTP อาจมีหน้าตาแบบนี้:

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": "การย้าย MCP แบบไร้สถานะ"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "2.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}

เซิร์ฟเวอร์ที่รองรับโปรโตคอลใหม่ต้องมี server/discover ซึ่งโฆษณาเวอร์ชันที่รองรับ ความสามารถ และเอกลักษณ์ของเซิร์ฟเวอร์ ไคลเอนต์อาจเรียกก่อนปฏิบัติการอื่น หรือใช้เพื่อดูว่าต้องถอยกลับแบบเดิมหรือไม่

อ่านเอกสาร server/discover documentation สำหรับสัญญาการตอบกลับ

การเจรจาเวอร์ชันใน TypeScript SDK

การอัปเกรด TypeScript SDK อย่างเดียวไม่ได้ทำให้ไคลเอนต์สลับไปใช้โปรโตคอลใหม่โดยอัตโนมัติ

ไคลเอนต์ที่ใช้ SDK v2 ต้องระบุให้ชัดเจน:

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

await client.connect(transport);

ในโหมดอัตโนมัติ SDK จะสำรวจด้วย server/discover และสามารถถอยกลับไปสู่โฟลว์ initialize แบบเก่าเมื่อเจอเซิร์ฟเวอร์รุ่นเดิม

ทีมที่ยังใช้ @modelcontextprotocol/sdk v1 ควรทำตาม แนวทางย้าย TypeScript SDK จาก v1 เป็น v2 ก่อน ทีมที่ใช้ v2 แล้วควรดู คู่มือรองรับโปรโตคอล 2026-07-28 แยกต่างหาก

4. แทนที่คำขอที่เริ่มโดยเซิร์ฟเวอร์ด้วย MRTR

การใช้งาน MCP ก่อนหน้าสามารถส่งคำขอเช่น elicitation/create sampling/createMessage หรือ roots/list จากเซิร์ฟเวอร์ไปยังไคลเอนต์ได้

โปรโตคอลใหม่แทนโมเดลนั้นด้วย Multi Round-Trip Requests

โฟลว์คือ:

1. ไคลเอนต์ส่งคำขอต้นฉบับ
2. เซิร์ฟเวอร์ส่งกลับ resultType: "input_required"
3. ไคลเอนต์รวบรวมข้อมูลหรือการอนุมัติที่ร้องขอ
4. ไคลเอนต์รีไทรปฏิบัติการเดิมโดยใช้ JSON-RPC ID ใหม่
5. การรีไทรรวม inputResponses และ requestState เดิม
6. เซิร์ฟเวอร์ทำคำขอสำเร็จหรือเริ่มรอบใหม่

ตัวอย่างการตอบกลับ:

{
  "jsonrpc": "2.0",
  "id": "delete-1",
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "confirm_delete": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "ลบโปรเจกต์ project_123 หรือไม่?",
          "requestedSchema": {
            "type": "object",
            "properties": {
              "confirmed": {
                "type": "boolean"
              }
            },
            "required": ["confirmed"]
          }
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

ไคลเอนต์รีไทรปฏิบัติการเดิม:

{
  "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"
  }
}

การใช้งาน MRTR ในโปรดักชันควรกำหนด:

• จำนวนรอบสูงสุด
• เวลาหมดอายุของ request-state
• พฤติกรรมการยกเลิกและการปฏิเสธ
• การตรวจสอบสคีมาของคำตอบ
• การตรวจสอบสิทธิ์ทุกครั้งที่รีไทร
• การป้องกันการเล่นซ้ำ
• ความเป็น idempotent สำหรับผลข้างเคียง
• พฤติกรรมเมื่อไคลเอนต์ไม่รองรับความสามารถที่ร้องขอ

หลีกเลี่ยงการทำธุรกรรม เช่น การซื้อ การลบ การหักเครดิต หรือการเขียนภายนอก ให้เสร็จ ก่อนส่ง input_required

ใช้ปฏิบัติการแบบเป็นขั้นหรือตั้งคีย์ idempotency เพื่อให้การรีไทรไม่ทำงานซ้ำ ดู สเปก MRTR อย่างเป็นทางการ สำหรับโมเดลปฏิสัมพันธ์เต็มรูปแบบ

5. อัปเดตเกตเวย์ แคช และการอนุญาต

การเปลี่ยนแปลงโครงสร้างพื้นฐานเหล่านี้เกี่ยวข้องกันอย่างใกล้ชิดและควรทดสอบร่วมกัน

ตรวจสอบความถูกต้องของเฮดเดอร์การทำเส้นทาง MCP

คำขอ Streamable HTTP แบบ POST ตอนนี้รวม:

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

เฮดเดอร์เหล่านี้ช่วยให้เกตเวย์ทำเส้นทาง คิดค่า ใช้สิทธิ์ และจำกัดอัตราทราฟฟิกได้โดยไม่ต้องแยก JSON ทุก body

สามารถรองรับคอนโทรลต่างๆ เช่น:

• ขีดจำกัดอัตราแบบเฉพาะทูล
• นโยบายแยกสำหรับเมธอดรายการกับเมธอดปฏิบัติการ
• พูลคนงานเฉพาะสำหรับทูลที่แพง
• การเข้าถึงที่จำกัดสำหรับปฏิบัติการความเสี่ยงสูง
• เมตริกความหน่วงและข้อผิดพลาดแยกตามทูล
• การจัดสรรต้นทุนโครงสร้างพื้นฐาน

อย่างไรก็ตาม ค่ายังมาจากไคลเอนต์ เปรียบเทียบกับ JSON-RPC body ก่อนบังคับใช้นโยบาย

คำขอจะต้องไม่สามารถอ้างว่าเป็นทูลความเสี่ยงต่ำใน Mcp-Name ขณะเรียกทูลอื่นใน body ได้ ควรปฏิเสธและบันทึกความไม่ตรงกันระหว่างเฮดเดอร์กับ body

ใช้กุญแจแคชที่คำนึงถึงการอนุญาต

โปรโตคอลใหม่เพิ่ม ttlMs และ cacheScope ให้กับผลลัพธ์ที่แคชได้ ได้แก่:

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

โดยปกติคีย์ของแคชควรรวม:

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

อย่านำรายการแคชแบบ private ไปใช้ข้ามผู้ใช้หรือผู้เช่า เพียงเพราะ TTL ยังไม่หมดอายุ

การจัดเรียงทูลแบบกำหนดได้สำคัญเช่นกัน แคตตาล็อกที่เสถียรช่วยหลีกเลี่ยงแคชมิสโดยไม่จำเป็น และอาจเพิ่มโอกาสการใช้ prompt-cache ของโมเดลซ้ำเมื่อมีการแทรกคำจำกัดความของทูลเข้าไปในพรอมต์

ทำให้การจัดการ OAuth Issuer เข้มแข็งขึ้น

ระหว่างย้ายการอนุญาต:

• ตรวจสอบค่า iss ที่ได้รับเทียบกับ issuer ที่บันทึกไว้สำหรับโฟลว์นั้น
• ผูกการเก็บ client credentials ตาม issuer
• อย่าใช้ credentials ซ้ำกับ authorization server อื่น
• ตั้งค่า application_type ที่เหมาะสมระหว่าง DCR
• เตรียมอินทิเกรชันใหม่สำหรับ Client ID Metadata Documents

Dynamic Client Registration ยังคงใช้ได้เพื่อความเข้ากันได้ย้อนหลัง แต่เลิกใช้เป็นแนวทางหลักในการลงทะเบียน

6. ย้าย Notifications, Tasks และฟีเจอร์ที่เลิกใช้

เส้นทางการแจ้งเตือนผ่าน HTTP GET แบบเก่า และโฟลว์ resources/subscribe หรือ resources/unsubscribe ถูกแทนที่ด้วย subscriptions/listen

ไคลเอนต์เปิดสตรีมการตอบกลับ POST แบบยาวและเลือกเข้ารับหมวดการแจ้งเตือนที่ต้องการ การแจ้งเตือนความคืบหน้าและล็อกที่เฉพาะกับคำขอยังคงผูกอยู่กับสตรีมการตอบกลับของคำขอนั้น

สำหรับดีพลอยหลายอินสแตนซ์ ใช้บัสเหตุการณ์ที่แชร์เมื่อการแจ้งเตือนที่สร้างบนอินสแตนซ์หนึ่งต้องไปถึงการสมัครที่เชื่อมต่อกับอีกอินสแตนซ์หนึ่ง

ส่วนขยาย Tasks

งานระยะยาวถูกย้ายออกจากคอร์โปรโตคอลเชิงทดลองไปยัง:

io.modelcontextprotocol/tasks

ส่วนขยายใช้:

• tasks/get สำหรับโพลลิง
• tasks/update สำหรับอัปเดตจากไคลเอนต์ไปเซิร์ฟเวอร์
• แฮนเดิลงานแบบทนทาน
• subscriptions/listen สำหรับอัปเดตที่เลือกเข้ารับ

รูปแบบ tasks/result และ tasks/list แบบเก่าไม่ควรถูกนำไปยังการใช้งานใหม่

ฟีเจอร์ที่เลิกใช้

ฟีเจอร์ต่อไปนี้เลิกใช้แล้ว:

ฟังก์ชันที่เลิกใช้ยังมีในช่วงหน้าต่างการเลิกใช้ แต่ไม่ควรนำไปใช้ในงานใหม่ นโยบายวัฏจักร MCP ให้ระยะเลิกใช้น้อยที่สุดสิบสองเดือน; ไม่ได้หมายความว่าทุกฟีเจอร์จะมีวันยืนยันการถอดออกเหมือนกัน

ทบทวน รีจิสทรีฟีเจอร์ที่เลิกใช้ อย่างเป็นทางการก่อนกำหนดเส้นเวลาการเลิก

7. ปล่อยการย้ายอย่างปลอดภัย

อย่าเปลี่ยนไคลเอนต์ เซิร์ฟเวอร์ เกตเวย์ แคช และการอนุญาตในรีลีสที่ไม่มีการสังเกตเดียวกัน

ลำดับการย้ายที่แนะนำ

1. สำรวจเวอร์ชันโปรโตคอล SDK เซสชัน ทราฟฟิก SSE ไคลเอนต์ DCR และเมธอดที่เลิกใช้
2. อัปเกรด SDK ในสภาพแวดล้อมที่ไม่ใช่โปรดักชัน
3. เพิ่ม server/discover และการเจรจาเวอร์ชัน
4. แทนที่การพึ่งพาเซสชันที่ซ่อนอยู่
5. ใช้และทำให้ MRTR ปลอดภัย
6. เพิ่มเฮดเดอร์การทำเส้นทางที่ตรวจสอบได้และแคชแบบกำหนดขอบเขต
7. ทดสอบขอบเขต issuer ของการอนุญาต
8. ทำแคนารีโปรโตคอลสมัยใหม่คู่กับเส้นทางรุ่นเดิม
9. เลิกพฤติกรรมเก่าเมื่อทบทวนเทเลเมทรีแล้วเท่านั้น

ความเข้ากันได้ระหว่างแคนารี

Modern client + modern server
→ ใช้ MCP 2026-07-28

Modern client + legacy server
→ สำรวจและถอยกลับเมื่อรองรับ

Legacy client + dual-version server
→ เดินต่อบนเส้นทางรุ่นเดิม

Unsupported combination
→ ส่งคืนข้อผิดพลาดเวอร์ชันโปรโตคอลที่ชัดเจน

การออกสเปก MCP ใหม่ไม่ใช่สวิตช์ของทั้งอีโคซิสเต็ม ไคลเอนต์ เซิร์ฟเวอร์ SDK และแพลตฟอร์มโฮสต์จะย้ายด้วยความเร็วต่างกัน

เทเลเมทรีที่ควรบันทึก

คำขอ tools/call แบบ one-shot ที่สำเร็จไม่พอสำหรับวัดการย้าย เวิร์กโฟลว์ที่หมดเวลา ขออินพุตโดยไม่จำเป็น หรือเขียนภายนอกซ้ำ ถือเป็นความล้มเหลวในโปรดักชัน

CometAPI อยู่ตรงไหนในสถาปัตยกรรม MCP

MCP ไม่ได้แทนที่ API ของโมเดล สองเลเยอร์นี้แก้ปัญหาการเชื่อมต่อคนละแบบ

สถาปัตยกรรมโปรดักชันทั่วไปมีลักษณะดังนี้:

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

MCP ทำให้มาตรฐานการปฏิสัมพันธ์ของเอเจนต์กับเครื่องมือและคอนเท็กซ์ แต่ไม่ได้ทำมาตรฐานราคาของโมเดล ครับเดนเชียลของผู้ให้บริการโมเดล เอ็นด์พอยต์อินเฟอเรนซ์ หรือการเฟลโอเวอร์ของผู้ให้บริการ

การแยกนี้มีประโยชน์อย่างยิ่งเมื่อย้ายออกจากความสามารถ Sampling ที่เลิกใช้ หากเซิร์ฟเวอร์ MCP หรือเอเจนต์ที่ใช้ยังต้องการอินเฟอเรนซ์โมเดล แอปสามารถเรียก API ของโมเดลโดยตรงแทนการพึ่งพาโฟลว์ Sampling เดิมของ MCP

เมื่อไรควรใช้ Unified Model Gateway

เกตเวย์โมเดลแบบรวมช่วยลดงานปฏิบัติการเมื่อ:

• เซิร์ฟเวอร์ MCP หลายตัวต้องเข้าถึงผู้ให้บริการโมเดลต่างกัน
• เครื่องมือต่างกันต้องการโมเดลต่างกัน
• ทีมอยากสลับโมเดลโดยไม่ต้องเขียนอินทิเกรชันเฉพาะผู้ให้บริการใหม่
• ครอบครองสิทธิ์ การใช้งาน และการคิดเงินต้องการการจัดการแบบศูนย์กลาง
• การเข้าถึงโมเดลควรเป็นอิสระจากการเปลี่ยนแปลง transport ของ MCP

CometAPI ให้เอ็นด์พอยต์ที่เข้ากันได้กับ OpenAI ซึ่งใช้เป็นเลเยอร์เข้าถึงโมเดลหลังแอป MCP ได้ ช่วยให้ตรรกะผู้ให้บริการโมเดลแยกจากเครื่องมือ ทรัพยากร และการจัดการงานของ MCP

ตัวอย่าง เครื่องมือ MCP สามารถเรียกโมเดลผ่านไคลเอนต์ที่เข้ากันกับ OpenAI เหมือนส่วนอื่นของแอป:

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: "สรุปทรัพยากรที่ให้มาอย่างชัดเจนและกระชับ"
      },
      {
        role: "user",
        content
      }
    ]
  });

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

เซิร์ฟเวอร์ MCP ยังคงรับผิดชอบสัญญาของทูล การอนุญาต สถานะ และการจัดการผลลัพธ์ ส่วนเกตเวย์โมเดลดูแลการเลือกโมเดล การเข้าถึงผู้ให้บริการ และการตอบกลับอินเฟอเรนซ์

การแยกเลเยอร์ให้ประโยชน์เชิงปฏิบัติ 2 ข้อ:

1. ไคลเอนต์และเซิร์ฟเวอร์ MCP ย้ายไปโปรโตคอลใหม่โดยไม่ต้องเปลี่ยนเลเยอร์อินทิเกรชันโมเดล
2. ผู้ให้บริการโมเดลสามารถเปลี่ยนได้โดยไม่ต้องออกแบบเครื่องมือ MCP หรือพฤติกรรม transport ใหม่

สำหรับรายละเอียดเพิ่มเติม ดู CometAPI Quickstart เอกสาร API และ คู่มือแอป AI หลายโมเดล

เช็กลิสต์การย้าย MCP 2026-07-28

Client

• อัปเกรดเป็น SDK ที่เข้ากันได้
• เปิดใช้การเจรจาเวอร์ชันแบบสมัยใหม่
• รองรับ server/discover
• ใส่เมทาดาตาโปรโตคอลในทุกคำขอ
• จัดการ resultType
• รองรับหรือปฏิเสธ MRTR อย่างชัดเจน
• ใช้ JSON-RPC ID ใหม่สำหรับการรีไทร
• เก็บและส่งคืน requestState
• ตรวจสอบ OAuth issuer
• เก็บ credentials ตาม issuer
• เคารพ cache hints
• รองรับ subscriptions/listen เมื่อจำเป็น

Server

• ลบเกท initialize ของคำขอสมัยใหม่
• ลบการพึ่งพา Mcp-Session-Id
• ใช้ server/discover
• แทนสถานะที่ซ่อนด้วยแฮนเดิลหรือสตอเรจที่แชร์
• ส่งคืน resultType
• แทนคำขอที่เริ่มโดยเซิร์ฟเวอร์ด้วย MRTR
• ป้องกัน requestState
• ตรวจสอบ inputResponses ทั้งหมด
• เพิ่ม idempotency สำหรับผลข้างเคียง
• ส่งคืนลิสต์แบบกำหนดได้
• เผยแพร่ cache hints แบบอนุรักษนิยม
• ย้ายงานยาวไปยังส่วนขยาย Tasks

Gateway และโครงสร้างพื้นฐาน

• ตรวจสอบความถูกต้องของเฮดเดอร์คำขอ MCP
• เปรียบเทียบเฮดเดอร์กับ body ของคำขอ
• ลบการรูตแบบ sticky ที่ไม่จำเป็น
• ทดสอบคำขอข้ามหลายอินสแตนซ์
• แบ่งพาร์ทิชันแคชตามขอบเขตการอนุญาต
• เพิ่มบัสการแจ้งเตือนที่แชร์เมื่อจำเป็น
• ติดตามทราฟฟิกแบบเดิมและที่เลิกใช้
• รักษาเส้นทางย้อนกลับระหว่างแคนารี

คำถามที่พบบ่อย

MCP 2026-07-28 คืออะไร?

MCP 2026-07-28 คือสเปก Model Context Protocol ที่เผยแพร่เมื่อวันที่ 28 กรกฎาคม 2026 ซึ่งนำเสนอแกนโปรโตคอลแบบไร้สถานะ Multi Round-Trip Requests เฮดเดอร์สำหรับการทำเส้นทาง HTTP ผลลัพธ์ที่แคชได้ การเปลี่ยนแปลงการอนุญาต ส่วนขยาย และวัฏจักรการเลิกใช้อย่างเป็นทางการ

Mcp-Session-Id ถูกถอดออกหรือไม่?

ใช่ โปรโตคอล Streamable HTTP ใหม่ไม่มี Mcp-Session-Id

แอปยังคงเก็บสถานะได้ผ่านแฮนเดิลแบบชัดเจน สตอเรจที่แชร์ งานที่ทนทาน หรือค่า request-state ที่ป้องกันแล้ว

การจับมือเริ่มต้นของ MCP ถูกถอดออกหรือไม่?

ใช่ คำขอสมัยใหม่ไม่ต้องแลกเปลี่ยน initialize และ notifications/initialized

เซิร์ฟเวอร์ต้องมี server/discover แม้ไคลเอนต์ไม่ต้องเรียกก่อนทุกปฏิบัติการ

MCP แบบไร้สถานะหมายความว่าเครื่องมือเก็บสถานะไม่ได้หรือไม่?

ไม่ ไร้สถานะหมายถึงเลเยอร์โปรโตคอล

เครื่องมือยังสามารถเก็บสถานะได้ แต่การประมวลผลคำขอไม่ควรพึ่งพาการผูกกับทรานสปอร์ตที่ซ่อนอยู่หรือโปรเซสเซิร์ฟเวอร์ตัวเดียว

MRTR คืออะไร?

Multi Round-Trip Requests ช่วยให้เซิร์ฟเวอร์ร้องขอข้อมูลหรืออินพุตจากผู้ใช้เพิ่มเติมได้ โดยไม่ต้องส่งคำขอที่เริ่มจากเซิร์ฟเวอร์ผ่านการเชื่อมต่อแบบสองทางที่เปิดทิ้ง

เซิร์ฟเวอร์จะส่งกลับ input_required และไคลเอนต์รีไทรปฏิบัติการเดิมพร้อมคำตอบที่ร้องขอ

HTTP+SSE ถูกถอดออกทันทีหรือไม่?

ไม่ ถูกเลิกใช้ แต่ไม่ได้ถอดออกทันที

เซิร์ฟเวอร์ใหม่ควรใช้ Streamable HTTP ขณะที่ระบบที่มีอยู่ควรวัดและย้ายทราฟฟิก HTTP+SSE ที่เหลือ

ไคลเอนต์ TypeScript SDK v2 ใช้ MCP 2026-07-28 โดยอัตโนมัติหรือไม่?

ไม่ SDK v2 ต้องกำหนดค่าการเจรจาเวอร์ชันอย่างชัดเจนเพื่อใช้โปรโตคอลสมัยใหม่

ใช้โหมดอัตโนมัติเมื่อไคลเอนต์ต้องทำงานกับทั้งเซิร์ฟเวอร์สมัยใหม่และรุ่นเดิม

ข้อแนะนำสุดท้าย

MCP 2026-07-28 ทำให้โครงสร้างพื้นฐาน MCP แบบรีโมตปรับขนาด ทำเส้นทาง แคช และสังเกตการณ์ได้ง่ายขึ้น ความเสี่ยงหลักของการย้ายไม่ใช่แค่การถอดเฮดเดอร์หรือจับมือ แต่มาจากสถานะแอปและตรรกะปฏิสัมพันธ์ที่ซ่อนอยู่ซึ่งอาจยังพึ่งพาสิ่งเหล่านั้น

ก่อนดีพลอยโปรโตคอลใหม่:

ค้นหาการพึ่งพาการ initialize และ Mcp-Session-Id ทั้งหมด

1. ย้ายสถานะที่ต้องใช้ไปยังแฮนเดิลแบบชัดเจนหรือสตอเรจที่แชร์
2. ใช้ MRTR พร้อมหมดอายุ การป้องกันการเล่นซ้ำ และ idempotency
3. ตรวจสอบเฮดเดอร์ MCP เทียบกับ JSON-RPC body
4. แบ่งแคชตามผู้เช่าและขอบเขตการอนุญาต
5. ทำให้การตรวจ issuer ของ OAuth เข้มแข็ง
6. วัดเมธอดที่เลิกใช้และทราฟฟิก transport รุ่นเดิม
7. ทำแคนารีเส้นทางโปรโตคอลสมัยใหม่และรุ่นเดิมก่อนเลิกใช้

มองการย้ายครั้งนี้เป็นการเปลี่ยนโครงสร้างพื้นฐาน ไม่ใช่แค่อัปเกรด SDK ตามปกติ

เมื่อเลเยอร์ MCP ไร้สถานะและสังเกตการณ์ได้แล้ว ให้เก็บการเข้าถึงโมเดลไว้หลังอินเทอร์เฟซแยกต่างหาก เพื่อให้โปรโตคอลเครื่องมือกับเลเยอร์ผู้ให้บริการโมเดลพัฒนาได้อย่างอิสระต่อกัน