MCP ในเว็บไซต์ 13 ระบบ: ตัวไหนออกแบบ tool ดี ตัวไหนยังหลงทาง

โดย Nokka (นก-กา) | 19 กันยายน 2026

บทความนี้เขียนโดย AI (โมเดล glm-5.3 ของผู้ให้บริการ ollama-cloud) ผ่าน Hermes Agent จาก Nous Research ตรวจสอบและเรียบเรียงโดย Nokka (นก-กา)

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

เรื่องนี้เกิดขึ้นจริงเมื่อเชื่อม AI เข้ากับระบบสร้างเว็บไซต์หลายตัวในตอนนี้ และเป็นเหตุผลที่ทำให้เกิดงานวิจัยชิ้นนี้ขึ้นมา: เก็บข้อมูลจากเว็บไซต์ 13 ระบบที่มี MCP (Model Context Protocol) แล้วเทียบกันว่า แนวทางการออกแบบเครื่องมือของแต่ละเจ้าดีแค่ไหน ตรงกับหลักการที่ควรทำหรือเปล่า

กราฟนี้แสดงเฉพาะ 11 ระบบที่ให้คะแนนเทียบเกณฑ์ 8 ข้อเต็มชุดได้ ส่วน Squarespace ที่ยังเปิดเฉพาะงานโดเมนอยู่ในสถานะ preview จึงอยู่นอกกราฟ และ Framer ไม่มี MCP อยู่แล้ว

MCP คืออะไร ในสองย่อหน้า

MCP เป็นมาตรฐานเปิดที่ทำให้ AI agent สื่อสารกับซอฟต์แวร์ภายนอกได้ด้วยภาษาเดียวกัน แทนที่แต่ละเว็บจะต้องเขียนวิธีเชื่อมต่อใหม่ทั้งหมดสำหรับทุก AI พูดง่าย ๆ คือเจ้าของเว็บเขียน “เครื่องมือ” (tool) ชุดหนึ่งตามสเปกของ MCP แล้ว AI ทุกตัวที่รองรับ MCP ก็เรียกใช้เครื่องมือชุดนั้นได้เลย

คนมักเข้าใจผิดว่าเขียน tool ก็เหมือนเขียน API ของเดิมแล้วต่อสายเข้า AI แต่ความจริงไม่ใช่ API เขียนไว้ให้โปรแกรมเรียกซ้ำ ๆ ตามสเปกที่แน่นอน ส่วน tool เขียนไว้ให้ AI อ่านแล้ว “เลือกเอง” ว่าจะเรียกตัวไหน เมื่อไหร่ ด้วยพารามิเตอร์อะไร

การเลือกเองนี่แหละคือหัวใจ ชื่อ tool คำอธิบาย และผลลัพธ์ที่คืนกลับมา ล้วนกลายเป็นภาษาที่ AI ใช้คิดด้วย ถ้าออกแบบไม่ดี AI จะเลือกผิด เรียกผิด หรืองงจนไม่ทำอะไรเลย

เกณฑ์ 8 ข้อที่ใช้ตัดสิน

งานนี้ใช้เกณฑ์จากบทความวิศวกรรมของ Anthropic เรื่องการเขียน tool ให้ agent [1] รวมกับเอกสารแนวปฏิบัติด้านความปลอดภัยของ MCP ทางการ [2] สรุปเป็น 8 ข้อ

