📄 Documentation & Supplemental Learning: https://docs.google.com/document/d/1HbhCZHxbl-tfAXueC1XtjoFG0naJbW3nx36hDFbmaIQ/edit?usp=sharing ➤ I have been personally going through custom tools lately that are not able to be mapped or having trouble will calling the tool so I created this 20 min crash course that goes over everything exactly and I build, test and use an update_contact custom tool to show you how to map it ➤ Some things I have noticed: - Custom tool names and parameter names should be in JSON format: All names should be completely lowercase with underscores instead of spaces, with no special characters. Simple raw text with underscores. (I.e. update_contact, send_sms, first_name, opt_out, etc) This makes mapping consistent and reliable since args is completely AI generated and LLMs are familiar with JSON formatting. - Descriptions are so very important. AIs are smart - but that are not super intuitive. So, your description is key. It should leave absolutely nothing to interpretation. Be clear and concise on what the tool does and under what condition to call the tool - this create a consistent and reliable rule for functionality that the AI can understand. This goes for both the tool description it self and the information. ____________ ➤ Leave no room for AI interpretation on what the tool does, what you want it to do & when you want it do Examples of great descriptions: For a tool itself - Get the delivery date for a customer's order. Call this whenever you need to know the delivery date, for example when a customer asks 'Where is my package' For a parameter - The annualized revenue of the user in raw number format. For parameters, we leave no room for interpretation on what information we need, and in what format to send that information. ⛔ opt_out: contact opt out The reason this is not great is, opt out of what? what format - true/false, yes/no? etc. There is a lot of room for interpretation and inconsistent results may generate (args is generated by AI)