เชื่อม Claude เข้า MCP Server แล้ว Agent ไม่ยอมเรียก Tool เลย ปัญหาอยู่ที่ MCP Client หรือเปล่า

หลังจากตั้งค่า MCP Server เสร็จเรียบร้อยและทดสอบว่า Server ทำงานถูกต้องแล้ว ทีมพัฒนาจำนวนไม่น้อยเจอสถานการณ์เดียวกัน คือเชื่อมต่อ Host เข้ากับ Server สำเร็จ ระบบขึ้นสถานะว่าเชื่อมต่อแล้ว แต่พอสั่งงานที่ควรต้องใช้ Tool ที่เปิดไว้ Agent กลับตอบแบบไม่เรียก Tool เลยสักครั้ง หรือเรียกผิดตัว

จุดที่หลายทีมมองข้ามคือ Client ไม่ใช่แค่ 'ท่อ' ที่ส่งข้อความผ่าน แต่เป็นตัวจัดการ Session ที่มีผลต่อว่าโมเดลจะเห็น Tool อะไรบ้าง และเห็นในรูปแบบไหน ถ้าขั้นตอนตรงนี้มีปัญหา ต่อให้ Server เขียนถูกสมบูรณ์แบบแค่ไหน Agent ก็ไม่มีทางเรียก Tool ได้ถูกต้อง

บทความนี้จะอธิบาย MCP Client คืออะไรในเชิงเทคนิค แยกจาก Host ให้ชัด พาไล่ดูวงจรการเชื่อมต่อทีละขั้น แล้วจบด้วยแนวทางไล่หาสาเหตุเมื่อเจอปัญหา Agent ไม่ยอมเรียก Tool แบบในหัวเรื่อง

MCP Client คือส่วนไหนกันแน่ ไม่ใช่ตัว Host เอง

MCP Client คือ Module หรือไลบรารีที่ฝังอยู่ภายใน Host ทำหน้าที่เฉพาะเจาะจงคือจัดการการสื่อสารกับ MCP Server หนึ่งตัวต่อหนึ่ง Connection ถ้า Host เชื่อมกับ Server สามตัว ภายใน Host จะมี Client Instance สามตัวทำงานคู่ขนานกัน แต่ละตัวคุยกับ Server ของตัวเองเท่านั้น

หลายคนสับสนระหว่าง Client กับ Host เพราะในบทสนทนาทั่วไปมักพูดรวมกันว่า 'Claude เชื่อมกับ MCP Server' ซึ่งจริง ๆ แล้ว Host คือแอปพลิเคชันทั้งหมดที่ผู้ใช้เห็น เช่น Claude Desktop ส่วน Client คือกลไกภายในที่ Host เรียกใช้เพื่อคุยกับ Server แต่ละตัว การแยกสองคำนี้ให้ชัดช่วยให้เข้าใจว่าปัญหาที่เจอเกิดที่ชั้นไหนกันแน่

วงจรการเชื่อมต่อของ MCP Client มีขั้นตอนอะไรบ้าง

เมื่อ Client เริ่มเชื่อมต่อกับ Server หนึ่งตัว จะผ่านขั้นตอน Handshake ก่อนเสมอ คือทั้งสองฝั่งแลกกันว่ารองรับความสามารถอะไรบ้าง เวอร์ชันโปรโตคอลตรงกันหรือไม่ หลังจาก Handshake สำเร็จ Client จะร้องขอรายการ Tool, Resource และ Prompt ทั้งหมดที่ Server เปิดไว้ แล้วส่งต่อข้อมูลนี้ให้ Host นำไปประกอบเป็นบริบทให้โมเดลเห็น

ขั้นตอนนี้สำคัญมากเพราะถ้า Handshake ไม่สำเร็จ หรือ Client ดึงรายการ Tool มาไม่ครบ โมเดลจะไม่รู้ด้วยซ้ำว่ามี Tool ให้เรียก ต่อให้ Server เปิด Tool ไว้ถูกต้องทุกอย่าง ปัญหาที่ Agent ไม่เรียก Tool เลยส่วนใหญ่จึงเริ่มต้นจากตรงจุดนี้ ไม่ใช่ตอนที่ Agent 'ตัดสินใจ' ไม่เรียก

ทำไมโมเดลถึงไม่เห็น Tool ทั้งที่ Client เชื่อมต่อสำเร็จ

ตัวอย่างสมมติ: ทีมพัฒนาตั้งค่า MCP Server เปิด Tool ชื่อ search_inventory ไว้ Host แสดงสถานะว่าเชื่อมต่อกับ Server สำเร็จ แต่พอถามว่า 'สินค้ารหัส SKU-2201 เหลือกี่ชิ้น' Agent กลับตอบว่าไม่มีข้อมูล ไม่ได้เรียก Tool เลย สาเหตุที่พบบ่อยที่สุดคือคำอธิบาย Tool ที่ Server ส่งให้ Client คลุมเครือเกินไป โมเดลจึงประเมินว่า Tool นี้ไม่เกี่ยวกับคำถาม

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

