MCP is so back! Build Tools for the Agents Your Users Already Use

0:00 weekly master workshop. My name is Alex. I'll be your host today and I'm joined by Daniel Lou. Hey Daniel, what's up? >> not too much. How's it going? >> Well, yesterday was a pretty huge day at Mastra. We just launched Mastra and we were we finished the day in the number one spot on Product Hunt, which I think we're all feeling proud about. >> Yeah. Yeah. above. it's it's always pretty tough because we we launched on the same day that OpenAI launched a product and that Meta announced their their Muse Musebot something like that Muse Muse model and yeah beat them both. So So we're pretty happy about that.

0:44 >> It's always kind of a mixed bag because you never know >> who's going to launch on the same day. >> That is the risk with Product Hunt. and and there was one product on Product Hunt that we just absolutely couldn't lose to that you that you mentioned on Slack. It would have been humiliating if we lost of this product. What am I talking about? >> it was yeah in in number six came ass auction. Somebody had a had a product where I guess you can you can bid for space for your brand on their butt or their boxers or something like that.

1:21 I didn't look too much into it. I I don't think I don't think we're going to be one of the biders, but but you know, >> so there was some tough competition with Meta and OP and AI. And then there was some easier competition, but you know, came out on top. Masteractory. >> Check it out if you haven't already. Master.aifactory. But we're not here today to talk about Factory. Oh no. We're here to talk about MCP.

1:46 And so what do you reckon, Daniel? It's been a few minutes. Shall we get into the workshop good and proper? >> Yeah, let's do it. >> Where are you based again, Daniel? >> I'm out in Waterlue. >> You're in water? >> Canada? I I guess there's a lot of Yeah, >> I'm in London. London, England. There's a lot of Londons as well. >> Yeah, there's a London an hour away from me, too. That distinction has been useful and it's an important distinction. And yes, if you're joining us here on Riverside or YouTube, we'd love to hear from you as well in the chat. Whereabouts are you tuning in from? Let us know.

2:41 Aon's tuning in from SF. Aon, is that a key and Peele reference? Dim from Vienna. Aditia is based in London. Is that Aditia? Yakob is based in Canada or Jacob perhaps. I have a Danish friend called Yakob spelled the same way. That's why I pronounce it that way. Wati is definitely from Denmark. So, that's cool. Gerald from Germany. Okay. Okay. Everyone's awake. Everyone's here in the chat. >> All right. Does it look all right?

3:13 It does. it looks nice and crisp. Yeah. you're going to be Yeah, there's like I think you're a little bit blurry actually, Daniel. Daniel, you're going to be mortified because this happened last time as well. And this is with all the best options enabled. So, let's just monitor that situation. And if Daniel's audio or video does degrade, just let us know in the chat and we can try turning off your video, Daniel, to make sure that it's nice and smooth.

3:45 >> I think there's a if you're able to pause the upload to Riverside, I think >> that's already >> right now. I see I see it's saying that it's uploading right now. >> Okay. Says paused on my end. We'll have to monitor the situation, I think. >> Okay. >> Should we get into it? The slides look okay. At least >> the slides are crisp. Yeah, MCP is so back and >> so are we. >> As long as you can see the slides, I don't matter that much. I can be pixelated. That's fine.

4:14 >> We'll figure it out. Yes. This is actually not even our first MCP workshop. Is it Daniel? Fun fact, the first ever workshop I hosted at Mastra well over a year ago now was about MCP and with Daniel. Daniel is the engineer who implemented our MCP feature in Master. So I thought who better to have on and talk about this subject. Why are we talking about it now? Because MCP recently went underwent a big update and with it some new features and refinements. We thought this would be a great time to talk a little bit about what's new in MCP 2 and the industry is evolving a bit as well. So what do you reckon Daniel? Should we jump over to the next slide and talk a little bit about the timeline so far?

5:00 >> Yeah, let's do it. >> What is MCP? It stands for model context protocol. And fundamentally, it's a specification and a protocol that enables a server to expose things to agents. These might be agents that you control. Or they might be agents that other people build and use, but they want to somehow connect to your services and specifically do things like call tools that you define or consume resources or prompts. Web applications have APIs. A good way of thinking about MCP is that it's kind of like an MC kind of like an API, but specifically optimized for agents. What does that mean? But we'll have to get a bit more specific in the next few slides as we give some examples around discoverability and OR and the specific things that these servers expose.

6:05 So, I know you're saying MCP is so back, but I just want to say I don't think it ever left. I think >> Okay. >> Yeah. Well, like I don't know. There there's so much just back and forth with the the AI domain and like there's so much hype around new things that pop up. Like I remember when when skills came out, everybody was like, "Skills came out, MCP is dead. Nobody's going to use MCP anymore." And then everybody just started they're like, "Okay." After a bit, they're like, "Okay, you know what? MCP still exists.

