Google เปิดคู่มือรัน MCP stateless บนโปรดักชัน — SDK ทั้งสี่ภาษาออก beta แล้ว และ GitHub MCP ถอด Redis ทิ้งทั้งชั้น

หลังจากสเปก MCP รุ่น 2026-07-28 ประกาศ stable เมื่อ 28 กรกฎาคม คำถามที่ค้างอยู่ของทีมที่รัน MCP server จริงคือ “แล้วย้ายยังไง และย้ายแล้วได้อะไรเป็นรูปธรรม” — เมื่อ 5 สิงหาคม 2026 Google ตอบคำถามนั้นด้วยบทความจาก Kurtis Van Gent (Senior Staff Software Engineer, Google Cloud Data) และ Alan Blount (Senior Technical Product Manager) ที่เป็นทั้งการเปิดเผยว่าใครผลักดันการเปลี่ยนแปลงนี้ และคู่มือย้ายระบบพร้อมคำสั่งติดตั้งจริง

บทความนี้ไม่ใช่การเล่าสเปกซ้ำ แต่เป็นมุมของคนที่เจ็บมาก่อน — Google บอกตรง ๆ ว่าเมื่อเริ่มดีพลอย MCP server ทั่วโครงสร้างพื้นฐานของตัวเอง “we hit a hard wall” และนั่นคือเหตุผลที่ Google ร่วมกับ Hugging Face และพาร์ตเนอร์อื่นตั้ง MCP Transports Working Group ขึ้นมาเพื่อรื้อ transport ทิ้ง

ต้นทุนสี่ข้อของ session ที่ Google เรียกว่า production bottleneck

ในสเปกเดิม (2025-11-25) การต่อ MCP server ผ่าน HTTP ต้อง handshake ก่อน แล้วเซิร์ฟเวอร์คืน Mcp-Session-Id มาให้ ซึ่งไคลเอนต์ต้องแนบไปทุกคำขอถัดไป — และนั่นคือการ ปักหมุดไคลเอนต์ไว้กับ pod ตัวที่ถือ state ในหน่วยความจำ Google แจกแจงต้นทุนไว้สี่ข้อ:

• The Load Balancing Tax — load balancer แบบ round-robin ไม่รู้ว่า container ตัวไหนถือ session ไหน ดีพลอยบน Kubernetes สาม pod แปลว่าคำขอที่สองมีโอกาสวิ่งไปโดน pod อื่นแล้วได้ 400 Session Not Found กลับมา
• Sticky Routing Overheads — ต้องตั้ง session affinity ที่ชั้น load balancer ซึ่งทำให้ traffic กระจายไม่สม่ำเสมอและ autoscale ได้แย่ลงมาก
• Zero Fault Tolerance — pod restart หรือแครชเมื่อไหร่ state หายทันที ผู้ใช้ที่กำลังคุยอยู่เจอ error กลางคัน
• Complex Infrastructure Demands — ต้องมี Redis session store ที่แชร์กัน หรือให้ gateway แกะ packet ดู ซึ่งเพิ่มทั้ง latency และค่าใช้จ่ายดำเนินการ

ข้อพิสูจน์ที่จับต้องได้ที่สุดในบทความคือ GitHub MCP Server อัปเกรดไปสเปกใหม่และถอด Redis session storage ออกทั้งหมดแล้ว — ตัดการอ่านเขียนฐานข้อมูลที่เคยเกิดขึ้นทุก ๆ การเรียกทิ้งไป

ของใหม่ที่โพสต์สเปกไม่ได้เน้น: header มาตรฐาน SEP-2243

จุดที่บทความนี้เพิ่มจากสิ่งที่เรารายงานไปตอนสเปกออก คือ SEP-2243 (HTTP Standardization) ที่ Google ช่วยออกแบบใน Transports Working Group ตอนนี้คำขอ Streamable HTTP POST พก header สามตัวมาด้วย:

• Mcp-Protocol-Version — เวอร์ชันโปรโตคอล
• Mcp-Method — เมธอด JSON-RPC ที่กำลังเรียก เช่น tools/call
• Mcp-Name — ชื่อ tool, prompt หรือ resource ที่ถูกเรียก

header เหล่านี้ต้องตรงกับ body ถ้าไม่ตรง เซิร์ฟเวอร์ปฏิเสธด้วยโค้ด -32020 header mismatch