ไล่หาสาเหตุทีละขั้นเมื่อ Agent ไม่ยอมเรียก Tool

เมื่อเจอปัญหานี้ ไม่ควรรีบแก้ที่ฝั่ง Server ก่อน เพราะเสียเวลาถ้าปัญหาจริง ๆ อยู่ที่ชั้น Client หรือ Host แนวทางไล่หาสาเหตุที่ได้ผลคือเริ่มจากจุดที่ตรวจสอบง่ายที่สุดก่อนเสมอ:

1. เช็คสถานะ Connection ใน Host ว่าขึ้นว่าเชื่อมต่อสำเร็จจริง ไม่ใช่ค้างอยู่ระหว่าง Handshake
2. เรียกดูรายการ Tool ที่ Client ดึงมาได้ตรง ๆ ผ่านเครื่องมือ Debug ของ Host ว่า Tool ที่ต้องการอยู่ในรายการหรือไม่
3. อ่านคำอธิบาย Tool ที่ Server ส่งออกไปซ้ำอีกครั้งในมุมมองของคนที่ไม่รู้บริบทมาก่อน ว่าสื่อเจตนาชัดพอให้โมเดลจับคู่กับคำถามหรือไม่
4. ลองถามคำถามที่ตรงกับ Tool แบบตรงตัวที่สุด เช่น พูดชื่อ Tool ตรง ๆ เพื่อแยกว่าปัญหาคือโมเดลไม่รู้จัก Tool หรือแค่ประเมินว่าไม่เกี่ยวกับคำถามเดิม
5. ถ้ายังไม่เจอ ให้ตรวจว่าจำนวน Tool รวมจากทุก Server ที่เชื่อมพร้อมกันเกินขีดจำกัดของ Host หรือไม่ ลองปิด Server อื่นที่ไม่จำเป็นชั่วคราวเพื่อทดสอบ

จัดการหลาย MCP Server พร้อมกันใน Client เดียว

เมื่อทีมเริ่มเชื่อม Server หลายตัวเข้ากับ Host เดียวกัน จะเจอคำถามเรื่องการจัดลำดับความสำคัญและการตั้งชื่อ Tool ไม่ให้ซ้ำกัน เพราะถ้า Server สองตัวเปิด Tool ชื่อคล้ายกันมาก โมเดลอาจสับสนว่าควรเรียกตัวไหน ตารางนี้สรุปแนวทางจัดการที่ทีมส่วนใหญ่ใช้กัน:

ตัวอย่าง Host ที่มี MCP Client ในตัวให้ทดลองก่อนเขียนเอง

ก่อนจะเขียน Client เองซึ่งเป็นงานที่ซับซ้อนกว่าการเขียน Server มาก ทีมพัฒนาส่วนใหญ่ควรเริ่มทดลองกับ Host ที่มี MCP Client ในตัวอยู่แล้ว เช่น แอปพลิเคชัน Desktop สำหรับผู้ช่วย AI หรือเครื่องมือพัฒนาที่มีผู้ช่วย AI ในตัวและประกาศรองรับ MCP อย่างเป็นทางการ

การทดลองกับ Host สำเร็จรูปก่อนช่วยให้เห็นพฤติกรรมจริงของ Client โดยไม่ต้องเสียเวลาเขียนโค้ดจัดการ Connection เอง เมื่อเข้าใจพฤติกรรมแล้วว่าโมเดลเลือกเรียก Tool อย่างไร ค่อยพิจารณาว่าจำเป็นต้องเขียน Client แบบกำหนดเองสำหรับ Agent ที่บริษัทพัฒนาขึ้นมาเองหรือไม่

Client ต้องจัดการ State ของบทสนทนายาวอย่างไร

อีกเรื่องที่มักถูกมองข้ามคือ MCP Client ต้องจัดการสถานะของบทสนทนาที่ยาวหลายรอบให้สอดคล้องกับผลลัพธ์ของ Tool ที่เรียกไปก่อนหน้า ไม่ใช่แค่ส่ง Request แล้วลืม ตัวอย่างสมมติ: ผู้ใช้ถามว่า 'ลูกค้ารายนี้มีตั๋วงานค้างกี่ใบ' Agent เรียก Tool list_open_tickets ได้ผลลัพธ์มา 3 ใบ จากนั้นผู้ใช้ถามต่อว่า 'ใบที่เก่าที่สุดใครรับผิดชอบ' คำถามนี้อ้างอิงผลลัพธ์รอบก่อนหน้าโดยไม่ได้พูดเลขตั๋วซ้ำ

