What is MCP? Model Context Protocol Explained

Key Takeaways

If you believe that AI agents are going to be the next big thing and you want to learn how to build them and use them effectively, then you also really need to know about MCP. MCP stands for model context protocol and it is a new open standard that enables AI agents and LLMs to interact with the world. For example, this will allow it to do things like browse the web, update a spreadsheet, or create an event in your calendar. This idea was introduced by Anthropic in late 2024 and it is an important progression in how we think about APIs. This is because it brings us one step closer to building fully autonomous AI agents that can do almost anything that a human can do on a computer and not only think outside the box, but act outside it as well. In this video, I'm going to walk you through everything you need to know about MCPS to get started. It doesn't matter what text stacker language you use. This content is for everyone. We're going to start with the problem that MCP solves so that we can understand why it even exists. Then we'll take a closer look at how it works on a technical level. And it's actually a lot simpler than you might think. Finally, we'll finish off with a concrete practical example so that you can get an idea of what you can do with it today. Let's get started. So, what is the problem? Well, before MCP came along, connecting AI agents to any kind of external tool was still possible, but took a lot of extra effort. Concepts like tool use or function calling existed, and this did allow you to connect an LLM to an external service. But you'd have to implement the integration and call the REST API yourself. The burden of implementation was usually on the ones building the AI agent. And to make things worse, each platform had its own way of calling external functions and each service had its own API format. So if you were building an AI agent that can access YouTube and Discord, for example, then you'd probably be spending a lot of time creating custom adapters for each of those services before you could even get started with any agent logic. This problem grows very quickly as well. For example, if you had three different AI platforms you wanted to use and three different services, you'd be looking at nine separate integrations. So, you end up writing a lot of custom code for every single API and for each LLM provider. And that code needs to be maintained, updated, and debugged separately for each integration. MCP helps to standardize this integration and also kind of shifts the burden away from the builder to the service and the platform owners instead. Instead of every AI application having to understand every API format, MCP creates a universal translation layer for all AI platforms and services to sort of meet in the middle. Now you can write one MCP server once per external service and it works with every other MCP compatible AI application. In this example, we can go from nine separate integrations down to just three and it scales much better. It's language agnostic and it lets you focus your time on actually building the agent. Naturally, this means that there's two main ways you can work with MCP. One way is that you are a service developer and you are building an MCP server for your service. This will open your service up for yourself and for other developers to build AI agents with, which is probably good for your business. The other side of it is you just want to use existing MCP servers. In this case, you're either a client or a user. And that could be via a chat interface, an IDE like cursor, or programmatically if you are wanting to build your own AI agent from scratch. In this case, there are hundreds of existing MCP servers you can choose from for all kinds of things. For example, there's integrations for Google Docs, GitHub, AWS, web crawling, and even finance platforms. Basically, anything that has a REST API can have an MCP server. And this will let you build very powerful agents very quickly. And when you find an MCP server that you want to use, it only takes a couple of minutes to set it up and plug it into your system. So to sum it up, MCP's value isn't that it allows you to do something that you couldn't do before. You could already do all of this stuff with traditional REST APIs. The breakthrough here is that it lets you do it much faster, reducing the time it takes from hours or even days down to just minutes. Now, let's take a quick look at how MCP works under the hood. It's actually quite simple. The way I think of it is that it's just an implementation of tool use or function calling or whatever you want to call it that has been universally standardized. The official MCP documentation describes the highle architecture in three parts. You have your external services, databases, uh whatever you have on the side with their existing APIs. Each of these would have an MCP server. These are lightweight programs that could be run locally or online over HTTP. They have methods that you can call to list what operations are available and when and how to use them. Then over on this side, you have the other component which is an MCP client. And these will talk to the servers and provides a way for your LMS to interact with them. The MCP protocol itself is the thing that connects them. It's basically just JSON. Meanwhile, the MCP server will still be talking to the external services using REST APIs or some other traditional interface. And the final component is the MCP host or the runtime of the agent. It is basically a running application that has state an event loop and it manages the whole interaction between a user an LLM model and the MCP client. And this runtime could be a chat app like cloud desktop, an IDE like cursor, or an AI agent that you build yourself running programmatically in the background. Now, if we take a closer look at a single MCP server itself, you'll find out that it basically takes uh the traditional REST API interface and it'll translate each operation into either a resource or a tool. Resources are basically readonly data like API get requests, databases, and files. Tools are just functions that can be called by the LOM. And all of these things are represented as a JSON schema with things like a name, a description, and hints about how to use it. For example, here this is the JSON schema for a tool. And because this is JSON, it is also language agnostic. There's an official SDK for practically every major programming language to help you automatically serialize your code into the schema. For example, here's a Python function to fetch the weather for a location. Using the MCP SDK for Python, all we have to do is put this MCP tool decorator at the top of the function and it will automatically translate this into an MCP compatible schema for us by using the function name, the parameter names, and the doc string. And here is what the output will look like. So, it doesn't matter what the function does or what language it is implemented in. and MCP server can understand it. It will be able to tell its MCP clients about all the tools available on the server and how to use each of them. So this should be pretty clear so far. But the next question naturally is how does any of this work together with the LLM? An LLM is just a model. Tokens go in, tokens come out. How does it actually use these MCP clients to execute code? Well, the answer is that it doesn't. That's actually the job of the MCP host or the runtime. There's an event loop that maintains these MCP clients and basically facilitates this whole interaction between the LLM and the clients with prompt engineering. So the JSON schema for the weather tool that you saw earlier simply gets flattened into a text prompt like this one and then fed into the LLM. The LLM response is then parsed back into JSON which is then used to execute the tool. And then the response of the tool is sent back to the LLM again as text. And this loop can just keep on going. Now this is all very good to know but in reality you probably don't need to worry about implementing any of this. Uh this is all done for you on AI platforms like claw desktop or cursor. And if you wanted to use it programmatically there's probably an existing library or framework that you can use. And if you're familiar with the concept of function calling or tool use in LLMs, then you're probably wondering what's the difference between that and MCP or even what's the difference between MCP and traditional REST APIs. Well, I would probably say to think of MCP not as something different, but more of a standardized natural extension of those things. Next, let's take a look at a real example of MCP in action. I'm going to use Claude Desktop as the MCP runtime here because it's just the easiest option to get started with. And there's going to be two separate tools that I'm going to connect to it via MCP. The first is going to be a Python function that helps me get the weather for a location. And this is just a test function. So, it's just going to return random results. Uh, but this code is running on my computer. So, I can write whatever I want and I can implement whatever I want here if I wanted to. The second tool is going to be this third-party integration I found online that lets me uh connect to Google Sheets. And I'm going to have it create and manage Sheets in this drive folder that I've created. To connect an MCP server to Claude Desktop, we need to edit a configuration file. And you can find it by going to Claude and then settings and then going to the developer tab and click edit config. And that will pop up with a file called cloud desktopconfig.json. Um, and this is the one you need to edit. And if you open up the file, this is what it will look like. It's just the JSON file where we define each MCP server we want to use and how to connect to it. And we can also add environment variables. And right now you have two general options for connecting an MCP server. It could be a program that you run locally on your machine, which is pretty common for testing, or a remote server that someone else is hosting for you, and you'll have to connect to it via an HTTP endpoint. Here's an example config for an MCP server that runs locally. Uh, when I start up my cloud desktop, it will actually run this command in a separate process to start up a local MCP server, uh, which is going to connect to my GitHub. And I don't have to go and start my server separately in another terminal window. This configuration will actually manage the life cycle of that MCP server for me. And most useful MCP servers will need some special permissions to be able to access things like files, data, or in this case a GitHub account. We can enable that by passing in things like authentication tokens or secret keys as environment variables to the MCP server. Now, let me show you an example of an agent that I put together. Back to my config file, let me show you all the pieces we have. So there's actually two different tools that we've connected, two different MCP servers. One is for talking to Google Sheets and the other one is for getting random weather status for a location. Um, and this one is actually using a binary. Well, it's not really a binary. It's Python, but you can think of it like a binary that someone else has developed. So this is a third party integration that someone else has built and I want to use it. Obviously, I have to give it my uh service account keys and my drive folder ID if I want to be able to manage my spreadsheets. The second one is code that I have on my own computer, which is why uh the command here points to running a Python file that is on this machine. So, this one will actually start the server and run it when claop the runtime or the host uh is running. Uh so, I don't have to start this separately. this this uh command will create and start these runtimes themselves. Now let's pop over to claw desktop and see how that looks. So if we open the search and tools function here, we'll see that our MCP servers are connected and we can see them down here. So here's crazy weather. There's only one function which is to get the weather. We can turn it on or off here. And if we go down, Google Sheets has a lot more operations available. So it can actually create sheets, add rows, add columns, and basically do anything that we could do with a normal API. Now with both of these enabled, let's actually try it out. Okay, so my command is get the weather for the top 10 travel destination cities and put them into a Google Sheets for me. And you can see here it has discovered the tool and it's actually using it. And you can see that it's synchronous, so it's going to wait until the tool finishes executing. Okay. And now it's done processing. Let's take a look. It's used our get weather tool 10 times because we did ask for 10 different cities. And it's also created the spreadsheet and updated the cells for us. And sure enough, if I go back to my drive folder, I see that it's created a new uh Google Sheets here. And I can open it and see that it's actually copied all of the data it's found from the weather API and put it into here. And this is a very basic example, but I hope it gives you an idea of how useful MCP servers are and how it can help you to build very powerful AI agents. All of this is just the tip of the iceberg. If you go to the official MCP GitHub page, you'll find that there's already hundreds of MCP server implementations that you can start using today to build something very cool. I recommend you going to this link so that you can explore them. Now, if you enjoy this video, then do subscribe to the channel because there's more fun stuff on the way. I also don't do any sponsors or affiliates of any kind because I want to keep these videos as useful and as short as possible. I hope you liked it and I'll see you in the next one.