• เลือก tool ให้น้อยแต่ตรงงาน รวมหลายขั้นตอนที่ใช้ต่อกันบ่อยเข้าเป็น tool เดียว ดีกว่าห่อ API ทีละ endpoint
• ตั้งชื่อให้มีระเบียบ มี prefix บอกว่าเป็นบริการอะไร ทำให้ AI เลือกถูกตัวท่ามกลาง tool หลายร้อยจากหลายเจ้า
• คืนข้อมูลที่อ่านรู้เรื่อง ชื่อสินค้า ชื่อหน้า ดีกว่ารหัส UUID ยาว ๆ ที่ AI ต้องเดาต่อ
• ประหยัด token มีการแบ่งหน้า มีตัวกรอง มีค่าเริ่มต้นที่ไม่ดึงข้อมูลมาทั้งก้อน
• คำอธิบายเขียนเพื่อ AI บอกเมื่อไหร่ควรใช้ และเมื่อไหร่ไม่ควรใช้ tool นี้
• แยกงานอ่านกับงานเขียน การลบข้อมูลต้องมีด่านกันชัดเจน
• สิทธิ์แคบที่สุดเท่าที่จำเป็น ขออนุญาตแบบเลือกเฉพาะ site หรือ environment ดีกว่ายกกุญแจบัญชีทั้งใบให้ AI
• เอกสารและตัวอย่างครบ มีคู่มือเฉพาะสำหรับ MCP ไม่ใช่โยน API docs เดิมมาให้อ่าน

ทั้ง 13 ระบบถูกให้คะแนนตาม 8 ข้อนี้จากเอกสารทางการและ source code ที่เปิดเผยสาธารณะ

สนามแข่งมีใครบ้าง

กลุ่มสร้างเว็บแบบสำเร็จรูปได้แก่ Wix, WordPress.com, Duda, Webflow และ Squarespace กลุ่ม CMS มี Contentful, Storyblok, Sanity, Strapi, Directus, Payload และ Drupal รวม 12 ตัว บวกข้อยกเว้นหนึ่งเดียวคือ Framer ที่ประกาศชัดว่าไม่ทำ MCP แต่ใช้ระบบ External Agent ของตัวเอง จึงไม่นับรวมในการให้คะแนน ส่วน Ghost ถูกตัดออกเพราะยังไม่มี MCP ทางการ

สถาปัตยกรรม 4 แบบที่พบ

งานวิจัยสรุปได้เป็น 4 แนวทางที่ต่างกันชัดเจน

แบบที่ 1: รวมยุบเป็น tool เดียว (WordPress.com)

WordPress.com เป็นตัวอย่างที่หนักแน่นที่สุดของแนวคิด “น้อยแต่มาก” แทนที่จะเปิด operation กว่า 60 อย่างเป็น 60 tool เขาใส่ทุกอย่างไว้ใน tool เดียวชื่อ wpcom-mcp-content-authoring [3]

AI ทำงานกับ tool นี้เป็น 3 จังหวะ: list เพื่อดูว่ามี operation อะไร, describe เพื่อดูรูปแบบข้อมูลของ operation นั้น, และ execute เพื่อเรียกใช้จริง เช่น posts.create หรือ pages.update

จุดที่ทำให้แบบนี้ได้คะแนนเต็มคือด่านความปลอดภัย ทุกงานที่เขียนหรือลบข้อมูลต้องส่งพารามิเตอร์ user_confirmed มาด้วยเสมอ และการลบถาวรของหมวดหมู่หรือแท็กต้องยืนยันอีกชั้นหนึ่ง [3]

ยังมี tool คู่หูแบบอ่านอย่างเดียวอีกตัวที่ให้ AI ไปดูธีมและบล็อกที่ใช้อยู่ก่อน เพื่อไม่ให้เนื้อหาใหม่ขัดกับดีไซน์เดิมของเว็บ คู่มือเขียนไว้ตรง ๆ ว่าควรใช้ก่อนสร้างเนื้อหาเสมอ

แบบที่ 2: ค้นหาก่อนแล้วค่อยเรียก (Storyblok)

Storyblok เดินสวนทางกับค่ายห่อ API สุดขั้ว แทนที่จะห่อ Management API ที่มี endpoint ราว 160 ตัวให้ครบทุกอัน เขาเปิด tool แค่ 7 ตัว: search ค้นหาว่ามี operation ที่ต้องการไหม, describe ดูรายละเอียดพารามิเตอร์, ประตูเรียกใช้ 3 บานที่แยกกันตามความอันตราย และคู่ upload_asset กับ upload_asset_finish สำหรับอัปโหลดไฟล์แบบสองเฟส

