การออกแบบ Tool Schema: พัฒนา AI Agent ให้เลือก Endpoint ได้อย่างแม่นยำ

คุณได้มอบเครื่องมือสองชิ้นให้กับเอเจนต์: updateUser และ deactivateUser ตั๋วสนับสนุนระบุว่า “ปิดบัญชีนี้” เอเจนต์เรียกใช้ deactivateUser เมื่อสัปดาห์ที่แล้ว ตั๋วที่คล้ายกันเกือบจะทำให้มันเรียกใช้ updateUser ด้วย status: "closed" ซึ่ง API ของคุณยอมรับและมีความหมายแตกต่างกันเล็กน้อยในขั้นตอนถัดไป

ไม่มีอะไรเสีย โมเดลกำลังเลือกระหว่างสองตัวเลือกที่เป็นไปได้ซึ่งมีคำอธิบายที่ไม่บอกว่าตัวเลือกใดที่เหมาะสม การเลือกเครื่องมือเป็นโหมดความล้มเหลวที่ผู้คนตำหนิโมเดลและแก้ไขใน schema เนื่องจาก schema เป็นสิ่งเดียวที่โมเดลต้องใช้ในการดำเนินการ

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

Apidog เป็นที่ที่คำอธิบายอยู่หากเครื่องมือของคุณมาจากคำจำกัดความ API ของคุณ ดังนั้นการปรับปรุงอย่างหนึ่งจึงเป็นการปรับปรุงเอกสารและเครื่องมือไปพร้อมๆ กัน

สิ่งที่โมเดลเห็น

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

นั่นหมายความว่าการแยกความกำกวมทุกอย่างจะต้องถูกเขียนลงในคำจำกัดความนั้นเอง ทั้ง คู่มือการเรียกใช้ฟังก์ชันของ OpenAI และ เอกสารการใช้เครื่องมือของ Anthropic ต่างก็ชี้ประเด็นเดียวกัน: คำอธิบายคือข้อความที่สำคัญที่สุดในคำจำกัดความทั้งหมด และควรจะละเอียดมากกว่าสั้นกระชับ

ข้อผิดพลาดในการเลือกมีสี่รูปแบบ และแต่ละรูปแบบมีการแก้ไขที่แตกต่างกันไป

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

ตั้งชื่อเครื่องมือตามสิ่งที่ทำ

ชื่อมีความสำคัญมากกว่าความยาวที่แสดง เพราะโมเดลจะอ่านก่อน

ใช้ verbNoun ในสไตล์เดียวกันทั่วทั้งชุดเครื่องมือ: createOrder, refundOrder, getOrderStatus ความสอดคล้องมีความสำคัญพอๆ กับการเลือกแต่ละรายการ เนื่องจากชุดที่ผสมผสาน order_create, getOrder และ refund ทำให้ชื่อแต่ละชื่ออ่านยากขึ้นเล็กน้อย

ระบุวัตถุให้ชัดเจน search เป็นชื่อเครื่องมือที่ไม่ดี searchCustomersByEmail เป็นชื่อที่ดี และมันบอกโมเดลทั้งสิ่งที่ค้นหาและวิธีการค้นหา

หลีกเลี่ยงศัพท์เฉพาะภายใน หาก API ของคุณเรียกผู้ใช้ว่า “entity” และการสมัครสมาชิกว่า “instrument” โมเดลจะไม่เชื่อมโยงสิ่งเหล่านั้นกับตั๋วที่ระบุว่า “customer” และ “plan” ตั้งชื่อเครื่องมือด้วยภาษาของงาน ไม่ใช่ภาษาของ schema

อย่าใช้ชื่อซ้ำในบริบทที่แตกต่างกัน เครื่องมือสองชิ้นที่ชื่อ list ใน namespace ที่แตกต่างกันจะกลายเป็นความกำกวมทันทีที่ปรากฏในรายการเดียว

เขียนคำอธิบายที่แยกแยะได้

คำอธิบายที่มีประโยชน์จะตอบสี่คำถาม: มันทำอะไร มันเปลี่ยนแปลงอะไร เมื่อไหร่ควรใช้ และเมื่อไหร่ไม่ควรใช้

