AI SDK MCP 2.0: ต่อ MCP ได้แล้ว แต่ต้องมี Safety Harness

ช่วงนี้คำว่า MCP โผล่ในแทบทุกเครื่องมือ AI agent ครับ

Claude Code ต่อ MCP ได้ Cursor ต่อ MCP ได้ Codex ต่อ MCP ได้ หลายทีมเริ่มทำ MCP server เองเพื่อให้ agent อ่านเอกสาร, เรียก API, เช็ก CRM, เปิด issue, ดู database หรือค้นข้อมูลภายใน

แต่ปัญหาคือหลายคนยังคิดว่า MCP เป็นแค่ “สายต่อ tool”

ในความเห็นของผม นี่เป็นมุมที่อันตรายไปหน่อยครับ เพราะทันทีที่ agent เริ่มเรียก tool ได้จริง MCP client จะกลายเป็นด่านหน้าระหว่างโมเดลกับระบบธุรกิจ

ด่านหน้านี้ต้องตอบได้ว่า:

• agent เห็น tool อะไรบ้าง
• tool ไหนถูก allow จริง
• transport ล้มเหลวแบบไหน
• redirect ไปไหน
• token มาจาก authorization server ที่ถูกต้องไหม
• ถ้า tool มี UI ผ่าน MCP Apps ใครตรวจ
• ถ้ามี billable action เช่น test inference ใคร approve

นี่คือเหตุผลที่ @ai-sdk/[email protected] ของ Vercel น่าสนใจสำหรับคนทำงานจริง ไม่ใช่เพราะมันเป็นข่าว package ใหม่ แต่เพราะ release note ของมันสะท้อนปัญหาที่ operator จะเจอเมื่อ MCP เริ่มเข้า production

1) สิ่งที่เกิดขึ้นแบบสั้น ๆ

Vercel ปล่อย @ai-sdk/[email protected] บน GitHub วันที่ 25 มิถุนายน 2026

ใน release นี้มีหลายประเด็นสำคัญ เช่น:

• package เป็น ESM-only
• minimum Node.js ขยับเป็น 22
• MCP transport error มีข้อมูล structured มากขึ้น
• เพิ่ม option เพื่อคุม redirect
• รองรับ MCP Apps
• validation ฝั่ง OAuth ชัดขึ้น
• แก้ช่อง schema allowlist ที่ tool ชื่อ prototype เช่น constructor, toString, proto อาจหลุดผ่าน allowlist ได้

ถ้าอ่านแบบ developer ปกติ นี่คือ changelog

แต่ถ้าอ่านแบบ operator นี่คือสัญญาณว่า MCP client ต้องเริ่มถูกมองเป็น control surface ไม่ใช่แค่ library

2) ทำไมเรื่องนี้สำคัญกับธุรกิจ

สมมติธุรกิจมี internal assistant หนึ่งตัวที่ต่อ MCP เข้ากับหลายระบบ:

• GitHub สำหรับเปิด issue หรืออ่าน PR
• CRM สำหรับดู lead และประวัติลูกค้า
• Google Drive หรือ Notion สำหรับค้นเอกสาร
• LINE OA สำหรับดูบทสนทนาลูกค้า
• billing หรือ payment dashboard สำหรับเช็กยอด

เมื่อ agent ถามว่า “มี tool อะไรใช้ได้บ้าง” MCP client คือคนแปลโลกของ tool ให้โมเดลเห็น

ถ้า client ผิดพลาดหรือเปิดกว้างเกินไป ปัญหาไม่ได้อยู่แค่ code fail ครับ แต่กลายเป็นเรื่อง business risk ทันที

ตัวอย่างง่าย ๆ:

• allowlist พลาด ทำให้ tool ที่ไม่ควรเห็นถูก expose ให้โมเดล
• redirect ไม่ถูกคุม ทำให้ client ไป endpoint ที่ไม่ตั้งใจ
• error ไม่มีรายละเอียด ทำให้ระบบ fallback แบบเดาสุ่ม
• OAuth validation อ่อน ทำให้ token หรือ resource binding ถูกตีความผิด
• MCP Apps มี UI interaction แต่ทีมไม่ได้ review ว่า action ไหนควรต้องขอ approval

นี่คือเหตุผลที่ผมใช้คำว่า Safety Harness

ไม่ใช่เพื่อทำให้ agent ช้าลง แต่เพื่อให้ agent ทำงานเร็วขึ้นโดยมีเข็มขัดนิรภัย

3) จุดที่ release นี้สะท้อนบทเรียนสำคัญ

Structured error ไม่ใช่เรื่อง developer convenience อย่างเดียว

ใน release note มีการเพิ่ม statusCode, url, และ responseBody ใน MCPClientError สำหรับ HTTP transport failures

ฟังดูเล็ก แต่สำหรับ production สำคัญมากครับ

ถ้า agent ต่อ MCP server ไม่ได้ เราต้องรู้ว่า:

