ข้ามไปยังเนื้อหา

Production and Ecosystem

ถึงตอนนี้คุณสร้าง server ที่ list tool ได้, serve resource ได้, พูดได้ทั้งสอง transport และถามข้อมูลจาก user ได้แล้ว server ตัวนั้น ใช้งานได้ แต่ยังไม่ถึงขั้น ดี

คนที่ตัดสินว่า MCP server ตัวหนึ่งดีหรือไม่มีอยู่สองกลุ่ม และไม่มีกลุ่มไหนเป็นคุณเลย:

  • Model มันอ่านชื่อ tool กับ description ของคุณแบบไม่มีบริบท ไม่มี README แล้วตัดสินใจในรอบเดียวว่าจะเรียก tool ไหนและเรียกอย่างไร tool ที่คนต้องใช้เวลาสิบนาทีถึงจะเข้าใจ คือ tool ที่ model จะใช้ผิดภายในสิบมิลลิวินาที
  • Operator คนที่ deploy server ของคุณไว้หลัง load balancer เฝ้าดูมันตอนตีสาม และอัปเกรดมันโดยไม่ทำให้ client ที่ต่ออยู่พัง ถ้า server ซ่อน state ไว้ใน process, log ลง stdout หรือส่ง breaking change ของ tool ออกไปเงียบ ๆ คนที่จะถูกปลุกตอนตีสามคือ คุณ

module นี้ว่าด้วยการรับใช้คนทั้งสองกลุ่ม แล้วต่อด้วยระบบนิเวศที่ server ของคุณอยู่: คนจะหาเจอได้อย่างไร ติดตั้งอย่างไร และ protocol กำลังเติบโตไปทางไหน

flowchart LR
  a["Works locally"] --> b["Tools a model uses well"]
  b --> c["Tested and debuggable"]
  c --> d["Deployed stateless behind HTTPS"]
  d --> e["Published and discoverable"]
  e --> f["Extensions: Tasks, Apps"]
เส้นทางจาก 'ใช้งานได้' ไปสู่ production
บทเรียนคำถามที่ตอบ
Designing Tools for Agentsทำไม model ถึงเลือก tool ผิดอยู่เรื่อย และจะแก้ที่ definition แทนที่จะแก้ prompt ได้อย่างไร
Testing and Debuggingจะลองยิง server โดยไม่ต้องมี LLM ใน loop, เขียน test ที่รันใน CI และอ่าน wire ตอนที่มันพังได้อย่างไร
Deploying Remote ServersStreamable HTTP server แบบ stateless ต้องการอะไรจาก proxy, runtime และ operator
Publishing and the MCP Registryจะทำให้คนติดตั้ง server ของเราได้ในบรรทัดเดียว และลงทะเบียนใน registry ทางการได้อย่างไร
Extensions and the Road AheadTasks กับ MCP Apps คืออะไร อะไรถูก deprecate ไปแล้ว และ spec วิวัฒนาการอย่างไร

ออกแบบให้ผู้อ่านที่เป็น model description ของ tool ทุกตัวคือ prompt ชื่อ parameter ทุกตัวคือ hint และ error message ทุกข้อความคือโอกาสให้ model แก้ตัวเองแทนที่จะยอมแพ้ คุณจะได้เรียนวิธีเขียนสามอย่างนี้อย่างตั้งใจ

เชื่อ wire ไม่ใช่ SDK เวลามีอะไรพัง JSON-RPC message บน wire คือความจริงเพียงหนึ่งเดียว Inspector แสดงมันให้คุณเห็น และ in-process test ให้คุณ assert กับมันได้ abstraction ของ SDK ที่คุณมองทะลุไม่ได้ คือภาระตอนตีสาม

stateless เข้าไว้ น่าเบื่อเข้าไว้ protocol version 2026-07-28 ถอด session ออกไปอย่างตั้งใจ server ที่รักษาสัญญาว่า “ทุก request อยู่ได้ด้วยตัวเอง” จะ scale แนวนอนได้ฟรี รอดจากการ restart และไม่ต้องใช้ sticky load balancing การตัดสินใจเรื่อง deployment ทุกข้อใน module นี้ตามมาจากคุณสมบัติข้อเดียวนี้

ตาม module นี้ ใครคือสองกลุ่มที่ตัดสินว่า MCP server "ดี" หรือไม่?
ทำไม protocol version 2026-07-28 ถึงทำให้การ deploy ง่ายขึ้น?
เมื่อ server ทำงานผิดปกติ module นี้ถือว่าอะไรคือความจริงเพียงหนึ่งเดียว?