ความหมายเชิงปฏิบัติคือ ไม่ต้องทำ deep packet inspection อีกต่อไป — proxy, gateway และ load balancer route, rate-limit และ audit traffic ได้จากส่วนหัวล้วน ๆ สำหรับทีม security และ logging นี่คือการลด latency และภาระประมวลผลที่ชั้น gateway ลงอย่างมีนัยสำคัญ

ตัวอย่างคำขอ tool call แบบ stateless ที่ Google ยกมา:

POST /mcp HTTP/1.1
Host: mcp-server.example
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{
  "name":"search","arguments":{"q":"otters"},
  "_meta":{
    "io.modelcontextprotocol/protocolVersion":"2026-07-28",
    "io.modelcontextprotocol/clientCapabilities":{},
    "io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}
  }}}

Google ยังชี้ว่าความ stateless ทำให้ รัน MCP server เป็น serverless function บน Cloud Run หรือ Cloud Functions ได้จริง — สเกลลงถึงศูนย์เมื่อไม่มีคนใช้ เพราะไม่มี connection ที่ต้องคาไว้ และ pod restart / rollout / autoscale กลายเป็นเรื่องที่ไคลเอนต์มองไม่เห็นเลย

ฝั่งความปลอดภัยมีสามข้อที่ควรจดไว้: RFC 9207 (Issuer Verification) บังคับให้ public client ตรวจพารามิเตอร์ iss ในคำตอบ authorization เพื่อกัน session hijacking, RFC 8707 (Resource Indicators) ให้ไคลเอนต์ระบุชัดว่า token ตั้งใจใช้กับเซิร์ฟเวอร์ตัวไหน เพื่อแก้ปัญหา confused deputy และ JSON Schema 2020-12 เต็มรูปแบบสำหรับ tool ที่เปิดให้ใช้ oneOf / anyOf / allOf และ local $ref ได้

ย้ายจริงต้องพิมพ์อะไร