6:41 skills are are also a thing but like a separate use case. And then CLIs started to get more more attention. Everybody's like MCP's dead. Everybody just use CLIs. And then the same thing happened. They're like, "Oh, actually, no. They're they kind of serve like different purposes. Like MCP is still alive." And yeah, just like if you look at this this tweet from from somebody from OpenAI, just looking at their traffic, there wasn't any dips. Like when when skills came out, when CLIs got more attention, there there wasn't any drop in MCP usage. It's just been steadily increasing and increasing. I think like we just have a blind spot to the new shiny thing in this domain because everything's changing so much.

7:31 But like MCP was one of the OGs for for interact for like around like agent protocols and so yeah what is it like two years later still kicking still growing like crazy. Yeah, I think we have this tendency to look at the new stuff and abandon all the existing stuff in the context of X and developer circles where we're all excited about the new stuff, but then there's always this almost dark matter of industry and products and teams of developers. They're not chasing the hype. They're solving real problems. And one of those solutions is MCP as this graph proves.

8:20 >> Yeah. And let's I'll pass it over to you to to talk about the the timeline. And I don't know if this is intentional or not, but your your video disappeared at least to me. You know, this the fun thing about using one of these fancy webcams, which is basically a camera, is that the battery dies and then I have to replace the battery every couple of hours. So, just did a little hot swap and I'm back with you.

8:47 So yes, back in November 2024, MCP came to the forefront and there was an uproar of hype because we could all feel the power of reasoning models and we knew that if we asked them to create a plan and just output it in text, it knew the right things to do, but it didn't really have a good way to reach out into the outside world and do things like authenticate and interact with services on our behalf. Reasoning models were exciting back then, but they weren't quite powerful enough yet to write code or call CLIs and things like that. So, the industry started to think about, okay, what is the right protocol that's going to enable agents to interact with existing services and do things on a user's behalf and so entered MCP and then during this time there was a lot of hype and a lot of figuring stuff out. I don't think the initial specification even touched on or off or for example and there were all kinds of challenges with this approach. The first most naive approach was and so just to clarify and put an underline under all of this the fundamental purpose of MCP and the most common use case is to enable agents to call tools over the network. Tools that your service defines for example just like an just like a client might call an API. And so naively, what we did is create a bunch of tools for each thing that was previously an API endpoint. But in doing that, it meant that the model would quickly get overwhelmed with too many options. It wouldn't always pick the right tool. And then even if it did, the implications on the context window would be enormous as you would return these like full payloads of JSON that maybe an API client could consume and just dot dot access the JSON properties it needs, but an agent would have to look at all of it and make sense of it. And so models messy were were pretty garbage as well. So it's like you have this this new spec that they don't really know quite how people are going to use it and consume it. And then you have these models that aren't very good either. So it's just kind of this this mishmash of like when you you don't just it doesn't feel like a great experience when you first try it out unless you're using like a very very simple use case.

11:03 >> That's right. Yeah. And I think gradually as different teams and as people took their use of MCP further, the spec continued to evolve up until present day really which was just the end of July I think. they released MCP2 which is something that we want to talk a little bit about today. I don't know Daniel, what other key events stand out to you on the MCP timeline?

11:35 yeah, I think moving away from like it started off as server sentent events and like standard IO and just moving to streamable HTTP was a a pretty huge deal because then you could start running MCP servers in a serverless environment. And so even things like enabling like you have here like richer interactions like structured outputs elicitation being able to like have some some back and forth between the the client and the server like all of that enabled a lot more use cases. Yeah. And just like authorization like that was such a huge deal. just a lot of people complaining about like the security of MTP >> without any guidance. So it's quite hard to like know you're doing things the right way. but that does come a little bit further along.

12:32 >> Yeah. Welcome to engineering. >> We gave a workshop around the foundation part of this timeline somewhere in between and now we're here to give you the the latest in this event. And so what do you reckon Daniel? Should we move on to the next slide? >> Yeah, let's do it. >> Yeah. So, so we kind of touched upon this like here and there, but like why should you care about MCP? And so, a lot of people, a lot of users kind of think about, the like should you ex like you have you have an API, you you have some sort of product and so you want to expose it to a user. It's like, okay, do you build an agent on your platform that interacts with your product that can like have all these tools that interact with your with your APIs or do you build an MCP server and let somebody bring their own client to it? So it's like okay I can just use chat GPT and interact with your product through that interface rather than having to like go to your platform and interact that way. And so what we're what we're seeing is that there's on the MCP side of thing the MCP argument instead of building out an agent on your platform there's a lot lower barrier to adoption. It's a lot easier to build an MCP server around your your product than it is to build an agent around your product. and also it's it's one less assistant for for somebody to learn how to use. Like I I don't know if like Yeah, even just going between like Claude and ChatgBT like they they feel slightly different that you have to talk to them in different ways. So it's like every every additional agent that you make a person use it it's just kind of overwhelming that you have to learn the quirks of all these different agents. So it's like maybe maybe you don't want to to to put the the burden on your on your user.

