S08E05 1h 10mSeason 8

Episode Summary
Mike Kistler discussed his work on the Model Context Protocol (MCP), an emerging standard for building web APIs. He explained that MCP is based on OpenAPI, which has become increasingly popular as a tool for defining APIs. However, Kistler argued that MCP offers more capabilities and flexibility than OpenAPI alone.
Kistler highlighted one of the key features of MCP: its ability to handle multiple protocols and languages in a single API. This means that developers can write APIs that can be consumed by multiple programming languages, without having to rewrite the API code for each language. Additionally, MCP allows for more flexible data modeling and schema definition, making it easier to build robust and scalable APIs.
One of the most exciting aspects of MCP is its potential to enable agents and other kinds of automation in web development. Kistler described how developers can use MCP servers as a kind of “agent” that can perform tasks on their behalf, without having to write custom code for each task. This could have significant implications for industries such as finance and healthcare, where automating manual processes is crucial.
Kistler also talked about the importance of Azure Functions in hosting MCP servers. He noted that Azure Functions is a pay-as-you-go service, which makes it an attractive option for developers who want to build and deploy MCP servers without having to worry about upfront costs or maintenance responsibilities.
Throughout the conversation, Kistler emphasized the potential of MCP to transform the way we build and consume APIs. He encouraged developers to learn more about MCP and get started building their own MCP servers, which he promised would be amazing experiences. The interview ended with a lighthearted remark from Jamie, the host, who joked that Mike’s suggestion to create an MCP server for the podcast was a great idea - even if it might inspire some chaos in the world of web development.
Episode Transcription
And we talk about that contract. We say, “this is your contract. This Open API definition that you have is the contract for your service.” And in the end, that’s how customers interact with Azure is through APIs. And so it’s important to have that contract so that customers know how things work, how to use them, hopefully how to use them easily, right?
Hey everyone, and welcome back to The Modern .NET Show; the premier .NET podcast, focusing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. I’m your host Jamie Taylor, bringing you conversations with the brightest minds in the .NET ecosystem.
Today, we’re joined by Mike Kistler to talk about two topics (we usually only tackle one topic per episode, so you’re getting a bonus with this episode): Open API and both MCP and the MCP SDK for C#.
We started our conversation by focussing on Open API, as this is a passion of Mike’s. We talked about what it is, how you’ve likely already been using it with any ASP .NET Core WebAPIs that you’ve worked on, and how the latest versions of ASP .NET Core can generate a lot of the Open API specification for you without having to add lots and lots of metadata an attributes.
Pro tip: If you’ve been using the Swagger UI in your applications, you’ve been using Open API.
And when the LLM decides that it wants to use an MCP tool or access an MCP resource, it doesn’t go and do that directly. It comes back to the MCP host and asks the MCP host to call a tool with a particular set of parameters, or to access an MCP resource. And at first, when I saw this in the MCP architecture, I thought, “boy, that’s clunky. Why not have the LLM just call these things directly?” And there’s a deliberate reason why it was done this way.
We then pivoted over to talking about MCP (or Model Context Protocol) which is a rapidly evolving standard for creating your own agents and applications which can communicate with or be instructed by, LLMs. We talked about how the MCP standard works, and how the standard is written in such a way that there’s always a human in the loop. We also talked about how you can build your own MCP servers using the MCP SDK for C#.
It’s worth pointing out that both MCP and Open API are evolving standards. While Open API tends to evolve with a much more relaxed pace, the MCP standard (having not even reached a year old when we recorded) uses the date as it’s version number. And Mike actually references the latest version of the MCP spec in our conversation, which will give you a clue as to when we recorded it.
Before we jump in, a quick reminder: if The Modern .NET Show has become part of your learning journey, please consider supporting us through Patreon or Buy Me A Coffee. Every contribution helps us continue bringing you these in-depth conversations with industry experts. You’ll find all the links in the show notes.
So let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.
Jamie
Mike
Jamie
So For the folks listening in, would you mind giving them a really quick brief intro of yourself and the kind of stuff that you work on, that you can talk about, and all that kind of stuff?
Mike
My main interests and background are in REST APIs, HTTP APIs, and Open API descriptions of those REST APIs. And then the tooling that is driven from Open API, doing things like SDK generation and other things. That was kind of what got me into . NET when I was looking for a new opportunity. The. NET team has some great capabilities for generating Open API. from ASPNet Core web APIs, and I’ve been working on that basically since I got onto the team. Bunch of folks there have sort of preceded me on that Safia Abdallah, one of the lead engineers on that, working very closely with her and and the rest of the folks.
Jamie
Mike
Jamie
Mike
Jamie
Mike
Jamie
Mike
Jamie
But then I also know that I can not just create that sort of front end through—again, I keep using Swagger, but it’s the one that I know, but there’s lots of others—but I can also hand that off to say like a front-end engineer and they they will know exactly what’s going on with my API. So it kind of acts like a contract, doesn’t it?
Mike
I’m also on the Breaking Changes review board, which reviews the REST APIs to make sure that they aren’t breaking when you go from version to version. And we talk about that contract. We say, “this is your contract. This Open API definition that you have is the contract for your service.” And and in the end, that’s how customers interact with Azure is through APIs. And so it’s important to have that contract so that customers know how things work, how to use them, hopefully how to use them easily, right.
Jamie
Let’s talk about that for a couple of minutes then, right? So it’s like I know from what you’ve said earlier and from our conversations, the Open API is one of the big passions for you. So like, I guess, let’s dial it back a bit. Let’s start from the beginning. What is Open API? And I mean it’s being leveraged for me automatically in ASP. NET Core, but what if I had to write my own? Is that something I could do?
Mike
One of the big debates right now that that it’s actually been going on for a long time about how you build API projects is: do you design your API first or do you write your code and then extract the API definition from the code? You know, I used to be much more of a design first. I used to believe in the design first philosophy uh more than I do now. I still think it’s very important to pay very close attention to your API design. And so when you were doing design first, you would write the Open API by hand or you would use some tools to generate it. And you know, you can do that. And then you have an Open API and then you have to figure out how to build an implementation that matches that.
You know, the perspective that I’ve come to now with ASP .NET Core is you can have a very intentional Open API definition, produced from your code, you can you can be as careful about it as you want in terms of describing the API the way that you want it to work. But the beauty of doing it by generating it from your code is that you then know not perfectly, but but very, very high confidence that the API definition matches the implementation. And that’s one of the things that we see quite commonly that when people design their API first separately and then implement it, they don’t have that very close connection, that close correlation between the design and the implementation. So yes, you can write your Open API yourself.
You asked, what is Open API? Open API is just a description language for HTTP APIs. It’s typically written in JSON, although you can write it in YAML. There’s sort of a divide in the community about whether JSON or YAML is better. And it just goes through and it describes things about your API, like what are the endpoints? What parameters do those endpoints take? What request bodies do they take and what do the response bodies look like? What’s the authorization schemes that are required? All those things.
And and we can extract a lot of that information from your ASP .NET Core application. You know, we know the types that you’re consuming and producing from your APIs, and we can turn those types into JSON schema, which is the way things are described in Open API. So yeah, so it’s a very nice system, I think.
Jamie
Mike
Terraform, you know, all the infrastructure as code tools that we have, they can be generated from Open API. Command lines, the Azure CLI (is) generated from Open API. So it it’s really very, very powerful.
Jamie
Mike
Jamie
Mike
Jamie
Mike
Jamie
Mike
Jamie
Mike
Jamie
Mike
Jamie
Mike
So There are attributes you were talking about, like
ProducesResponseType, which is a way of saying, “my endpoint will produce this type of response. This is what the response body will look like for this status code or whatever.”With Minimal APIs, which is really the the foundation of modern. NET web APIs now, there’s a new capability, a new feature called
TypedResults. And when you return TypedResults from your endpoint, that allows the framework to capture, “this is what this endpoint is returning,” you know, with a type and the status code, and all that kind of stuff. And when you use TypedResults, you don’t need to use those ProducesResponseType attributes, we can extract it from the code.And what’s beautiful about that is it’s now coming from the code. It’s coming from what the code is actually doing as opposed to something that the developer, you know, sort of annotated on top, which could be wrong. Or it might have been right when they wrote it and then it became wrong later because somebody changed the code and didn’t change the attribute. So using things like
TypedResults really ties the Open API definition that’s generated with the way the code actually works.Jamie
And the other thing was exactly what you just had what you just said there was like: I’ve created an API, initially, let’s say it was a POST—we’ll ignore the argument of whether it should be a POST or a PUT for create, let’s just put that to one side. I created a POST and it would create or update a record of some kind, and it would return a 201 for created. Brilliant. And then someone’s come along and changed it to produces a 200. Okay, rather than, “I’ve created it and here’s the URL.”
Mike
Jamie
Mike
Jamie
Mike
Once you make an a an API GA, customers start building their apps on them. And as you say, they might build an app and then that app is done. It’s released in the customer’s production environment. And the development team goes away and it just continues to run, and and it should just continue to run for as long as the customer wants to run it. We shouldn’t force the customer to have to make changes. So Yep, that’s very important.
And, you know, we talked about the tooling aspect earlier. This is another thing that we actually use Open API for is detecting these changes. When (a) service comes along and says, “I have a new API version,” we have tooling that will compare that new API version, that new Open API to the previous Open API. And we will look for things like, “did you add a new required parameter?” Well, if you did, then that’s going to break existing users. “Did you remove a property from a response.” That’s going to break customers. And so once again, we use Open API, the tooling that we can build with Open API to facilitate these important processes.
Jamie
But, like, I’m getting flashbacks of uh for for the devs who’ve been around long enough You know, folks didn’t just always use web APIs, they used operating system level APIs. You know, you might talk to the Win32 API and say, “draw me a window please, and give me a handle to that window so that I can do things with that window. And get messages from it, and change the font or whatever.” And obviously if that API version, if that API changes between different versions of the operating system you’re using, that means that your app no longer works on the new operating system, right?
And so I can imagine that because we’re in a web world, the feeling is, “let’s innovate really, really quickly. Whoops, we’ve,” I’m not saying Microsoft do this. I’m saying everybody does this, right? Lots of people in lots of teams do this. I’ve seen it with a number of my customers where it’s like, “quickly innovate. We’ll add this. No, now we need to remove this property. Now we’ll change the property name. Now we’ll change the property type.” And I’m like. “you do realize people are using this stuff, right? Needs to be a little bit more stable than that.”
Mike
Jamie
So my question was going to be, can I, because you said earlier on about you can use the Open API documentation, I guess, that you generate for your API to generate tests. And then you’ve just said there that you will then compare the Open API documentation that is generated for, let’s call it, version 1 of an API, and then compare it to the documentation that is created for say version 2 of the API—or a version two proposal of the API. And then you’ll compare the Open API documentation across them all. But this may seem like a latent question, but can I use the Open API documentation to test that my API is correct, right?
Because like you said, it might be that, I you know you mentioned earlier on, “I’ve added this API endpoint and it used to return a 201 but now it returns a 200.” I can bake that into my tests, right? And say, “oh, did we update the documentation or should the documentation always be static and now the API is changed for all the tests?”
Mike
You said, “can I test that my API is correct?” Unfortunately, that gets into the whole business logic aspect. So for example, if you have a filter parameter, which many Azure APIs do, that will let you select which things come back and which things don’t. That’s awfully hard to test just by looking at the Open API document. But the things that you, you know, whether it’s a 200 or a 201. Absolutely. Whether certain properties come back in a response, that you can test. Whether certain parameters are respected in the in the request. Those things you can test.
One of the things that I that I did, I can’t remember which conference this was, but I showed generating an Open API document for an API service that I had in in ASP .NET Core. And then Telling Copilot, because we’re in the world of AI now, Jamie. I’m sure you know that. You can you can ask Copilot, “look at this Open API and generate a set of tests for me,” and it’ll do it. It’ll do it. It will test for things like, “did you get the right response code?” right.
One of the big things that we did in .NET 10 for Minimal APIs is we added support for validation of inputs, which is a big feature. That’s a really important feature because validating inputs is important for security. It’s important for the proper operation of your API. That capability is now there in Minimal API for .NET 10.
And the validations, the the attributes that you put on things to say, “I want you to validate that this string is no longer than 50 characters,” for example, those things show up in the Open API that gets generated. And then Copilot or whatever can say, “okay, well, that’s something that I should test. I should send it a string with 51 characters and make sure that it fails.” So we are just continuing to get better and better at describing the behaviour, at least at that, you know, at the surface, at that facade, as you said, of the API, describing that behaviour in the Open API, and then using that in all of the downstream tooling for benefits.
Jamie
And I think it was a conversation that I had with Jason Taylor a while back when we talked about the Clean Architecture and he said essentially, “you can write your integration tests, you can write your tests to test the facade. But that’s not the actual,” if you’ll excuse the expression, “the meat and potatoes of the app,” right? The app is the business logic.
Mike
Jamie
You know, if I look at my car. I want to know that the engine works. I don’t really care so much that the paint work is black or red or orange, right? That is an… it’s an important thing to help me recognize my car. But when I get in it, I don’t care what colour it is as long as it goes forward when I tell it to go forward, right?
Mike
Jamie
Mike
So about about six months ago, I guess, I started working on Model Context Protocol and the C# SDK for Model Context Protocol. I’m now the PM for that. And that has been, wow, so exciting because Model Context Protocol has just exploded. There’s just so many things happening with it. And because it’s AI, it’s moving at the speed of light, you know, as you said, you know.
And and MCP was only released in November of last year. It’s not even a year old. It’s a baby. We are just, you know, trying to mature it as quickly as possible. It’s already providing great benefits. But there’s a lot more that we think that it can do and and so we’re working on that.
Jamie
What that… that just… I can’t… like my… how do I put it? You know, how we say that nothing can go faster than the speed of light? I’m pretty sure innovation in AI is going faster than the speed of light, right?
Mike
Jamie
Sponsor Message
Today's episode of The Modern .NET Show is brought to you by RJJ Software: strategic technology consulting for ambitious SMEs.
You know me as the host of this podcast, but here's what you might not know: I'm also a former Microsoft MVP who's helped businesses from Formula 1 teams to funded startups transform technology from a cost center into a competitive advantage. At RJJ Software, we specialize in three things that matter to growing businesses:
- AI that actually delivers ROI: not hype, just practical implementations that pay for themselves
- Developer Experience optimization: we've helped teams achieve 99% faster deployments and 3x productivity gains
- Strategic technology decisions: from architecture reviews to fractional CTO services
The difference? We don't just advise. We ensure successful implementation through knowledge transfer to your team.
If you're an SME leader wondering why your technology investments aren't delivering, or you're facing critical decisions about AI, modernization, or team productivity, let's talk.
Visit rjj-software.co.uk/podcast to book a strategic consultation.
Now, let's back to today's episode...
Jamie
Mike
So Model Context Protocol is a protocol for connecting an LLM or some AI model, let’s say, to tools, which are executable things; things that can do things for you, or resources, which would be like data. And the problem that it’s meant to solve is that LLMs typically are trained on information that’s out on the internet at some period of time, right? And when they’re done training, they get released, but they don’t get retrained as new things happen. So there’s information out on the internet, or elsewhere that the LLM doesn’t know. And how do you get that information into the LLM so that it can act on it? And this this might be information that’s on the web and and and actually a lot of the new AI models know how to go search the web and that’s become a very common thing now for for LLMs. But there might be information that’s not on the web. It might be information that’s inside your company. It might be information that’s, you know, in a particular format that the LLM might not know how to browse. So you can provide that information to the LLM through resources or tools through the MCP protocol.
There can also be actions that you want the LLM to take creating a file or the one that I just spoke about, you know, write write some code for me, you know, build this thing. If you have specific actions that the LLM might not know how to do on its own, but you can provide a tool to the LLM to perform those actions, the MCP protocol is the way to do it.
MCP was originally conceived to work very similar to what they call the the language servers that are used in in GitHub and and many other other editors. that help you do coding, compiling the code, finding errors, you know, maybe suggesting corrections, things like that. There are language servers for all these different kind of models, all these different languages. MCP is meant to operate in the same way. It’s sort of an extension of your AI application, what we call an MCP host, where it provides this extra context to the LLM to do its work.
Jamie
Mike
Jamie
Mike
Jamie
Mike
Jamie
Mike
Jamie
So like, just real quick for folks who are listening and who don’t know what retrieval augmented generation is, my description of it is. Like you were saying, the LLM training stops at some point, the world moves on, and then you’re able to say to the LLM, “yes, you have your training data, but also this wiki, or this document, or this thing over here is the source of truth. Go use that.” So is that different from MCP?
Mike
The whole point of retrieval augmented generation is you can’t take your whole corpus and put it in the context window. It’s too big. Context windows are have a limited size. And so retrieval augmented generation lets you pick the most important documents to put in the context window so that you get the highest quality result from the LLM.
Jamie
Mike
A more concrete example, perhaps, is one of the most popular MCP servers is the GitHub MCP server. And the GitHub MCP server can do things like open pull requests, or open issues, or close issues, or things like that. Those are specific actions, you know, that are taken, and that’s something that The LLM can decide it wants to do it, but then it has to use the MCP server to actually do it.
Jamie
Mike
Jamie
Mike
Jamie
And then because my LLM is then talking to… is it… am I getting the thoughts right then? My LLM talks to an MCP thing. You said MCP server a few times and I’ve parroted it back to you ‘cause like that’s what you’ve used. So are they all servers or is it server in the traditional sense of there is a box somewhere on the internet that my LLM is talking to? Or is it just it can be an app that runs on my computer? Like how does that work?
Mike
One is In the MCP architecture, there’s a thing called the host. The host is really kind of like the AI application, and it uses the LLM and it talks to the MCP servers. And when the LLM decides that it wants to use an MCP tool or access an MCP resource, it doesn’t go and do that directly. It comes back to the MCP host and asks the MCP host to call a tool with a particular set of parameters, or to access an MCP resource.
And at first when I saw this in the MCP architecture, I thought, “boy, that’s clunky. Why not have the LLM just just call these things directly?” And there’s a deliberate reason why it was done this way. It’s because MCP wants to keep humans in the loop. It wants the user of that MCP host, that ai application, to know when an LLM is going to use an MCP tool, what it’s going to try to do with it, and to decide whether it wants to allow the LLM to do that, whether it wants to allow that MCP tool to be called or not. So keeping humans in the loop, making sure that there’s control, you know, not letting the LLM go, you know, rogue and delete all your GitHub repos, right.
So that’s the first thing that I wanted to say is that is that there’s an MCP host that’s that’s sort of the the traffic cop that’s making sure that all the things that are going on are are kosher.
Now, you asked another question about is this a server or is this running on my machine? And the answer is it could be either. The MCP protocol has a set of transports which are the ways that the host talks to the MCP server. One of the transports is is what’s called
stdio. And this is the way language servers work today. I said that, you know, language servers was sort of the inspiration for MCP. The language server runs locally and your editor talks to it over pipes, basically, stdio. And so you can run your MCP server that way. It’ll run locally. It’ll run on on your machine. Nothing goes out on the internet. Or there’s another transport that’s called the streamable HTTP transport. And that will allow your MCP server to be running on another machine somewhere and you talk to it over HTTP. So it could be either.Now, there’s some very important differences between these two transports. When you’re talking stio, it’s basically your server. It’s your MCP server because it’s running on your box. There’s only one person talking to it, right? It’s you. Whereas if you’re using the streamable HTTP transport and that thing is running elsewhere, that MCP server could be talking to you and it could be talking to your neighbour and it could be talking to somebody halfway across the world all at the same time. It’s just like a a a regular web API, right? In that it’s sitting there on the internet, you’re talking to it, and many other people could be talking to it at the same time.
This has some security implications that, you know, you need to make you need to be careful about. There’s authentication and authorization built into the MCP protocol to try and make sure that all the all the right security things are done. But it’s a new protocol, so we’re learning, you know, how we can improve this as things go on.
Jamie
Mike
Jamie
rf -rf (“rimraf”), or a you know, delete system32 or whatever the Windows version is now. It could still do those malicious steps as long as I say to it, “yes, do that,” right? So I still need to be critically thinking, “what is it that it wants to do and how does it do that?” I think that’s kind of an important point, right?Mike
So that’s one thing that you can do. But yeah, running things locally is, you want to really make sure that that’s a trusted application. And that you are, as you said, validating any of the actions that it’s going to take before it takes them to make sure that it’s not going to do anything destructive.
Jamie
But you have to really take a moment to, like you said, read through, you know, “your your MCP server is going to do, your MCP thing is going to do this step, this step, and this step. Are you happy with that?” And then you can say yes. Or perhaps, I mean, I’m just gonna ask this question now: I can say, “no and say don’t do step two?” Like is that something that I can do?
Mike
Jamie
Mike
Jamie
Mike
Jamie
Mike
Jamie
Mike
The streamable HTTP servers are built on top of ASP .NET Core, so If you’re a. NET developer building web APIs, this will be very familiar to you. And you in your program.cs, you do some setup and then when you build your app. You say
app.MapMcp, much like you would have MapGet or MapPut or whatever. This maps the MCP endpoints and you define a set of tools, you define a set of resources. There’s also something called prompts, which I didn’t talk about much. But prompts are a way for the MCP server to provide sort of canned instructions to an LLM. that would use its tools, or use its resources in the way that they were intended. And so all of those things can can be providedYou can write all those in in your MCP server with the MCP C# SDK. And there are a bunch of examples. There are some sample projects that are built right into the into the repo. One of the things that I’m doing now is I’m trying to build out some of the conceptual documentation for the SDK. We have our reference documentation that shows all of the different classes and features that are available, but it doesn’t sort of describe, “okay, well here’s how you would use them.” That’s that’s the role of conceptual docs that that people actually have to write and and we’re working on putting those together now. But yeah, just pick up the MCP C# SDK and go to town.
Jamie
Mike
So it’s still preview, but it’s we we do our best to try and minimize any breaking changes between releases. We had a big update a couple months ago when they released the newest version of the spec. The newest version is—they’re date-based. So 2025-06-18 is the current latest version of the spec, and it was released on that date. We had a few minor breaks maybe there, but but nothing nothing really major. There should probably be another spec coming in September-ish, and we’ll see whether there’s breaking changes at that point; but we will try to minimize them so that people won’t have to you know, make big changes to their app in order to adopt the new version.
Jamie
Mike
Jamie
Mike
Jamie
Mike
Jamie
Mike
So it is very challenging, and we’re still figuring it out. You know, we do have members of Microsoft in the MCP steering committee so that we can provide input on changes and, sort of, make them aware of when their changes might impact the C# SDK and its users. But in the end, you know, they’re viewing this as, “well, some of these changes have to happen and if they’re not breaking at the protocol level You know, you’re gonna have to figure out how to handle it.”" And so we’re working on that right now.
Jamie
Okay. So obviously one of the things that folks, when they build their apps, are very keen on, we’ve mentioned it a few times is tests. Right. I have attempted to figure out how to write tests when an LLM can be involved and things there get a bit wobbly. And I know some advice that I’ve received previously is, “you can probably test everything up to the LLM, but not the communication with it, because obviously it’s non-deterministic.” Now, as an MCP, you’re receiving information from the LLM. And since you’re going to be, as an MCP author, you’re going to be taking that information, doing some stuff. And returning the output, right? But via the LLM. From a testing perspective, what does that look like? Because I think I just broke my brain trying to think about how it works.
Mike
But what people, some people are doing now is they’re actually building MCP tools that underneath the covers have AI models built into them. That then does become challenging in the way that you described, where I call an MCP tool, and one time I call it it gives this input, and the next time I call it it gives some other input; because the LLM that was used underneath the covers decided to give something different. This is, it’s a brave new world in terms of you know testing when AI is involved.
There are some things that you can do. So one of the things is a lot of the models have a parameter that will limit the creativity, if you will. of the response. OpenAI’s models have the ones that I worked with anyway have a a parameter called
temperature Which is kind of an interesting name for the parameter. But you can set the temperature so that it’s so that its output is almost deterministic, right? So you can test that way But generally you don’t want to run that way because you want the LLM to be creative. That’s kind of why you’re using it.So it is a challenge. It’s a real challenge.
Jamie
Mike
Jamie
Mike
Jamie
‘Cause when I… okay, let me dial back a second. For what I’m about to say, I always describe to non-developers, non-engineers, non-software engineers, a computer program is just a finite state machine. You’re altering the the computer to be a different finite state machine based on what you want to achieve. Then when I get asked, “what does that mean?” I say, “you’re making a cup of coffee, right? What do you need to do?” The steps to make a cup of coffee is the finite state machine for making that cup of coffee. There are only so many steps you can get into.
If we’re at a point where people are already using AI top to bottom, all the way down, and probably using AI to write it. Personal opinion: maybe we’re on a trajectory towards not using human language-centric programming languages anymore. And that we might just be able to, at some point way off in the future, describe to the computer, “this is the ideal situation that I want you to solve this problem in. Here are the rules, here are the inputs and outputs you should expect. Go solve the problem for me.” And it goes away and does it, right?
Mike
So I actually I wanted to go back a little bit to the point about AI all the way down because there’s a word that we haven’t used yet that is getting used quite a bit. And that’s agents. I think more and more people want to think about these things as if they are agents, as if they are assistants, if you will, and you can just ask your agent to do something for you and it goes off and gets it done. And if your agent has to use some other agent in order to get that done, it can go do that. And You know, this is something that we’re working on. We’re working on making sure MCP can can let you do, whether it’s just having that AI model in the back end or calling other MCP servers from your MCP server. That’s something that’s that’s where we think things are going.
Jamie
Mike
Jamie
Jamie
Jamie
Mike
I’m got a trip to New York City coming up, and I’m landing in JFK, and I have a hotel in downtown Manhattan. And I needed to figure out how to get from the airport to the hotel. And I just asked ChatGPT. It told me, you know, “use this ground transportation, and then hop onto this subway and it’ll take you right there.”
Jamie
Mike
Jamie
Mike
Jamie
Mike
Jamie
But before you disappear, somebody’s been listening in and going, “I really like this sound of this OpenAPI stuff and what’s happening with ASP .NET Core with, like, validation and things like that.” Or they’re listening in going, “MCP sounds amazing. I want to get started with the MCP SDK C# and other three-letter acronyms.” How do they go about learning all of that? I know I’ve got some resources from you. I’ll put those in the show notes, but like is there anything that comes to mind immediately? “Hey, go learn this first.”
Mike
Go look at that set of MCP servers. You probably want to, you know, try out some of those. And then that will give you some inspiration. That’ll say, “oh, now I see what MCP can do for me. Now I want to go build something that does something specific to my use case.” Then you can go find the C# SDK and build yourself your own MCP server, which is something that you can just, as we talked about before, run locally on your machine and it’ll just do things just for you.
Or if it’s something that you think other people would benefit from, you could figure out how to Host it in Azure. Something that we didn’t talk about actually is that you can host MCP servers in Azure Functions, which is a pretty cool thing, because Azure Functions is a sort of a pay as you go. You only pay for the resources that you use so that you can host something out there, and then people can use it or not, and you’ll only get billed for what gets used. So those those would be my call to actions.
Jamie
Mike
And then the other place that is great for hearing about what’s going on at ASP .NET Core is the. NET Community Standup, which happens every Tuesday at 10am pacific time. I’ve been a a pretty regular guest on that, what do you call it, stream? And we talk about the things that are coming up in in ASP .NET Core, things that we’re talking about. Sometimes we just open it up for people to tell us, you know, what are you thinking? And we try to get feedback on where we need to take the the product going forward. So those are great places to find me.
Jamie
Maybe there should be an MCP server for The Modern .NET Show. And then people can ask, “what was that website that Mike recommended?”" Maybe that’s what I should… maybe that’s what I should do.
Mike
Jamie
Well I mean, like I said earlier on, I feel like I could talk to you all day but you’re very busy, so let’s get you back to doing the stuff that is important to you I have had an absolute blast talking to you today.
Mike
Jamie
Mike
Wrapping Up
Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest for graciously sharing their time, expertise, and knowledge.
Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at the podcast's website, and there will be a link directly to them in your podcatcher.
And don’t forget to spread the word, leave a rating or review on your podcatcher of choice—head over to dotnetcore.show/review for ways to do that—reach out via our contact page, or join our discord server at dotnetcore.show/discord—all of which are linked in the show notes.
But above all, I hope you have a fantastic rest of your day, and I hope that I’ll see you again, next time for more .NET goodness.
I will see you again real soon. See you later folks.
Useful Links
- OpenAPI
- API Blueprint
- RAML
- ProducesResponseType attribute
- Minimal API
- TypedResults
- S07E16 - From Code to Cloud in 15 Minutes: Jason Taylor’s Expert Insights And The Clean Architecture Template
- GitHub MCP Server
- MCP Transports
- MCP C# SDK
- Current version of the MCP spec as of the date of recording (aka version 2025-06-18)
- Microsoft MCP Servers List
- Mike on LinkedIn
- .NET Community Standup
- Supporting the show:
- Getting in touch:
- Podcast editing services provided by Matthew Bliss
- Music created by Mono Memory Music, licensed to RJJ Software for use in The Modern .NET Show
- Editing and post-production services for this episode were provided by MB Podcast Services