跳到主要内容
返回文章列表

Apigee X ส่ง MCP Tool Arguments ตาม Header และ Cookie ที่ OpenAPI ระบุ: Proxy เดิมต้อง Deploy Revision ใหม่

อัปเดต 26 ตุลาคมแก้การวาง arguments ที่เคยเข้า query string พร้อมข้อควรระวัง Cookie header และแนวทางตรวจ backend ก่อนเปลี่ยน revision

Apigee X ส่ง MCP Tool Arguments ตาม Header และ Cookie ที่ OpenAPI ระบุ: Proxy เดิมต้อง Deploy Revision ใหม่

Google Cloud ประกาศใน release notes วันที่ 26 ตุลาคม 2026 ว่า Apigee X เปลี่ยนการส่ง MCP tool arguments ให้ตรงตำแหน่งที่ OpenAPI parameter ประกาศไว้ ค่า in: header จะเป็น request header และ in: cookie จะอยู่ใน Cookie header แทนพฤติกรรมเดิมที่ส่งทั้งสองชนิดใน query string การเปลี่ยนนี้สำคัญกับ backend ที่เคยเขียนรับค่าตามพฤติกรรมเก่า

Schema ที่ Client เห็นเหมือนเดิม แต่คำขอปลายทางเปลี่ยน

ประกาศระบุว่า query และ path parameters ไม่เปลี่ยน และ parameters ยังอยู่ใน inputSchema ของเครื่องมือเหมือนเดิม ดังนั้นการทดสอบจาก MCP client เพียงว่ามีช่อง argument ครบอาจไม่พบความต่าง ต้องดู HTTP request ที่ backend ได้รับจริงว่าค่าไปถึงตำแหน่งที่ handler อ่านหรือไม่

หาก backend ตั้งใจรับค่าใน query ให้ประกาศ in: query ให้ตรงกับสัญญา แทนการปล่อย spec บอก header แต่โค้ดอ่าน query ต่อไป การทำให้เอกสารกับ implementation ตรงกันช่วยลดปัญหาเมื่อเพิ่ม client หรือ regenerate proxy ครั้งถัดไป

Cookie ที่ไม่ได้ประกาศอาจไม่ถูกส่งต่อ

บน tool call ที่มี cookie argument อย่างน้อยหนึ่งตัว Cookie header จะถูกแทนด้วยเฉพาะ cookie parameters ที่ประกาศไว้ หาก backend พึ่ง cookie อื่น ต้องประกาศให้ครบตามเอกสาร ประเด็นนี้อาจกระทบทั้ง session และค่าประกอบการเลือก tenant จึงควรตรวจด้วยข้อมูลจำลองที่เห็นความต่างได้ชัด

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

Proxy ที่ Deploy อยู่ไม่เปลี่ยนทันทีทุกตัว

MCP proxy เดิมยังใช้พฤติกรรม query string จน configuration ถูก regenerate การรับ routing ใหม่บน proxy เดิมต้อง deploy revision ใหม่ จึงมีโอกาสที่ระบบจะมีหลาย revision ใช้สัญญาต่างกันในช่วงเปลี่ยนผ่าน ผู้ดูแลควรบันทึกว่า environment ใดใช้ revision ใดก่อนเปลี่ยน backend

หากปรับ backend ให้รับตำแหน่งใหม่ก่อนทุก proxy เปลี่ยน คำขอจาก revision เก่าอาจขาดข้อมูลที่ต้องการ ควรวางลำดับ rollout และทางย้อนค่าที่ตรวจแล้ว โดยระบุชัดว่าช่วงเปลี่ยนผ่านรองรับรูปแบบใด ไม่ควรเปิดรับค่าจากทุกตำแหน่งถาวรโดยไม่กำหนด precedence เมื่อมีค่าขัดกัน

ตรวจสัญญาด้วย Endpoint ทดสอบ

สร้าง backend ทดลองที่รายงานเพียงชื่อ field และค่าจำลองซึ่งไม่ใช่ secret แล้วทดสอบ header, cookie, query และ path แยกกัน รวมถึงชื่อที่มี encoding และคำขอที่ไม่มีค่า optional ตรวจว่าค่าที่หายหรือไม่ถูกชนิดถูกจัดการตาม spec ไม่ใช่เงียบไปใช้ default ที่ทำให้งานผิดกลุ่ม

หลังทดสอบระดับ HTTP ให้เรียกผ่าน MCP client จริงด้วย เพื่อให้เห็นทั้งเส้นทางจาก inputSchema ไปถึง handler เมื่อผ่านแล้วจึงเก็บผลไว้กับการเปลี่ยน revision การแก้ครั้งนี้เป็นตัวอย่างว่าการเรียก tool สำเร็จไม่ได้ยืนยันว่าทุก argument ถูกตีความตรงกันตั้งแต่ต้นจนจบ

แหล่งต้นทาง: Google Cloud release notes วันที่ 26 ตุลาคม 2026 และ MCP in Apigee overview