• เป็น 401 เพราะ auth fail หรือเปล่า
• เป็น 404 เพราะ URL ผิดหรือ server path เปลี่ยน
• เป็น 5xx เพราะ server ล่ม
• ควร fallback ไป legacy SSE transport ไหม
• ควรหยุดและให้คนดูไหม

ถ้า error มีแค่ string ยาว ๆ ระบบจะตัดสินใจยาก และ operator ก็ debug ยาก

Tool allowlist ต้องกันชื่อแปลก ๆ ด้วย

อีกจุดที่สำคัญคือ fix ที่ป้องกัน prototype-named tools จากการ bypass schemas allowlist

ภาษาคนคือ ถ้าเราบอกว่า agent ใช้ได้เฉพาะ tool ที่ระบุไว้ใน schema ระบบต้องเช็กเฉพาะ tool ที่เราตั้งใจจริง ๆ ไม่ใช่ปล่อยให้ชื่อที่ inherited มาจาก object prototype ผ่านไปได้

นี่ไม่ใช่แค่ bug technical แต่เป็นบทเรียนใหญ่:

allowlist ที่ดีต้องตรวจแบบ precise ไม่ใช่ตรวจแบบคล้าย ๆ ว่าอยู่ใน object ไหม

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

OAuth และ redirect คือ trust boundary

MCP ที่ต่อผ่าน HTTP หรือ remote server จะเริ่มเจอปัญหาคล้าย web security มากขึ้น

release นี้พูดถึง redirect option, OAuth metadata issuer validation, OAuth resource parameter และ token refresh หลายจุด

ถ้าทีมคิดว่า MCP เป็นแค่ local stdio server อาจยังไม่รู้สึก แต่พอเริ่มใช้ remote MCP, OAuth login, hosted docs, hosted model catalog หรือ enterprise tool server trust boundary จะซับซ้อนขึ้นทันที

คำถามที่ต้องตอบคือ:

• client ไว้ใจ authorization server ไหน
• resource parameter ถูกผูกกับ service ไหน
• redirect ไป endpoint ที่ทีมควบคุมหรือไม่
• token refresh ถูก dedupe และไม่รั่วไหลระหว่าง rediscovery หรือเปล่า

นี่คือเรื่อง security ที่คนทำ workflow ต้องเข้าใจในระดับ operational ไม่จำเป็นต้องเป็น security engineer เต็มตัว แต่ต้องรู้ว่าจุดไหนต้องขอ review ก่อนเปิดใช้

4) MCP Apps ทำให้ tool ไม่ได้เป็นแค่ API แล้ว

MCP Apps เป็นอีกสัญญาณที่น่าสนใจมาก

แนวคิดคือ MCP server สามารถให้ UI หรือ interactive surface ที่ host render ใน sandbox ได้ ทำให้ agent ไม่ได้เรียกแค่ function เงียบ ๆ แต่มีหน้า interaction ให้คนดูหรืออนุมัติได้มากขึ้น

ด้านหนึ่ง นี่ดีมาก เพราะทำให้ agent workflow มี proof, preview และ human review ได้ดีขึ้น

แต่อีกด้านหนึ่ง มันเพิ่มพื้นที่ที่ต้องตรวจ:

• UI นี้มาจาก server ไหน
• sandbox policy เป็นอย่างไร
• action ใดเกิดจากผู้ใช้กดเอง และ action ใดเกิดจาก agent
• มีข้อมูล sensitive โผล่บน UI หรือไม่
• host log interaction ได้ครบไหม

สำหรับธุรกิจ นี่คือจุดที่ MCP เริ่มเข้าใกล้คำว่า “work surface” มากกว่า “tool protocol”

Operator Kit: MCP Client Safety Harness

นี่คือ checklist ที่ทีมใช้ก่อนอัปเกรดหรือต่อ MCP client เข้า workflow จริง

1. Runtime Gate

ก่อนอัปเกรด ให้เช็กว่า runtime พร้อมไหม

• Node.js version ตรงกับ package ใหม่หรือไม่
• project ยังใช้ CommonJS require() อยู่หรือเปล่า
• build pipeline, serverless runtime, edge runtime, Docker image รองรับ ESM-only หรือยัง
• dependency ที่เรียก @ai-sdk/mcp ต่ออีกชั้นจะพังไหม

คำถามสำคัญคือ อย่าอัปเกรดแค่เครื่อง developer แล้วลืม production runtime

2. Tool Allowlist Gate

ทุก MCP client ควรมีรายการ tool ที่อนุญาตอย่างชัดเจน

เช็กว่า:

• allowlist ใช้ exact own-property check
• tool ชื่อแปลก เช่น constructor, toString, proto ไม่ผ่าน
• tool ที่ destructive ต้องแยกจาก read-only
• tool ที่แตะ customer data ต้องมี approval หรือ scoped permission

ถ้าไม่แน่ใจ ให้เริ่มจาก read-only ก่อนครับ

3. Transport Evidence Gate