14:48 another interesting thing that that we've heard people say is that when you give somebody an MCP server they they bring their own client. So like chat GPT and interact with it. When when something goes wrong, they blame chat GPT. If you have an agent that's embedded in your product and people start chatting with your agent and it it doesn't do what it's supposed to do, they blame your agent. So you're kind of also shifting the perception of what is important or sorry the shifting the perception of where where the the issues come from. So, it's like, okay, if if my client is isn't able to interact with this MCP server properly, they're likely less to blame your MCP server than than the the agent.

15:38 we're also seeing a lot of enterprise adoption of of MCP servers. yeah, pretty much, yeah, no, you name it. like every every single big big company has has an MCP server that to to interact with. >> it's quite an interesting point you make that building agents is hard fundamentally you have to think about memory personality evals all this behavior that that is a maintenance burden but you could instead focus on building a really high quality tested MCP server that exposes tools good or prompts resources all that good stuff and then your users consume it and the client they're already familiar with plus maybe another benefit of that is not just the user experience, but a lot of people when they use Grockbot or Codeex, they have like schedules. so then they could bring parts of your product and its capabilities into their existing workflows like a schedule for example. And it also takes care of the integration side of things where maybe the task at hand requires taking data from your product or doing an action in your product in conjunction with another MCP server. So they can rely on it as a coordination layer. Whereas if you were to build an agent to enable that same behavior, you would have to then start to embrace the maintenance burden and the product thinking burden of offering these type of integrations. It's possible you do both as well. By the way, you might give users an inapp assistance or some kind of agent and also expose an MCP server so that your users have that option.

17:17 >> Yeah, exactly. And I guess I kind of jumped ahead and and talked about the the other points here about put like shifting the blame to the agent rather than the the tools and easier to maintain. You know what's funny though is that I've literally never tried using like chat GPT for example and giving it access to an MCP server to to use tools. I'm quite curious what that workflow looks like from an end user's point of view.

17:54 Oh, you're you're you're really setting me up here because the the next slide I'm going to minimize that and walk through a quick demo here. >> I'm genuinely so curious. Yeah. >> Yeah. Honestly, before before this, I hadn't done the same either. So, I learned a couple things on the way. >> And so, see how it works. >> I I have a a MRA MCP server. the server is running. And so I'm going to go to my chat GPT settings. And so I had to enable some stuff in developer mode for this to happen. I'll just show quick. Yeah, turn on developer mode.

18:38 and then what I'll do, I'll browse plugins. I'm going to create my own plugin. I'm just going to copy some values into here. So, my MCP server is a returns desk. I'm going to drop a description in there as well. I have a URL here. And so, this is just the I'm using Enro to make it available to the web. and just using the the MRA MCP server endpoint there as well.

19:21 >> So, okay, so just to slow down the we're in like a development mode right now. So, we're setting up the plug-in manually, but you could build a plugin and put it on the marketplace for chat GPT and then your users wouldn't have to go through this step. >> Exactly. This is mostly like in in like a development mode type of thing when you're working on your your MCP server and you just want to test some things out. But as you like build up your product and like release it, yeah, you you'll want to have like an official plugin.

19:56 And so I'm just and I I have authentication with OOTH set up. And so I'm going to create this. And then it should direct me to a login. >> Yeah. So, it's saying to sign in. It's going to redirect me >> to >> work OS. >> Oh, I guess I was already logged into work.

20:27 >> Yeah. Yeah. So, you can see I'm I'm logged in with my email here. And so now I can go >> So it's authenticated on your behalf. Cool. >> Yeah, exactly. So now I'm just going to show just a few interactions here. So I'm just going to tell it to to look up an order. >> I love how we talk about MCP as builders, right? We have to think about the spec and the protocol. but from an end user's point of view, especially an enterprise user or B2C user, they don't really think about MCP. They just think about plugins basically.

21:02 Yeah, exactly. And the nice thing about MCP is that it's leaked out from just the tech community and a lot of people who aren't techsavvy like use MCP without them realizing. They just call it a plugin or connector >> based off of like whatever client they're using. So they yeah and like going back to to things like CLIs, it's like CLI are are very technical thing. They're they're not going to have the same kind of >> growth as MCP for that reason.