• execute_readonly สำหรับอ่านข้อมูล
• execute_mutating สำหรับสร้างและแก้ไข
• execute_destructive สำหรับลบ โดยต้องได้รับการยืนยันจากผู้ใช้ทุกครั้ง

การแยกสามบานนี้ไม่ใช่เรื่องสวยงามแต่เป็นเรื่องความปลอดภัยจริง [4] เพราะคนดูแลระบบสามารถเลือกได้เลยว่าจะต่อ AI เข้าแค่ประตูอ่านอย่างเดียว โดยไม่ต้องไปเขียนกฎเพิ่ม ยิ่งไปกว่านั้น role ของผู้ใช้ถูกฝังอยู่ใน URL ของการเชื่อมต่อ ทำให้ AI แอบขยับสิทธิ์ตัวเองไม่ได้เลย

แบบที่ 3: บังคับให้อ่านคู่มือก่อน (Wix)

Wix เลือกมุมที่ต่างออกไป จาก tool 12 ตัวมีถึง 6 ตัวที่หน้าที่คือค้นหาเอกสารของ Wix เอง ทั้งค้นหาคู่มือ REST, คู่มือ SDK และดึง schema ของเมธอดแต่ละอัน แล้วประตูจริงสู่ API มีเพียง CallWixSiteAPI ตัวเดียว [10] แนวคิดคือบังคับให้ AI อ่านก่อนเรียก ลดโอกาสที่มันจะเดา schema จนหลง

แผนนี้ได้ผลด้านกันการมั่ว แต่คำอธิบายของ tool สั้นเกินไป เช่น “Perform an action or query” ซึ่งไม่ช่วยให้ AI ตัดสินใจเลยว่าเมื่อไหร่ควรใช้ตัวนี้ และการแยก tool ค้นหาเอกสารเป็น 6 ตัวตามชนิดเอกสารก็เป็นการห่อบาง ๆ ที่รวมเป็นตัวเดียวได้

แบบที่ 4: ห่อ API ทีละตัว (Duda, Contentful)

Duda เป็นตัวอย่างของแนวทางที่ขัดกับคำแนะนำของ Anthropic ชัดที่สุด [1] tool 54 ตัวถูกสร้างตาม endpoint แบบหนึ่งต่อหนึ่ง ชื่อไม่มี prefix บอกบริการ จนมี tool ขึ้นต้นด้วย create_ อยู่มากกว่าสิบตัว คำอธิบายสั้นบรรทัดเดียว

และที่หนักสุดคือมีทั้ง delete_account โดยไม่พบขั้นยืนยันใด ๆ ในเอกสาร [9]

Contentful เป็นแนวเดียวกันที่ขนาด 40 กว่า tool แต่มีจุดเด่นที่ต้องยกให้เครดิต คือ PROTECTED_ENVIRONMENTS ที่ปิดไม่ให้เขียนหรือลบข้อมูลใน environment สำคัญอย่าง production ได้ [6] กันความเสียหายไว้ที่ระดับโครงสร้างทั้งระบบ ไม่ใช่กันเฉพาะระดับ tool

ตารางคะแนนรวม

ให้คะแนนข้อละ 1 (ผ่านครึ่งหนึ่งถ้าหาหลักฐานไม่ได้หรือทำได้บางส่วน) รวมเต็ม 8

ระบบ คะแนน จุดเด่นที่สุด WordPress.com 8/8 tool เดียวรวม 60+ operations + ยืนยันทุกการเขียน Storyblok 8/8 7 tool แทน 160 endpoint + แยกระดับตามความอันตราย Sanity 7.5/8 คำอธิบายสอน AI ในตัว Webflow 7/8 รวมหลาย action ต่อ resource + แยก Data/Designer Contentful 6.5/8 ป้องกันระดับ environment Strapi 7/8 tool ที่ไม่มีสิทธิ์จะไม่แสดงเลย Directus 7/8 ปิด tool ที่ไม่ใช้ได้ต่อ deployment Payload 6.5/8 สร้าง tool ตาม collection อัตโนมัติ Wix 6/8 บังคับอ่านเอกสารก่อนเรียก Drupal 6/8 สถาปัตยกรรม plugin ยืดหยุ่น Duda 2/8 ครอบคลุมทุกงานแต่แทบไม่มีด่านกัน Squarespace 7/8* ดีแต่เปิดเฉพาะงานโดเมน 2 tool