นี่คือคู่ที่อ่อนแอ:

{ "name": "updateUser", "description": "Updates a user." }
{ "name": "deactivateUser", "description": "Deactivates a user." }

และคู่ที่สามารถแยกแยะได้จริง:

{
  "name": "updateUser",
  "description": "อัปเดตฟิลด์โปรไฟล์ของผู้ใช้ที่ใช้งานอยู่ เช่น ชื่อ อีเมล หรือเขตเวลา ใช้สำหรับการแก้ไขและการแก้ไขโปรไฟล์ที่ผู้ใช้ร้องขอ ไม่เปลี่ยนสถานะบัญชี หากต้องการปิดใช้งานบัญชี ให้ใช้ deactivateUser แทน ห้ามใช้เพื่อปิดหรือยกเลิกบัญชี"
}
{
  "name": "deactivateUser",
  "description": "ปิดใช้งานบัญชีผู้ใช้ เพิกถอนเซสชันทั้งหมดและบล็อกการเข้าสู่ระบบ สามารถย้อนกลับได้ด้วย reactivateUser ใช้เมื่อลูกค้าขอปิด ยกเลิก พัก หรือระงับบัญชีของตน ไม่ลบข้อมูล สำหรับการลบถาวร ให้ใช้ deleteUser ซึ่งไม่สามารถย้อนกลับได้"
}

เทคนิคสี่อย่างกำลังทำงานอยู่ที่นั่น

ระบุเครื่องมือพี่น้อง “ใช้ deactivateUser แทน” ช่วยแก้ไขความกำกวมโดยตรง ในขณะที่โมเดลกำลังเปรียบเทียบเครื่องมือเหล่านั้น

รวมคำศัพท์ของผู้ใช้ คำว่า “ปิด”, “ยกเลิก”, “พัก” และ “ระงับ” ปรากฏขึ้นเนื่องจากเป็นคำที่ปรากฏในตั๋ว นี่คือการแก้ไขที่ให้ผลตอบแทนสูงสุดเพียงอย่างเดียวที่คุณสามารถทำได้ และเกือบจะฟรี

บอกว่ามันไม่ทำอะไร ข้อความเชิงลบสามารถแยกแยะได้มากกว่าข้อความเชิงบวก เพราะข้อความเชิงบวกของเครื่องมือสองชิ้นที่อยู่ใกล้กันมักจะดูคล้ายกัน

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

ความยาวไม่เป็นไร คำอธิบายร้อยคำที่ป้องกันการเรียกผิดพลาดเพียงครั้งเดียวไปยังปลายทางที่ทำลายล้างนั้นคุ้มค่า

ออกแบบพารามิเตอร์เพื่อให้ยากต่อการใช้ arguments ที่ผิด

เมื่อเลือกเครื่องมือที่ถูกต้องแล้ว อาร์กิวเมนต์คือจุดต่อไปที่สิ่งต่างๆ ผิดพลาด

JSON Schema ให้ข้อจำกัดส่วนใหญ่ที่คุณต้องการที่นี่ และ คำศัพท์การตรวจสอบ JSON Schema คุ้มค่าที่จะอ่านเพื่อดูคำหลักที่ API ที่เรียกใช้เครื่องมือของคุณรองรับ

ใช้ enums ทุกที่ที่ชุดข้อมูลถูกปิด พารามิเตอร์ status ที่พิมพ์เป็นสตริงจะชวนให้เกิดการคิดค้นสิ่งใหม่ๆ เมื่อพิมพ์เป็น enum มันจะจำกัดโมเดลให้ใช้ค่าที่ API ของคุณยอมรับ

"status": {
  "type": "string",
  "enum": ["pending", "paid", "refunded", "cancelled"],
  "description": "สถานะคำสั่งซื้อ 'cancelled' หมายถึงไม่เคยดำเนินการ; 'refunded' หมายถึงดำเนินการแล้วถูกยกเลิก"
}

