Transcript
Uh, having a good understanding of, of where MCP sits in the stack. I didn't know what it, what it stood for coming in. Hello and welcome to I owe you an explanation. I'm Dan. Hello and welcome back to I owe you an explanation. I'm Dan Cerulli, VP and general manager of cloud native at Nutanix. And if you've been following the AI explosion lately, you know, the input can be overwhelming. This podcast is here to help you process the noise with the people that are actually building the future. Joining me today is someone who spends her days making complex AI concepts feel like, you know, common sense, Laura Jordana, our principal technical marketing engineer who focuses on AI here at Nutanix. Laura, I've been looking forward to this episode for a long time because we are going to dive into the MCP. I want you to help us understand how this is going to change the way we use AI, talk to our models and talk to our data, Laura Jordana. Welcome to the show. Thanks, Dan. Thanks for having me. I'm really happy to have you here. Um, you focus on AI, uh, for people who don't know what, what the TMEs do, our technical marketing engineers. They take the technology that is built here at Nutanix and really figures out and they figure out how to, how it's going to work in the real world. So they get their hands on, get their hands dirty. Um, you work in AI, right? How long have you, how long have you been at Nutanix? How long have you been in AI? I've been at Nutanix about 14 years now. So started out in support, uh, way back when we were, you know, just hyper-converged, uh, running VMs and virtualization and VDI, and we've expanded out obviously, and, you know, now we're kind of on the other extreme with, with AI and Nutanix Enterprise AI. And so I've been focused on that, uh, for, for a couple of years now. And, and I'm actually dedicated now to AI for the past couple of months. So I'm really diving in. All AI, all the time, all AI, all the time. But before we get into that, we're going to do a segment. We call the before times, uh, the before times, uh, we like to, uh, take a technology that has really changed the way we live and work, uh, and talk about, explain to listeners who might not, might not have been around to remember what life was like. Uh, so today we're going to talk about before email became ubiquitous, before we all had email and that's the only way we corresponded. Tell me, you, you started working in your career before everything was via email. I assume. Yeah, definitely. I'm my first job in an office. I was an administrative assistant. We had email, but we still relied heavily on things like inter-office envelopes, you know, where you would put memos and things, so you would have this manila envelope with a bunch of names on it and, uh, you know, you cross out the last name and put someone else's name, maybe they're in another location and then you're the mail person would come and, you know, deliver appropriately. Um, and that's how we kind of distributed, you know, things that needed to be signed or, or all hands memos, um, that were coming from corporate. So, yeah, that was a, so, so just so people are clear on this, cause this was very common. Everybody with multiple offices did this, even small companies. Um, of course we had the U S mail, which, which would use to move up, I say a box from one building to another, which is still do, and even those they would probably still do, but you don't want 50 employees sending 50 individual letters. Right. So you had these inter-office envelopes. You would write, you just write the name, scribble Laura Jordana, you know, San Jose office. Right. And some courier would take that and either put it in a box and, and, and put it over here or put it in a box and mail that it would get here. There was a mail room, right? Right. People would sit in the mail room and would, uh, have to have to distribute and get a little cards and push them around like elf, like the movie elf, like the movie elf. That's right. That's right. Did you ever have a dance party in the, I did not. No, I don't think I ever went to the mail room being able to just email large attachments really changed. Oh yeah. Yeah. Yeah. And, and cloud storage and all that. Right. That was the before times now we're to the present. Um, and, and so you work in AI, uh, which in some ways I envy you. It is, it is really exciting what's happening there, but in some ways I don't envy you because it changes really quick, new things are coming out. Of course, new companies are launching and everything, but fundamental pieces of technology are, are, are coming out there from, from someone who sits at Jason. I see new words and I'll see a new word and I, you know, I won't know if it's important and then all of a sudden I realized six months later, oh my gosh, everything I see is about this. And that's one of the things I want to dive in and talk. Okay. Uh, just over a year ago, we started hearing these three letters, MCP all the time today. I want to get into what that is. Have you explained that to me and, and our listeners and, and then let's get into how it's changing the way we interact with it. Okay. Sound good. Yeah. All right. Let's start at the beginning. What's an MCP? Sounds good. So, uh, MCP stands for model context protocol. And so. As you said, a little over a year ago, um, Anthropic open-source this, this protocol that they were starting to use internally. Um, and so it was a way for them to kind of standardize the way your models and your data integrated, uh, to make AI agent building, um, more seamless, make, make it easy to discover what tools are available. Uh, what resources are available in a standard format. So you're not having really what they were solving was something called the, uh, N times M integration problem where for every LLM that they were using, right, uh, you know, within Anthropic, right, like Sonnet or Opus or whatever, uh, they're using, they had to build, um, potentially different integrations for different tools for each one. So that's what they were aiming to solve with, with MCP. Very interesting because we, we, in the last episode, we talked about a GRPC, which is a, a protocol for between services, um, with one of the, with one of the inventors actually. And what's interesting is they open-sourced it for a reason, right? They open-sourced it because they, they needed, they needed a better way to call and they didn't want a custom protocol. So here again, this protocol is an open source, but they did it for a reason. Right. And, and so the, the MCP sits between the model and the data, not between the user and the model, between the model and the data. So you gave examples. What are some of the models that, that they might've been using that people might use today? Uh, in terms of models. So like, it's like, if you're building a, an AI agent, right. You're just, you know, uh, working for an enterprise or you're building an AI agent and you want to use, you know, you're using open AI or using other model providers. Uh, you need to rewrite, right. Like how that model is talking to your different tools and your data underneath where, and that data might be stored in anywhere, right. Google, Google drive, uh, JIRA, Slack could be local, could be local, could be remote structured and unstructured. Yeah, for sure. Okay. So you got just file system. Yeah. Yeah. Yeah. So there's, people are writing, you know, MCP servers for, for everything. Um, so it's, it's like this big floodgate of, of MCP servers out there and, you know, figuring out which ones are people are actually using in the enterprise, especially, right. To figure out what's, what's kind of secure and validated, um, is, is something that's definitely, uh, is there an analogy in the Kubernetes world? We have CSI, which effectively is, is how the, the things running containers talk to the storage. Is this kind of an analogy, an analogous, uh, uh, layer of interface? It's a standard way to do it so that you don't have to have, have custom. Okay. Yeah, exactly. Yeah. So you don't have to be writing, uh, the, the custom code every time, right. When you're building an AI agent to talk to something like GitHub's come out with their own MCP servers. Uh, I think maybe Jira as well. And, and even at Nutanix, we're looking at building some for, you know, interacting with, with the infrastructure, uh, to integrate with those AI agents. So if GitHub has an MCP server, uh, that means I can now from my, my AI agent or, or, or an LLM, I assume either one, I can now essentially talk to get information about my GitHub, right? So if I want to do some analysis on, I don't know, my developers and, and, and who's being the most productive or whatever, um, that's what that enables. It gets access to that particular data. Yeah. Yeah. Whatever they're, whatever tools are offering. Um, so MCP servers, uh, what's, what's nice about them is that your, your LLM now, you're not worrying about what tools the MCP server is offering. Your LLM can actually go discover that themselves with this protocol. They can discover what tools that particular server has available. Then they figure out which ones they need to use. They'll make a call to that tool, you know, take that response, put that back in the context window, and then, you know, come up with that final, uh, you know, result back to the end user. Right. But the LLM is kind of going off on its own and figuring all that out. This is fantastic for me because I've never known exactly where MCPs sit. So you don't need to now, another thing we talked about on the previous episode was an open API specification and an open API specification, uh, you, you specify exactly how you're going to call a particular system, right? Like the, the API looks like this. Here are the resources, here are the verbs, here are the nouns. With MCP, because people can ask arbitrary natural language questions effectively, I assume you don't need to describe the data that's in there as well. Is that part of the, the, the part of what's built into an MCP is it can, it can inspect what's out there. Yeah. So the, the MCP is what's abstracting all that logic, right? So all those API calls, it knows like what, how to talk to a specific tool, right, and what the API, what version it works with, and then, so you have a different MCP servers based on different versions of whatever, you know, product or tool you're using. And you can just, you know, be sure you'll know, you'll get that answer back. And in fact, it might be using an open API or a GRP API, actually to call it, it doesn't care. And that's the point because whatever's sitting on top, the model, whatever that's calling that, that MCP server. Okay. Uh, that's really useful. Um, are in general, are people who own data, you mentioned GitHub, uh, are they, are they writing these as fast as they can? Are they, are they really trying to say, Hey, we'll publish MCP servers for our, for our data. So that their data is useful in these. Yeah. It seems, yeah, it seems to be the case. And, and, you know, I've seen a lot of debate online about, you know, whether MCP servers are useful or not. You know, why can't you just use CLI to do, to do certain things. But, um, it, it seems like, uh, the implementation is an important piece of it too. Right. So like, uh, you want to make sure when you're, you're leveraging an MCP server in your application that it's, it's kind of doing the right things and it's, you know, not, not falling over and, um, you're using some enterprise grade platform to manage it. Right. I assume you could, you could have real performance problems here. Yeah. Yeah. So the protocol itself is, is a great idea, like standardizing, but just, you know, we have to see how the implementation. I, again, I, it's, it's interesting, the analogies to, to, uh, to APIs are, are really strong. Uh, partly the APIs, by the way, open API spec is not a specification for a protocol, right? It's, it's just the, it's just describing the surface. gRPC actually is both protocol. Um, but. Which MCP actually uses JSON RPC. Uh, oh, it does. Yeah. Yeah. Underneath. So transport. So, uh, yeah, the interesting thing is that of course anyone can implement it, but there can be bad implementation. You might have an API proxy that is really, really not performant. And if you have an application, if you, you know, you're calling that in your win for user responses, I assume we're seeing the same thing for MCP servers that implementation is key. That's going to be key. Are they exposing the data properly? Does it perform properly? Um, and does it perform properly under load? Right. Yeah. And under load is going to be a really big deal because you mentioned agents. Like as a user, I might ask one question. Yeah. That might result in a, you don't want to wait an hour to get that result back. So, so for APIs, it, it, there's often a caching layer that, that can, can store data to improve performance. Is there the same concept in MCPs? Yeah, that's a, that's a good question. Um, let me just take a quick look. This is literally AI is going to answer this question right now. It's AI overview. Yes. Yeah. It's caching layers or critical component in MCP server design. I can see. So you don't hammer that database with them. Yeah, that, that is awesome. Love the AI overview. In general, when someone is running an MCP server, are they running that themselves, for example, GitHub, and maybe, you know, about GitHub, GitHub, maybe you don't, are they running an MCP server? So people who are using GitHub in the cloud can just hit that MCP server or people like running their own MCP server? I think we're seeing both. So there are some remote MCP servers, um, out there like GitHub, I believe has one. I know Hugging Face and Postman and some others do as well. Um, but I, I know a lot, especially, uh, in the enterprise, a lot of customers are going to want to bring those on-prem. Maybe those, those, uh, MCP servers that these companies have built, but run them locally for security reasons, or, or, you know, they don't want to send their data out, um, to the cloud. So I think there's a case for both. For sure. So if I have data in my enterprise, in my data center, might be databases, might be unstructured, might be files, might be whatever, but we want to build applications, you know, say a support database, for example, right? We want to build AI, AI enabled applications that allow people to allow interrogation of the data sitting in that database. Now I'm going to, I'm going to maybe have to write, depending on if I, if I wrote this database or not, have to write an MCP server that I host so that I can. Okay. Yeah. Or depending on the database, there might be MCP server for that database already. Right. And you could pull that in, connect it to your database and then. Right. If it's a standard Oracle or a SQL server or a MySQL database. Yeah. You can have something that's going to talk to that, probably using literally things like table names and column names to get the context. Right. Right. Like I can bet if there's a table called customers, that's where I'm going to go look for customers. That is fascinating. And, and at Nutanix, you know, we have teams that are building things like to run, literally run those, right. You want to run your MCP server. Uh, NAI will, will, will. Yeah. Yeah. So, so yeah. So NAI will offer the ability right now to connect to low, uh, to remote MCP servers and then in a future release, bring that on-premise as well. So bring that inside. Yeah. Either way. Exactly. Okay. That's pretty useful. What questions am I not asking about MCP servers that I should be? Um, I think you covered them. I think I covered them pretty well. Uh, and you can write them in any language you want to write. It's, it's just a definition of a protocol. So as long as you're obeying that protocol. I've seen them in Go, Python. I'm sure others as well. Oh, interesting. Yeah. That's it. That, I mean, just those two languages alone, it's kind of interesting. Right. Gives you a hint as to who's writing those. Yeah. Right. Yeah. Exactly. It does. This for me is long overdue. Uh, having a good understanding of, of where MCP sits in the stack. I didn't know what it, what it stood for coming in, but, but it is, but it is really interesting to see where it sits in the stack, see where it'll go. I really love the analogies to how this relates to API, um, management and, and having a defined way that you're going to talk to these things. Yeah. And I was watching a YouTube video of the guy who founded it at Anthropic. Um, and they were saying like, oh, you know, the name's not very creative or good, but it explains exactly what it is. It's giving the model context, right? So you standardize the way the model can get context, uh, the way that it's ingesting data, right? That's all it's doing. It's ingesting tokens. Um, and so I, I think it's a perfectly fine name because it's understandable. It explains what it is. And I always think it is, it is fascinating when people do standardize a, a protocol like this, because again, they, they're not, they didn't have a commercial product, but they did this to enable business that they want to do and enable, you know, what they know is, you know, I was going to say hundreds, but millions of use cases of actively, right? Like now there's a standard integration, which did nothing other than accelerate the pace at which AI is, is that now all of a sudden there's a standard way to connect, make it easier to build these agents and connect. Yeah. It'll really accelerate it. And, and it is, it is crazy how quickly it took you, how, you know, that tells you, it was really badly needed. All right. Thank you. That helps me tremendously. Uh, all right, now we're going to move on to week. We close with a hot take, cold take. Uh, I'm going to, I'm going to say something out loud and you decide, you know, do you think that's great? Do you think no, do you think somewhere in between? And the take I have AI is coming from my job. For your job, maybe your job. No, no, I'm just joking. I think we have a long way to go before it takes over everybody's jobs right now. It's, it's, uh, the kind of low level automated tasks that can be done, you know, menial tasks, we've already seen some of that with automation, like that, that maybe is a little bit at risk, but there's still, I think there's still a long way to go with it. So I guess I give that a medium take. Medium take. Yeah. I'm kind of cold on that. I think that, um, Every time, you know, I'm, I've, I've been in this industry longer than you, every time we see one of these technologies come and we predict, oh, it's going to, it's going to take everybody's job where all the mail couriers go, well, it's true. It changed a lot of jobs, right? No one has to carry those envelopes around anymore, but it's, it's not like, uh, they didn't net create jobs. And so, you know, individual jobs are going to change, but I think that we will find as usual. What's going to happen is we're gonna find more and more ways to use people and people are going to be more productive than ever before. So that's true. There's, there's still mailmen out there. So that's true. Like I, I'm, I definitely am down on AI is going to take all the jobs. I think that just your job. Me mine. Maybe. I'm just kidding. Well, thank you very much, Laura. I think we all have a much cleaner idea of what MCP is now. And we will be releasing episodes every month on YouTube, everywhere you get your podcasts. Please do like, and subscribe. And we will see you here next time that you need an explanation.