21:42 >> So that's a great point, isn't it? Because after MCP skills became very prevalent and the idea was why do we need MCP when we can just have a skill that knows how to call an API or a local CLI the really and that works pretty well actually for dev tools by the way but for consumer products or enterprise products you can't expect people to do local or off right like putting a key on their local machine you want to use oorthth fundamentally and that's what we just experienced right here as the plug-in authenticator on Daniel's behalf to take actions linked to his account here in the return task.

22:18 >> Yeah, exactly. And and like OOTH is a very non-technical thing like any anywhere you try and make an account or log in like you you click the oh sign in with Google and then bam, you're you're in and that's like people are just used to that now. >> Yeah, that's the way to go. that way enough like Oof had a bit of trial and error which is funny to remember because >> so has and will MCP. Just a quick question here from Matt. They're asking if MCP MCP plus Master is hosted on Enro. So the idea here is that the chat GPT server needs to connect to the MCP server running on Daniel's local machine. you can't access a local server via local host from chatgptt right and so angro is a tool that makes the local server accessible on the public internet that we then point chatgptt to you would always host your server somewhere right maybe on amazon for example in which case you would enter a public URL it it's not hosted on enrock as such it's more of a tunnel in this case >> exactly yeah yeah so you can see >> a question from NASA.

23:30 >> By the way, Daniel, I think it was I think last week you John and I did a workshop on evals and I had this idea like I'll leave all the questions till the end and we'll do Q&A and so we had like 30 questions in the backlog in no time. So today I'm like trying to clear the back clear the deck as soon as the question comes in. >> NASA asked a good question. Should the MCP tools be the same as the internal tools? So, do you expose every tool on your master server or just some of them? What's the right way of thinking about it, do you think?

24:02 >> you can think of like a a single MCP server as a collection of of tools. So, it's it's possible that you might want like if you have different products, and it's like, okay, you might want only this collection of tools or that collection of tools, then that's like a a pretty good argument for having multiple MCP servers. But if you just have a a single a single product, maybe you just want all your your tools together. So it it it really depends on it's I know it's it's a bit of a copout, but when you're talking about tools, it it really depends on like the like what exactly you're building.

24:39 >> I I will say try and expose as few as you can because the more you offer, the more the plug-in or rather the agent has to choose from and therefore more the likelihood it goes wrong. So you want to reduce the surface area ideally >> and there are >> you go I we'll we'll finish this before moving on to the next question. Go ahead please Daniel. and there without to say like there there are ways to to work around that as well. Like there's there's different patterns. I was going to mention this later, but it's a good time good segue here as well. that we've seen people use patterns where they group all of their tools together with a search tool and an execute tool.

25:26 So they just give their client or their agent two tools and basically give it a way to search through tools and to execute the tool and so that kind of lets allows you to have quite a lot more tools at an agent's disposal. >> To have asked what's a CLI AON's right that's a command line interface and yeah OF is the way to go when you're doing client side stuff. If you have any more questions, let us know in the chat and we'll periodically answer them. Back to you, Daniel.

25:58 >> Yeah, thank thanks for keeping me honest here. yeah. So, so you can see that it called the tool from the MCP server. I'm just going to walk through a couple different flows here as well. so I'm checking out these other two orders, see if they're eligible for return. gonna let it do its thing. You know, for this being instant, it's pretty slow.

26:29 >> Okay. So, neither of these are are eligible. So, let's see. You can see the the results there. So, now I'm going to pass it another command. so this time I'm going to ask it to process a return, get a shipping label, and give me packaging reasons. >> Great. So, it it did a did another call.

27:07 Are we going to look at how someone watching can code their own MCP server later in the workshop? >> Yeah. Yeah, exactly. So, so right now I'm just going to walk through a couple things. We're going to jump back into the slides and then we're going to walk through the code in in more detail and I'll show you like MRA Studio as well. And so this this is interesting. So now we have another interaction here that we haven't run into yet. So now it's asking me to give it permission to do something. And so you me as we mentioned before one of the earlier specs of MCP allowed allowed for more richer interactions from the server to the client. So now it it can do things like request input or ask for confirmation things like that.

27:57 And so this is this is using >> elicitation which we'll we'll talk about later how that how that's slightly changed in the new spec as well. So I'm just going to allow this once. >> Elicitation is to have the MCP server elicit a response or an input from the user. >> And I guess in this case it's being used as a type of human in the loop approval thing. could be to seek clarification on something or request additional context in general.

