Understanding MCP’s Architecture

This lesson preview is part of the MCP in Practice: The Future of AI Agents course and can be unlocked immediately with a \newline Pro subscription or a single-time purchase. Already have access to this course? Log in here.

This video is available to students only
Unlock This Course

Get unlimited access to MCP in Practice: The Future of AI Agents, plus 70+ \newline books, guides and courses with the \newline Pro subscription.

Thumbnail for the \newline course MCP in Practice: The Future of AI Agents
  • [00:00 - 00:10] And right now it's time to get into some architecture. Nothing to be scared of, step by step, we'll learn about everything, then about server, and about the architecture.

    [00:11 - 00:17] It consists from these three main parts. And the third part can be excluded, if needed.

    [00:18 - 00:23] First of all, it's host with the MCP client. Just in short, I would play in the difference and whether so many boards in it.

    [00:24 - 00:27] But let's call it for now the client, right? Or the application side.

    [00:28 - 00:33] It can be once again cloud, some ID, or some other companies and tools. And then we have MCP server.

    [00:34 - 00:44] They're all once again connected, why MCP protocol? And they both need to be like support the MCP itself, the protocol itself.

    [00:45 - 00:56] And then as the third part, we have some local storage, remote storage, so whatever data you're working with, whatever it is located so we can grab and do something with it. So what is happening?

    [00:57 - 01:07] We are giving some instruction on the client side for the LLM and we tell, I need to know what the weather is, right? We are actually talking to the host.

    [01:08 - 01:24] A host is responsible for the actually talking to the LLM and basically anything LLM related. Then host tells like clients, no worries, we'll go over more detail just on the next slide, but just for now, just general overview.

    [01:25 - 01:43] Host tells the MCP client actually to check what servers are available and what actually it can pick for the task. And then client gives the response and we are then connecting to the, for example, server B, server B is responsible for weather or whatever.

    [01:44 - 02:09] And then we are sending whatever we have the query to the server in some specific structured way. Server on its side makes the API goals underneath the hood and then it actually goes and fetch some data or a, it might not even fetch some data, but it can just perform some calculations and corporations.

    [02:10 - 02:18] That's why I mentioned that the storage is not usually not necessarily included, sorry. - It's not published.

    [02:19 - 02:36] - So it can go fetch data and could calculate something on the server side, then the results are being sent via MCP protocol back to the client side and we get actually the response of it. One question you might have by now.

    [02:37 - 02:47] Okay, so we still use the API in the next hood and this is correct because we are not exactly like by magic throwing away all the API connections, right? And it just works, right?

    [02:48 - 02:59] MCP server, basically this side. It encapsulates all the different logic that we are writing to connect to the different services inside of itself.

    [03:00 - 03:13] So it's like a group with beautiful wrapper, right? We can change the code the way we want inside of the MCP server, but it would still be easily connected to whatever we want and whenever, and we can easily share it with whoever we want.

    [03:14 - 03:33] It just wants to get a wrapper which gives us super easy way and flexible way to apply this server to whenever if we want, but the, it would still is wrong, but the API goals actually in place. It just the logic a little bit is nested and it just underneath the hood doing a job.

    [03:34 - 03:37] So a bit is there, they are not gone. We are still using that.

    [03:38 - 03:50] Then I believe we can talk a little bit more about the host client and the server a little bit in more details. First thing that I want to address is about actually figuring out what's the difference between MCP host and CPC client.

    [03:51 - 03:59] This is actually really interesting solution and really right solution of the anthropic to actually separate the logic. One logic is working with the LLM.

    [04:00 - 04:12] Actually, it's processing the data we are interacting with it. And another logic is responsible for actually sending the request, getting the request, and basically keeping the connection with the server, right?

    [04:13 - 04:23] So as I mentioned before, you can see about the MCP host as the your AI application that you're using for choice. And when you write something, you actually write to the MCP host.

    [04:24 - 04:35] And MCP host on the other hand, it actually includes multiple MCP clients inside. And not exactly includes, it can spawn multiple MCP clients inside.

    [04:36 - 04:50] Why exactly spawn because the client is responsible one to one connection to our MCP server. So if we have hundreds MCP servers, we would have 100 MCP clients, which would be basically managing the connection to it.

    [04:51 - 05:07] And it's responsible, you can see a transport player. Once again, just you can think of it as the highway, for example, but specifically for the MCP, which this protocol uses to securely and quickly to transfer data back and forth.

    [05:08 - 05:21] That's basically the platform for transferring and transfer to the data. And MCP client is responsible to understand this like connection and to be connected to the server and to have constant communication with it.

    [05:22 - 05:24] Okay. So that's why we have the MCP host as the wrapper.

    [05:25 - 05:38] And then we have the MCP clients as specifically entity for managing the data transfer and communication. And then on the MCP server side, what's magical things are happening, all right?

    [05:39 - 05:51] At the beginning, I have mentioned that the MCP clients or our host in this case, let's name it already correctly. It's always knowledgeable about what servers we have at hand, right?

    [05:52 - 05:55] And how does it do it? Does it analyze code or something like that?

    [05:56 - 06:08] It's much more simple. On the MCP server side, we're actually providing, among other stuff, name and the description for our multiple tools or features inside of this server.

    [06:09 - 06:17] So whatever we are connecting to the client side, actually host knows about those features. It's actually just like a wall of text, right?

    [06:18 - 06:34] We're just sending all this description to the LLM and then LLM can decide since LLM already powerful enough, they can decide what exactly they need for the job, all right? And then it just automatically able to connect to it, just understanding where coming from, right?

    [06:35 - 06:46] Where it's to each server, it belongs. So it's really in one way, simple, but really elegant way of solving this dynamic issue, just providing VR creators and developers.

    [06:47 - 06:55] We are providing actually information about the server on the server side. And this way, what would always basically know about whatever we are doing there.

    [06:56 - 07:15] This is like the old general information, for now we will go deeper, no worries. But also I want to address that inside of the webinar and general in your developing career, you would be most likely working with these servers because client sites, most likely you will be using like big established applications.

    [07:16 - 07:27] So you don't need to build one from the scratch, right? So that's where VR would be specifically focusing on developing this server, which you can connect and use with whatever client of your choice.

    [07:28 - 07:37] Since once again, it's much more easier to pick some big established guys, right? And then server will perform the task that you want and will send to the client of your choice.

    [07:38 - 07:43] So that's why we are specifically going to cover right now server in more details from now on.