ใส่หน่วยในชื่อ amount คลุมเครือ และโมเดลจะคาดเดาดอลลาร์หรือเซนต์อย่างไม่สอดคล้องกัน amount_cents จะไม่เป็นเช่นนั้นเลย เช่นเดียวกับ timeout_seconds, distance_meters และ duration_ms

ให้ตัวอย่างรูปแบบวันที่ "description": "Start date in ISO 8601 format, for example 2026-08-26" สร้างวันที่ที่จัดรูปแบบถูกต้องบ่อยกว่า “start date” เพียงอย่างเดียวมาก

รักษารายการที่จำเป็นให้ซื่อสัตย์ การทำเครื่องหมายทุกอย่างเป็นตัวเลือกจะผลักความล้มเหลวไปสู่รันไทม์; การทำเครื่องหมายสิ่งของที่จำเป็นที่ API กำหนดค่าเริ่มต้นอย่างชาญฉลาดจะทำให้โมเดลสร้างค่า ทั้งสองอย่างเป็นเรื่องปกติ และทั้งสองอย่างจะแสดงเป็นข้อผิดพลาดในการตรวจสอบความถูกต้องที่ครอบคลุมโดยโพสต์ของเราเกี่ยวกับ การออกแบบข้อความแสดงข้อผิดพลาดของ API สำหรับเอเจนต์

ชอบแบบแบนราบมากกว่าแบบซ้อนกัน โมเดลที่เติม {"customer": {"address": {"postal_code": "..."}}} สร้างข้อผิดพลาดทางโครงสร้างที่มันไม่สร้างบน customer_postal_code ทำให้มันแบนราบที่ขอบเขตเครื่องมือและประกอบกลับในตัวดำเนินการของคุณ

แยกเครื่องมือที่ใช้งานเกินกำลัง เครื่องมือที่มีพารามิเตอร์ mode ที่เปลี่ยนความหมายของฟิลด์อื่นๆ ทั้งหมด แท้จริงแล้วคือเครื่องมือสองชิ้น การแยกมันจะช่วยปรับปรุงการเลือกและทำให้ schema ทั้งสองง่ายขึ้น

ระบุเงื่อนไขเบื้องต้นและลำดับ

งานหลายขั้นตอนล้มเหลวเมื่อโมเดลไม่ทราบลำดับ ระบุไว้ในคำอธิบายของเครื่องมือที่ต้องพึ่งพา:

{
  "name": "captureCharge",
  "description": "บันทึกการเรียกเก็บเงินที่ได้รับอนุญาตไว้ก่อนหน้านี้ ต้องมี authorization_id จาก authorizeCharge เรียก authorizeCharge ก่อนหากคุณยังไม่มี ไม่สามารถบันทึกได้เกินกว่าจำนวนที่ได้รับอนุญาต"
}

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

ทดสอบการเลือกเหมือนพฤติกรรมอื่นๆ

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

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

เริ่มต้นด้วยกรณีที่น่าจะทำให้เกิดข้อผิดพลาดมากที่สุด:

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

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

ชี้การรันไปที่ mocks เพื่อให้การทดสอบการเลือกไม่แตะต้องข้อมูลจริง โพสต์ของเราเกี่ยวกับ การรันเอเจนต์กับ mocks แทนการใช้งานจริง ครอบคลุมการตั้งค่า และ Apidog สามารถให้บริการ mocks เหล่านั้นจากคำจำกัดความเดียวกันกับที่เครื่องมือของคุณถูกสร้างขึ้น ซึ่งช่วยให้ schema และพฤติกรรมสอดคล้องกัน

ชุดสามชุดที่ผิดพลาดในลักษณะเดียวกัน

ชุด CRUD API เผยแพร่ getUser, listUsers, searchUsers และ queryUsers ซึ่งทั้งหมดสร้างขึ้นจากปลายทางที่เติบโตมาหลายปี สำหรับโมเดล สิ่งเหล่านี้คือสี่ชื่อสำหรับแนวคิดเดียว การแก้ไขไม่ใช่การเขียนคำอธิบายที่ดีขึ้นในทั้งสี่ แต่เป็นการเปิดเผยเพียงหนึ่งในนั้นต่อเอเจนต์และปล่อยส่วนที่เหลือออกจากรายการเครื่องมือ ชุดที่ถูกคัดสรรมาดีกว่าชุดที่สมบูรณ์เสมอ

