เซิร์ฟเวอร์ MCP ระยะไกลในการใช้งานจริง: จุดเริ่มต้นใหม่สำหรับผลิตภัณฑ์ SaaS ในยุค AI

ผลิตภัณฑ์ 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 รวมถึง:

• MCP กับ Agent Skills: ทำไมเราถึงเลือก MCP
• ปัญหาที่เราพบเมื่อปล่อย MCP server และแนวทางการแก้ไข
• หลักการออกแบบเครื่องมือ MCP และแนวคิดสำหรับผู้พัฒนา
• ความคาดหวังของเราต่ออนาคตของ MCP

MCP กับ Agent Skills: ทำไมเราถึงเลือก MCP#

ก่อนจะตัดสินใจว่าจะให้ 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, เชื่อมต่อ นี่คือประสบการณ์ที่เราอยากส่งมอบ

ขอบเขต ecosystem#

ใน 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 ซึ่งนำปัญหามาอย่างรวดเร็ว:

• ถ้า API เปลี่ยนล่ะ?
• ถ้า CLI ใช้ไม่ได้ หรือเปลี่ยนวิธีทำงานล่ะ?
• จะอัปเกรด/กระจาย Skill ยังไง?

คุณต้องแจกจ่าย 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 server และวิธีแก้ไข#

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

ฟีเจอร์ MCP สนับสนุนไม่สม่ำเสมอ#

สเปค MCP กำหนดฟีเจอร์หลายอย่าง แต่ client สนับสนุนต่างกัน:

• เครื่องมือ: รองรับแพร่หลาย
• OAuth: รองรับดีใน VS Code เครื่องมือบางตัวเช่น Cursor ต้องใช้ mcp-remote เป็นสะพานเชื่อม
• ฟีเจอร์อื่น ๆ (Resources, Prompts, Instructions): สนับสนุนไม่สม่ำเสมอ

ปัจจุบัน เครื่องมือเป็นเลเยอร์ที่เชื่อถือได้มากที่สุด (ดูข้อมูลเพิ่มเติมที่ MCP Community Page ว่า client ไหนรองรับฟีเจอร์อะไรบ้าง)

ยุทธศาสตร์ของเราคือ: สร้างบนพื้นฐานเครื่องมือ

LLM ไม่รู้วิธีใช้เครื่องมือของคุณ#

นี่เป็นปัญหาในชั้น business

Agent Skills: logic และบริบทถูกแพ็กด้วยกัน ทำให้ LLM ใช้งานได้เลย MCP มีแต่เครื่องมือ ต่อให้เชื่อมต่อ LLM ก็ไม่รู้:

• กรณีใช้เครื่องมือ
• ลำดับการเรียกใช้งาน
• ข้อจำกัดทาง business

MCP มีแนวคิด Instructions แต่ client ไม่รองรับทั้งหมด Instructions ยังดันข้อมูลทั้งหมดเข้า context ตอนเชื่อมต่อ ทำให้เปลือง token

อีกไอเดีย คือใส่แนวทางแนะนำในคำอธิบายเครื่องมือ แต่นี่สร้างปัญหา 2 ข้อ:

• คำอธิบายซับซ้อนซ้อนทับกัน workflow หลายเครื่องมือ logic พันกัน ยากต่อการดูแล
• เมื่อเครื่องมือเพิ่ม คำอธิบายกิน context window มากขึ้น

แนวทางเราคือ: เพิ่มเครื่องมือ getInstructions

ไอเดียคือ ถ้า instruction ไม่เวิร์กก็เปลี่ยนเป็นเครื่องมือ

LLM ขอเรียกใช้ getInstructions ได้ตามสถานการณ์
ถ้างาน A ก็เรียก getTaskAInstructions MCP server ตอบกลับ prompt อธิบายวิธีทำ task A และวิธีใช้เครื่องมืออื่นร่วมกัน

Logic ธุรกิจซับซ้อนอยู่หลังเครื่องมือกลุ่ม instruction เครื่องมืออื่น ๆ เรียบง่าย คำอธิบายโฟกัสเฉพาะฟังก์ชันแต่ละตัว

