บทที่ 11 · เชื่อมกับโลก · MCP — The Access Protocol

MCP — โปรโตคอลการเข้าถึง

ผู้ช่วยของเราพึ่งเครื่องมือมากขึ้นเรื่อย ๆ — ถึงเวลา ทำให้การเข้าถึงข้อมูล/การกระทำเป็นมาตรฐาน นั่นคือสิ่งที่ MCP (Model Context Protocol) ทำ และจุดที่คนส่วนใหญ่พลาด: MCP ไม่ได้มีแค่ “tools” แต่มีสามแบบ — tools · resources · prompts — แต่ละแบบบอกว่า ใครเป็นคนคุม

พูดแบบเข้าใจง่าย

MCP คือมาตรฐานเปิดสำหรับต่อแอป LLM เข้ากับความสามารถภายนอก มี 3 บทบาท: HOST (แอปที่ผู้ใช้รัน เช่น Claude Code), CLIENT (ตัวเชื่อมในโฮสต์ หนึ่งตัวต่อเซิร์ฟเวอร์), และ SERVER (สิ่งที่เปิดเผยความสามารถ) และเซิร์ฟเวอร์เปิดเผยได้ 3 แบบ — เส้นแบ่งคือ “ใครคุม”:

กับดักความปลอดภัยชื่อดัง: confused deputy — เซิร์ฟเวอร์เอา token สิทธิ์สูงของตัวเองไปใช้แทนใครก็ตามที่เรียกมา และ scope guard ไม่ใช่การพิสูจน์ตัวตน

เปรียบเทียบ: เคาน์เตอร์ต้อนรับของโรงแรม แขกไม่เดินเข้าครัวหรือห้องเซฟ — เขาไปที่เคาน์เตอร์ ซึ่งให้บริการ 3 แบบ สิ่งที่พนักงาน “ทำ” ให้เมื่อขอ = tools (แม้แค่ “บอกอุณหภูมิสระ” ก็เป็น tool เพราะต้อง “ขอ”), แฟ้มอ้างอิงบนเคาน์เตอร์ (แผนที่ เมนู ทางหนีไฟ) = resources, แบบฟอร์มสำเร็จรูปในชั้นวาง = prompts ที่แขกเลือกหยิบเอง ส่วน confused deputy = พนักงานใช้ “กุญแจมาสเตอร์” เปิดห้องที่ใครชี้ให้ แทนการเช็คกุญแจของแขกคนนั้น

ในระบบของเรา — เซิร์ฟเวอร์ที่เป็น “tools-only”

Hostแอปที่ผู้ใช้รัน
→
discoverถามเซิร์ฟเวอร์ว่ามีอะไรบ้าง (รีโหลดสด)
→
toolsคืน 56 tool · 0 resources · 0 prompts
→
invokeโมเดลเรียก tool ที่ต้องใช้

เซิร์ฟเวอร์ MCP ของเรา อ่านแค็ตตาล็อกใหม่ทุกครั้งที่ถาม (แก้รายการแล้วเห็นผลทันทีโดยไม่ต้องรีสตาร์ต) — เป็น discovery ที่ถูกต้องตามสเปก แต่มันเป็น tools-only: คู่มือนักศึกษาซึ่ง ควรเป็น resource กลับเข้าถึงได้ทาง tool ค้นหาเท่านั้น และ ผัง OBE ของหลักสูตร (Classroom → LLO → CLO → PLO) คือตัวอย่างที่เหมาะจะเป็น “resource ตัวแรก” ของเรา — กราฟอ้างอิงที่โฮสต์แนบให้อ่านได้ตรง ๆ แทนที่จะต้องให้โมเดลเรียก tool มาประกอบเอง

ทำพลาด vs ทำถูก

⚠️ แย่ · ยัด resource ให้เป็น tool
คู่มือ = tool ค้นหา
เอกสารอ้างอิง read-only ที่เหมาะเป็น resource กลับเข้าถึงได้ผ่าน tool ที่โมเดล “ต้องนึกจะเรียก” เท่านั้น — มันลืมเรียก เรียกผิดจังหวะ หรือเปลืองเทิร์นได้ ทั้งที่แอปแนบให้ตั้งแต่ต้นได้
⚠️ แย่ · confused deputy
scope guard ≠ การพิสูจน์ตัวตน
เซิร์ฟเวอร์เอา token สิทธิ์สูงของตัวเองรันคำขอของใครก็ได้ที่ต่อเข้ามา — gate แบบ “ยืนยันก่อนทำ” กันอุบัติเหตุ แต่ ไม่ได้พิสูจน์ว่าใครเรียก ต้องผูกสิทธิ์กับตัวตนของผู้เรียกเอง
✅ ดี · discovery + รู้ว่าอะไรควรเป็น resource
tools-only แต่รู้ตัว
เซิร์ฟเวอร์ที่ list ความสามารถได้และรีโหลดแค็ตตาล็อกสด ๆ คือ discovery ที่ถูก — และทักษะคือ มองออกว่า “นี่ควรเป็น resource” (ผัง OBE) เพื่อให้โฮสต์ปักข้อมูลให้ตั้งแต่ต้น

ลองเอง — จัดความสามารถเข้า tools / resources / prompts

กิจกรรม · คลิกจัดลงถัง (3 ทาง)
Who's in Control?
จัดความสามารถ 8 อย่างลง 3 ถัง — เส้นแบ่งคือ “ใครคุม” ไม่ใช่ “อ่านหรือเขียน” ระวังกับดัก: tool ที่ read-only ก็ยังเป็น tool! แล้วกด “เผยว่าเซิร์ฟเวอร์จริงทำอะไร”
คลิกเลือกการ์ด แล้วคลิกถัง → ตรวจ → เผย
มองไปข้างหน้า — มาตรฐานแล้ว แต่ต้อง “เบา” ด้วย MCP ทำให้การเข้าถึงเป็นมาตรฐาน แต่ยิ่งมี tool เยอะ definitions และผลลัพธ์ก็ยิ่งท่วม context บทที่ 12 ว่าด้วย Skills (แพ็กวิธีทำงานซ้ำ) และ การคุมพื้นที่ context ให้พื้นผิว tool เบา

สรุปบทที่ 11

Harness Scorecard · มิติ: “รูปแบบ MCP เหมาะกับงานไหม?” ผู้ช่วย/ระบบเรา: ◑ — discovery ถูกต้องและรีโหลดสด แต่ยัง tools-only (resources/prompts ยังว่าง) ผัง OBE คือ resource ตัวแรกที่ควรทำ

📋 build-your-harness checklist · บรรทัดที่ 10 “ทำการเข้าถึงให้เป็นมาตรฐาน (MCP) + เลือกชนิดให้ถูก: tools (โมเดลคุม) · resources (แอปแนบ) · prompts (ผู้ใช้เลือก)”
← ก่อนหน้า
10 — นี่แหละ Harness
หมายเหตุข้อมูล: ตัวเลข 56 tools · 0 resources · 0 prompts สะท้อนรูปจริงของเซิร์ฟเวอร์ MCP ของเรา (ตรวจ 2026-05-29) การ์ดในกิจกรรมเป็นตัวอย่างเชิงแนวคิด เซิร์ฟเวอร์จริงยังไม่ได้ทำ resources/prompts (จึงติดสแตมป์ “ยังไม่ได้ทำ”)