ชุดแอดมิน เครื่องมืออ่านและเครื่องมือทำลายล้างอยู่เคียงข้างกันด้วยน้ำเสียงเดียวกัน: getInvoice, voidInvoice, deleteInvoice ไม่มีอะไรในข้อความที่ส่งสัญญาณว่าสองในสามสิ่งนี้จะทำให้หน้าที่การงานจบลง เพิ่มผลที่ตามมาลงในคำอธิบาย ทำเครื่องหมายสำหรับการอนุมัติ และคงการบังคับใช้ไว้ในตัวดำเนินการ แทนที่จะเชื่อคำพูด แนวทางแบบแบ่งชั้นอยู่ในโพสต์ของเราเกี่ยวกับ การป้องกันไม่ให้เอเจนต์ทำลาย API ของคุณ

ชุด Legacy ปลายทางสองจุดทำงานเดียวกัน จุดหนึ่งเลิกใช้แล้ว Spec ยังคงระบุทั้งสองจุด ดังนั้นตัวสร้างจึงปล่อยทั้งสองจุด และเอเจนต์เลือกจุดเก่าประมาณครึ่งหนึ่งของเวลา ไม่ว่าจะยกเลิกการดำเนินการที่เลิกใช้แล้วออกจากเครื่องมือที่สร้างขึ้น หรือเริ่มต้นคำอธิบายด้วยคำว่า “Deprecated. ใช้ createOrderV2 แทน” โมเดลจะให้ความสำคัญกับบรรทัดนั้นเมื่ออยู่ตอนต้น และไม่สนใจเมื่อถูกฝังอยู่ตอนท้าย

คำอธิบายคือการกำหนดค่าที่ใช้ร่วมกัน

เมื่อคุณยอมรับว่าคำอธิบายเครื่องมือขับเคลื่อนพฤติกรรม คำถามต่อไปคือใครเป็นเจ้าของมัน ในทีมส่วนใหญ่ คำตอบคือโดยบังเอิญ: ใครก็ตามที่ตั้งค่าเอเจนต์เป็นคนแรก ในไฟล์บนเครื่องของเขา

ถือว่าชุดเครื่องมือเป็นสิ่งประดิษฐ์ที่ใช้ร่วมกันแทน ซึ่งได้รับการตรวจสอบเหมือนอินเทอร์เฟซอื่นๆ แพลตฟอร์มที่สร้างขึ้นรอบๆ งานเอเจนต์มักจะสร้างแบบจำลองนี้โดยตรง Sharkly Agent เป็นการกำหนดค่าที่บันทึกไว้ซึ่งครอบคลุมคำแนะนำ, Runtime, Skills และ repositories และการแบ่งปันใน Space ทำให้การตั้งค่าการทำงานของคนคนหนึ่งสามารถนำกลับมาใช้ใหม่โดยทีมได้ คุณค่าไม่ได้อยู่ที่การจัดเก็บ แต่มันคือการที่การเปลี่ยนแปลงคำอธิบายกลายเป็นการแก้ไขที่สามารถตรวจสอบได้ซึ่งส่งผลกระทบต่อทุกคน แทนที่จะเป็นการปรับเปลี่ยนในเครื่องที่เงียบซึ่งทำให้เอเจนต์ของนักพัฒนาคนหนึ่งมีพฤติกรรมแตกต่างจากส่วนที่เหลือ

สังเกตคำที่ผู้ใช้นำมา

ช่องว่างที่พบบ่อยที่สุดคือคำศัพท์ API ของคุณบอกว่า subscription ลูกค้าของคุณบอกว่า plan, membership และ billing API ของคุณบอกว่า deactivate พวกเขาบอกว่า cancel, close และ turn off

รวบรวมภาษาจริง ดึงวลียอดนิยมจากตั๋วสนับสนุน บันทึกการค้นหา หรือบันทึกการรันเอเจนต์ที่ล้มเหลว จากนั้นนำไปรวมในคำอธิบายของเครื่องมือที่ควรจะตรงกัน สิ่งนี้ใช้เวลาหนึ่งชั่วโมงและมักจะเพิ่มความแม่นยำในการเลือกมากกว่าการปรับแต่ง schema

