Understanding Model Context Protocol (MCP)

Key Takeaways

Hi, I'm Holland Dath. I'm a Microsoft AI MVP and today we're going to look at model context protocol. So in this session understanding model context protocol, we're going to um look at what it is because model context protocol was it took the world by storm in late 2024 and it was introduced by Enthropic and it's such a powerful tool. So we're going to explore what it is. We're going to look at the fundamentals. We're going to look at some versioning because we got a new version November 2025 where we there's a definitely some very exciting new features there. So we're going to look at those and we're going to build one from scratch just from Visual Studio. And of course I'll share the key takeaways just to remember what was really important during the session. And this is all in the next like 20some minutes. And as I said the model context protocol was introduced by Enthropic in November 2024 and they defined it as this open standard that enables developers to build secure two-way connections between their data sources and AI powered tools. And I encourage you to check out the the URL that is on the bottom and the accompanying videos. Enthropy created some videos. Microsoft did amazing job explaining this as well and they propose something very cool and useful. But what do they propose and why is this context so important to our models? So let's explore this context in model context protocol. What is this context we're trying to feed our AI applications and models? LMS don't know your world by default. So context is everything to these models. They rely entirely on the context you provide to reason and act effectively. And this context is a combination of of data, of state, of memory. And of course, this access to tools, giving the AI applications um the actual access to tools to be actionable, to have the ability to act. And providing this um this context to our AI applications is so important because it makes our AI applications, our large language models, our agents um much much more um aligned with the actions that we want to to to have to take them to reduce the number of illucinations in there and to ground their outputs in in our data in real data. And MCP shares the sharing of this context allowing agents and models to access consistent up-to-date informations and tools across our entire landscape. And of course the best way to show you is through a demo. So let's dive into Visual Studio Code. And with Visual Studio Code um we're now looking at Copilot. And Copilot is our AI application that will be leveraging MCP. And if we'll be asking it a a a question that everyone will understand that everyone that created software in the development team will understand. If we ask it I am a product owner. I want to assign a team member to the task and this task is to fix a front-end bug that suddenly popped up in production. Which team member should I assign this task to? And there's a couple of reasons these models or um there's a couple of ways these models can respond. And usually it is a way to um to find the information yourself. So it gives you an actionable plan as we see here as well to retrieve that information because it does not have access to my team members. It does not have access to my features, my components is lacking the context it needs to actually give me a better answer. So um with this general response which is amazing in itself of course we can do a lot better and we can use MTP to do that. So if we're going to add an MCP server and just to let you see there's nothing magic in this Visual Studio Code. So it's just the built-in stuff. There's some uh extensions there but no MCP servers as of yet. And of course we can add that MCP server really easily. So if you go to the command pallet and just click add server, it gives us a couple of options and it takes us in a wizard to these options we need to provide it. And immediately we are confronted with some some questions we'll dive into later. So if you don't understand what we're looking at now, don't worry. We'll get to the transport options in the later later uh slide. So we see standard output http. We can run it from uh mpm packages from a docker image. But for now, we're just going to add that http server. And we need a URL of course and this is a URL of an MCP server I have running on the background. And of course, we have to give it a name. And it has to reason about the information about my team. So we're going to call the team server and just add it for this workspace. And now we see this magic MCP JSON uh being filled with only that MCP server. So we now have that singular MCP server that is running in the background. So let me just close that up and ask it the same question again. And now it will leverage MCP to actually get the information about my team. Um so it can do better task on returning this relevant answer to me. And immediately we see it wants to invoke that MCP server command and it asks me as the user as the human in the loop for approval if you want to allow that MCP call. Of course, we're now going to allow it, but it's very important to have those human um well human like guardrails in place to um to keep those agents in check. And now it it ran that get team members call and it's now saying well Chloe Rasmusson is the best uh the best fit to assign this task to and it also knows why. So it it's all Chloe is very good at front end at UX at testing. So in the end she is the best fit for this fixing this production production bug but also if Chloe is not available it also gives you alternative options. So Noah and Sophia are fine as well and there's also some other calls in there. So from now for co-pilot sake we could also just assign Chloe here to that front end bug and uh have her work on it. But just to show you that at first when not providing it the right context, it provided this general answer which was still powerful. But with those MCP calls in place, it did such a better job in um reasoning over that data and giving me a really relevant answer to my um to my problem. And if we look at another example and this is more like the the large language models the agents we see in the wild and we see here this agent with a large language model in the center with a couple of connections to some underlying systems. So it has a connection to email a time server a calendar and some documents and before you had to create and develop all these inter interfaces for all these systems separately and you could not you were not be able to really reuse those connections. So if you had another agent with another large language model model, you would have to set up those connections and um uh those connections to those services uh every single time for those agents and that is the reason that entropic proposed the model protocol which standardizes how we interact with these systems. So instead of writing these connections every single time to wrap these, we can just wrap these APIs in an MCP server. And the large language model, the agent at its core only want needs to know how it can talk to these MCP servers. Um and then not only standardizes how we interact with these systems, it also allows us to reuse these tools across our AR applications. So here we see multiple agents leveraging the same tool through MCP connections and this reuse really allows us to to build once and use everywhere which really fuels innovation there and at its core it's a really simple protocol. MCP standardizes this uh these tool interactions with external systems using JSON RPC, JSON remote procedure calls which are just a very fancy word for a small lightweight JSON messages going back and forth. And in the top left we see an example of such a request and this is a client. So it's GitHub copilot asking the MCP server, hey, what tools do you have? So give me a list of these tools. And on the right side we see an actual response from an MCP server which exposes a singular tool search GitHub. And the description we see here is very very important because it allows us to tell the large language models what it's actually it can invoke that tool for. So by this description search repositories in GitHub um GitHub copilot knows well I have to invoke this search GitHub tool um when I want to search repositories on GitHub and it also provides us input schema so it tells us if you want to invoke this tool please provide me a query and uh optionally a limit but the query of course is very important because we want to search something so it makes sense we have to input input that query but it also tells us what it's going to output so it defines the output schema and tells us it will return an array of of objects of JSON objects containing a repository name and a URL. So with all this information the agent is really able to leverage those um those tools and all these tools and all these tools calls uh from the client to the server really for for follow the same general pattern and most of the time of course we won't be able to see these interactions. we won't won't we don't won't want to see these interactions because they're wrapped in these really AI application libraries we're we're using on the application side and as we saw when we added the MCP server in Visual Studio Code it provided us a couple of options and the transport options are really important and there in the like the past couple of months it has been quite a journey because it all started with the SDIO so the standard input output, but it only was suitable for local development. And in fact, the NTP protocol is is transport type agnostic. It doesn't really care as long as the transport option is birectional um and has low latency. So if you want really want to, you could develop your own transport protocol to leverage these MTP if you have this very specific use case. But most of the time you really are better off just using the the standard options provided here. Um, and that is of course because we're standardizing. We're we're making everything reusable. And if you're creating your own protocol, then you won't be able to leverage all the the amazing MCP servers that are already out there. But more on that later. But usually we want our servers to be accessible remotely. And then streamable HTTP is the standard we are almost always using currently. And that is uh a protocol which is a mix of HTTP and some servers and events. And those service and events are used uh to create the long polling mechanism to have that birectional behavior and it also has some authentication headers. So we can actually do the security securely but more on security later as well. And then the good stuff the thing that MCP servers are exposing to our MCP clients. So the the the data gold, the tool gold, we really want um we we would want the value of uh the fundamental building blocks for these MCP servers. And this is not an exhaustive list. There there are so many more things to explore regarding MCP, but these are the the most popular options in there. So we start with with tools. So tools is the the the uh the resource type we see being used most. So almost every MCP server will expose some set of tools and these are the functions and tools that can be invoked by the client. Basically everything you can have in an API you can wrap an MCP server around it and invoke those API calls through those tools. For our resources which are static data chunks um that is are read only data and are exposed by the server is a specific resource type created to return data to our MCP uh clients. And we see tool use um being used most of the time. So most most people use tools to do the data retrieval as well. But please know and understand there's a specific data type resource type for uh static data being exposed from MCP. But we'll look at some demos just in um uh in the next slide. And then we also have these prompt templates because the past couple of years since Genai, we've been at getting good at prompt engineering, right? We've been creating those amazing prompts to reuse across our applications to reuse across our teams. And MCP really makes it really easy to share and redistribute those those prom templates to our AI applications or um well in in fact everywhere we want to send them in a in a uh generalized and standardized way. And the first three so the tools, resources and prompts are all the client asking the server for some piece of information. But the last one sampling is the other way around. For sampling, it's the MCP server that's requesting some inference on that amazing large language model on the client side because the server knows, well, the client that has um that's invoking me probably has this this really cool large language model I can use to run some inference to actually ask you the question and have that large language model reason over that input. And that input is sent from the server to the client and of course human in the loop. So there's approval needed there um from the from the user from the human user and if that approval is given the client sends that to the large language model sends that answer back to the MCP server. So the MCP server can leverage that inference on the client side in uh an amazing value answer it's going to give um back to the client. And of course there's a lot more to explore but if you want to know more then then please just go to that the the um URL in in the earlier slides because um these are just the like the the the tip of the iceberg the most popular options here and let's just have a look at in Visual Studio Code what we're looking at and just close this um GitHub copilot and open up a terminal and we just are going to invoke this command. So, npx contact protocol/insspector and if you don't have that installed, it will install it for you and it will now run that inspector in this window. So, let me get that window in here. And this is a tool also created by Enthropic to um inspect the traffic going back and forth. So, it's really a debugging tool for our MCP servers. And it gives us a couple of options here. So, again, the transport type. So, we have to configure. We're now going to look at that MCP server um we have running in the background which is on port 5105 and we have some other connection options here as well. all we um could uh if we have some authentication on this on the uh MCPU server and usually you would want to well for this demo we don't but if you want to configure that you can do that zero you have some other connection configuration options here as well but for now we're just going to connect and it will provide us a very important initialization call we're just going to look at and let me zoom in a bit so we're now looking at that first call that the MCP client is sending to the MCP server which is initialized and immediately the MCP server is providing value because it's telling the client what it has to offer. So here we see we have some prompts we have some resources and we have some tools that are being exposed by this MCP server and telling the client well if you want to you can list those uh resources from me and in the top we um see those resources being listed. So get this debugging information out of there and uh just look at the resources. So if we list our resources, we now have two resources that are being exposed to the client. So we have some uh call to get our architectural guidelines and maybe some call to get our current endpoint to our APIs. So if you explore that get architectural guidelines, we can click it and it will fetch it from the FCP server. And here on the right we see the contents and it's actually a very large markdown file um with our arch architectural guidelines for our C#.NET applications and it's a really big file and it's not the best way to read this. So please believe me this is an amazing architectural guideline for our C.NET applications being exposed by this MCP server. And the same goes for prompts. So we can list our prompts and here we have the summarization prompt um that we can fetch from that MCP server and that allows us to create the best prompt out there and in reuse it and um use this in our AI applications. So here we need to provide it some content. So I'll just do the word demo which is not the best thing to summarize but just to get a feel for the prompt. Usually you would input your content you want to summarize, but here we get this amazing prompt. You're an expert summarizer trained to produce accurate, concise and reliable summaries. And then the thing that we're most excited about the resource type tools and these tools can and as I said it can be anything you can rep API. So for here we um uh for the product owner example we to provide it with the team information we have the call get team members here and we can invoke that tool and we get all our team members back with the set of skills they actually have. So on the right we see the MCP server actually being invoked and we'll we'll dive into the code later because we're going to build this MCP server for ourself. And to look at the last example for sampling and as as I told you it was the other way around. So here if I click on sampling there's nothing yet because it is the MCP server that needs to call into the client um and ask it for the inference on that side. And I'm going to cheat here because I created a tool that will invoke that um that client that will invoke the server to to fetch into that client. So if I run that tool, we now see a sampling request popping up and this is simulating the user approval. So here on the left side, we see that message going to the client and we can improve that um as we would on the client side because remember this inspector is a debugging tool to uh understand what is going back and forth between the client and the MCP server. And if we go now back to our sampling request, we now here get that amazing I just waited too long so I got a timeout before. We're now getting this LLM sampling result we would expect from our client which is our amazing inference on the client side returned to the server. So if I go back to the slides because there's so much more to explore and with these um um with these this MCP protocol a lot of people got excited and started building MCP servers and those MCP servers are now logged and categorized and and and being cataloged in these MCP registries. And this is not an exhaustive list. This is just a top five of MCP registries I use um well almost on a daily basis. Well, especially the MCP servers on there. I use a lot of them and these are just if you're getting started with MCP um these are just a couple to get you started. But what is most important when using public MCP registries that you trust the registry and you can trust the registry um you're about to use because it's really easy for malicious actors in this supply chain of MCP to get some malicious content or get some malicious tool calling in there and you really don't want that. So make sure you use MCP servers you can actually trust. So, these are just a couple of of MCP servers I trust, but please make your own judgment which will work for for you and um the projects you're working on. And this is of course a very nice segue to the security part because security-wise MCP has had a rough start because we got so excited building those MCP servers uh using standard input output. So, no uh real authentication in there. Um and that led to some not well protected MCP servers in there. And um in the end MCP is just as secure as you make it, right? And if you go to the protocol and inspect what is in there about security, uh there are some open doors. So it will tell you to protect sensitive operations. Well, hopefully we've been doing that as software developers for years. Uh it tells us to validate tokens. Well yes that that should we should do that and we should be doing that and we should have done that in the first place. We should enforce lease privilege and we should follow best practices. So in short that is what the the model contract protocol is telling us. So use common sense follow those best practices. But that's not really helpful in in like securing our uh MCP servers. But if you read on it tells you it follows the OOTH 2.1 standard. And if you know, oh 2.0, so maybe you don't know 2.1 yet. Well, if you know 2.00, then you're set because 2.1 is is just an iteration on that. So there's some um RC's that are now in there and and it's gotten uh more secure and better and uh more amazing, but the principles that you're using for 2.0 are still the same. So if you want to know actually know of 2.0, then you're set using all 2.1. So if you're using standard or 2.1 you're using client credentials for autonomous agents and you're using author authorization codes and pixie on behalf of user flows and if you're using that it's just as safe as the off protocol itself. So um MTP is is just as safe as you make it. And then last November so November 2020 20 November 25 2025 we got a new version. So we got the uh the new version of the model conduct protocol the 20251 11125 version and it brought some uh very important improvements um things like uh simpler authorization authentication thanks to open ID connect discovery some things regarding incremental consent some usability improvements um some icons there's there are all small tweaks and uh improvements there but they also introduced a new experimental um resource type. Well, it's not really resource type. It's an addition to the existing resource type, but that addition was the asynchronous tasks which finally lets MCP handle those longunning jobs where re results can be retrieved later, which is a major major step towards real multi-step pipelines. So, if we look at that MCP tasks, um it is really very simple. So we decorate our existing uh tool call with some task metadata and we get back our task ID and that the server is working on it and then we can just keep calling it so we get the task by the task ID and maybe the the server is still working but if it's done in the end we get our result back and it says well status completed and we actually get that result we need and at first we had we could create this flow ourselves but then we needed multiple tool calls and this makes it a lot easier and by standardizing it it's a lot easier to implement on the client side. So very excited about that and then as I promised we are also going to build one from scratch in vis Visual Studio using C. So, if I head over to Visual Studio and I have uh the demo project running here, but we're going to start a new C# project entirely from scratch. So, I'm going to create a new project and I'm just going to create a vanilla ASP.NET Core web API. So, we're going to call that MCP demo. And I'll just hit next. And um I'm still on net 9 which should be fine for this demo. So I'm just going to create this project and it should be done really pretty really pretty really fast because it's a very small vanilla um C project. So let me close this and I'm going to strip out everything that we won't need because I created this this standard API. We don't need those controllers currently because we're exposing an MCP server. And of course I just told you security is very important but just to show you um how easy it is and the moving parts which are really here for this MCP server I'm also going to remove this authorization uh mappings for now and as I said we don't need the controllers. So now we have this very simple template of this ASP.NET net web API. Well, it's not really web a API anymore, but it's .NET applications at its core and it will still build and run. But as I said, we want to build an MCP server. So, I created some tool uh tool snippets just to make typing easier. So, we're we're adding this to builder services and MTP server. And of course, we need to add that dependency. So let's head over and manage the new good packages and add that one for model cont protocol. And please remember it's still most of those packages are in pre-release. So I have this check mark here and we're going to use the one for ASB.NET core. So we're just going to install it and we're going to apply it and accept it and it will solve that dependency now for me. So we now have added that MCP server just as those recaller controllers we have to map this um uh these these tool calls to this um to the added MCP server. So just as controllers we're now going to tell it well map my MCP server here and for the the the uh the model contextual inspector we um we really want an end health endpoint in there as well. So, we're just going to return healthy if um if that endpoint is fetched. And this is a working MCP server. But of course, as um as we learned, there's resources we need to um we need to to uh expose. So, if you look at line eight, we're just going to tell it, well, just add all the tools from my assembly in here. But there's no tools in here. So, let's add some tools. So I'm going to add new class and naming is hard so I'm just going to add call it MCP tool. Please have better names for these um for these classes. I've prepared a snippet here as well. So we're going to add that MCP tool. And there's really no nothing magic going on. There's a couple of things important and those are the decorators that we we see here for the MCP server tool type and the server tool. So let me zoom in a bit. So we we decorate it with the server tool type. So we tell um uh we we tell the compiler well these classes are are tools. So we have one for resources as well for prompts but these are the tools and there's tools we we're we're um exposing here. So we have this MCP server tool with the name get team members and we have the description here of course in here as well because then our large language models or agents know how um what to invoke these these tool calls for. And as you see here there's nothing really magic. It's just fetching into an API and this is all just fetching the API code and serializing it and returning that JSON result from the API call back through that MCP um server. So with that, if we go back to the program and we just run it, hopefully we get back a new port number we can use in our inspector. So here we see a command result. And we now have port 5075 and let's open that model protocol uh server again. And where did I leave it? It was still running. just open up a new terminal and that will solve all our issues. So let's start a new protocol inspector port 5075 and update it here as well. Um I'm just going to leave the rest here because it's also of course a streamable HTTP protocol. If we list our tools, we now get the team members from our um uh just created MCP server. And if I run that tool, we actually get the same result as we had before, but now from our new MCP server. So very cool. And just and this is just to show you the moving parts in C. And just to show you how easy it is to get started building these MTP servers. And just to sum it up, there is a couple of takeaways I really want to um you to to leave with because MCP is very powerful and it's being the adoption is crazy. It's an open source uh initiative and development is um is really going well. So a lot of new exciting features are introduced um to the protocol. So please keep updated through model protocol.io. what cool new features are there and how um we can implement those and please remember MCP is just as secure as you make it. So, please follow those best practices. We've been learning as software developers for years. Um, and and also use these for MCP. And if you're done with this video, try creating your own MCP server. And you don't have to do this C#. There are amazing libraries in all these other languages as well. So, if you're using another language, there's probably a library to set up your own MCP server. And it should be just as easy as we saw before. And what I'm really excited about is the possibility of service discovery and some auto registration of MCP servers and MCP calls in there. That is really the next step. But and maybe it is science fiction and maybe it is something we don't really want uh from a business perspective. Um but it it would be very cool nonetheless. So thank you so much for um for being here with me and uh being here for that information about model protocol.