*คะแนน Squarespace คำนวณจากขอบเขตงานที่เปิดจริงในตอนนี้ ซึ่งเป็นสถานะ preview จึงไม่เทียบกับระบบเต็มตัวได้เท่าที่ควร

จุดที่ทำได้ดีที่สุดของสนามนี้

นอกจากสองแชมป์แล้ว มีรายละเอียดเล็ก ๆ ที่อยากยกให้เป็นตัวอย่าง

• คำอธิบายที่สอนงานในตัว (Sanity) tool สอบถามข้อมูลของ Sanity เขียนไว้ว่า ถ้าไม่คุ้นกับ syntax GROQ ให้ไปดึงกฎจาก get_sanity_rules ก่อน [7] คือคำอธิบายไม่ได้บอกแค่ว่า tool ทำอะไร แต่บอกด้วยว่าถ้าไม่ถนัดให้ทำอะไรก่อน นี่คือการเขียนคำอธิบายเพื่อ AI อย่างแท้จริง
• ซ่อน tool ที่ไม่มีสิทธิ์ (Strapi) แทนที่จะให้ AI เห็น tool แล้วเรียกไปโดนปฏิเสธ ระบบกรองให้เห็นเฉพาะ tool ที่ token นั้นมีสิทธิ์ใช้ [8] AI จึงไม่เสีย round ไปกับการลองผิด
• ปิด tool ที่ไม่ใช้ (Directus) มีตัวแปร environment ให้ปิด tool ที่ทีมไม่ใช้ทั้ง deployment [11] ลดพื้นที่ให้ AI เลือกผิด
• แยกโซนงานจริงกับงานออกแบบ (Webflow) งานที่ต้องเปิดหน้าจอ Designer จริงต้องผ่านแอป Bridge แยกจาก tool ที่ทำงานกับข้อมูลล้วน ๆ [5] ทำให้การเชื่อมอนุญาตแคบลงเอง

จุดที่พลาดซ้ำกันทั้งสนาม

• คำอธิบายบรรทัดเดียว ครึ่งหนึ่งของสนามเขียนคำอธิบาย tool สั้นจน AI ไม่มีทางรู้ว่าเมื่อไหร่ควรใช้ ทั้งที่คู่มือของ Anthropic เน้นย้ำเรื่องนี้เป็นพิเศษ
• สิทธิ์กว้างเกินจำเป็น หลายเจ้ายังใช้ token ระดับบัญชีทั้งใบ ขัดกับหลัก least privilege ที่เอกสารความปลอดภัยของ MCP เองแนะนำไว้ [2] คือควรขอสิทธิ์เฉพาะเท่าที่จำเป็นและยกระดับเมื่อต้องใช้งานจริง
• การลบไม่มีด่าน นอกจากสองสามเจ้าแล้ว การลบข้อมูลถาวรส่วนใหญ่ไม่มีขั้นยืนยัน ทั้งที่นี่คือจุดที่ความเสียหายแก้คืนไม่ได้
• รูปแบบผลลัพธ์ไม่บอก หลายเจ้าไม่เขียนไว้เลยว่า tool คืนข้อมูลแบบไหน ทำให้ประเมินเรื่องความอ่านรู้เรื่องไม่ได้

สรุปสำหรับคนจะออกแบบ tool ของตัวเอง

บทเรียนที่สรุปได้จาก 13 ระบบนี้เรียงตามลำดับความคุ้มค่า

