MDN MCP: เมื่อ Coding Agent ต้องอ่านเอกสารจริงก่อนตอบ

AI coding agent เก่งขึ้นทุกเดือนครับ แต่ปัญหาหนึ่งที่ยังเจอบ่อยคือมันตอบจาก “ความจำของโมเดล” มากเกินไป

ถ้าเป็นเรื่องทั่วไปอาจไม่หนักมาก แต่ถ้าเป็นงานเขียนเว็บ ต่อ API หรือเช็ค browser compatibility ข้อมูลเก่าหรือข้อมูลจำผิดอาจทำให้ทีมเสียเวลาหลายชั่วโมง

MDN เพิ่งเปิดตัว MDN MCP server เพื่อแก้ปัญหานี้ในมุมของ web development

มันเป็น MCP server ที่ให้ AI tool หรือ coding agent เข้าถึง MDN documentation และ browser compatibility data ได้โดยตรง

ฟังดูเหมือนเป็น release เล็ก ๆ แต่ผมมองว่านี่เป็นสัญญาณใหญ่ของ agent workflow ครับ

1) ปัญหาจริงไม่ใช่ AI ไม่รู้ แต่คือ AI ไม่รู้ว่าต้องเช็คจากไหน

เวลาเราใช้ coding agent เขียนโค้ด มันอาจอธิบาย syntax ได้ดีมาก

แต่คำถามแบบนี้เสี่ยงกว่า:

• CSS feature นี้ browser ไหนรองรับแล้วบ้าง
• Web API นี้ใช้ production ได้ไหม
• attribute นี้เพิ่ง ship หรือยัง experimental
• วิธีใช้ล่าสุดตาม official docs คืออะไร

ถ้า agent ตอบจาก training data อย่างเดียว ข้อมูลอาจค้างอยู่ที่อดีต

MDN ยกตัวอย่างว่า LLM หรือ coding agent อาจไม่รู้ว่า feature อย่าง @view-transition มีอยู่แล้ว หรือ feature บางตัวถึงระดับ Baseline Widely Available หรือยัง

นี่คือ pain ที่ developer เจอจริงครับ ไม่ใช่แค่เรื่องตอบผิดในแชท แต่คือตอบผิดแล้วเอาไปเขียนโค้ดจริง

2) MDN MCP ทำอะไร

MDN MCP server ต่อ MDN เข้าไปเป็น source of truth ให้ agent

แทนที่ coding agent จะเดาจากความจำ หรือไปค้นเว็บแบบกว้าง ๆ มันสามารถเรียกข้อมูลจาก MDN ที่เป็นแหล่งอ้างอิงหลักของ web platform ได้

หน้า MDN MCP ระบุว่า server นี้ให้ access กับ:

• MDN search
• MDN documentation
• browser compatibility data

ตัวอย่าง command ที่ MDN ให้สำหรับ Claude Code คือ:

claude mcp add --transport http mdn https://mcp.mdn.mozilla.net/

แต่สาระไม่ได้อยู่ที่ command ครับ

สาระคือ agent เริ่มมี “ทางเดินไปหาเอกสารจริง” แทนที่จะตอบจากความจำอย่างเดียว

3) MDN ทดสอบแล้วต่างตรงไหน

MDN ทดสอบ Claude Code Opus 4.7 กับคำถามเกี่ยวกับ web features ที่เพิ่ง ship ใน Firefox 151

เขาเทียบคำตอบแบบเปิด MDN MCP กับไม่เปิด MDN MCP

ผลที่น่าสนใจคือคำอธิบายวิธีใช้งานบางข้ออาจพอใกล้กัน แต่จุดที่ MCP ช่วยชัดมากคือ browser support information

ตัวอย่างหนึ่งคือ shadowrootslotassignment

MDN บอกว่า Claude Code แบบไม่ใช้ MCP ตอบว่า attribute นี้รองรับใน Chrome 120 และ Safari 18.3 ซึ่งน่าจะสับสนกับ slotAssignment option ของ Element.attachShadow()

แต่ข้อมูลจริงตาม MDN คือ Firefox 151 เป็น browser แรกที่ ship support สำหรับ attribute นี้

นี่เป็นตัวอย่างที่ดีมาก เพราะมันทำให้เห็นว่า AI ไม่ได้พลาดเพราะเขียนโค้ดไม่ได้ แต่มันพลาดเพราะบริบทล่าสุดของ platform ไม่อยู่ในหัว

4) บทเรียนสำหรับธุรกิจ: MCP ไม่ใช่แค่ปลั๊กอิน แต่มันคือชั้น source of truth

หลายทีมเริ่มพูดว่า “ต้องต่อ MCP ให้ AI”

แต่ผมอยากให้ระวังนิดหนึ่งครับ ถ้าเราคิดว่า MCP คือการเพิ่มปลั๊กอินให้ agent เรียก tool ได้เยอะ ๆ เราอาจพาทีมไปเสี่ยงกว่าเดิม

ในมุม operator MCP ควรถูกมองเป็นชั้น source of truth และ governance

คำถามที่ควรถามก่อนต่อ MCP คือ:

1. แหล่งข้อมูลนี้เชื่อถือได้ไหม
2. ใครเป็นเจ้าของและอัปเดตข้อมูล
3. agent อ่านได้อย่างเดียว หรือแก้ไขข้อมูลได้ด้วย
4. มี log ไหมว่า agent เรียก tool อะไร
5. ข้อมูลไหนห้ามส่งออกไปยัง external service
6. งานไหนต้องมีคน review ก่อนใช้ผลลัพธ์

สำหรับ MDN กรณีนี้ค่อนข้างชัด เพราะเป็นเอกสารสาธารณะสำหรับ web platform

แต่ถ้าเปลี่ยนเป็น CRM, finance, HR, customer support หรือ internal policy เรื่องจะละเอียดกว่านี้มาก

5) จุดที่ต้องระวัง: experimental ไม่ได้แปลว่า production-ready

MDN ระบุชัดว่า MDN MCP server ยังเป็น experiment และอาจถูกถอนเมื่อไรก็ได้

หน้า MDN MCP ยังบอกด้วยว่าช่วงทดลองจะมีการเก็บข้อมูล query ที่ได้รับ และแม้ข้อมูลนั้นจะไม่ถูกผูกกับข้อมูลที่ออกแบบมาเพื่อระบุตัวบุคคล แต่ก็มีความเป็นไปได้ว่า private information ที่ผู้ใช้ส่งให้ LLM อาจรวมอยู่ใน query ได้

นี่เป็น caveat ที่ดีมากครับ

เพราะมันเตือนเราว่า “ต่อ tool แล้วแม่นขึ้น” ไม่ได้แปลว่า “ต่อได้ทุกข้อมูล”

ถ้าจะใช้กับงานธุรกิจ ต้องแยกอย่างน้อย 3 ชั้น:

• ข้อมูลสาธารณะ เช่น docs, changelog, API reference
• ข้อมูลภายในที่อ่านได้ เช่น SOP, policy, knowledge base
• ข้อมูลเสี่ยงสูง เช่น customer data, contract, financial data, credential, production system

แต่ละชั้นควรมี permission และ approval ไม่เหมือนกัน

6) วิธีเอาบทเรียนนี้ไปใช้แบบไม่เสี่ยงเกินไป

ถ้าทีมของคุณกำลังเริ่มใช้ AI Agent หรือ coding agent ผมแนะนำให้เริ่มจาก workflow ที่ข้อมูลเป็นสาธารณะหรือเสี่ยงต่ำก่อน

เช่น:

• ให้ coding agent เช็ค docs ล่าสุดก่อนใช้ library
• ให้ agent สรุป compatibility จาก official docs
• ให้ agent ทำ checklist migration จาก release notes
• ให้ agent เทียบ API docs กับโค้ดใน repo
• ให้ agent เปิด PR แบบมี source link และเหตุผลประกอบ

จากนั้นค่อยเพิ่มระดับความเสี่ยง โดยต้องมี control เพิ่มตามไปด้วย

งานอ่านเอกสาร อาจให้ agent ทำเองได้ งานแก้ไฟล์ ให้ทำใน branch หรือ sandbox งานแตะ production, ลูกค้า, เงิน หรือ public channel ต้องมีคน approve

นี่คือความต่างระหว่าง “AI ที่ตอบเร็ว” กับ “AI ที่ทำงานในระบบธุรกิจได้จริง”

7) Data-Espresso take

ในความเห็นของผม MDN MCP เป็นข่าวเล็กที่ชี้ภาพใหญ่ครับ

อนาคตของ AI Agent จะไม่ใช่การถามว่าโมเดลไหนฉลาดที่สุดอย่างเดียว แต่จะถามว่า agent ตัวนี้ต่อกับ source of truth ถูกไหม มี permission ถูกไหม มี log ไหม และรู้ไหมว่าเมื่อไรต้องให้คนตรวจ

สำหรับทีมไทยที่กำลังเริ่มใช้ coding agent ผมจะสรุปเป็น rule ง่าย ๆ แบบนี้:

อย่าให้ agent เดาในเรื่องที่มีเอกสารจริงให้เช็ค

ถ้ามี official docs ให้ต่อ docs ถ้ามี system of record ให้ต่อแบบอ่านอย่างปลอดภัย ถ้ามี action เสี่ยง ให้ใส่ human review ถ้ามีข้อมูลส่วนตัวหรือข้อมูลลูกค้า ให้ตั้ง boundary ก่อน ไม่ใช่ค่อยมาแก้ทีหลัง

สรุป

MDN MCP ไม่ใช่แค่ server ใหม่ในกระแส MCP ครับ

มันเป็นตัวอย่างที่ดีว่า AI Agent ที่ใช้งานจริงควรถูกออกแบบให้หยุดเดา และไปอ่านข้อมูลจากแหล่งที่น่าเชื่อถือก่อนตอบ

แต่ในขณะเดียวกัน MDN ก็เตือนชัดว่า server นี้ยัง experimental และมีประเด็นเรื่อง query data ที่ต้องอ่านให้เข้าใจก่อนใช้

เพราะฉะนั้นบทเรียนสำหรับธุรกิจคือ:

ต่อ source of truth ให้ agent แต่อย่าลืมต่อ policy, privacy boundary, log และ human review ไปพร้อมกัน

สุดท้าย AI ที่น่าใช้ ไม่ใช่ AI ที่ตอบเร็วที่สุดครับ แต่คือ AI ที่รู้ว่าเมื่อไรต้องเช็คหลักฐานก่อนตอบ