MCP คืออะไร: ต่อ AI Agent เข้ากับเครื่องมือจริงอย่างไรให้ไม่หลุดขอบเขต

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

ถ้าใช้ chatbot แบบทั่วไป AI อาจช่วยตอบคำถาม เขียน draft หรือสรุปข้อมูลที่เราป้อนเข้าไปได้ แต่พองานจริงเริ่มเกี่ยวกับไฟล์ใน Drive, ticket ใน helpdesk, issue ใน Git, calendar, CRM, database, internal wiki หรือระบบ automation คำถามจะเปลี่ยนทันทีว่า AI จะเข้าถึงอะไรได้บ้าง ทำอะไรแทนเราได้บ้าง และใครรับผิดชอบถ้ามันทำผิด

Model Context Protocol หรือ MCP ถูกออกแบบมาเพื่อตอบโจทย์นี้ในเชิงโครงสร้าง มันเป็น protocol เปิดที่ช่วยให้ application ฝั่ง AI เชื่อมกับเครื่องมือและแหล่งข้อมูลภายนอกผ่านรูปแบบที่สม่ำเสมอขึ้น แทนที่แต่ละ tool จะต้องมี integration เฉพาะทางของตัวเองทั้งหมด

บทความนี้เป็นตอนแรกของซีรีส์ MCP ผมจะไม่ลง production config หรือสอนต่อ server ทีละบรรทัด เพราะรายละเอียดขึ้นกับ client, server, transport, identity, network และข้อมูลของแต่ละองค์กร แต่จะวาง mental model ว่า MCP คืออะไร ใช้ทำอะไรได้บ้าง และต้องระวังอะไรถ้าจะนำไปใช้กับงานจริง

สาระตั้งต้นจากแหล่งข้อมูล

ก่อนเรียบเรียงเป็นบทความ ผมสรุปแก่นจากเอกสารทางการของ MCP และแนวคิดด้าน AI governance ไว้ก่อน:

1. MCP อธิบายตัวเองเป็น protocol เปิดสำหรับทําให้ application ให้ context กับ LLM ได้เป็นมาตรฐานมากขึ้น คล้ายการมีชั้นเชื่อมต่อกลางระหว่าง AI application กับระบบรอบตัว
2. โครงสร้างหลักมักพูดถึง host, client และ server: host คือ application ที่ผู้ใช้คุยด้วย, client คือส่วนเชื่อมต่อภายใน host, server คือระบบที่ expose ความสามารถหรือข้อมูลให้ AI ใช้ผ่าน MCP
3. MCP server สามารถเสนอความสามารถหลายแบบ เช่น tools สำหรับ action, resources สำหรับข้อมูลที่อ่านได้, และ prompts สำหรับ workflow หรือ template ที่เรียกใช้ซ้ำได้
4. ประเด็นสำคัญคือ MCP ไม่ได้ทำให้ AI "ปลอดภัยเอง" มันแค่ทำให้การเชื่อมต่อมีรูปแบบชัดขึ้น การตั้ง permission, approval, logging, data boundary และ owner ยังเป็นงานของคนออกแบบระบบ
5. Use case ที่ดีควรเริ่มจากงานเล็กและตรวจสอบได้ เช่น ค้น knowledge base, อ่าน ticket, draft report, สรุป pull request หรือเตรียม action item ไม่ควรเริ่มจากการให้ agent ทำงาน production-critical โดยไม่มี review

ถ้าแปลเป็นภาษาง่าย MCP ไม่ใช่เวทมนตร์ที่ทำให้ AI กลายเป็นพนักงานอัตโนมัติทันที แต่เป็น "ปลั๊กมาตรฐาน" ที่ช่วยให้เราต่อ AI เข้ากับเครื่องมือได้เป็นระบบขึ้น และเพราะมันต่อได้เป็นระบบขึ้น เราจึงต้องออกแบบขอบเขตให้เป็นระบบตามไปด้วย

MCP แก้ปัญหาอะไร