ถ้า Client และ Host จัดการ Context ไม่ดี โมเดลอาจไม่มีข้อมูลผลลัพธ์รอบก่อนเหลืออยู่ให้อ้างอิง ทำให้ต้องเรียก Tool ซ้ำใหม่ทั้งหมดหรือตอบผิดไปเลย การออกแบบว่าจะเก็บผลลัพธ์จาก Tool Call ก่อนหน้าไว้ใน Context นานแค่ไหน จึงเป็นการตัดสินใจที่ส่งผลต่อทั้งความแม่นยำของคำตอบและปริมาณ Token ที่ใช้ในแต่ละรอบสนทนา

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

ถ้าต้องเขียน MCP Client เองสำหรับ Agent ภายในบริษัท

บางทีมมี Agent ที่พัฒนาขึ้นเองสำหรับงานเฉพาะทาง เช่น Bot ตอบคำถามพนักงานภายใน ซึ่งไม่ได้ใช้ Host สำเร็จรูปจากภายนอก กรณีนี้ทีมต้องเขียน MCP Client ฝังเข้าไปใน Agent เอง งานหลักที่ต้องทำคือจัดการ Session ต่อ Server แต่ละตัว แปลงรายการ Tool ที่ได้มาให้อยู่ในรูปแบบที่โมเดลของทีมเข้าใจ และจัดการ Error เมื่อ Server ไม่ตอบสนอง

จุดที่ทีมเขียน Client เองมักพลาดคือลืมจัดการกรณี Server หลุดการเชื่อมต่อกลางคัน ทำให้ Agent ค้างรอไม่มีที่สิ้นสุด ควรออกแบบ Timeout และ Retry Logic ตั้งแต่เริ่มเขียน ไม่ใช่มาเพิ่มทีหลังตอนเจอปัญหาในการใช้งานจริง

ทำแบบนี้แล้วพัง เพราะ… ข้อผิดพลาดที่พบบ่อยฝั่ง Client

นอกจากปัญหา Agent ไม่เรียก Tool ที่อธิบายไปแล้ว ยังมีข้อผิดพลาดอื่นที่ทีมพัฒนาฝั่ง Client เจอบ่อยเช่นกัน

• เชื่อม Server ใหม่ทุก Session โดยไม่ Cache รายการ Tool ทำแบบนี้แล้วพัง เพราะทำให้ทุกครั้งที่เริ่มบทสนทนาใหม่ต้องรอ Handshake ใหม่ทั้งหมด ช้าโดยไม่จำเป็นเมื่อ Server ไม่ได้เปลี่ยน Tool บ่อย
• ไม่ตรวจสอบเวอร์ชันโปรโตคอลก่อนเชื่อม ทำแบบนี้แล้วพัง เพราะถ้า Server ใช้เวอร์ชันใหม่กว่าที่ Client รองรับ อาจเชื่อมต่อได้แต่ Tool บางตัวทำงานผิดคาด โดยไม่มี Error ชัดเจนบอกสาเหตุ
• ปล่อยให้ Error จาก Server รั่วไปถึงผู้ใช้ตรง ๆ ทำแบบนี้แล้วพัง เพราะข้อความ Error ทางเทคนิคทำให้ผู้ใช้งานทั่วไปสับสน ควรให้ Client ดัก Error แล้วแปลงเป็นข้อความที่เข้าใจง่ายก่อนส่งต่อ

สรุป

ปัญหา Agent ไม่ยอมเรียก Tool ที่เปิดไว้ ส่วนใหญ่ไม่ได้เกิดจาก MCP Server พัง แต่เกิดจากขั้นตอนของ MCP Client ตั้งแต่ Handshake การดึงรายการ Tool ไปจนถึงขีดจำกัด Context ที่ Host กำหนด การไล่หาสาเหตุจึงควรเริ่มจากจุดที่ตรวจสอบง่ายที่สุดก่อนเสมอ ไม่ใช่รีบไปแก้โค้ด Server

เมื่อเข้าใจว่า Client กับ Host เป็นคนละส่วนกัน และรู้วงจรการเชื่อมต่อทั้งหมด การ Debug ปัญหาที่ดูเหมือนซับซ้อนจะกลายเป็นเรื่องที่ไล่หาสาเหตุได้เป็นขั้นเป็นตอน ไม่ต้องเดาสุ่ม

• MCP Client คือ Module ภายใน Host ที่จัดการ Connection กับ Server แต่ละตัวแบบหนึ่งต่อหนึ่ง
• ปัญหา Agent ไม่เรียก Tool ส่วนใหญ่เกิดจากขั้น Handshake หรือขีดจำกัด Context ไม่ใช่จาก Server
• เมื่อเชื่อม Server หลายตัว ต้องวางแผนตั้งชื่อ Tool ไม่ให้ซ้ำและจัดการ Timeout แยกกัน
• ควรทดลองกับ Host ที่มี Client สำเร็จรูปก่อน ก่อนตัดสินใจเขียน Client เองสำหรับ Agent ภายใน

คำถามที่พบบ่อย