SDK ระดับ Tier-1 ทั้งสี่ตัว (TypeScript, Python, Go, C#) มี beta รองรับสเปก 2026-07-28 แล้ว และ Google แนะนำให้เริ่มทดสอบบน staging ทันที

Python — decorator API ของ MCPServer เข้ากันได้เต็มที่ ติดตั้ง beta ตรง ๆ:

pip install "mcp[cli]==2.0.0b1"

TypeScript — v2 เลิกใช้แพ็กเกจก้อนเดียว @modelcontextprotocol/sdk แล้วแยกเป็นไลบรารีย่อยเพื่อลด dependency:

npm install @modelcontextprotocol/server@beta
npm install @modelcontextprotocol/client@beta

พร้อม codemod สำหรับการเปลี่ยนชื่อ API มาตรฐาน เช่น .tool() → registerTool:

npx @modelcontextprotocol/codemod@beta v1-to-v2 .

Go — ทีม Google ที่ดูแล Go MCP SDK ปล่อย v1.7.0 ในวันที่ 28 กรกฎาคม พร้อมกับวันที่สเปกออกพอดี และเป็นตัวที่ขับเคลื่อน GitHub MCP Server อยู่

ส่วน Tasks Extension (SEP-2663) ที่เลื่อนสถานะจาก experimental มาเป็น extension ระดับหนึ่ง Google ยกตัวอย่างงานที่กินเวลา 10–60 วินาที เช่น backup ฐานข้อมูล, sync CRM หรือคืนเงินผ่าน payment gateway — เซิร์ฟเวอร์คืน taskId กลับทันทีแล้วรันงานเบื้องหลัง ไคลเอนต์คุยกับผู้ใช้ต่อได้แล้วค่อย poll ผ่าน tasks/get

จุดที่ต้องอ่านอย่างระวัง

บทความของ Google เรียกสเปก 2026-07-28 ว่า “release candidate” ซึ่งไม่ตรงกับสถานะจริง ณ วันที่เขียน — หน้า release บน GitHub ระบุตั้งแต่ 28 กรกฎาคมว่านี่คือ stable release ของ revision นี้แล้ว ไม่ใช่ RC ความคลาดเคลื่อนนี้ไม่กระทบเนื้อหาเชิงเทคนิค แต่ถ้าคุณกำลังเอาบทความนี้ไปใช้เป็นหลักฐานประกอบการขออนุมัติ roadmap ให้อ้างหน้าสเปกทางการแทน

อีกจุดคือตัวอย่างโค้ด Tasks Extension ที่ Google เขียนเอง ยังเก็บ task state ไว้ใน Redis (“Store initial task state in a shared datastore (e.g. Redis)”) ซึ่งไม่ขัดกับสเปก — เพราะสิ่งที่สเปกตัดคือ state ที่ระดับ transport ไม่ใช่ state ที่ระดับ แอปพลิเคชัน แต่มันเป็นเครื่องเตือนใจว่า “stateless” ในที่นี้ไม่ได้แปลว่าคุณจะไม่ต้องมีที่เก็บสถานะอีกเลย มันแค่ย้ายภาระนั้นจากชั้นโปรโตคอลมาที่ชั้นที่คุณควบคุมได้

มุมมอง AI Curator

สิ่งที่ทำให้บทความนี้ต่างจากโพสต์สเปกทั่วไป คือมันเป็น คำสารภาพเชิงวิศวกรรมของบริษัทที่ผลักดันการเปลี่ยนแปลง Google ไม่ได้บอกว่า “เราออกแบบให้ดีขึ้น” แต่บอกว่า “เราชนกำแพงตอนสเกล จึงต้องรื้อ” ซึ่งเป็นเหตุผลที่ตรงไปตรงมาและอธิบายว่าทำไมสเปกถึงเปลี่ยนแรงขนาดตัด handshake ทิ้ง — ไม่ใช่ความสวยงามเชิงทฤษฎี แต่คือ 400 Session Not Found ที่เกิดจริงบนคลัสเตอร์สาม pod

สำหรับทีมไทยและ SEA ข่าวนี้เปลี่ยนสมการต้นทุนอย่างเป็นรูปธรรมกว่าที่เห็น การรัน MCP server ที่เปิดสาธารณะให้ลูกค้าเรียกใช้ เคยหมายถึงต้องมี VM หรือ container ที่รันตลอดเวลาบวก Redis อีกก้อน — ต้นทุนขั้นต่ำต่อเดือนที่จ่ายแม้ไม่มีใครเรียก ตอนนี้ สเกลลงถึงศูนย์ได้จริงบน Cloud Run ซึ่งสำหรับสตาร์ตอัปหรือทีมภายในองค์กรที่ทราฟฟิกไม่สม่ำเสมอ นี่คือความต่างระหว่าง “ทำได้” กับ “คุ้มจะทำ” และเมื่อรวมกับการที่ header เป็นมาตรฐานแล้ว การวาง API gateway ในประเทศเพื่อทำ audit log ตาม PDPA ก็ทำได้โดยไม่ต้องแกะ payload ที่อาจมีข้อมูลส่วนบุคคลอยู่ข้างใน

สิ่งที่ยังต้องระวังคือ ทุก SDK ยังเป็น beta ทั้งหมด และหน้าต่าง deprecation 12 เดือนของ Roots / Sampling / Logging เพิ่งเริ่มนับ คำแนะนำที่พอเหมาะสำหรับตอนนี้คือ: ถ้าคุณกำลังจะ เขียนใหม่ ให้เริ่มที่สเปกใหม่เลย อย่าเพิ่งเพิ่มการรองรับสามฟีเจอร์ที่ถูก deprecate; ถ้าคุณ มีของรันอยู่แล้ว ให้ลอง codemod บน staging และวัดว่าถอด sticky session ออกแล้วค่าใช้จ่ายลดจริงเท่าไหร่ ก่อนตัดสินใจย้าย production ตัวเลขนั้นจะเป็นเหตุผลที่ดีกว่าคำว่า “สเปกใหม่ออกแล้ว” เวลาต้องคุยกับฝ่ายที่ถือ budget

แหล่งข่าว

• Scaling AI Agent Infrastructure with the MCP Stateless updates — Google Developers Blog
• MCP Specification 2026-07-28 changelog — modelcontextprotocol.io
• โพสต์ก่อนหน้า: สเปก MCP 2026-07-28 ออกตัวจริง
• โพสต์ก่อนหน้า: GitHub MCP Server กับสเปก stateless