ก่อนมี pattern แบบ MCP เรามักเจอ integration แบบกระจัดกระจายครับ เครื่องมือหนึ่งต่อกับ AI แบบหนึ่ง อีกเครื่องมือมี API อีกแบบหนึ่ง บางอย่างต้องเขียน custom script บางอย่างต้อง copy-paste ข้อมูลเข้า prompt เอง บางอย่างใช้ browser automation แบบเปราะ ๆ และบางอย่างไม่มีใครแน่ใจว่า credential ถูกเก็บตรงไหน

ปัญหานี้ไม่ใช่แค่เรื่อง developer เหนื่อย แต่เป็นเรื่อง operation และ security ด้วย เพราะเมื่อ integration กระจายมาก ๆ จะตอบคำถามพื้นฐานยากขึ้น:

1. AI เข้าถึงข้อมูลชุดไหนได้บ้าง
2. AI เรียก action อะไรได้บ้าง
3. ข้อมูลที่ส่งเข้าโมเดลมีอะไรบ้าง
4. ถ้าต้องปิดสิทธิ์ ต้องปิดที่ไหน
5. ถ้า agent ทำผิด จะดู log จากตรงไหน
6. integration ตัวไหนเป็นของทดลองแต่ถูกใช้เหมือน production แล้ว

MCP ช่วยให้เราคิดเป็นชั้นเชื่อมต่อกลางมากขึ้น ตัว AI application ไม่จำเป็นต้องรู้รายละเอียดของทุกระบบโดยตรง แต่คุยกับ MCP server ที่ประกาศความสามารถออกมาอย่างเป็นรูปแบบ เช่น "อ่านรายการไฟล์ได้", "ค้น ticket ได้", "สร้าง draft ได้", หรือ "เรียก workflow นี้ได้"

สำหรับคนทำ IT หรือ security จุดที่น่าสนใจคือเราสามารถเริ่มคิดเรื่อง boundary ตั้งแต่ design ไม่ใช่ปล่อยให้ integration โตเองตามความสะดวกของแต่ละทีม

Mental model: host, client, server

ภาพง่าย ๆ คือ MCP มี 3 บทบาทหลัก:

1. Host: application ที่ผู้ใช้ใช้คุยกับ AI เช่น desktop app, IDE, internal assistant หรือ agent platform
2. Client: ตัวเชื่อมใน host ที่เปิด connection ไปยัง MCP server แต่ละตัว
3. Server: ตัวที่ expose tools, resources หรือ prompts จากระบบภายนอกให้ host เรียกใช้

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

ส่วนที่ควรแยกให้ออกคือ:

1. Resources: ข้อมูลที่ AI อ่านได้ เช่นเอกสาร reference, issue description, schema, knowledge base หรือไฟล์ context
2. Tools: การกระทำที่ AI ขอให้ระบบทำ เช่นค้นหา ticket, สร้าง draft, เปิด issue, ดึงข้อมูลจาก API หรือ trigger workflow
3. Prompts: template หรือ workflow ที่ server เสนอให้ใช้ซ้ำ เช่น prompt สำหรับสรุป incident, review policy หรือเตรียม report

ถ้าออกแบบดี เราจะรู้ว่าอะไรเป็นแค่การอ่าน อะไรเป็น action และ action ไหนต้องมี human approval ก่อนเสมอ จุดนี้สำคัญมาก เพราะคำว่า "AI ต่อ tool ได้" ฟังดูเล็ก แต่ในทางปฏิบัติ tool อาจหมายถึงการส่งอีเมล เปิด ticket เปลี่ยน config หรือดึงข้อมูลลูกค้าได้เลย

ตัวอย่างการประยุกต์ใช้ที่ practical

MCP เหมาะกับงานที่ AI ต้องมี context จากระบบจริง แต่ยังควรอยู่ในกรอบที่ตรวจสอบได้ ตัวอย่างที่ practical สำหรับทีมเล็กหรือ consultant มีหลายแบบ:

1. Internal knowledge assistant: ให้ AI ค้น policy, SOP, runbook, architecture note หรือ proposal template ที่จัดไว้แล้ว แทนการให้คนค้นเองทุกครั้ง
2. Support triage: ให้ AI อ่าน ticket, จัดกลุ่มปัญหา, เสนอ priority และ draft คำตอบ แต่ยังให้คน support กดส่งเอง
3. Security review helper: ให้ AI อ่าน checklist, asset list, finding template และช่วย draft observation โดยไม่ให้แตะระบบ production โดยตรง
4. Developer workflow: ให้ AI อ่าน issue, pull request, test result หรือ documentation แล้วช่วยสรุป context ก่อน developer ลงมือ
5. Meeting follow-up: ให้ AI ใช้โน้ตที่ผ่านการคัดข้อมูลแล้วสร้าง action item, owner และ follow-up email draft
6. Business operations assistant: ให้ AI อ่าน CRM หรือ project board ในขอบเขตที่กำหนด แล้วช่วยเตรียม weekly review หรือ reminder

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

สิ่งที่ไม่ควรเริ่มจาก MCP

มีบางงานที่ไม่ควรรีบเริ่มด้วย MCP แม้จะทำได้ทางเทคนิค:

1. งานที่ยังไม่มี process ชัด เช่นไม่มี owner, ไม่มี rule, ไม่มี input/output ที่ตกลงกัน
2. งานที่ข้อมูลอ่อนไหวสูงแต่ยังไม่มี classification หรือ access policy
3. งานที่ action ผิดแล้วแก้ยาก เช่นเปลี่ยน production config, ลบข้อมูล, ส่งอีเมลแทนคน, อนุมัติค่าใช้จ่าย หรือเปลี่ยนสิทธิ์ผู้ใช้
4. งานที่ไม่มี log หรือ audit trail
5. งานที่ทีมยังไม่รู้ว่า AI ใช้ข้อมูลอะไรตอบ

พูดแบบตรง ๆ คือถ้า workflow เดิมยังยุ่ง MCP อาจทำให้ความยุ่งนั้นเร็วขึ้น ไม่ได้ทำให้ดีขึ้นโดยอัตโนมัติ เหมือนเอาท่อมาต่อกับบ้านที่ยังไม่รู้ว่าน้ำควรไหลไปทางไหน สุดท้ายอาจรั่วเร็วกว่าเดิม

ก่อนทำ MCP server จริง ผมจะแนะนำให้เขียน use case card สั้น ๆ:

1. ผู้ใช้คือใคร
2. AI ต้องอ่านข้อมูลอะไร
3. AI เรียก action อะไรได้
4. action ไหนต้องขออนุมัติ
5. ข้อมูลอะไรห้ามส่งให้ AI
6. log ต้องเก็บอะไร
7. ถ้า agent ทำผิด จะย้อนกลับอย่างไร

ถ้าตอบไม่ได้หลายข้อ แปลว่ายังไม่ควรเริ่มจาก implementation ควรเริ่มจาก workflow design และ data boundary ก่อน

Guardrail ที่ควรมีตั้งแต่แรก

MCP ทำให้การเชื่อมต่อเป็นระเบียบขึ้น แต่ guardrail ต้องออกแบบเองครับ อย่างน้อยควรคิดเรื่องเหล่านี้:

1. Least privilege: server แต่ละตัวควร expose เฉพาะ tool/resource ที่ use case ต้องใช้จริง
2. Read before write: เริ่มจากอ่านและ draft ก่อน อย่าเริ่มจาก action ที่เปลี่ยน state ทันที
3. Human approval: action ที่ส่งผลต่อคน ลูกค้า เงิน production หรือสิทธิ์ผู้ใช้ควรมี approval
4. Audit log: ต้องรู้ว่าใครสั่ง agent, agent เรียก tool ไหน, input/output สำคัญคืออะไร และผลลัพธ์เป็นอย่างไร
5. Data boundary: แยกข้อมูล public, internal, confidential และ client-specific ให้ชัด
6. Revocation: ถ้าต้องปิด access ต้องรู้ว่าปิด server, credential หรือ permission ตรงไหน
7. Testing environment: ทดลองกับข้อมูลจำลองหรือ read-only ก่อนแตะข้อมูลจริง

