Why MCP Makes AI Tool Use More Flexible (Full Transcript)

[00:00:00] Speaker 1: Is MCP worth the hype? I'm so glad you asked. Welcome back to Slack School. My name is Mike Reynolds. I'm your host. I'm part of the Slack team here at Salesforce. And today I'm really excited because we get to do a little bit of thought leadership at Slack School. We are going to talk about if MCP is actually worth all the hype. I'll cut to the chase and say, yeah, it is. But let's dig into why. So what we're going to do is we're going to learn exactly what MCP is, why it matters, and then we're going to see it in action. Let's get after it. Because we're going to be going over a bunch of different ideas, I'm actually going to show you some slides. But don't worry, I'll get to a real demo in a minute. So the question is, is MCP worth the hype? Well, in order to really understand that, we've got to know what an API is first, because MCP uses APIs. It's not all new. So what exactly is an API? Well, I know this is a silly example, but an API is a lot like going to a restaurant. You've got to get to the restaurant. After you get there, you got to sit down. After you sit down, you got to look at a menu. And after you look at the menu, you can place an order and the waiter will take your order and they'll take it back to the kitchen. And then in the kitchen, they're going to make your food. And after they make your food, they can give it back to the waiter who can then take the food back to you. And then, oh, yeah, that can happen, those errors. But hopefully, we actually get our order. And this process is essentially how an API works. Each of these steps corresponds with part of what an API is and what an API does. So don't get too caught up in the details. Know that this kind of process of ordering at a restaurant is very similar to how an API works. The only real distinction I'll tell you is don't refer to the waiter as a server. Because in our example, the word server needs to mean something very specific. That's the computer that is serving the client. In our case, that's the kitchen. So what exactly is MCP? Well, MCP stands for Model Context Protocol. We're familiar with other protocols. These are just sets of rules like HTTP. That's Hypertext Transfer Protocol, right? That's at the beginning of all of our URLs. So HTTP is the set of rules that allow computers to talk to each other over the internet. And MCP is the set of rules that allow large language models to work with APIs. And essentially, large language model capable servers. So how does MCP really work? Well, you still arrive at the restaurant, but you don't get seated. You just make your way straight back to the kitchen. And then you're going to say, hey, what all you got back here? You're going to find out about all the kitchen appliances that they have, what they can cook, the available ingredients that they have, the skills that they have. You're going to find out everything. And then based on that information, you'll actually order what you want. The server still prepares it, but you can be way more specific about what you want. So in a really simple example, if what you really needed were two individual slices of pepperoni and you went to a pizza place to get these, if you're using an API, you have to order a pepperoni pizza, even though what you want is just the two slices of pepperoni. But if you are a large language model and you're using an MCP connection, well, then you can actually just go into the kitchen and get two individual slices of pepperoni. Way more efficient. So this is going to happen with three big parts. The first is OAuth. And it's good OAuth that's got Pixie. That's a really great way of helping to keep us safe. Can read up on that on the internet. The next thing that MCP has is this idea of tools list. Tools list is the first real step once an MCP server connection exists. The agent says, hey, tell me about all of the tools that you have. And then in real time, the server responds with here's all of the tools that we have. The agent can then choose to use any of those tools, however the agent needs to. So when we compare the way that an API and the way that MCP connections work, they're similar. They have some similarities. But they really, really, really function differently. And it is worth the hype. If you're using an API, you've got to constantly maintain everything. And if you're using MCP, you can build a new tool and then deploy it and it's live for everybody immediately. You don't have to train on anything. If you have to take a tool away, you can take a tool away. Nothing's going to break when you do that. Because each agent that approaches your MCP server is going to get their information right then and there. When you say, give me the list of tools, you're going to get the current list of tools. And it's the list of tools that the authenticated user has access to. So we still have all of the controls that we need, but it's incredibly flexible, very, very dynamic. That's really pretty cool. Now, I do want to be really specific about this use of server and client. Remember, we have the capabilities of doing both, but we want to be clear with our language. So Salesforce and Slack can be MCP servers for you. You can have an agent reach into Slack or reach into Salesforce, and then we can give you a set of tools as a result. Slack and Salesforce can also be MCP clients. That means we're leaving, right? We're going into somebody else's kitchen. So Slack bot can do this and agent force can do this. So what does it look like if we put all of this together? Well, I've shown you Slack code in another episode. You can go check that out here, but let's look underneath the hood of what makes Slack code work. I told you when I explained all of that in the other episode that the agent is able to call on these tools to create a channel or add a code diff or add an HTML preview. It just decides that it wants to do these things. So let's look at the actual code and see where this happens. When you create an agent, you get a bunch of things right out of the box. But one of the most important is this system prompt. The system prompt is a huge, huge section of who your agent really is. And you can see this is where I've got the basic information about my agent, the Jolly Roger. He's a coding agent that can do a bunch of different things. I want you to be cheerful and make sure that I can still understand you, even though I do want you to have the personality of a pirate. Of course, there's all sorts of different things that I put in here. Like, hey, I want you to know all programming languages, right? Remember, it's important to have agents that have a different perspective. So I might want you to be the best security specialist that the world has ever seen or the best admin that the world has ever known. Those are really good agents to create. That's why you'd want to have an assembly of agents all working together on something. But what gives the agent actual capabilities? What are the agent's tools? Well, if you scroll farther down in this, eventually you're going to get to a section that shows you the different tools. Now, I've collapsed these sections because the actual code is not super important. If you have any questions about the code, ask your local Slack bot. They'll answer all your questions. But here you can see I've actually got a tool for creating a code channel. I've got another tool for setting the code diff or the code view or going out into GitHub and reading. Each of these is a specific tool that the agent, Jolly, can call on when they think they need to. I'm using the word think here really loosely. It's an LLM. It's not thinking. But it's nice to kind of have this idea in your head. What the agent is literally doing is deciding that it needs to use a tool. And so it uses that third and final step of tools call. The server then says, hey, here's the actual capabilities that I have. Here's the list of tools you can use. And then the agent is able to call on those tools as often as it needs. In fact, it can call on multiple tools at the same time as long as the agent has that capability. Slack bot can do I think when Slack bot first came out, Slack bot could use five tools. And I think now it's ten tools concurrently. Each of the tools that my agent can use is listed here. And if I don't list them here, even if I've got the code, it won't work. So let's take a look at this in action again. What I can do is at mention my agent. I just say, hey, at Jolly. And then we can ask Jolly to kind of write anything. In this case, I want to ask Jolly to write a trigger. This should not result in an HTML preview because there's nothing to show. So Jolly should be able to grab a GitHub or create a GitHub branch and then create a pull request and write the actual trigger. But I shouldn't get a preview. Jolly should know the difference between code that requires a preview and code that doesn't. So let's test it out. This is a pretty simple coding task that really any developer learning Salesforce coding, this is a great example, good way to learn and start. I've asked Jolly to create a trigger that will count the number of open cases and then update the account. We got to think this through. We want this trigger to be on the case. Oh, I did say that. I said, create a trigger on the case. So I took a little bit of the fun away. But Jolly's got to figure out I'm creating a trigger on the case and then I need to update the account. Well, I don't want that trigger. You know, I don't want to update the account every single time. I only want to update it under certain circumstances. So we can actually check in the code diff and see if the logic behind when this code's going to be executed in the trigger is done properly. So it's given me this little package emoji. It's giving me a little bit of a preview that it's thinking. I'm going to go ahead and open my code channel. I can see I've got an emoji here. I know that I've got a link to my, you know, the context that this came from, where the original message was posted. And let's see what Jolly comes up with. All right. Let's take a look. Jolly's done thinking. So I can see I have an artifacts tab. So it's created some code. I can also see that that's linked here. And I've got a nice message explaining exactly what it did. It looks like we've got a trigger. We've got a helper, which is good. I didn't say I wanted it to follow good coding standards, but it did. We've also got a test, which is nice. And I think this naming convention is acceptable. I didn't specify one. So that's pretty reasonable. And then it's also calling out, you've got to create this custom field. I didn't give it that field. So it set it. I will say it would be nice if it created that field and then included it in the metadata, because, you know, this test will not run successfully if the field doesn't exist. But that's pretty reasonable. It's also using is closed equals false. That's great. If you're a Salesforce dev, you know, on the case object, we get that out of the box field. And we've got a pull request, which is nice. Let's take a look at the actual code diff kind of in a larger view and see what we've got here. So this is good. This is what I was looking for. Would it be able to do this? And of course here it has. So why is this working? Well, well, this agent is using Claude, tag Claude. So Jolly is a tag Claude wrapper. So it's using a Claude agent right here in Slack. I've just kind of made it. Well, there you have it. Is MCP worth the hype? Yeah. Yeah. It's incredible how sophisticated we can be if we add in this reasoning engine, this idea that we can consider what actually needs to happen and then use tools dynamically. It's way better from a maintenance perspective as well. I cannot overstate this enough. The fact that I can create a new tool, push that tool to production, and then not rebuild any endpoints, not adjust any APIs, really not do anything else. I don't have to redeploy anything outside either or train anyone or any agents how to use the new tool. I simply create the tool, expose it, and I'm done. That's super cool. It's genuinely really cool. So is it worth the hype? Absolutely. Let us know what you thought of the episode by jumping into the Slack community at slack community.com. Join me in the Slack school channel and let me know what you want to see next. Don't forget to like, and subscribe. We'll see you next time. Oh, hey. Hope you have a good day. And made it a pirate. Yarr.