Granularity और नामकरण

न बहुत ज़्यादा, न बहुत छोटे

हर REST endpoint को tool बना देने से model के पास दर्जनों निचले स्तर के विकल्प हो जाते हैं और एक काम के लिए कई steps चाहिए। इसके बजाय कामों के आसपास डिज़ाइन करें: calendars सूचीबद्ध करने, खाली समय खोजने और events बनाने के अलग calls की जगह schedule_meeting(attendees, time)। क्रिया-संज्ञा नाम (search_orders, cancel_order) रखें और संबंधित नाम एक-से रखें।

Tool model के लिए interface है

Tools को ऐसे पाठक के लिए API की तरह डिज़ाइन करें जो सावधान पर अक्षरशः समझने वाला है: साफ़ नाम, संकरा उद्देश्य, मददगार errors।

निचला स्तर बनाम काम का स्तर

काम के स्तर का tool orchestration को आपके कोड के भीतर छिपाता है, जहाँ वह परखने योग्य और निश्चित है।

Low-level (4 model steps):
  list_calendars -> get_free_slots -> pick_slot -> create_event

Task-level (1 model step):
  schedule_meeting(attendees=["asha","ravi"], duration_min=30)
  # your code finds a slot and creates the event

मिलते-जुलते tools मिलाएँ

दो tools के लगभग एक-जैसे descriptions हों तो model उन्हें उलझाएगा। उन्हें मिलाएँ या हर description में अंतर स्पष्ट लिखें।

त्वरित जाँच: कई छोटे endpoint wrappers की जगह काम के स्तर का tool क्यों बेहतर है?

• यह descriptions को अनावश्यक बना देता है
• छोटे tools अवैध हैं
• यह model steps घटाता है और orchestration को परखने योग्य कोड में ले जाता है
• Models छोटे tools नहीं बुला सकते