AI Agent Mastery Certification Course: Lab 4 – Tools & MCP

[00:00:00]Hi everyone and welcome back to lab 4.

[00:00:03]Um in this lab we're going to focus almost entirely on tools. So the tools are the functions that kind of let your agent kind of reach out into the real world, call APIs and bring back some real data. So you've already seen um our basic travel agent and now we're going to upgrade it via its tools so that they can um do things like use specialized APIs instead of just a generic search.

[00:00:24]They can return more precise and actionable information. And of course, we're going to trace all of that in Arise AX. So you can actually see um all the different calls um and see how our tools are changing from our base agent to what is happening after we run this notebook itself. So we'll walk through how each tool is implemented, how it kind of fails in like a graceful way. Um and also just how it shows up in our traces. So let's go ahead and dive in.

[00:00:51]Um, I've talked about setup in the other labs previously, so I'm going to kind of keep it short in this one and focus more on our tools, but if you wanted to get more information on our setup, I would recommend um watching the previous labs um especially the first one. So, I'll run through it really quickly, but we'll start with our really quick setup. So, we'll install a few packages like our Arise Hotel, Agno, OpenAI, as well as our open inference instrumentations. Um then we'll enter our Arise API key and space ID and then we'll also enter um the other API keys for OpenAI as well as Tavi um using get pass and then we're just going to register our tracing with our model ID. So this is going to be our project in Arise AX called um travel agent demo. And the register function basically will just like connect what's happening in this notebook to our Arise AX account itself. And so this is the same pattern that you've kind of seen in earlier labs, nothing is new conceptually. Um, but in general, we're just wiring up all of this so that everything that we do in the notebook is captured in AX.

[00:01:56]So now let's go ahead and talk about the tools themselves. So in previous labs, our tools kind of leaned more on in general like a generic search approach.

[00:02:08]Um, and here we're changing our tools a little bit to kind of focus on um, the goal here is to like make them more focused, right? By using the right API for the job, to make them more reliable, like in terms of handling errors or if you don't have a key and in general just more like we'll have them be more observable by tracing each of the API calls themselves.

[00:02:28]So to basically do that, right, and achieve our goals that we've set, we're going to use both Wikipedia and open media for our essentials. We'll still use our Tavali search for our budget and local flavor like um what we want our focus of our trip to be to find the information for that. And then we'll wrap everything in our traceable helper functions um so that we can trace all the different pieces there.

[00:02:53]And so these are the same tools that we've been using, but I haven't actually like done a deep dive into explaining exactly what these tools are doing. So we can do a little bit more of that right now. So let's start with the search API function that we have. So this is a helper function um that centralizes kind of how we talk to Tavi.

[00:03:13]So it's decorated with this tracer.chain um name search API. And basically what that means is um every call that happens for this function itself will have a span call within the like trace tree and that span will be called search API itself. And so what this function does is it search for a Tavali key and it will return none if the key is not set.

[00:03:38]But if the key is there, it'll send a post request to um api.tav.com/arch.

[00:03:44]So this URL right here um with information like our max tries obviously the key um the search depth being basic and including the answer. And so that is pretty much it. So this um function itself will basically pull out the main answer. it'll gather like some text snippets from the results and then um the way it actually returns the results it is that it combines all of them into one long string and trims it to be um 400ish characters actually yeah it can it cuts it off at 400 characters and the idea here is that if anything fails so like if you don't have like an API key or you're having like a HTTP error or just like in general something weird happens like you have a weird response it will return none instead of like throwing an error or like stopping the entire program basically is the idea behind the search API key. Moving on, um compact is also another function that we've been using. So these are are part of our two helper methods that we've had in all the labs previously and we'll keep using them in future labs as well.

[00:04:50]Um the compact function itself actually is a small but important utility. Um, essentially what it does is it collapsed the extra white space in responses and then if a string is like longer than a certain limit that is set, then it basically will cut the last space before the limit so that you're not like chopping a whole word. You'll get like like you'll get the entire last word basically. And so we're actually going to use compact inside our tools to kind of keep these responses both short and readable. Something to note here too as we go on and look at these next ones is that the compact function does not have at tracer.chain.