28:33 >> Yeah. Cool. So So that's all I want to show for for that and then we'll jump back into the slides and I'll I'll go more into detail. >> Mhm. Yeah. Sounds good. >> Cool. So, kind of alluded to this a little bit, but a a new spec dropped a couple weeks ago and some things changed. the what we've seen mostly is that a lot of different things are being deprecated.

29:08 And so the the spec is mostly steering you in a way of like these capabilities already existed, but we want to make sure you do it in the right way now. >> And and so kind of making sure that you don't do things in ways that might either not exist in the future or just like over complicating or just like will make you run into issues in the future as well. And so the the first one is stateless requests, >> the the big one, right? Sort of headline >> and and and I mentioned that earlier in the timeline. It was a huge deal when streamable HTTP came out and it's like, okay, now you can run MCP servers in in a serverless environment. And so now they're making it that the the default and eventually going to remove support for everything else. But right now, >> was it websockets originally?

30:08 >> it it was server sent events. >> Okay. >> And then standard in and out. >> Mhm. >> And and so yeah, it everything was done through long live sessions and now the way it's moving towards is every request has all the information contained in it. And we'll we'll talk a bit more about that in a in a later slide as well. >> Yeah. So really that's about it's partly to do with scalability, right?

30:42 Because maintaining long live sessions can be quite difficult for things like load balancing. we learned through HTTP that stateless is a good thing and now MCP have embraced that too which is cool. >> Yeah. >> Shall I talk a bit about server discovery? Yeah, let's do that. >> Well, the other thing that's changed here is that when the sessions were stateful, they were initialized with a handshake. And during that handshake, the client could share data with the server. And the server can respond and say, "Hey, here's all the things I have available that I can do, right? Here are the tools I have, the resources, the prompts, and so forth." But with this new stateless system, we don't really have a handshake anymore. And so there has to be a way for the client to basically discover what is available to it on the server. That is more important like there's nothing about HTTP that says a server has to expose a list of all the endpoints. We we happen to do that with things like swagger, right? but the point I'm getting at here is that because agents are able to reason and auton autonomously move towards goals, we have to give them the means to figure stuff out. And if it doesn't know what's available to it, it can't find its way and reason to the best solution, certainly not efficiently. And so, it's really important that an MCP server gives a client a really clear way to discover what's available to it. And so this server discovery replaces the capability exchange that previously happened during the handshake.

32:19 >> Yeah. And another big thing they're calling MRT or multi-round trip requests. And so this is a way for now now all tools return either an input request or a completed request. So a completed basically tells the client this is this is like the the response to the tool. Don't worry about it. And then when you're asking for an input request is is basically saying I need input to continue on with this tool request. So then the client would respond with whatever input. So I I I showed that earlier in the chat GPT interaction with elicitation. And so now in this new world, elicitation along with sampling and roots. If you don't know what sampling and roots are, that's fine. You don't need to know. They're all deprecated now.

33:16 >> Yeah. >> Oh, a few one. nobody was nobody was using those those patterns or they just like didn't get good adoption or the way that they were done just like didn't make sense. So they kind of smooshed it all into this way that a tool call now can basically just ask for input and in a in a deterministic way. And so the with elicitation it would the connection would essentially stay open.

33:47 So when when I showed that in in the chat GBT the connection was staying open with the the server. So it was basically asking for input and just waiting rather than asking for input and then >> or then returning the the response. And so this allows also an a push towards like scalability stateless statelessness. And so all of this is kind of towards the vision of like MCP needs to support like millions and millions of requests like supporting the the enterprise story and the adoption of it.

34:32 Subscriptions are a new thing. Subscriptions and listen here in the right hand column. Basically, what's really cool about MCP servers is that they can dynamically add or remove things like add or remove a tool or even update it. A better a better the clearer example is probably updating a resource, right? So, there could be a simp simply a resource could be a text file on the server that the MCP server exposes. Maybe that has some data in it that gets updated through different tool calls. How does a client know it's been updated? because maybe it needs to have the latest data and fetch the latest data. In previous versions of MCP, you'd have to basically keep pulling the server. That's just like knocking on the door and being like, "Hey, any updates yet? Any updates yet?

35:18 Any update?" Like, it's crazy inefficient doing short pulling like that. And so with subscriptions, the client can subscribe to events and then if something changes on the server that the server thinks the clients might need to know about, it can raise an event. And then the client, this event, by the way, doesn't contain any payload really. It's just an indication to the client that it says, "Hey, there's something new available. Here's what's new. Fetch it if you want to. Don't fetch it if you don't want to." It allows the client to always be up to date in in an efficient manner.

