สเปกแคช tools/list: ข้อจำกัดของปั๊ม TTL และ Cache-Control
เจาะลึกบทความจาก Dev.to ถอดบทเรียนสเปก SEP-2549 เมื่อแสตมป์ TTL และ Cache-Control บน tools/list เป็นเพียงคำกล่าวอ้าง ไม่ใช่หลักประกันการแคชจริง
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- สเปก SEP-2549 เพิ่ม ttlMs และ cacheScope ลงใน tools/list ของ MCP เลียนแบบ HTTP Cache-Control
- การมีอยู่ของแสตมป์เป็นเพียงคำกล่าวอ้างเรื่องการนำกลับมาใช้ซ้ำ ไม่ใช่หลักฐานว่าการเรียกครั้งถัดไปจะแคชได้จริง
- คำสั่ง contrast-smoke ใน mcp-better ช่วยตรวจสอบและระบุเงื่อนไขเชิงลบที่ยังใช้งานได้จริง
- การตรวจสอบความถูกต้องต้องการการสังเกตการณ์ที่สามารถล้มเหลวได้ ไม่ใช่แค่การตรวจดูว่ามีฟิลด์อยู่หรือไม่
ในแวดวงการพัฒนาซอฟต์แวร์ ประเด็นเรื่องการแคชข้อมูลมักถูกหยิบยกมาถกเถียงกันอยู่เสมอ ล่าสุดมีบทความที่น่าสนใจบน Dev.to โดยผู้ใช้งานชื่อ wolfejam ได้ออกมาสะท้อนมุมมองเกี่ยวกับสเปกวันที่ 2026-07-28 หรือที่รู้จักกันในรหัส SEP-2549 ซึ่งได้เพิ่มฟีเจอร์ list-cache stamps อย่าง ttlMs และ cacheScope เข้ามาใน tools/list ของ Model Context Protocol (MCP) โดยจำลองแนวคิดมาจาก Cache-Control ของโปรโตคอล HTTP
แนวคิดดังกล่าวตั้งอยู่บนความเชื่อที่ว่า ไคลเอนต์จะทราบได้อย่างแม่นยำว่าเมื่อใดที่ tools/list ยังคงมีความสดใหม่ อย่างไรก็ตาม บทความได้ชี้ให้เห็นว่า HTTP เคยสอนบทเรียนนี้มาแล้ว การกำหนดค่าอย่าง Cache-Control: max-age=60 เป็นเพียงการกล่าวอ้างของเซิร์ฟเวอร์เท่านั้น มันไม่ใช่บทพิสูจน์ว่าคำขอ GET ครั้งถัดไปจะได้ไบต์ข้อมูลชุดเดิมกลับมา ทว่า MCP กลับนำชุดคำศัพท์นี้มาใช้งานโดยที่ยังไม่มีการสร้างชุดทดสอบที่รัดกุมมารองรับ
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ปัญหาก็คือ เซิร์ฟเวอร์สามารถพิมพ์ค่า ttlMs: 60000 และ cacheScope: Public ออกมาได้อย่างถูกต้องตามรูปแบบ แต่กลับเปลี่ยนแค็ตตาล็อกของตัวเองในการเรียกใช้งานครั้งถัดไปทันที ส่งผลให้เครื่องมือตรวจสอบ (probe) ที่ทำหน้าที่เพียงแค่เช็กว่ามีฟิลด์เหล่านี้อยู่หรือไม่ ยังคงผ่านการทดสอบได้อย่างสบายใจ กลายเป็นว่าระบบได้ส่งมอบสิ่งที่ให้ข้อมูลไม่ตรงกับความเป็นจริงออกไปโดยที่เครื่องมือตรวจสอบไม่สามารถจับพิรุธได้
ในมุมมองเชิงวิเคราะห์ การทำความเข้าใจเรื่องสเปกแคชในระดับโพรโตคอลถือเป็นหัวใจสำคัญที่จะช่วยป้องกันปัญหาความไม่สอดคล้องระหว่างข้อมูลที่ประกาศ (Declared State) กับสถานะจริงของเซิร์ฟเวอร์ (Actual State) การที่แสตมป์ถูกแสดงผลว่าถูกต้องไม่ได้หมายความว่าพฤติกรรมการแคชเบื้องหลังจะทำงานตามนั้นเสมอไป นักพัฒนาจึงต้องออกแบบระบบทดสอบที่สามารถพิสูจน์ความล้มเหลวได้ (Falsifiable test) แทนที่จะไว้วางใจแค่การมีอยู่ของคีย์ข้อมูล
เพื่อแก้ปัญหานี้ ทางโครงการจึงได้พัฒนาคอมพาเนียนที่ชื่อว่า mcp-worse ขึ้นมาคู่กับ mcp-better พร้อมทั้งเพิ่มคำสั่ง contrast-smoke ซึ่งจะยอมให้ผ่านก็ต่อเมื่อเซิร์ฟเวอร์ที่ดีตรงตามสัญญาของรายการ (BETTER list contract) และเซิร์ฟเวอร์ที่ไม่ดี (worse) ไม่ผ่านเงื่อนไขดังกล่าว โดยใน mcp-better มีการเพิ่มเครื่องมือตัวที่สามเข้ามาคือ confirm_echo ในขณะที่ mcp-worse ยังคงมีแค่สองตัวคือ echo และ health ทำให้ความแตกต่างด้านชื่อแค็ตตาล็อกแสดงผลลัพธ์ที่ชัดเจน
คำสั่งทดสอบดังกล่าวจะแสดงผลลัพธ์ในลักษณะนี้:
- better names: ["health", "echo", "confirm_echo"], ttl: Some(60000), scope: Some(Public)
- worse names: ["echo", "health"], ttl: None, scope: None
- contrast-smoke: OK (better contract · worse unstamped · worse names≠health,echo,confirm_echo)
บทเรียนสำคัญจากเรื่องนี้คือ การมีอยู่ของฟิลด์ ttlMs และ cacheScope บนรายการ tools/list เป็นเพียงคำกล่าวอ้างเรื่องการนำกลับมาใช้ซ้ำ (reuse claim) เท่านั้น การยืนยันว่าฟิลด์เหล่านี้มีอยู่จริงและฟอร์แมตถูกต้องเป็นเพียงการพิสูจน์ว่าเซิร์ฟเวอร์ได้ทำการกล่าวอ้างบางอย่างออกมา แต่มันไม่ได้พิสูจน์ว่าไคลเอนต์จะมีสิทธิ์ข้ามการเรียก tools/list ในครั้งถัดไปได้อย่างถูกต้องแท้จริง
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น