[00:05:26]So we're never actually going to see um when compact is being used in our trace tree. But if you wanted to set that up, you would just do the same thing of at tracer.chain name and then have it be like compact or like something um for it to actually show up in our trace tree.

[00:05:44]So, moving on, here are kind of the new things that we're adding in for this lab. Um, we're going to have dedicated APIs for our essentials. So, the first one that we can go through is wiki summary. And so, this is basically just like Wikipedia context. So, for essential travel information, we can use um Wikipedia directly using this function wiki summary where you pass in your like destination or your location.

[00:06:08]Um, so some key details about this is that obviously it is decorated with this tracer.chain. chain and so it's going to appear basically as its own span anytime you run this function and it's going to basically the entire purpose of the function is to call this like um wikipedia.org/api org/appi page right that is here um with the spaces kind of replaced by the underscores of the destination name that is in the destination name and then um if the response is 200 okay then it returns the extract field which is basically just going to be like a clear summary paragraph otherwise it will return um an empty string and so this kind of gives our essentials tool so this is like the essential information tool that's defined down here it's going to give us um a highquality base description for most cities that um the user is like trying to get information on or like is planning a trip around basically. Um another function that we've added is this weather API function. So we also want live weather um is the idea and so that's why we're kind of defining this fun this function. Some key um things about it is also the fact that it will show up as its own span in our trace tree just given that we are using the at tracer.chain function. Um, first it's going to basically call the open media geocoding API to look up the latitude and longitude for the city or the destination that you are passing in. And if the geocoding um call like fails or kind of like returns no result or something happens where um it's not helpful, it will basically return an empty string and then it'll stop. Um, so yeah, and then it calls the if it does have the encoding, right? And it's able to find the longitude and latitude, it calls the open medios API with current weather set to true. And so this will basically extract the temperature and wind speed from the current weather and format it in like a oneline summary that says like, okay, your weather now is 20° C and your wind is 6 miles 6 km hour or something like that. And so again the span will kind of show both the input.

[00:08:14]So the input being the destination or the city um and output so the weather summary when you will inspect this in ax basically.

[00:08:24]So now I think for the main event um the tools themselves three tools that our agent will call. So these are the same tools that we've had in the last couple labs. Um but I never actually went into explaining them to too much depth. So we'll go ahead and do that right now. um especially with our changes that we made to our essential info um tool to use like the wiki summary and the weather um tools that we just defined. So some briefs is that um for this essential information tool this is kind of like your your quick info quick basically brief on the city. So inside of the function, you basically in initiate initialize a parts list and then it will call your wiki summary and append the results to that parts list and then you'll call um weather and we'll also append that if it's not empty. And so the idea here is that it will finally return something like destination. So like Tokyo essentials um is the wiki summary of like Tokyo um and then also the weather line. So you would see like Tokyo essentials whatever the Wikipedia summary is and then it'll say weather now um 22° C for kilometers per hour or something like that and all this is built from API so it's very trusted and it's not like any sort of guesswork it's like rooted in truth get the idea there so moving on to the next tool we can go to budget basics and so the idea here is that this tool is optimized for cost information um so it's going to build kind of like a focus query string like okay your Tokyo travel um budget average daily cost for 5 days right and so it'll basically give you like if you give it a destination and a duration it wants to figure out what the daily cost is and it's going to take that that um query string and it's going to send it back into our search API function that we have and that search API function is going to be our Tavi answer and so if a Tavi answer comes back it's going to return something like Tokyo budget um for 5 days is going to be whatever number that it figures out. Now, if the search API returns none because of any of those reasons, right, like you didn't have an API key set or something, then it'll fall back to saying like budget for 5 days in Tokyo will depend on things like lodging, meals, transport, as well as attractions. And so I think like the happy ground here um the happy path here is that it's grounded in like real search results if your API key is set and you're able to get like an actual accurate answer. But the fallback is still a safe and generic explanation that is still like somewhat helpful, right? Like you know that you need to know the cost for things like lodging, meals, transport, and attractions to be able to actually um figure out what your budget for your trip is. And so the local flavor um tool is going to be very similar to the budget basics tool. Um this is going to be like your vibes tool basically like focusing on whatever experiences that the user has essentially said that they are interested in. So similarly it'll build a query itself um something like Tokyo authentic um like local experiences in food culture and fashion or something like that if your interests were food culture and fashion. Um once it makes that query, it's going to do the same thing and send it to the search API. If the result comes back, it'll return like Tokyo interest include um something something something. And if no search results come back, then it'll just have a generic response of explore Tokyo's unique um food culture through markets, neighborhoods, and local eeries. And so it's kind of designed to pull in local and on the ground um style suggestions when your search is available. But again, it'll still sound realistic and reasonable um if you don't have that API key set or if your search API function just isn't working for whatever reason, if it fails for whatever reason. And so that is pretty much how our tools are defined. And so with our tools ready, we can go ahead and define the agent that will actually use them. Um so we're creating this trip planner agent or our trip agent. Um the name is trip planner.