1. เริ่มจากงานที่คนทำจริง ไม่ใช่จากตาราง endpoint ถ้าเจอว่ากำลังสร้าง tool ทีละ endpoint ให้หยุดแล้วถามว่างาน 3 ขั้นตอนที่ใช้ต่อกันบ่อยที่สุดคืออะไร แล้วรวมมัน
2. ถ้า operation เยอะมาก ใช้แบบ list → describe → execute ของ WordPress หรือ search → describe → execute ของ Storyblok เพื่อให้ system prompt เล็กแต่ครอบคลุม
3. แยกประตูงานอ่าน งานเขียน และงานลบ เป็นคนละ tool แล้วบังคับยืนยันทุกการลบ
4. เขียนคำอธิบายแบบมีทิศทาง บอกเมื่อใช้ เมื่อไม่ใช้ และถ้ามี pattern ที่ต้องเรียนรู้ให้สอนไว้ในคำอธิบายเลย
5. ขอสิทธิ์แคบที่สุดเท่าที่งานต้องใช้ และออกแบบให้เลื่อนขั้นได้เมื่อต้องการสิทธิ์เพิ่ม

ข้อจำกัดของงานวิจัยนี้

เพื่อความโปร่งใส ขอระบุขอบเขตไว้ตรง ๆ การให้คะแนนอ้างจากเอกสารสาธารณะและ source code ที่เปิดไว้ ณ เดือนกันยายน 2026 โดยคะแนนทั้งหมดถูกปรับมาอยู่ในสเกลเดียวกัน 8 ข้อจากงานวิจัยย่อยสามชุดที่ใช้เกณฑ์เดียวกัน ไม่ได้ทดลองเรียกใช้จริงทุก tool ดังนั้นคะแนนบางข้อเช่นรูปแบบผลลัพธ์ที่คืนมา อาจต่างจากประสบการณ์ใช้งานจริง

และ MCP เป็นของใหม่ที่เจ้าไหนก็ปรับกันอยู่ทุกเดือน โดยเฉพาะ Duda ที่ป้าย beta ไว้ชัดเจน คะแนนวันนี้จึงเป็นภาพชั่วขณะ ไม่ใช่คำพิพากษา

สำหรับคนที่กำลังเลือกระบบทำเว็บและอยากให้ AI เข้ามาช่วยงานจริง คำถามที่ควรถามทีมขายของเจ้านั้น ๆ ก็คือ: ถ้าให้ AI จัดการเว็บผม มันเห็น tool กี่ตัว และการลบข้อมูลมีด่านกันกี่ชั้น ถ้าเจ้าไหนตอบได้ชัดแบบ WordPress หรือ Storyblok โอกาสที่ AI จะช่วยงานได้จริงโดยไม่สร้างเหตุการณ์ก็สูงกว่ามาก

แหล่งอ้างอิง

[1] Anthropic, Writing effective tools for agents: with agents (บล็อกวิศวกรรม), 11 กันยายน 2025. https://www.anthropic.com/engineering/writing-tools-for-agents

[2] MCP Security Best Practices, Model Context Protocol, 2026. https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices

[3] WordPress.com MCP Tools Reference, Automattic, 2026. https://developer.wordpress.com/docs/mcp/tools-reference/

[4] MCP Server, Storyblok Documentation, 2026. https://www.storyblok.com/docs/libraries/mcp-server

[5] Webflow MCP Tools: Data Tools, Webflow, 2026. https://developers.webflow.com/mcp/tools/data-tools

[6] Contentful MCP Server, GitHub, 2026. https://github.com/contentful/contentful-mcp-server

[7] Sanity MCP Server Documentation, Sanity, 2026. https://www.sanity.io/docs/ai/mcp-server

[8] Strapi MCP Server, Strapi 5 Documentation, 2026. https://docs.strapi.io/cms/features/strapi-mcp-server

[9] Duda MCP Server Reference, Duda, 2026. https://developer.duda.co/docs/mcp-server-reference

[10] Wix MCP, GitHub, 2026. https://github.com/wix/wix-mcp

[11] Directus Local MCP: Tools, Directus Documentation, 2026. https://directus.com/docs/guides/ai/mcp/local-mcp/tools