เรื่องนี้เชื่อมกับ AI Governance สำหรับทีมเล็ก: ไม่ต้องมีเอกสารร้อยหน้า แต่ต้องมีขอบเขต โดยตรง เพราะ MCP ไม่ใช่แค่เรื่อง developer ต่อ API แต่เป็นเรื่องว่าองค์กรยอมให้ AI ทำอะไรกับข้อมูลและระบบงานของตัวเอง

Checklist ก่อนเริ่มใช้ MCP ในงานจริง

ถ้าจะเริ่มทดลอง MCP แบบไม่หลุด ผมจะใช้ checklist นี้:

1. Use case นี้ช่วยลดงานซ้ำหรือเพิ่มคุณภาพการตัดสินใจจริงไหม
2. ข้อมูลที่ AI ต้องอ่านอยู่ที่ไหน และมี owner หรือไม่
3. ข้อมูลนั้นมี personal data, client data หรือ secret ปนอยู่หรือไม่
4. MCP server ต้อง expose resource หรือ tool อะไรบ้าง
5. มี action ไหนที่ควรเป็น read-only หรือ draft-only
6. มี approval point ตรงไหนก่อน action จริง
7. ต้องเก็บ log อะไรเพื่อสืบย้อนหลัง
8. ถ้า agent ตอบผิดหรือทำผิด คนจะตรวจพบอย่างไร
9. มีวิธีปิด access เร็วไหมถ้าพบปัญหา
10. คนใช้เข้าใจหรือไม่ว่า AI เห็นข้อมูลและทำอะไรได้บ้าง

ถ้าเป็น consultant หรือทีม IT ที่ต้องให้คำแนะนำลูกค้า จุดที่ขายความเชี่ยวชาญไม่ได้อยู่ที่ต่อ MCP ได้เร็วที่สุด แต่อยู่ที่เลือก use case ที่เหมาะ วาง boundary ให้ชัด และไม่ทำให้ลูกค้าเข้าใจผิดว่า agent จะรับผิดชอบแทนคนได้

บทความ AI สำหรับงานเอกสารเทคนิค: วิธีลดเวลาเขียน SOP, runbook และ checklist โดยไม่ลดความน่าเชื่อถือ เป็นตัวอย่าง use case ที่เหมาะกับ MCP มาก เพราะ AI สามารถอ่าน context ที่ผ่านการจัดระเบียบแล้ว ช่วย draft เอกสาร และให้คนตรวจคุณภาพก่อน publish

สรุป

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

ถ้าเริ่มจาก use case เล็ก ๆ เช่นค้น knowledge base, อ่าน ticket, draft report หรือสรุป context สำหรับ developer MCP จะช่วยให้ AI มีประโยชน์กว่าการ copy-paste ข้อมูลเข้า chatbot มาก แต่ถ้าเริ่มจากการให้ agent ทำ action สำคัญโดยไม่มี permission, approval และ audit มันก็เพิ่ม attack surface และ operational risk ได้เร็วมากเช่นกัน

ตอนถัดไปของซีรีส์นี้ควรลงลึกเรื่องการออกแบบ MCP use case card และ permission model ก่อนเขียน server จริง เพราะในงาน production คำถามสำคัญไม่ใช่ "ต่อได้ไหม" แต่คือ "ควรให้ต่อแค่ไหน และใครรับผิดชอบเมื่อมันทำงานแล้ว" ครับ

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

• Model Context Protocol: Introduction
• Model Context Protocol: Architecture
• Model Context Protocol: Tools
• Model Context Protocol: Resources
• Model Context Protocol: Prompts
• NIST AI Risk Management Framework