เวลา MCP transport fail ระบบต้องมีหลักฐาน ไม่ใช่แค่ข้อความ error กว้าง ๆ

อย่างน้อยควร log:

• status code
• URL หรือ server alias
• response body แบบ redacted
• transport mode ที่ใช้
• fallback decision
• request id หรือ trace id

เป้าหมายคือเวลา agent บอกว่า “ต่อ tool ไม่ได้” ทีมต้องรู้ว่าเกิดอะไรขึ้นจริง

4. Redirect และ Endpoint Gate

ถ้าใช้ HTTP transport ให้ตั้ง policy เรื่อง redirect ชัดเจน

• redirect ได้ไหม
• redirect ไป domain ไหนได้บ้าง
• path เปลี่ยนได้หรือไม่
• ถ้า redirect เกิดจาก auth flow ต้อง log ไหม
• production กับ staging ใช้ endpoint แยกกันชัดไหม

เรื่องนี้ดูเล็ก แต่เป็นจุดที่ทำให้ client วิ่งไปผิดที่ได้ง่ายมาก

5. OAuth Boundary Gate

สำหรับ remote MCP ที่ใช้ OAuth ให้ถามห้าข้อนี้ก่อนเปิดใช้:

• authorization server คือเจ้าไหน
• issuer metadata ตรวจหรือยัง
• token ผูกกับ resource ที่ถูกต้องไหม
• refresh token flow มี dedupe และ retry ที่ปลอดภัยไหม
• ถอดสิทธิ์หรือ revoke ได้จากที่ไหน

ถ้าตอบไม่ได้ อย่าเพิ่งให้ agent แตะข้อมูลจริง

6. App/UI Review Gate

ถ้าใช้ MCP Apps หรือ UI จาก MCP server ให้ treat เหมือน mini product surface

ต้องมี:

• owner ของ UI
• review ว่าแสดงข้อมูลอะไรได้บ้าง
• approval point สำหรับ action สำคัญ
• sandbox policy
• log ว่า user หรือ agent เป็นคนเริ่ม action

จำไว้ว่าหน้า UI ที่ agent ใช้ได้ อาจกลายเป็นจุดตัดสินใจของ workflow ทั้งระบบ

7. Billable Tool Gate

ถ้า MCP server มี tool ที่ทำให้เกิดค่าใช้จ่าย เช่น test inference, run job, send message, call external API ต้องแยกออกมาเป็น billable gate

ตั้งกติกาให้ชัด:

• budget cap
• per-user หรือ per-agent limit
• dry-run mode
• approval สำหรับงานแพง
• cost log ต่อ task

กรณี OpenRouter MCP เป็นตัวอย่างที่ดี เพราะเขาแยกชัดว่า tools ส่วนใหญ่เป็น read-only lookup แต่ chat-send เป็น billable inference call

6) วิธีเริ่มแบบไม่เสี่ยงเกินไป

ถ้าทีมยังใหม่กับ MCP ผมแนะนำให้เริ่มแบบนี้ครับ

1. ต่อ MCP เฉพาะ read-only tools ก่อน
2. เปิด log ให้ครบก่อนเปิด action tools
3. แยก dev, staging, production MCP server
4. ทำ allowlist ราย tool ไม่ใช่ allow ทั้ง server
5. ใช้ test prompt ชุดเดิมทุกครั้งหลังอัปเกรด client
6. ตั้ง fallback rule ว่า error แบบไหน retry, error แบบไหนหยุด
7. review OAuth และ redirect ก่อนใช้ remote MCP กับข้อมูลจริง

ไม่ต้องทำทั้งหมดแบบ enterprise ใหญ่ตั้งแต่วันแรก แต่ต้องมี minimum harness ก่อนให้ agent แตะงานที่มีเงิน ลูกค้า หรือข้อมูลสำคัญ

7) สรุป

ในความเห็นของผม @ai-sdk/[email protected] เป็นข่าวเล็กที่สะท้อนเรื่องใหญ่ครับ

MCP กำลังโตจาก protocol สำหรับต่อ tool ไปเป็นส่วนหนึ่งของ agent runtime ที่แตะงานจริงมากขึ้นเรื่อย ๆ

ดังนั้นคำถามของทีมไม่ควรหยุดที่:

“ต่อ MCP ได้ไหม”

แต่ควรถามต่อว่า:

“ต่อแล้วเราคุม tool, token, transport, UI, cost และ audit ได้แค่ไหน”

สุดท้าย AI agent ที่พร้อมใช้งานจริง ไม่ใช่ตัวที่มี tool เยอะที่สุดครับ

แต่คือตัวที่เมื่อมันเรียก tool แล้ว เรารู้ว่าเรียกอะไร ทำไมถึงเรียก ใครอนุญาต ถ้าพลาดจะหยุดตรงไหน และจะพิสูจน์ย้อนหลังอย่างไร

นั่นแหละคือ MCP Client Safety Harness ที่ทีมควรมีตั้งแต่วันนี้