What is MCP? MCP Explained Simply

[00:00] Let's say you are a backend engineer and [00:02] your team just got a new task to build [00:05] an AI powered customer support chatbot [00:08] for your e-commerce platform. Sounds [00:11] straightforward, right? But then you [00:13] look at what this chatbot actually needs [00:15] to do. A customer asks, "Where's my [00:18] order?" Your chatbot needs to query your [00:21] Postgrql database with 2 million orders [00:24] in it. The customer then asks, "Do you [00:27] have this in blue?" Now it needs to [00:30] search your elastic search product [00:32] catalog with 500,000 products. The [00:34] customer then asks, "I want a refund. [00:37] Now it needs to call your Stripe API to [00:39] process the refund and also hit your [00:42] Slack API to notify the finance team." [00:44] So you start building. You write custom [00:47] integration code to connect your AI [00:50] model. Let's say you're using Claude to [00:53] Possql. Then you write another [00:55] integration for Elastic Search. Then you [00:58] build an authentication and data [01:00] formatting layer for Stripe, then for [01:02] SLE. And then your manager says, "Hey, [01:06] for the simple quick response questions, [01:08] let's actually use GPT4. It's faster." [01:12] So now you need to do the same [01:13] integrations again, but for GPT4. [01:17] So you're looking at two AI models and [01:20] four data sources. So eight custom [01:23] integrations. And each one has different [01:26] authentication, different error formats, [01:28] different ways of handling rate limits. [01:30] Your codebase is already a mess. And two [01:34] months later, your company decides to [01:36] try Gemini. So now you're rewriting [01:39] everything again. And that's exactly the [01:42] problem that MCP solves. So very simply [01:45] put, MCP is a common communication [01:48] language between LLM powered [01:51] applications and all the tools that you [01:54] want to use. So it's used to connect [01:56] LLMs with various tools and data [01:59] sources. But wait a minute, we have [02:01] APIs. It's been industry standard, which [02:04] is a way machines and programs have been [02:07] communicating for years. They use APIs [02:10] to communicate and speak common language [02:12] using HTTP protocol. So why do we have [02:14] MCPs suddenly instead of APIs? Can't LM [02:18] just use APIs like other programs have [02:21] for years? So let's dive into that [02:23] question to understand why MCP concept [02:27] was even created and why we need it. But [02:30] first quick thing, we noticed that 80% [02:33] of people who watch our videos every [02:35] month are still not subscribed yet. Me [02:38] and our entire video editor team are [02:41] putting insane time and effort into each [02:43] and every video to make it as valuable [02:46] and high quality as possible for you. [02:49] So, if any of these videos have helped [02:51] you at all, giving it a like and [02:53] subscribing to the channel and becoming [02:56] officially part of our community is the [02:58] simplest way to support us and it would [03:01] mean the world to us. Seriously, thank [03:03] you and let's get into it. [03:08] So the problem with HTTP APIs is that [03:11] they were designed for humans writing [03:14] code not AI agents. So for example here [03:18] we have an HTTP call to get pod status [03:22] via Kubernetes REST API. And this is a [03:25] raw Kubernetes API response when you ask [03:28] for pod status. So it's hundreds of [03:30] fields of nested JSON and most of it is [03:34] irrelevant for the LLM. So for a human [03:36] this is fine because you just parse what [03:39] you need. But for an LLM this is a [03:41] nightmare. An LLM has to figure out [03:44] which fields actually matter and which [03:46] not and it will hallucinate or get [03:49] confused because most fields here are [03:52] actually irrelevant to answer the [03:54] question is the pod running. So LLM [03:57] first has to figure out which fields are [03:59] relevant for the question it is trying [04:01] to answer. So what MCP does in this case [04:04] is your MCP server for Kubernetes [04:08] prep-processes that response from an API [04:11] and returns something like pod my app is [04:15] running three out of three containers [04:17] ready no restarts uptime 2 hours clean [04:21] relevant only the information that LLM [04:24] needs no extra fields so basically MCP [04:27] sits before an API and translates the [04:30] API responses from API I speak to AI [04:34] speak and this is how a simplified LLM [04:37] friendly response of MCP server looks [04:41] like in comparison. So you can actually [04:43] think of it like a smart adapter between [04:46] LLMs and APIs to translate the human [04:50] friendly response to AI friendly [04:52] response. So now as you just saw clearly [04:56] and this is a very important point to [04:58] understand MCP is not a replacement for [05:01] APIs because your posgusql database [05:04] still has its API. Stripe has its rest [05:07] API kubernetes has its API. So what MCP [05:11] replaces is just the glue code that you [05:14] write to connect your AI model to those [05:17] APIs. So it's not a replacement. It just [05:19] sits between LLM and APIs. So [05:22] essentially you can think of MCP as a [05:24] wrapper around APIs which also means and [05:27] that is another important point to [05:29] understand that having MCP doesn't [05:32] magically expose more features than what [05:35] API actually allows. And this is a [05:38] perception of a lot of people that using [05:40] MCP somehow makes the tools behind it [05:44] magically powerful and flexible. But [05:47] essentially you are still limited to [05:48] what APIs allow because APIs are like [05:51] contracts. The API creator for example [05:54] developers of Stripe decide what Stripe [05:57] API will expose. So you're still limited [06:00] to what the tool itself provides. So if [06:02] poscsql API only lets you read tables, [06:06] MCP cannot write to them. It will also [06:08] be limited to just reading tables. So [06:10] that's just something to keep in mind to [06:13] be realistic about expectations of MCP. [06:15] Now, another very important advantage of [06:18] MCP is what's called a dynamic [06:20] discovery. So, with traditional APIs, [06:23] you read the documentation, you hardcode [06:26] the endpoints and write custom parsers. [06:29] If the API adds or changes an endpoint [06:32] that you want to use, you will have to [06:34] go back to your codebase, update it to [06:37] call that new or changed API and parse [06:40] the responses. With MCP, your AI [06:43] application that is using LMS can run a [06:46] tool lookup at startup and basically ask [06:49] the MCP server, hey, tell me what [06:52] actions or tools I have available to [06:55] use. So, we can run this tools/list at [06:58] startup and discover everything [07:00] dynamically. And that means if you add [07:03] another API or connect it to another API [07:06] with bunch of new functionalities, then [07:08] the AI application will simply ask the [07:10] MCP server, hey, do you have new tools [07:12] for me? Something some new stuff that I [07:14] can use. And it will know it immediately [07:16] without any changes in the code. And the [07:19] term tool in MCP is actually a technical [07:23] term that refers to a specific function [07:26] that is exposed by an MCP server that [07:29] the model can invoke or ask the MCP [07:33] server to invoke on its behalf. So for [07:35] example, you can have a tool called [07:37] query orders for possql or you can have [07:40] a tool called search products for [07:42] elastic search or a tool called create [07:44] refund for stripe notify slack for slack [07:47] and so on. So those are MCP tools which [07:50] is a function that model can choose to [07:53] call which is described in machine [07:55] readable form so that LLM can sit in the [07:59] tools list understand what parameters it [08:02] takes so every tool has a well- [08:03] definfined JSON input and output shape [08:06] so you know what parameters it takes and [08:08] what it returns as a response and LLM [08:11] can also decide when and how to invoke [08:14] that MCP tool and that can be huge [08:17] advantage when writing code because [08:18] instead of [snorts] hard- coding every [08:20] endpoint and then updating them when the [08:22] endpoint changes with MCP you don't even [08:24] need to know before what endpoints exist [08:28] with MCP approach the LLM can [08:31] essentially autodiscocover capabilities [08:33] at runtime so when you start the [08:35] application it will send a request hey [08:37] give me all the tools available and then [08:39] use them on demand so to give you an [08:42] easy analogy as a comparison think about [08:45] APIs like a restaurant with a printed [08:48] menu. You're going to read it to know [08:49] exactly what they serve. And if they add [08:52] a dish or remove a dish, they must [08:54] reprint or change the menu. Whereas MCP [08:57] is like a waiter who basically tells [09:00] you, "Today we have XY Z." And if the [09:03] chef adds a new special, the waiter [09:05] immediately knows about it and can just [09:07] update you on the go. Another very [09:09] important part is the stateful context. [09:12] Let me explain. Traditional HTTP APIs [09:15] are stateless, which means every request [09:18] is isolated. It doesn't connect and [09:21] share context with previous or following [09:24] requests. So if you want to chain three [09:26] API calls together, you are writing the [09:29] orchestration logic yourself, which [09:31] means you make the first call, you get a [09:33] response, you store the result of call [09:36] one in a variable, you pass it into call [09:39] two, and you do the same for the third [09:41] call, and so on. With MCP, the protocol [09:44] session is stateful. So basically, the [09:47] application that talks to the MCP server [09:49] can keep prior tool results in context [09:53] for the LLM because LLM will propose the [09:56] orchestration steps. So you can do [09:58] multi-step requests and then host will [10:01] execute those steps. Which means you [10:04] don't have to repeat or give the entire [10:07] context in every single request. You can [10:09] actually do follow-up requests instead. [10:12] Now, why is this amazing for LLMs and [10:15] LLM based applications? Because you have [10:18] natural conversation flow for a chatbot, [10:20] for example, like talking to a human. [10:22] You don't need to respppecify context [10:24] every time. LM can chain multiple tool [10:27] calls, which is also important. So, you [10:29] can carry context between requests to [10:32] different tools and so on. So for [10:34] example here the first request will be [10:36] check my app pod status in a Kubernetes [10:39] cluster. You get a response that pod is [10:42] running but one of three containers is [10:45] not ready. So LM decides should I [10:47] restart the pod and instead of saying [10:49] restart the pod my app in this name [10:52] space in a Kubernetes cluster you [10:54] literally just say yes restart it and it [10:57] knows what it refers to. It knows what [10:59] this follow-up request actually needs to [11:02] do exactly from the previous call. Now [11:05] there is another big advantage with MCPS [11:07] around security and access control. What [11:10] do I mean by that? With HTTP APIs, you [11:13] actually have a big problem. If you're [11:15] using 10 different APIs of 10 different [11:18] tools, you're going to need to manage 10 [11:20] different API keys in your code because [11:22] you need to give your application access [11:25] to the API keys in order to authenticate [11:28] to those endpoints, right? And if you [11:30] were connecting your LLMs to the APIs [11:32] directly, you would actually need to [11:34] give LLMs API keys to call those API [11:38] endpoints which would be a security [11:40] nightmare. Imagine giving your LLMs who [11:43] sometimes are unpredictable API keys to [11:46] all the tools that you want to connect [11:48] to. And especially for enterprises and [11:50] companies with lot of security [11:52] requirements, a lot of compliance [11:54] requirements, this is a huge one. So [11:56] with MCPS the big advantage is that the [12:00] secrets like API keys, connection [12:02] strings, tokens and so on they live [12:04] inside the MCP server itself. So LLM [12:08] never sees them. The LM proposes call [12:10] this tool or invokes a function and then [12:14] MCP server then uses its own credentials [12:17] to call the underlying APIs which means [12:20] LLM never sees your secrets. So secrets [12:22] stay in MCP server. LMS connect to the [12:25] MCP server try to invoke different [12:27] functions. So for example, LM says [12:30] restart the pot in a Kubernetes cluster [12:32] in this name space. MCP server will [12:34] validate the request, check permissions, [12:37] add authentication header and then after [12:40] the LLM request is validated, it will [12:43] connect to Kubernetes API and restart [12:45] the pod. So LLM never sees API keys, [12:48] tokens, connection, strings, internal [12:50] URLs. And as I said, this is huge, [12:53] especially for enterprises because you [12:55] can safely give LLMs and AI agents [12:58] really powerful capabilities without [13:01] exposing your credentials. But note that [13:03] this is just one layer of security. Your [13:06] MCP servers and AI agents are still [13:09] running somewhere on the network, right? [13:11] And if they're reachable from the public [13:13] internet, they are exposed. And this is [13:16] exactly what Tailscale, the sponsor of [13:19] this video, helps with. Tailscale is a [13:21] modern zerorust connectivity platform. [13:24] It builds an encrypted private network [13:27] between your devices and services. So [13:29] your MCP servers only talk to the [13:32] machines you've authorized. There are no [13:34] open ports, no firewall rules to manage. [13:37] It handles the connection automatically [13:39] even through nets and firewalls. And for [13:42] AI specifically, they built Aperture, [13:45] which is a gateway that sits in front of [13:47] your AI setup, and you can easily swap [13:50] which agents you're using without a new [13:52] configuration introducing risk. You get [13:55] full logs of every tool call your agent [13:58] makes. You can block calls before they [14:01] execute. And your API keys stay in one [14:04] central place instead of being spread [14:06] across containers and developer [14:08] machines. Tail scale handles network [14:10] level access. Aperture adds the [14:13] governance layer on top of it. Two [14:15] problems you'd otherwise have to solve [14:17] yourself. If you're running AI agents in [14:20] production, security is definitely not [14:23] something that you want to skip. So, be [14:25] sure to check them out. Their personal [14:28] plan is always free. And if you want to [14:30] bring Tailscale to work, then you can [14:33] use code nana for three free months on [14:37] any paid plan. Link and all the [14:38] information is going to be in the [14:40] description. And now back to the video. [14:43] And finally, another big advantage I [14:46] want to highlight is that you can swap [14:49] AI models much faster when using MCP. So [14:53] without MCP, Claude would need custom [14:56] integration code. GPT4 would need [14:58] different custom integration code. [15:00] Gemini would need another one because as [15:03] I said at the beginning, you were [15:04] connecting each LLM directly to each [15:07] tool without any middleman. But with [15:09] MCPA, you basically introduce a [15:11] middleman between your LLMs, all the [15:14] different models of all the different [15:16] LLM providers and all the tools on the [15:19] other side and you change your LLM by [15:21] changing one line in your host [15:23] application and your integrations stay [15:25] exactly the same. Now obviously you [15:28] still need to write the logic or syntax [15:31] for MCP client to call the MCP server, [15:34] but that's it. You just write that once [15:37] invoking functions of different tools [15:39] like possql and stripe and slack and so [15:42] on happen all through MCP server. So you [15:45] don't need to write custom integration [15:47] code for those. And again to think about [15:49] it as an analogy think about traditional [15:53] power outlets. So different countries, [15:55] for example, have different plugs, [15:57] right? Your laptop from Germany needs an [15:59] adapter for the US, a different one for [16:02] Japan or UK, different one for [16:05] Australia, and so on. And HTB APIs are [16:09] like power outlets. Every device needs a [16:11] specific plug. You manually plug or [16:14] unplug your device, and there is no [16:16] intelligence or context behind. But then [16:18] you have USBC, which is one port that [16:22] works with everything. You just plug it [16:23] in and the devices negotiate [16:25] capabilities automatically. And you can [16:27] even use a USBC hub to connect multiple [16:31] devices through one connection. And MCP [16:33] is basically like a USBC port where you [16:36] have one port. You can use a hub even to [16:39] connect multiple devices with different [16:41] ports through the same connection. Which [16:43] means your tools do not change. You [16:45] still have your POSSQL database, Slack, [16:48] Stripe API, Slack web hook and so on. [16:50] But instead of building a custom adapter [16:52] for each combination of AI model and the [16:56] tool, you have one standard port that [16:58] everything connects through. [17:02] So now that you understand why MCP is [17:04] needed, let's talk about the name MCP. [17:07] So why that name and what does it [17:09] actually stand for? Let's start with P [17:11] which stands for protocol. Well, you [17:13] already know what HTTP is. It's a [17:16] standardized protocol, right? basically [17:18] a common communication language that [17:20] every web client like a browser and [17:23] every web server agrees to speak and [17:26] that's why Chrome can talk to any [17:28] website in the world and the website [17:30] doesn't need to write custom code for [17:32] Chrome specifically. You have one [17:34] standard and everything just works. MCP [17:36] is the same idea but for AI models and [17:39] tools. It's a standardized communication [17:41] language between any AI application and [17:45] any tool to talk to each other. So [17:47] instead of writing eight custom [17:48] integrations, you write zero integration [17:52] directly between LLM and the tools [17:54] because you have MCP in the middle. So [17:56] you basically just write integration to [17:58] the MCP server and all the tools like [18:01] possql, elastic search, stripe, CRM [18:04] system, kubernetes cluster, whatever [18:06] tools you're using, they each expose [18:09] themselves through MCP and your AI [18:11] application connects to all of them [18:14] through just one protocol. So that's the [18:16] protocol part. Now the model MCP is [18:19] specifically designed for AI models, not [18:22] for web applications, not for mobile [18:23] applications, for LLMs. And that [18:26] distinction is important because the way [18:28] an LLM needs to interact with tools is [18:31] fundamentally different from how a human [18:34] written application does. A normal app [18:36] calls a specific API endpoint because a [18:39] developer hard-coded it. And LM needs to [18:41] first discover what tools even exist, [18:45] understand what they do, and then [18:46] decide. It's important decide because LM [18:50] are more intelligent than hard-coded [18:52] code. So LM will then decide based on [18:54] this information which one of those [18:56] tools it needs to call in which order [18:59] and MCP is built around exactly that [19:02] workflow. So that's why a model [19:04] protocol. And then finally, we have [19:06] context. And this is the one that APIs [19:09] actually cannot do at all because HTTP [19:12] is stateless. Every request you make [19:14] starts from zero. The server has no [19:16] memory of what happened before and it [19:18] was supposed to be that way. But with [19:20] LMS, a conversation has a state when a [19:23] customer says, "I want to refund it." [19:25] The word it refers to the order they [19:27] asked about 30 seconds ago. And an AI [19:30] assistant needs to carry that context [19:32] forward. And MCP supports stateful [19:35] sessions at the protocol level and your [19:38] host. So basically application that has [19:40] the MCP client to call the MCP server [19:43] and the LLM they keep the conversation [19:45] and prior tool results in context across [19:48] multiple steps. So you can keep the [19:50] conversation flowing with follow-up [19:53] requests. So put it together, MCP or [19:56] model context protocol is a protocol [20:00] designed specifically for AI models that [20:03] maintains context across multi-step [20:07] interactions with tools. That's the name [20:09] and that's exactly what it does. Okay, [20:11] so now you understand what MCP is [20:14] conceptually, most importantly why we [20:16] need it and even the breakdown of the [20:19] name. But let's get into how it actually [20:21] works because the architecture is [20:23] actually a very interesting part. So [20:26] there are three components of an MCP. [20:28] You have the host, the MCP client and [20:30] the MCP server. So let's start from the [20:33] tools side and work backwards. We have a [20:35] posgrsql database, right? So we install [20:38] an MCP server for it. That MCP server is [20:41] essentially a translator between [20:43] PostgresQL database responses and [20:46] something that AI can understand. That [20:49] MCP server is essentially a translator. [20:52] On one side, it speaks MCP protocol [20:55] which is the standardized language so [20:57] that any AI application can talk to it [21:00] and on the other side it speaks SQL to [21:02] your actual database. It's a wrapper [21:04] that takes MCB requests and converts [21:07] them into native database operations. [21:09] That MCP server exposes tools. As I [21:13] mentioned before, tools are basically [21:15] functions that your AI model can call. [21:19] For Possql, those may be things like [21:21] query orders, get customer info, check [21:24] inventory, and so on. And every tool [21:27] will have its set of functions like [21:29] elastic search will have its own [21:31] functions or tools that will be exposed [21:34] as tools. Stripe, slick will have their [21:37] own list of functions and so on. Now on [21:40] the other side you have your host. This [21:42] is your application that your customers [21:45] are interacting with. For example, this [21:47] could be your chatbot backend. So this [21:50] is your custom code or custom [21:52] application written in Node.js JS or [21:55] Python, Go, whatever you prefer. And [21:58] inside that host application lives an [22:00] MCP client, which is a library that [22:03] handles all the MCP protocol [22:05] communication. So the client [22:06] communicates or sends requests to the [22:08] MCP server. And here is an important [22:10] architectural detail. In most [22:13] architectures, the host owns the MCP [22:16] client and orchestrates both LLM calls [22:20] and MCP calls. The LLM does not open [22:23] connections to MCP servers by itself. [22:26] That's handled and orchestrated by the [22:28] host. So, let me walk you through [22:30] exactly what happens when a user sends a [22:33] message with our example chatbot. Step [22:36] one is discovery. When your chatbot [22:39] starts up, the MCP client asks each MCP [22:42] server. So, you may have separate MCP [22:44] servers for different tools. The MCP [22:47] client will ask the MCP server, what [22:50] tools do you have? MCP server will [22:52] reply. I have query orders, get customer [22:55] info and check inventory for PostgreSQL [22:58] and this and this tools for elastic [23:02] search and so on. And here's the input [23:04] schema for each one. Your host will [23:06] store that list. So LM now knows what [23:10] tools exist without you hard- coding [23:12] anything in the code. Step one, the user [23:15] asks a question like where is order 1 2 [23:18] 3 4 5. Your host sends this question to [23:22] LLM along with the tool definitions it [23:25] just discovered. The LLM now makes a [23:27] decision. It will look at the question, [23:29] look at the available tools and decide [23:32] in order to reply to this question, I'm [23:34] going to call query orders with order ID [23:37] 1 2 3 4 5 to get the result. Important, [23:41] it doesn't execute anything. It just [23:43] states the intent. The host executes. So [23:46] your host receives that intent from the [23:48] LM. It sends a tools/call [23:52] request to the MCP server for Postgrql [23:55] which then runs the actual SQL query and [23:58] returns the result. So back to the LLM, [24:00] your host will receive that result first [24:03] and it will forward it back to the LLM. [24:05] The LLM now has the data it needs or [24:08] input data to generate the final answer [24:11] in human friendly way like your order [24:14] shipped yesterday via DHL and it will [24:18] arrive on Thursday. And step six also [24:20] very important follow-up because now [24:23] user may have a follow-up question like [24:26] can you actually refund it? I don't want [24:28] this anymore. And because your host and [24:30] LLM keep the conversation and tool [24:33] results in context, your application [24:35] already has the order details from the [24:38] previous step. So LLM can now decide to [24:41] call the Stripe tool with that amount [24:45] without needing another database query [24:48] again and also trigger notify SLE [24:51] function or tool to alert the finance [24:54] team all in one conversation flow. So [24:56] that's one specific flow of MCP in [25:00] practice. [25:02] Now one question you might have here is [25:05] do I need to build an MCP server for [25:07] every single tool? And also who actually [25:10] builds those MCP servers? Do I need to [25:13] do it myself? Are there ready MCP [25:15] servers? Where do you get one? So let's [25:17] answer those questions as well. First of [25:19] all, who builds those MCP servers or [25:22] where do you get one? Do you have to [25:24] build it yourself or how does it work? [25:26] And in terms of who builds MCP servers, [25:29] there are actually three types of MCP [25:31] servers in the ecosystem right now. So [25:34] first you have communitydriven or [25:37] open-source MCP servers and this could [25:40] be official reference servers like the [25:42] one built by entropic which is now [25:44] maintained as open-source project and [25:47] this cover common tools like file [25:49] systems databases basic web operations [25:52] and so on and there are a lot of [25:53] open-source community maintained MCP [25:56] servers and they're actually good [25:58] starting points for simple use cases but [26:01] in production it can have limited [26:04] features plus you need to make sure that [26:05] they're up to date and properly [26:07] maintained by whoever is maintaining [26:09] them. The second option is enterprise [26:12] servers and these are actually MCP [26:14] servers built by the tool companies [26:16] themselves and this is a gold standard [26:19] because Stripe building their own MCP [26:21] server is essentially the same as Stripe [26:24] building their own official SDK because [26:27] they know their API the best and they [26:29] maintain it. So you can trust that it's [26:32] production ready and up to date. And [26:34] third, you also have community servers [26:36] built by developers when the official [26:38] one does not exist yet. The quality here [26:41] is different, but this is a really good [26:43] choice when there is no enterprise [26:45] server available. There's nothing which [26:47] is official open- source project and [26:50] basically just developers and engineers [26:52] or group of engineers build them because [26:54] there is no other alternative. Now, [26:56] another question that we asked is, do [26:59] you actually need an MCP server for [27:01] every single tool or can you have just [27:04] one with all the tools that you want to [27:06] connect to? Zapier, for example, which [27:08] is an automation tool, has one MCP [27:11] server that exposes 5,000 plus tools. [27:15] And obviously, it's way more efficient [27:17] than having 5,000 MCP servers because [27:20] that would make the whole thing [27:21] completely inefficient. instead you have [27:23] one that aggregates many APIs but you [27:26] can build your own aggregator MCP server [27:29] for your own internal tools because [27:31] there's still a chance that an MCP [27:33] server does not actually connect to the [27:36] APIs that you need. So for example let's [27:38] say internally use Postrql Kubernetes uh [27:41] Prometheus AWS Slack workspace and so [27:45] on. So instead of installing five, six [27:48] separate MCP servers, one per tool, you [27:51] can build one custom MCP server that [27:54] reps all five or six tools. And if [27:56] you're building internal tooling, rather [27:58] than installing separate MCP servers for [28:00] each tool, you can actually build you [28:02] will have just one deployment, one [28:04] authentication layer, one endpoint to [28:06] secure, and one server to manage. So [28:09] it's usually better choice for companies [28:12] and enterprises because you can properly [28:15] manage and secure one server instead of [28:18] splitting your attention and resources [28:20] on multiple. And also very useful, you [28:23] can actually add custom business logic [28:25] in your MCP server. For example, only [28:28] allow pod restarts in nonproduction [28:30] after 6 p.m. And that kind of policy [28:33] will live in your MCP server instead of [28:35] in your prompts. And you can control [28:38] rate limiting, audit logs, access [28:40] control, and so on. So to wrap up, when [28:43] you develop applications that use LLMs, [28:45] you need those LLMs or AI agents to work [28:49] with multiple tools. Without MCP, you [28:52] would have to write custom integrations [28:54] for every combination of AI model and [28:56] the tool, which is hard to build, hard [28:58] to maintain, breaks every time you swap [29:00] a model or a tool, and so on. So MCP was [29:04] created to give this standardized [29:05] protocol that sits between your AI [29:08] application and your tools. And we are [29:10] already seeing MCP used in production [29:13] style setups in many different use cases [29:16] including DevOps for example Kubernetes [29:19] operations via Cubectl style MCB [29:22] servers, database queries, observability [29:25] with data dog or Prometheus integrated [29:27] servers, code review flows that [29:29] integrate GitHosting for example or [29:32] error tracking tools and in many cases [29:34] these are community or internal servers [29:37] rather than official vendor products. So [29:39] there's a lot of activity in that space. [29:42] Now I hope I was able to cover all the [29:44] questions that you had around MCP and [29:47] you really understood the concept of [29:49] MCP, why it's useful and how it's used. [29:53] Hope this is going to help you in your [29:54] projects. If you found this useful, [29:56] share it with one friend or colleague [29:58] who you think will benefit from this [30:01] knowledge as well. And with that, as [30:03] always, thanks for watching and I'll see [30:05] you in the next