คล้าย Agent Skill ตรงที่โหลด prompt แบบออนดีมานด์ ได้ประสิทธิภาพกว่าเพราะไม่ดันทุกอย่างเข้า context

LLM อาจรั่วไหล secret#

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 เราทำสามอย่าง:

• ใช้ secret ชั่วคราวเท่านั้นระหว่าง integration ระหว่างเซ็ตอัปใน chat MCP server ตอบกลับ secret ที่อายุสั้น (เช่น 1 ชั่วโมง) พอให้ integration ใช้งานได้และหมดอายุก่อนขึ้น production นัก dev ต้องสร้างและเปลี่ยนเป็น secret จริงเองนอก chat
• กำหนดขอบเขตความปลอดภัยให้ชัด เตือนผู้ใช้อย่าสร้าง/แปะ/เก็บ secret จริงในแชท แจ้ง dev ด้วยว่า env var หรือไฟล์ config ก็อาจรั่วถ้า agent หรือ LLM อ่านได้ ให้ใช้ secret จริงใน env ที่ไม่มี AI integration เท่านั้น
• ไม่จัดการ secret production ในแชท ส่ง user ต่อไป console secret อายุยาวไม่สร้าง ไม่แจกจ่ายในแชท ผู้ใช้ต้องสร้างและตั้งค่าในหน้า credentials ของ console ใน chat ส่งลิงก์เข้า console เท่านั้น

หลักการออกแบบเครื่องมือ MCP#

แนวทางของเรา#

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 อีกรูปแบบ"

วิธีออกแบบ MCP tools#

กติกาชัดเจน:

• ถ้าผู้ใช้ใช้บริการคุณตรง ๆ (เช่น console) เครื่องมือควรมุ่งเน้น business
• ถ้ามอบความสามารถพื้นฐาน เครืองมือควรเล็กและเรียบง่าย เช่น server ไฟล์ระบบแค่ read_file, write_file แล้วเอเจนต์ค่อยใช้สร้างฟังค์ชันเพิ่ม

หลักเสริม:

• logic และคำอธิบายเครื่องมือควรเรียบง่ายเพื่อประหยัด context
• workflow ซับซ้อนก็ใช้ getInstructions ช่วยโหลดคำแนะนำแบบออนดีมานด์ คำอธิบาย instruction tools ก็อย่าให้รก

ความคาดหวังอนาคตของ MCP#

ระหว่างสร้าง MCP server เราก็นึกถึงสิ่งที่ ecosystem ควรปรับปรุง

การส่งมอบ capability แบบ skill#

บางครั้ง MCP server ต้องให้ทั้งเครื่องมือและแนวทางการผสมเครื่องมือเป็น task แบบ Agent Skill

พบได้ทั่วไปใน SaaS เช่น GitHub MCP, Logto MCP, แพลตฟอร์ม analytics ผู้ใช้เน้น workflow ไม่ใช่ call เล็ก ๆ

getInstructions เป็นทางแก้ระยะสั้น ถ้าช่วยได้ที่ระดับ protocol จะดีกว่า

การเปิด/ปิด MCP server ระดับ session#

client เชื่อมต่อ MCP server หลายตัว แต่ละ session อาจไม่ต้องใช้ทั้งหมด ถ้าควบคุมได้ระดับ session จะช่วยลด context

แยก context สำหรับการเรียกเครื่องมือ MCP#

การเรียกเครื่องมือกิน context เยอะ ถ้าให้ sub-agent จัดการ interaction ด้าน MCP แล้วค่อยสรุปผลเข้าบทสนทนาหลักจะสะดวกกว่า

สรุป#

นี่คือประสบการณ์ของเราสำหรับการสร้าง remote MCP server

ถ้าคุณกำลังสำรวจเส้นทางนี้ ลองใช้ Logto MCP Server หรือเข้าร่วม Discord เพื่อแลกเปลี่ยนวิธีใช้งานจริงกับชุมชน

เราจะนำเสนอรายละเอียดการออกแบบสถาปัตยกรรมและ OAuth flow ในโพสต์ถัดไปด้วย