[00:12:28]The role is AI travel assistant. we have set our model up and then there's instructions that explicitly say like to combine multiple tools include essentials budget and local flavor and then to keep the tone just like friendly and under 1,000 words. So that is totally like malleable like you can change what your instructions for your agent actually is. We also just set markdown to to true so that um the response is like formatted nicely and you can see it and then we're actually going to be passing in those tools. So for this specifically um this is the same structure as earlier labs um specifically lab one and two um and so the difference is basically just like how powerful and specific the tools now are. So we're changing the tool definitions and the tool use but we're keeping the actual agent the same.

[00:13:17]And so then we can actually go ahead and run our sample query so we can try a concrete example. So we'll I'm going to use the same one the Tokyo example. So, Tokyo 5 days interests are food and culture. Um, you can change this to be whatever you want it to be as well. So, I'm just going to let it run and we'll see it kind of thinking through. Um, and yeah, that is pretty much it. We can go ahead and as this is running and creating its answer, we can go ahead and go back into um, Arise AX and see what the trace tree is looking like. Now that we are um back in Arise AX, we can go ahead and see how this looks under the hood. So this is um me in my travel agent demo project and I found the trace that we had just ran. And so in this trace you can look for our top level span being that trip planner agent and under it we have the spans for each of our tools. So like the essential info, budget basics and local flavor. So this is what we had seen previously as well in our base agent. But now the difference is that we have these two um other chains that we have started defining and the reason why they are chain is because we set them to be tracer.

[00:14:24]Um in our actual run as these two make up a bigger span that is or the parent span that is the tool span itself. Um so yeah and so when you click into things like budget basic and local flavor you'll see the search API um spans which is basically where Tavi is called and then this is the basically the exact visibility that you want to have. So every tool call every external API um is clearly logged. It shows you the input and the output for all of them and what is kind of attached to the agent run itself.

[00:14:57]So that is pretty much it. We can go ahead and go back into our lab 4. And that's pretty much it. So, you didn't just kind of define tools in this um lab. You were actually able to design them around your specific jobs, right?

[00:15:10]So, essentials, budget, local flavor. Um you could have set even more up. So, you could have backed up more real APIs instead of just Wikipedia, open media, and tavally. Um if there's another API call, you could have done that and then set that to be a part of one of your other tools. Um but in general wrapping them um in some sort of helpful fallback when the APIs aren't available is also something that is fairly important to make sure that your agent is still able to work and not necessarily throwing errors and then of course you're able to actually trace them end to end so you can if you needed to debug and improve them in Arise AX. So as your agents kind of become more complex I think that this pattern becomes critical you know having good tools good observability you'll have good agents. So in the next lab we'll actually combine these ideas with a full rag system kind of driven by a curated data set of local guides. So again kind of building on our tools but using a different instead of using APIs kind of using a rag system there. So that's pretty much it for this lab. Um but I will see everyone in the next module.