35:49 >> Yeah. And another change was to logging. And so before it logging was set on the the server itself, now it's moved towards per request logging. And so again with the the vision of each request is kind of self-contained, contains everything it needs to you can switch between different servers through a load balancer, things like that if you're horizontally scaling. And yeah, not much else to say about that. I think that one's that one's pretty self-explanatory.

36:25 >> Daniel, I realize so if you can't tell watching, Daniel's taking the left column here. I'm taking the right column. Daniel, you made this slide. Feel like you've done me dirty here, mate, because there's like three things in your side. I mean, on my side, there's one, two, and you just put three things in the last one, which is schema, cache, and and OR. I can I can touch on each one on quickly. so schema is really simple.

36:49 it's just the MCP tool schemas now support the full JSON 2020 schema. The main thing I think people care about there is the ability to use ref which is kind of like having a variable in JSON. So that's kind of cool. the regarding caching list and resource responses now include a TTL in cache scope. So this lets the server tell clients how long they can reuse a certain response before it becomes stale and out of date and they should fetch a new copy. There's some really interesting parallels here with MCP and HTTP, right? It's becoming stateless. It's adding caching headers effectively. that that's interesting I think. And then regarding authentication, this is something that MCP is always iterating and improving upon. There's been a few more updates to OR as well to standardize things and offer a bit more control also.

37:43 >> Yeah. And and I will say if you want to do me dirty, you got to make the slides next time. >> Fair enough. That's Can't can't can't complain, can I? >> No, we just like to tease each other, dude. Daniel, >> we're not enemies. >> Yeah. >> Yeah. >> >> should we take some quick questions, Daniel? Let's >> Oh, yeah. Let's do it up in the chat. >> yeah, sessions do kind of suck for scalability.

38:16 That's a good point. NASA Mike says they'd like to have an MCP server that exposes the master servers rest API so you can equip a master agent with it and have it manage workflows and other agents. >> Yeah, that that that's totally possible. So I think the idea here is that you would because an MCP server doesn't expose a REST API as such. It would expose tools that maybe call that REST API. I guess you're talking here about having two separate master agents because you wouldn't want to use MCP when it's the agent calling its own tools or its own resources for example.

39:05 how do you define the MCP API in RS? you would create an open API spec. When I said swagger earlier, I meant open API. Thank you. was it called an MCP? And can you show the spec for your demo? I believe the the benefit of using and Daniel is the person who implemented this. You will tell me if I'm right or wrong, but the really cool thing about using Master to build your MCP server is that as you add tools, resources, and so on to your configuration, we handle updating that endpoint that the client can call and use on on your behalf.

39:35 we haven't updated it to use the latest specification as of yet, but I do believe that we take care of the what what you could call the sort of table of contents or index for the MCP server. >> Yeah. And and every every MCP server as per the spec has a discovery endpoint that gives you all the information and that's how the like the client would know how to interact. Like I can I can pull up the the >> So we do support the discovery endpoint.

40:08 >> Yeah. So if you look at here >> Yeah, cuz that reminds me actually. I think it's been a thing for a while in MCP, but in the new spec it's become mandatory. >> You plug in Oh, I don't know how I saw this. I was looking at this before and it showed me all of the schema stuff, but I don't know where that is in this UI. yeah, maybe maybe I can't show it. I thought it was here. but essentially, yeah, there's an endpoint that will give you like all of the the schema for everything, what's available in this MCP server, things like that.

40:46 Okay, >> cool. We'll keep an eye out for some more questions, but back to you, Daniel. Yeah. And I we talked about this this earlier as well when we were talking about the spec moving towards removing sessions entirely. And so essentially that this is just reiterating that just having having multiple requests needing to go to the same server because it's in the same session whereas now each request is is independent. and so yeah, any replica, easier to restart, no session cleanups, easier to horizontally scale.

41:38 yeah. And what like why why now? Why why are we doing this this workshop? And so yeah, it was it was triggered by a new spec coming out. And every time there's there's something like a new spec or something new in the AI world, we're going to be there. We're we're going to be one of the first ones there. And so, yeah, the the spec is maturing. It it's at a place where yeah, we showed like enterprise adoption is grow grown like crazy. usage is growing like crazy. And it's just the a good time to to to make sure that your your MCP story is solid if you want people interacting with your product through through an agent >> and just some some best practices.

42:29 >> Daniel, sorry to interrupt. >> Yeah. >> Can I suggest that we look at some of the code behind the server first and then sort of close on best practices? There's quite a few good questions here that I think we'll answer through looking at the code essentially. >> Let's do it. >> Yeah, that that's the last slide anyway. So, you could probably even just scrap it. All right. >> I'm going to learn some best practices. >> Okay. I know what you're going to tell me. I'll bump it up. Don't worry.

