เรียนรู้วิธีสร้างเซิร์ฟเวอร์ MCP ระยะไกลสำหรับผลิตภัณฑ์ SaaS ของคุณ เราแบ่งปันประสบการณ์เกี่ยวกับ MCP เทียบกับ Agent Skills, การผสานรวม OAuth และการออกแบบเครื่องมือ MCP
ผลิตภัณฑ์ SaaS ประสบปัญหามายาวนาน: เวลาสู่คุณค่า (time-to-value) ช้ามาก ผู้ใช้จำนวนมากเลิกใช้ก่อนจะถึงช่วง "aha moment"
เราได้ปรับปรุงขั้นตอน onboarding ของ Logto หลายครั้ง แม้จะช่วยได้แต่จุดติดขัดก็ยังคงอยู่ สุดท้ายคุณก็ต้องอ่านเอกสาร ไล่ดู tutorial ติดตั้ง SDK เชื่อมต่อการตั้งค่า เขียนโค้ด แล้ว debug อีก 10% ก่อนจะใช้งานได้จริง
เราจึงลองวิธีใหม่: สร้างเซิร์ฟเวอร์ MCP ระยะไกลให้เป็นศูนย์กลางควบคุม (control plane) ที่ฝังใน IDE แทนที่จะต้องคลิกบน admin console คุณสามารถตั้งค่า Logto และสร้างโค้ดเชื่อมต่อได้ทันทีผ่านบทสนทนา ขณะที่กำลังพัฒนาแอป
เพียงแค่ prompt เดียวก็สามารถเปลี่ยนจากศูนย์ไปสู่การเชื่อมต่อที่ใช้งานได้ เอเจนต์ไม่เพียงแค่สร้างโค้ด แต่ยังสร้างและเซ็ตอัปแอปพลิเคชัน Logto ใน tenant ของคุณ ทั้งหมดนี้ทำจากใน IDE ของคุณ (ลองใช้ Logto MCP Server)
ในบทความนี้ ฉันจะแบ่งปันประสบการณ์และแนวคิดในการสร้าง Logto MCP Server รวมถึง:
ก่อนจะตัดสินใจว่าจะให้ AI เข้าถึง Logto อย่างไร เราประเมินสองทางเลือก: MCP Server และ Agent Skills
MCP Server มีสองรูปแบบ: local และ remote
Local MCP server จะรันบนเครื่องของผู้ใช้ ต้องติดตั้งบริการ ตั้งค่าสภาพแวดล้อม ใช้ credential หรือวิธี login เฉพาะ ด้านการใช้งานและการจัดส่งจะเหมือน skill
ส่วน remote MCP server โฮสต์อยู่ฝั่ง server ผู้ใช้เชื่อมต่อผ่าน URL และอนุญาตด้วย OAuth โมเดลนี้คล้ายกับการขยายบริการ SaaS
ถ้ามองในเชิงโครงสร้าง Agent Skill คือการรวม "business logic + underlying capabilities" ความสามารถเหล่านี้อาจอยู่ในรูปของเครื่องมือ, CLI หรือ API call โดยเครื่องมือ MCP สามารถรองรับเลเยอร์นี้อย่างเป็นหนึ่งเดียว
คำถามหลักจึงไม่ใช่ว่าความสามารถถูกสร้างอย่างไร แต่ส่งถึงผู้ใช้อย่างไร
Agent Skills ส่งมอบ: toolchain แบบ local ครบชุด (Skill package + local runtime + API key หรือ platform credential + CLI + ชุดติดตั้ง, ตั้งค่า, อัปเกรด, บำรุงรักษา)
สาระสำคัญคือให้ผู้ใช้ขับเคลื่อนความสามารถเอง
Remote MCP server ส่งมอบ: จุดเข้าใช้บริการระยะไกล (URL + OAuth login)
สาระสำคัญคือให้ความสามารถในรูปแบบ service
ด้านล่างนี้ เราเปรียบเทียบในแง่ประสบการณ์ผู้ใช้ ขอบเขต ecosystem และภาระต้นทุน
Agent Skills มักต้องใช้ platform API หรือ CLI ผู้ใช้ต้องสร้าง API key หรือติดตั้งและล็อกอิน CLI ก่อน แม้แต่ละขั้นตอนอาจไม่ซับซ้อนแต่เพิ่มอุปสรรคในการเริ่มต้น
MCP server รองรับ OAuth ผู้ใช้เข้าสู่ระบบด้วยบัญชี SaaS ประสบการณ์คล้าย "Sign in with Google"
สำหรับผู้ใช้ MCP server ใช้งานง่ายมาก: กรอก URL, login, เชื่อมต่อ นี่คือประสบการณ์ที่เราอยากส่งมอบ
ใน MCP เว็บไซต์ มี AI app ที่รองรับ MCP กว่า 104 ตัว เช่น VS Code, Cursor, Windsurf เป็นต้น
Agent Skills ยังคงขึ้นกับแต่ละแพลตฟอร์ม แม้หลาย platform จะเริ่มรองรับแต่หากเราส่งมอบ MCP server ผู้ใช้ใช้ได้ทันที ถ้าปล่อย Skill เฉพาะ platform นั้นเท่านั้นจึงจะใช้งาน
MCP ยังได้รับการสนับสนุนโดย Agentic AI Foundation (AAIF) ซึ่งเป็นมาตรฐานระดับ protocol ecosystem จะโตขึ้นเรื่อย ๆ ซึ่งทำให้เราคิดว่าคุ้มค่าสำหรับการลงทุนระยะยาว
Agent Skills ต้องอาศัย platform API หรือ CLI ซึ่งนำปัญหามาอย่างรวดเร็ว:
คุณต้องแจกจ่าย CLI, จัดการ credential กระจัดกระจาย, ปรับให้รองรับหลายแพลตฟอร์ม, แนะนำผู้ใช้อัปเกรด ผลตอบแทนการลงทุนต่ำมาก
MCP server ง่ายกว่ามาก ผู้ใช้เพียงเชื่อมต่อ URL ซึ่งนำไปยังเวอร์ชั่นล่าสุดตลอด เราอัปเดต MCP server ได้เลย ครั้งต่อไปที่ผู้ใช้เชื่อมต่อก็ได้อัปเกรดอัตโนมัติ หาก API เปลี่ยน เราอัปเดตใน MCP server ได้
ผลิตภัณฑ์ SaaS ส่วนใหญ่มีโครงสร้างพื้นฐานที่แข็งแรงอยู่แล้ว เช่น API ที่สมบูรณ์ ระบบ auth ที่ดี การเพิ่ม MCP server คือการสร้าง "AI interface" บน API เหมือน admin console ที่เป็นอีกหนึ่ง interface ของ API เดียวกัน
สำหรับ Logto การเลือก MCP server เหมาะกับสถาปัตยกรรมและข้อได้เปรียบของเรา
รวมศูนย์ทุก request ให้อยู่ที่จุดเดียว จัดการ log กำกับ audit ง่าย สิทธิ์ชัดเจน: AI ทำได้เท่าที่ผู้ใช้อนุญาต โมเดลนี้เหมาะกับกรณี enterprise และ compliance มากกว่า
MCP ยังไม่สมบูรณ์ ส่วนใหญ่เป็นปัญหาด้านความสมบูรณ์ของ ecosystem จะดีขึ้นตามกาลเวลา ในระหว่างนี้เราหาทางแก้ชั่วคราวเพื่อตอบโจทย์ธุรกิจจริง
สเปค MCP กำหนดฟีเจอร์หลายอย่าง แต่ client สนับสนุนต่างกัน:
mcp-remote เป็นสะพานเชื่อมปัจจุบัน เครื่องมือเป็นเลเยอร์ที่เชื่อถือได้มากที่สุด (ดูข้อมูลเพิ่มเติมที่ MCP Community Page ว่า client ไหนรองรับฟีเจอร์อะไรบ้าง)
ยุทธศาสตร์ของเราคือ: สร้างบนพื้นฐานเครื่องมือ
นี่เป็นปัญหาในชั้น business
Agent Skills: logic และบริบทถูกแพ็กด้วยกัน ทำให้ LLM ใช้งานได้เลย MCP มีแต่เครื่องมือ ต่อให้เชื่อมต่อ LLM ก็ไม่รู้:
MCP มีแนวคิด Instructions แต่ client ไม่รองรับทั้งหมด Instructions ยังดันข้อมูลทั้งหมดเข้า context ตอนเชื่อมต่อ ทำให้เปลือง token
อีกไอเดีย คือใส่แนวทางแนะนำในคำอธิบายเครื่องมือ แต่นี่สร้างปัญหา 2 ข้อ:
แนวทางเราคือ: เพิ่มเครื่องมือ getInstructions
ไอเดียคือ ถ้า instruction ไม่เวิร์กก็เปลี่ยนเป็นเครื่องมือ
LLM ขอเรียกใช้ getInstructions ได้ตามสถานการณ์
ถ้างาน A ก็เรียก getTaskAInstructions MCP server ตอบกลับ prompt อธิบายวิธีทำ task A และวิธีใช้เครื่องมืออื่นร่วมกัน
Logic ธุรกิจซับซ้อนอยู่หลังเครื่องมือกลุ่ม instruction เครื่องมืออื่น ๆ เรียบง่าย คำอธิบายโฟกัสเฉพาะฟังก์ชันแต่ละตัว
คล้าย Agent Skill ตรงที่โหลด prompt แบบออนดีมานด์ ได้ประสิทธิภาพกว่าเพราะไม่ดันทุกอย่างเข้า context
SaaS หลายตัวมี secret ที่ห้ามเปิดเผย (client secret, API key, webhook signing key ฯลฯ) ถ้าหลุดออกไปคนอื่นจะสวมรอยหรือเข้าถึง resource ตรงๆ ได้
LLM มีความเสี่ยงเพราะช่องแชทไม่ใช่ช่องปลอดภัย message อาจถูกบันทึก, คัดลอก, ส่งต่อ, หรือจบลงใน log debug คุณไม่สามารถแน่ใจว่า "มีแค่ฉันกับโมเดลที่เห็น" เพราะหากให้ secret แบบอายุยาว หรือให้ LLM แจ้ง secret เพื่อลอก ก็มีความเสี่ยงสูง
นี่เกิดขึ้นเสมอใน web app integration แบบเดิม: dev มักเอา secret ลง env var หรือไฟล์ config เพื่อเซ็ตอัป SDK
เพื่อให้ onboarding ง่ายแต่ยังปลอดภัยต่อ secret เราทำสามอย่าง:
Logto มี Management API ครบ ในตอนแรกเราคิดจะเปิดทุก endpoint เป็น MCP tool
แต่พบว่าล้มเหลวทันที
อย่างแรก context ระเบิด Logto มี API เยอะ แมปตรง 1-1 ทำให้ context window เต็มไว คำอธิบายแต่ละเครื่องมือต้องใช้ token
อย่างที่สอง ความหมายหายไป API คือหน่วยพื้นฐานสำหรับ dev แต่ผู้ใช้ Logto MCP ไม่ได้สร้างระบบเอง แค่อยากเสร็จงานเป็นราย task ไม่สนใจว่า API กี่ตัว
เช่น Logto มี API sign-in-experience สำหรับ branding, วิธีการล็อกอิน/สมัคร, security policy
แรก ๆ เราก็คิดจะเปิดทุก optionให้ LLM หรือสอนให้เรียก call ต่าง ๆ รวมกัน
แต่วิธีคิดนี้ผิด เพราะ user ไม่ได้เรียก API เขาอยากเปลี่ยน branding หรือปรับวิธีล็อกอิน
ดังนั้นเครื่องมือควรเป็น updateBranding, updateSignInMethod, updateSignUpMethod ส่วน MCP server จะจัดการรวม API ในเบื้องหลัง
Logto MCP Server ควรคิดแบบ product ไม่ใช่ API wrapper จัดได้ว่าเป็น "admin console อีกรูปแบบ"
กติกาชัดเจน:
read_file, write_file แล้วเอเจนต์ค่อยใช้สร้างฟังค์ชันเพิ่มหลักเสริม:
getInstructions ช่วยโหลดคำแนะนำแบบออนดีมานด์ คำอธิบาย instruction tools ก็อย่าให้รกระหว่างสร้าง MCP server เราก็นึกถึงสิ่งที่ ecosystem ควรปรับปรุง
บางครั้ง MCP server ต้องให้ทั้งเครื่องมือและแนวทางการผสมเครื่องมือเป็น task แบบ Agent Skill
พบได้ทั่วไปใน SaaS เช่น GitHub MCP, Logto MCP, แพลตฟอร์ม analytics ผู้ใช้เน้น workflow ไม่ใช่ call เล็ก ๆ
getInstructions เป็นทางแก้ระยะสั้น ถ้าช่วยได้ที่ระดับ protocol จะดีกว่า
client เชื่อมต่อ MCP server หลายตัว แต่ละ session อาจไม่ต้องใช้ทั้งหมด ถ้าควบคุมได้ระดับ session จะช่วยลด context
การเรียกเครื่องมือกิน context เยอะ ถ้าให้ sub-agent จัดการ interaction ด้าน MCP แล้วค่อยสรุปผลเข้าบทสนทนาหลักจะสะดวกกว่า
นี่คือประสบการณ์ของเราสำหรับการสร้าง remote MCP server
ถ้าคุณกำลังสำรวจเส้นทางนี้ ลองใช้ Logto MCP Server หรือเข้าร่วม Discord เพื่อแลกเปลี่ยนวิธีใช้งานจริงกับชุมชน
เราจะนำเสนอรายละเอียดการออกแบบสถาปัตยกรรมและ OAuth flow ในโพสต์ถัดไปด้วย