Model Context Protocol (MCP) เพิ่งเปลี่ยนเป็นแบบ stateless และการเปลี่ยนแปลงนี้ช่วยให้นักพัฒนาสามารถรัน MCP server ขนาดเล็กบน Cloudflare Workers แผนฟรีได้—ตราบใดที่แต่ละคำขอ (request) ใช้ CPU ไม่เกินขีดจำกัด 10 ms ของแพลตฟอร์ม

ทำไมการเปลี่ยนแปลงนี้ถึงสำคัญ

การเคลื่อนไหวสองอย่างเมื่อเร็วๆ นี้ได้เปิดทางให้ สิ่งแรกคือ MCP core ได้สลัดการออกแบบที่ต้องใช้ session ออกไป และตอนนี้ทำงานได้โดยไม่ต้องมีการทำ handshake อีกต่อไป ทำให้คำขอใดๆ ก็สามารถจัดการโดย instance ใดก็ได้ของโค้ด ประการที่สอง Cloudflare ได้ยกเลิกคลาส McpAgent และแนะนำให้ใช้ request handlers แบบธรรมดาสำหรับเซิร์ฟเวอร์ใหม่แทน สิ่งเหล่านี้ช่วยขจัดความจำเป็นในการใช้ Durable Objects หรือการจัดเก็บข้อมูลแบบ stateful อื่นๆ ซึ่งเคยเป็นอุปสรรคหลักในการรัน MCP บนแผนฟรี

แผนฟรีทำอะไรได้บ้างจริงๆ

เราได้สร้าง MCP server แบบอ่านอย่างเดียว (read-only) ที่ให้บริการไฟล์ Markdown จากไซต์แบบ static เซิร์ฟเวอร์นี้มีเครื่องมือสองอย่างคือ list_articles และ get_article โดยใช้คำสั่ง switch statement แบบง่ายๆ ในการกำหนดเส้นทาง (route) ของเมธอด ไม่มีการคำนวณที่หนักหน่วง เพียงแค่ดึง static assets มาใช้งานเท่านั้น

การนับเวลา CPU ของ Cloudflare แตกต่างจากเวลาตอบสนองทั้งหมด (total response time) เวลา CPU จะนับเฉพาะรอบการทำงานที่ใช้ในการประมวลผล JavaScript ของคุณเท่านั้น ส่วนเวลาที่ใช้ในการรอการเรียกเครือข่าย (network calls) หรือการอ่านดิสก์จะไม่ถูกนำมานับ ความแตกต่างนี้สำคัญมากเพราะแผนฟรีจำกัด CPU ไว้ที่ 10 ms ต่อคำขอ ในขณะที่ latency รวมอาจสูงกว่านั้น

การวัดผลของเราบนแผนฟรีเป็นดังนี้:

  • server/discover: 0-1 ms CPU
  • tools/list: 0 ms CPU
  • get_article (ไฟล์ที่ใหญ่ที่สุด): 1-2 ms CPU

แม้แต่บทความที่ใหญ่ที่สุดก็ยังใช้เวลาเพียงเศษเสี้ยวของงบประมาณ 10 ms ความล่าช้าที่เห็นได้ชัดในฝั่ง client เกิดจากการรอให้อ่านไฟล์เสร็จ ไม่ใช่จากการประมวลผลโค้ด

เมื่อไหร่ที่ขีดจำกัดจะเริ่มเป็นปัญหา

ข้อมูลชี้ให้เห็นรูปแบบที่ชัดเจน:

  • เครื่องมือที่ใช้ส่งข้อมูล (Data-serving tools) (การอ่านแบบง่ายๆ, การแสดงรายการ) จะทำงานภายใต้ขีดจำกัดได้อย่างสบายๆ
  • เครื่องมือที่เน้นการประมวลผล (Compute-heavy tools) (การ parse, การ render, การทำ hashing หรือการทำงานเชิงอัลกอริทึมใดๆ) อาจใช้โควตา 10 ms หมดได้อย่างรวดเร็ว

หากเครื่องมือต้องการการประมวลผลที่มากกว่าระดับพื้นฐาน นักพัฒนาจะต้องเปลี่ยนไปใช้แผน Workers แบบชำระเงิน แผนราคา $5 จะเพิ่มขีดจำกัดเป็น 30 วินาทีต่อคำขอ

ใครได้ประโยชน์ และใครต้องคอยระวังเวลา

ไซต์ขนาดเล็กที่มีการโฮสต์ไฟล์ Markdown หรือ RSS feed อยู่แล้ว สามารถเปิดใช้งาน MCP endpoint ได้ด้วยการเพิ่ม route ใหม่เพียงเส้นเดียวและยังคงใช้แผนฟรีได้ นั่นหมายถึงต้นทุนการดำเนินงานที่ต่ำลงและมีส่วนประกอบที่ซับซ้อนน้อยลงสำหรับผู้ที่ทำเป็นงานอดิเรก, ไซต์เอกสาร (documentation sites) หรือบล็อกที่มีทราฟฟิกต่ำ

หากเครื่องมือต้องการการประมวลผลที่มากกว่าระดับพื้นฐาน นักพัฒนาจะต้องเปลี่ยนไปใช้แผน Workers แบบชำระเงิน

สิ่งที่ควรทดสอบก่อนเริ่มใช้งานจริง

  • Profile เครื่องมือของคุณ: ลองรันคำขอที่เป็นตัวแทนของงานจริงสักสองสามครั้ง และตรวจสอบมาตรวัด CPU ในแดชบอร์ดของ Cloudflare
  • แยกเส้นทาง static และ dynamic ออกจากกัน: ให้การให้บริการไฟล์ static อยู่ในแผนฟรี และส่งการเรียกใช้งานที่ต้องใช้การประมวลผลหนักๆ ไปยัง worker แบบชำระเงินหรือ backend อื่นแทน
  • ระวัง latency ที่ซ่อนอยู่: การรอเครือข่ายไม่ถูกนับรวมใน CPU แต่ก็ยังส่งผลต่อประสบการณ์ของผู้ใช้ ควรพิจารณาการทำ edge caching สำหรับไฟล์ที่คุณให้บริการ

ข้อโต้แย้ง: แผนฟรีไม่ได้ไร้ขีดจำกัด

แม้ว่า stateless core จะช่วยขจัดความจำเป็นในการใช้ Durable Objects แต่ขีดจำกัด 10 ms ก็ยังคงเป็นเพดานที่ตายตัว นักพัฒนาที่ประเมินค่าใช้จ่ายในการประมวลผลแม้เพียงเล็กน้อยต่ำเกินไป (เช่น การแปลง markdown เป็น HTML) อาจชนขีดจำกัดโดยไม่คาดคิด แผนฟรีเหมาะสำหรับสถานการณ์แบบ “serve-as-is” (ให้บริการตามสภาพเดิม) ไม่ใช่การสร้างเนื้อหาแบบ on-the-fly

ก้าวต่อไปของ MCP บน Cloudflare

หากไซต์ของคุณมีเนื้อหาอยู่ใน static bucket อยู่แล้ว การเพิ่ม MCP endpoint อาจง่ายเพียงแค่การเขียนโค้ดไม่กี่บรรทัดและเพิ่ม route เดียวเท่านั้น ตอนนี้โปรโตคอลนี้สอดคล้องกับความต้องการของเซิร์ฟเวอร์ขนาดเล็กแล้ว นั่นคือ HTTP endpoint แบบธรรมดาที่สามารถโฮสต์ได้ฟรี ตราบใดที่คุณยังอยู่ภายใต้เพดาน CPU 10 ms