42:58 >> It's not your first radio, huh? >> Yeah. >> Half my job on these workshops is to make the bigger. >> yeah. So, actually maybe I'll show the the studio first. And so, >> I will say, mate, that since sharing your screen, your video, it's been great all stream, but it just degraded. So, maybe turn your camera off while you screen share, and I'll just full screen you. >> Is that it? >> Take it away. >> Yep.

43:28 >> Sweet. >> Video video can't lag if it's not on. so all the interactions that I made in in in this chat here we have the nice thing about having your MCP server in MRA 2 is that we have all these other bells and whistles that we we've built around. So something like observability you can get out of the box. So I can see and I can look into each of these tools and get some some better better ideas as to as to what's going on here. So okay, that that took I don't know 7 milliseconds, something like that. And yeah, I can look through a bunch of different things here.

44:11 What I also get is is metrics. there isn't too much going on here because I haven't made a whole lot of calls, but essentially you get like an idea of okay, how how fast are your tools running? Like how how performant is your MCP server? And if you build in other things like if you have tools call workflows or agents you you'll see other information pop get populated here as well. And so there there's a lot that you get by building the MCP server in Maestra even if you don't build with like agents.

44:52 So if you look at this tool here no wrong tool. Which one is it? This one here. This tool is calling a workflow internally. So it's using our workflow primitive. And something that is is nice with that is that you can use things durable workflows. So let's say you have an MCP server that kicks off a workflow, it fails in the middle, you'll be able to resume it, things like that.

45:24 And so there's there's quite a lot of power underneath the hood and a lot of flexibility in building these tools that you can give your your MCP server. Can we look at Yeah. >> your own MCP server? >> Yeah. >> And so this is the >> By the way, NASA asked if there's a plan to support Python for Mastra. Mastra, we've built our brand on being like the TypeScript framework. We're really double down on Typescript to be honest.

45:58 >> Exactly. Yeah. so I have my my master instance here. I've I've set up observability. I've passed it this MCP server. Let me just look into it. And so this MCP server, the definition is just here. So I have some some resources, some resource templates, and a way to to fetch the resource information. And so this is just like getting information about about policies around returns. And then there's also a a list of prompts. We we kind of touched upon that briefly, but essentially a way that you can give you can give prompt hints to to the client. So you'd be able to to give them suggestions as to, hey, this is the type of prompt that you should ask.

46:58 yeah, and then kind of also mentioned cache hint cache hints as well. And I have all my tools here. Let's go check out a couple of the tools. I think this process return was the one. Yeah. So, this is this process return is the one that is using a workflow internally. So there there's quite a lot of you can essentially do anything from within these tools. And so you could use any of the existing master primitives in there as well. So even if it's just like hey I only need an MCP server. I don't need to build agents. There's a lot more that you can get out of the box to to help you to to build your interactions in here. And the the code itself not particularly interesting.

47:57 the the anatomy of a tool. You just pass an ID description. you'll need an input schema and optionally you can also have an output schema as well here. So just making sure that there's a like a structured output as well. And another thing that I've added in here that I touched on is OOTH. So we have these helpers to create to create OOTH interaction. So just using that as well for for the MCP server.

48:38 I don't know if we have have any more questions or >> how does the human in the loop stuff work with elicitation? >> Oh yes, >> good question. >> Forgot forgot about that. Let's >> or yakub perhaps. >> And so in in the old spec this is this is how it works. You would send you would get elicitation from the context in the tool. So this context object here it it holds different MCP specific properties in here. So if I like look at context.mcp it's not auto completing.

49:23 Oh there we go. Oh it's just working very slow. but yeah, we we have a bunch of different MCP stuff and one of the the thing is elicitation. So essentially you would just send a message and a schema telling them how to respond. And so in the in the new world instead of this you would just return a response with a you would return like a like a input.

49:54 I think it was like input required or something like that. It would be like type and then you'd pass like the schema as well to so they know how to respond. And so yeah, there's not there's not anything anything crazy going on here. So when they respond with the the elicitation response, you would return here. And so this is also what I mean by right now this with the older spec elicitation it it just awaits. So it holds the request open until the client responds.

50:38 So as you can you can see already that that that's pretty problematic. but in the in the new world it would just like return input required response and it would be something like that. And so the tool doesn't need a wait and then it would just accept when you when you send like a follow-up response essentially. >> Quick question from NASA. Is human in the loop normally used for mutation actions only or only for approving tool calls?