จับตาดูความล้มเหลวด้วย เมื่อเอเจนต์ไม่เลือกอะไรเลยและตอบจากความรู้ของตัวเอง นั่นคือการพลาดคำศัพท์ ไม่ใช่ความล้มเหลวในการให้เหตุผล ภาษาของงานไม่เคยทับซ้อนกับข้อความเครื่องมือ ดังนั้นเครื่องมือจึงมองไม่เห็น

รายการตรวจสอบสำหรับชุดเครื่องมือ

• ชื่อเป็นไปตามธรรมเนียม verbNoun และระบุวัตถุที่เฉพาะเจาะจง
• ทุกคำอธิบายบอกว่าอะไรเปลี่ยนแปลง เมื่อไหร่ควรใช้ และเมื่อไหร่ไม่ควรใช้
• เครื่องมือที่ทับซ้อนกันระบุชื่อกันอย่างชัดเจน
• คำอธิบายรวมคำที่ผู้ใช้ใช้จริง ไม่ใช่แค่คำศัพท์ภายใน
• การดำเนินการที่ทำลายล้างและไม่สามารถย้อนกลับได้ระบุไว้ในคำอธิบาย
• มีการประกาศ Enum สำหรับชุดข้อมูลที่ปิดทุกชุด
• หน่วยและรูปแบบอยู่ในชื่อพารามิเตอร์หรือคำอธิบาย พร้อมตัวอย่าง
• รายการที่จำเป็นตรงกับสิ่งที่ API บังคับใช้จริงๆ
• เครื่องมือที่พึ่งพาระบุเงื่อนไขเบื้องต้นของตน
• ชุดการเลือกจะรันใน CI กับ mocks

โมเดลกำลังจับคู่รูปแบบกับข้อความที่คุณเขียน เมื่อมันเลือกผิด ข้อความคือที่แรกที่ต้องดู และโดยปกติแล้วเป็นที่เดียวที่คุณต้องแก้ไข ดาวน์โหลด Apidog หากคุณต้องการคำอธิบาย mocks และการทดสอบในโปรเจกต์เดียว

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

คำอธิบายเครื่องมือควรยาวเท่าใด? ยาวพอที่จะแยกความกำกวมได้ ซึ่งโดยทั่วไปแล้วคือสองถึงห้าประโยค คำอธิบายใช้บริบท ดังนั้นให้ตัดคำอธิบายสำหรับเครื่องมือที่ไม่กำกวมและใช้พื้นที่สำหรับเครื่องมือที่อยู่ติดกัน

ฉันควรใส่ตัวอย่างในคำอธิบายหรือไม่? ใช่สำหรับรูปแบบและหน่วย ซึ่งตัวอย่างจะกำจัดข้อผิดพลาดได้ทั้งหมด ข้ามตัวอย่างการใช้งานที่ยาวนาน เพราะมันจะใช้บริบทและไม่ค่อยเปลี่ยนการเลือก

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

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

จะเกิดอะไรขึ้นถ้าโมเดลยังคงสร้างค่าพารามิเตอร์ขึ้นมาเอง? จำกัดประเภท เพิ่ม enum และระบุในคำอธิบายว่าค่าต้องมาจากคำเรียกก่อนหน้า แทนที่จะถูกสร้างขึ้นมาเอง หากยังคงเกิดขึ้น ให้ตรวจสอบความถูกต้องใน wrapper และส่งคืนข้อผิดพลาดโดยระบุค่าที่อนุญาต

กฎเหล่านี้ใช้กับเซิร์ฟเวอร์ MCP ด้วยหรือไม่? ใช่ เซิร์ฟเวอร์ MCP เผยแพร่ชื่อ คำอธิบาย และ schema ในรูปแบบเดียวกัน ดังนั้นกฎการใช้คำเดียวกันจึงใช้ได้ คำอธิบายของเราเกี่ยวกับ MCP คืออะไร ครอบคลุมโปรโตคอลนั้นเอง