51:16 >> Yeah. So so human in the loop doesn't necessarily have to only mean approval. human in the loop can be stuff like you're asking ju just think about like any interaction that you're you're you're doing with any any agent and then it asks you hey I don't actually have all the information that I need can you give me like like you're you're filling out a form it's like oh actually I need your email too like that that's a form of human in the loop as well like getting more information so it's not just like a a confirmation like yes or no like tool call approval but it can just be like getting getting any information. And so it it doesn't necessarily have to be mutation act actions cuz human like if you think about like using any any coding agent like they'll they'll ask for access if it go outside of like the the repository or the folder that you've let them look in. It's like yeah even just like nonmutating actions can be dangerous too like looking at like secrets or API keys >> and what is your opinion on leaving what is your opinion on on having human in the loop pre-baked into the MCP tools versus having the having those governance gates in the prompt for example in agent scale >> I think they they serve different purposes. It because you might not want to rely on the agent to do those types of things.

52:58 because one, you don't control you you like we talked about before, you might not control the agent that somebody's using to interact with your product. And so it's like you want your product or your MCP tools to be able to handle that themselves. and then also yeah like agents are unreliable. They might not use the skills and so if it's something that you do want human in the loop there for sure then you should build definitely build it into the tools themselves.

53:34 >> Yeah hard agree. You don't want to use prompts for things that you really rely on because models are unpredictable. They're also v susceptible to prompt injection. >> Yeah. We got any other questions here? I haven't been really monitoring the chat. >> There's a couple. Was there anything else you wanted to to show or should we go back to the slides? I feel we could turn our video back on then as well. >> Yeah, that that's kind of what I was thinking. and if you want to check out any of the the the slides or the code, all of it's pushed to a public repository in our MRA organization.

54:20 I'll find a link in a second. but it's essentially all of our workshops get posted in the same repository. Anybody who registered on Limo will receive a link after this workshop via your email. >> Okay. All right. I'm back. >> Hey, welcome back. Cool. Let's talk about some best practices to close things out. >> yeah, and so all of this stuff isn't necessarily groundbreaking. Like if you've if you've been here for the last hour or you've built with MCP before, you're likely already kind of doing these things. always good practice to to reuse business logic that your your tools shouldn't necessarily have too much business logic. likely it already exists somewhere in your system.

55:17 and so you should just like reuse that. write tools that fit your workflows. I used to be a lot more opinionated on on writing tools when when it was kind of more the story around okay you always have to write like super lean tools have very very few tools but now there's so many different creative ways that people are are like building around this that like it's hard to dictate exactly what you should do to build your tools.

55:57 so even just something like I mentioned before like having a a search and execute tool, it's like yeah, now now your tools can scale quite a lot more and like models are a lot smarter, they're a lot more powerful, they're cheaper than they were before. And so they're just able to handle a lot more tools better than they used to. And so it it's kind of hard to have these hard and fast rules around like how you should build your tools. just you want to just make sure like yeah like test testing in in like the actual client like making sure that it's actually working as intended. yeah, authentication, authorization, like we we talked about OOTH, very important.

56:41 another thing, I can't remember if I mentioned this, but make rights safe to retry. essentially, you want to be able to run, like we talked, agents are unpredictable. They might accidentally do a destructive command twice in a row. You want to make sure that that doesn't like mess with your database or your system at all. You want to make sure that if you run the same command or the the same tool with the same mutation, it's not going to do something that you don't want it to do.

57:19 And then yeah, te make sure to always test your your MCP servers depending on who who your users are like if they're like chat GPT cloud users or any kind of other custom harnesses. make sure to to check with different models interacting with the MCP server because I know back in the day you would try there was a lot of MCP servers that like the schema wouldn't be compatible with a like an open AI client because like the like not every not every agent client is built the same way and so you just have to be aware that your MCP server works in multiple different environments. because you don't necessarily know how people are going to use it, so you want to cover your ass essentially.

58:15 >> Daniel, thank you so much and thank you everybody for tuning in. That's the top of the hour and all the time we have today. If you registered on Luma, you'll receive a link to the recording, the slides, as well as the code. If you have questions about MCP that we just didn't answer because we didn't get around to it, you can always find us on Discord or DM myself at Booker Codes or Mastra at Mastrox and we'll try our best to help you. Until next time, >> I realize I forgot a final slide to show like Twitter information and Discord stuff, but I'm sure all of you are savvy enough that you know how to use Google.

58:54 >> Sure, you can find us if you're motivated. And next week we're going to be talking. There was a couple of requests earlier. I didn't want to interrupt your nice flow, Daniel, but people were asking about a masteractory workshop. And indeed, next week I'll be live with the team talking about masteractory now that it's out in the real world. So see you next Thursday at the same time to talk more about that. >> I'm excited to see that one, too.

59:20 >> Hell yeah. >> This has been fun. Thank you. Cheia.