Model Context Protocol (MCP), clearly explained

I’m joined by Ras Mic to explain MCPs. Mic breaks down how MCPs essentially standardize how LLMs connect with external tools and services. While LLMs alone can only predict text, connecting them to tools makes them more capable, but this integration has been cumbersome. MCPs create a unified layer that translates between LLMs and services, making it easier to build more powerful AI assistants. Timestamps: 00:00 - Intro 02:39 - The Evolution of LLMs: From Text Prediction to Tool Use 07:51 - MCPs explained 11:11 - MCP Ecosystem Overview 13:59 - Technical Challenges of MCP 15:18 - Conclusion on MCP's Potential 16:00 - Startup Ideas for Developers and Non-Technical Users Key Points: • MCP (Model Context Protocol) is a standard that creates a unified layer between LLMs and external services/tools • LLMs by themselves are limited to text prediction and cannot perform meaningful tasks without tools • MCP solves the problem of connecting multiple tools to LLMs by creating a standardized communication protocol • The MCP ecosystem consists of clients (like Tempo, Windsurf, Cursor), the protocol, servers, and services 1) What are MCPs and why should you care? MCPs are NOT some complex physics theory - they're simply STANDARDS that help LLMs connect to external tools and services. Think of them as universal translators between AI models and the tools they need to be truly useful. This is HUGE for making AI assistants actually capable! 2) The Evolution of LLMs: From Text Prediction to Tool Use Stage 1: Basic LLMs can only predict text • Ask ChatGPT to send an email? "Sorry, I can't do that" • They're glorified text predictors (if I say "My big fat Greek..." it knows "wedding" comes next) • Limited to answering questions, not DOING things 3) The Current State: LLMs + Tools Stage 2: LLMs connected to tools • Companies like Perplexity connect LLMs to search engines • This makes them more useful but creates problems • Each tool = different "language" the LLM must learn • Connecting multiple tools = engineering NIGHTMARE This is why we don't have Jarvis-level assistants yet! 4) Enter MCPs: The Game-Changer MCPs create a UNIFIED LAYER between LLMs and external services. Instead of your AI speaking 10 different "languages" to use 10 different tools, MCPs translate everything into ONE language. Result? LLMs can easily access databases, APIs, and services without massive engineering headaches. 5) The MCP Ecosystem Explained The MCP system has 4 key components: • MCP Client: User-facing apps like @tempoai, Windsurf, Cursor • Protocol: The standardized communication method • MCP Server: Translates between client and services • Service: The actual tool (database, search engine, etc.) Brilliant move by Anthropic: SERVICES must build MCP servers! 6) Why This Matters For Builders For technical folks: • Opportunity to build tools like MCP app stores • Easier integration between services • Less engineering headaches For non-technical folks: • Watch closely as standards evolve • When standards finalize, new business opportunities will emerge • Think of MCPs as Lego pieces you'll stack to build powerful AI apps Notable Quotes: "LLMs by themselves are incapable of doing anything meaningful... The only thing an LLM in its current state is good at is predicting the next text." - Ross Mike "Think of every tool that I have to connect to make my LLM valuable as a different language... MCP, you can consider it to be a layer between your LLM and the services and the tools." - Ross Mike LCA helps Fortune 500s and fast-growing startups build their future - from Warner Music to Fortnite to Dropbox. We turn 'what if' into reality with AI, apps, and next-gen products https://latecheckout.agency/ BoringAds — ads agency that will build you profitable ad campaigns http://boringads.com/ BoringMarketing — SEO agency and tools to get your organic customers http://boringmarketing.com/ Startup Empire — a membership for builders who want to build cash-flowing businesses https://www.startupempire.co FIND ME ON SOCIAL X/Twitter: https://twitter.com/gregisenberg Instagram: https://instagram.com/gregisenberg/ LinkedIn: https://www.linkedin.com/in/gisenberg/ FIND MIC ON SOCIAL X/Twitter: https://x.com/rasmickyy Youtube: https://www.youtube.com/@rasmic

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Greg Isenberg?

  Everyone is talking about MCPs. It's gone completely viral. But the reality is, most people have no idea what MCPs are and what they mean, and what are the startup opportunities associated with it. So in this episode, I brought Professor Ross Mike, who is probably the best explainer of technical concepts in a really easy way, that someone who's non-technical can really understand. I brought him on. He explains it beautifully in such a short amount of time. And if you stick to the end, you'll hear a couple of his startup ideas that incorporate MCPs. So enjoy the episode and see you soon.

• 0:51Greg Isenberg?

  All right, well, we got Professor Ross Mike on the pod. And the reason why we have him is because I don't know what the hell MCPs are. And I've been seeing it on X. And I need a succinct, clear Professor Ross Mike explanation. Yes, I've read a bunch of threads on it and I've seen a couple of videos on it, but there's nothing like a Ross Mike explanation. So I'm here for the what do I need to know about MCPs? And that's why you're here. Thank you for coming on.

• 1:28Speaker 01

  I appreciate that. Thank you very much. Yeah, class is definitely in session. I'll just start sharing my screen. Okay, so understanding MCP is really important. But you'll also realize the benefits and why it's sort of a big deal, but not really at the same time. You see, one of the things in programming land that we have and that programmers love are standards. And the reason why standards are important is they allow for us engineers to build systems that communicate with each other. The most popular one that, you know, you might have heard of or you might not, and you don't really need to know the details, is REST, REST APIs.

• 2:13Speaker 01

  And they're basically a standard that every company follows when they construct their APIs, when they construct their services for me as an engineer to be able to connect with them. Now, understanding that engineering is all about standards and having these formalities we follow to make life easier. When we think of, in the context of an LLM, I want you to understand this one important thing. LLMs by themselves are incapable of doing anything meaningful. What do I mean by that? If you remember the first, you know, ChatGPT 3, or was it 3.5, I'm not sure. But if you just open any chatbot and you tell it to send you an email, it won't know how to do that.

• 2:57Speaker 01

  It will just tell you, hey, I can't send you an email. The most you can do with an LLM is ask it questions, uh, maybe ask it to tell you about some historical figure, whatever it may be, right? Um, LLMs are truly incapable of doing anything, uh, meaningful. And what I mean by meaningful, it'd be nice if, you know, it could send me an email, um, if it could, um, do some specific task on my behalf. But the only thing an LLM in its current state is good at is predicting the next text, right? So for example, if I say, my big fat Greek, an LLM with all the data it sourced, with all its training material, will determine that the next word is wedding, right?

• 3:40Speaker 01

  So this is the most an LLM by itself that it could do, right? The next evolution was developers figured out how to take L L Ms and combine them with tools. And you can think of a tool like an A P I, for example. Most of us are where where chat G V T and these other chatbots are able to search the Internet. For example, perplexity, right? Perplexity gives you the option to chat with an L L M. But that L L M has the ability to fetch information from the Internet and present that to you. The L L M itself is not capable of doing that. But what they've done is they've constructed a tool.

• 4:22Speaker 01

  They've given the L L M access to an external service, right? And there's plenty of these services, right? I think there's Brave Search, Chat, Open A I offers an A P I now. So L L Ms have started to become a bit more powerful when we connected tools to them, right? I can give you an example. Let's say, um, let's say every time I get an email, I want there to be an entry in a spreadsheet. Now, most of you know there are services like Zapier, N N A, or you know, any of those automation services. If I build out an automation and connect that to my L L M, it just became a bit more meaningful.

• 5:05Speaker 01

  Now, that's awesome and cool, but it gets really frustrating when you want to build an assistant that does multiple things. Imagine search the Internet, read your emails, summarize this. You start to become someone who glues a bunch of different tools to these L L Ms. And it can get very frustrating, very cumbersome. If you're wondering why we don't have an Iron Man level Jarvis assistant is because combining these tools, making it work with the L L M is one thing. But then stacking these tools on top of each other, making it cohesive, making it work together, is a nightmare itself. And this is where we're currently at. And this, before I continue, does this make sense?

• 5:50Speaker 01

  This is where we started, LLMs by themselves, write me a poem. Um, you know, tell me about World War I. Um, and then the second evolution is, oh, we now have tools, right? We now have, um, these things, these external services that we can connect to our LLM. The problem here is they're difficult. It's annoying. And as someone who works at an AI startup, Tempo, and we have a lot of tools, like, for example, we do a search. Um, you have to find an external service. You have to connect it to the LLM. And you have to make sure the LLM doesn't hallucinate or do something stupid. And believe it or not, as cool as LLMs are by themselves, they're very, very dumb.

• 6:35Speaker 01

  Um, but these tools make them just a bit more capable. So this is where we're at. Uh, Greg, we good so far?

• 6:45Greg Isenberg?

  It's crystal clear. I'm loving this.

• 6:47Speaker 01

  Beautiful.

• 6:49Greg Isenberg?

  Quick break in the pod to tell you a little bit about Startup Empire. So Startup Empire is my private membership, where it's a bunch of people like me, like you, who want to build out their startup ideas. Uh, now they're looking for content to help accelerate that. They're looking for potential co-founders. They're looking for, uh, tutorials from people like me to come in and tell them, how do you do email marketing? How do you build an audience? How do you go viral on Twitter? All these different things. That's exactly what Startup Empire is. And it's for people who want to start a startup but are looking for ideas. Or it's for people who have a startup, but just they're not seeing the traction, uh, that they need.

• 7:34Greg Isenberg?

  So you can check out the link to startupempire.co in the description.

• 7:39Speaker 01

  Now, Inters MCP. And what does MCP mean? I think the simplest way, right? Without getting too technical, because I've read the threads too. And as a technical person, I appreciate it. But for the non-techy, I can assume it's frustrating. Think of it this way. Think of every tool that I have to connect to make my LLM valuable as a different language. So Tool 1 is English, Tool 2 is Spanish, Tool 3 is Japanese, right? And imagine every tool, it's its own language. And it's not that there isn't a standard for how APIs work, but every service provider constructs their APIs differently. There's different information you have to pass.

• 8:21Speaker 01

  There's just various degree of, of, of, of things that you have to set up that, again, it just feels like gluing a bunch of different things together. Will it work? Yes, but at scale, it gets very difficult. MCP, you can consider it to be a layer between your LLM and the services and the tools. And this layer translates all those different languages into a unified language that makes complete sense to the LLM. Right? So it's the evolution of LLM plus tools. But in this evolution, it just makes, it makes it very simple

• 9:02Speaker 01

  for the LLM to connect and to access different outside resources, right? Because that's what tools are at the end of the day. So with MCP, I'm able to connect to an outside data source, an outside database, maybe a tool like Convex or Superbase, right? Imagine, I just tell the LLM, you know what? Create me a new entry in my database. And it's connected to my database via MCP, and it knows exactly what to do and how to do. In the second evolution, LLMs and tools, there's a lot of manual work that goes on. There's a lot of step-by-step planning that you have to do. And there's a lot of edge cases where it can fail.

• 9:46Speaker 01

  And this is why, again, none of us, as exciting as the spaces, none of us have a Jarvis-level assistant yet. It feels like we're there and we're close, but this system makes it so that it's very difficult. And what's frustrating is this. Imagine, let me think of a simple service, a simple, like, you know, tool. Imagine, um, every time a Slack message comes, your LLM reads that Slack message and it shoots you a text, right? Sounds pretty trivial. Here's the frustrating part. Imagine Slack updates their API, or the text service updates, makes a change.

• 10:24Speaker 01

  And let's say that service is connected to other services, or you have some sort of, like, automation step-by-step thing that you've planned. It becomes a nightmare. It becomes terrifying. And this is why, even in the age of LLMs, good engineers will still get paid, because stuff like this, like this exists. But what MCP does, it unifies the LLM and the service, right? It creates this, this, uh, layer where the service and the LLM can communicate efficiently. Now, let's get into some practicality. You can think of the MCP ecosystem as follows.

• 11:07Speaker 01

  You have an MCP client, you have the protocol, you have an MCP server, and you have a service, right? An MCP client is something like Tempo, Windsurf, Cursor. And they are basically the client-facing side, the LLM-facing side of this ecosystem. The protocol, again, is that two-way connection between the client and the server.

• 11:35Speaker 01

  And the server is what translates translates that external service, its capabilities, and what it can do to the client. And that's why between the MCP client and the MCP server, there's a MCP protocol. But here's the fascinating part, and this is why I think Anthropic, they were playing 3D chess when they built this, is the way this is architected, the MCP server is now in the hands of the service provider. So if, let's say, me and Greg run a dev tool company, right? Where maybe we're doing a database, right? Like, we're like, listen, we're gonna build the best database company in the world, and we want people's LLMs to have access to this database.

• 12:20Speaker 01

  It is now on us to construct this MCP server so that the client can fully access this. So Anthropic in a way sort of said, listen, we want our LLMs to be more powerful, more capable, uh, but it's your job to figure this out. And this is why you've noticed all the external service providers are now building different MCP servers, they're building out repos and all this stuff, right? So this is a big deal in a sense where LLMs are going to be more capable. But from a technological perspective, all they did was create a standard, a standard that it seems like all companies and all engineers are going to agree upon. Because you can construct any system, any API, however you please.

• 13:06Speaker 01

  The problem is, if you want to scale, you want to grow, you want other developers, other businesses to connect and work with your service, it has to be in a fashion that makes sense for them. Imagine if all of us just spoke different languages, but standards allow us to communicate in a way that makes sense to all of us. And MCP is that for LLMs. Because LLMs by themselves... are not that capable. They're just, they're, they're, they're, they're systems that have great predictability and they know how to predict the next word. But when you can, when you add this MCP protocol as a whole, you now have a way for it to be capable of doing important stuff. Now, understanding all this, it's not all sunshine and rainbows.

• 13:51Speaker 01

  There are some technical challenges. If you notice, if anyone has set up an MCP um server on any of their favorite MCP clients, it's annoying. Um, there's a lot of downloading. You have to move this file. You have to copy this, that and the third. Um, and it's a lot of local stuff. There are some kinks that have to be figured out. Uh, but once this is figured out or finalized, polished, or maybe they update the standard, or maybe someone comes up with a better one. We start to enter a world where LLMs start to become more capable. And that is literally all what MCP is. Just making LLMs more capable. We're trying, we're doing that with tools right now. It's kind of working. Um,

• 14:34Speaker 01

  but MCP seems to be the next evolution. I think Greg, I saw your latest video. Um, Manus, Manus is a great example of number two. They have tons of tools. And kudos to them. They've engineered, engineered it it well in a way where, you know, they will, they work well cohesively. I didn't get to try it out, so I'm just looking at what people have done. But I can tell you this, it's a lot of engineering hours. It's a lot of, one change happens, something broke, someone's on call and not sleeping. But with MCP, um, it's structured in a way where um, if we all follow this um, standard, um, the LLM will have access to everything it needs.

• 15:18Speaker 01

  Um, and we will all be happy users. So in short, that is literally all what MCP is. It's not um Einstein's fifth law of physics or anything crazy like that. It's literally a standard for LLMs. And it's exciting. It's something to be excited about. Um, and yeah, I hope, I hope that clarified. I just kept rambling, so I apologize for that, Greg.

• 15:38Greg Isenberg?

  No, this is, this is exactly what I wanted. I want to end on one question for you. So this is now clear to me, crystal clear to me. What MCPs are. But my question is, well, before I even ask my question, every time there's been a popularized protocol, for example, HTTPS or SMTP, examples like that, there's been a lot of big businesses that were created on top of it. And there's been basically this like, why now? You know, why this just opening of opportunities?

• 16:14Speaker 01

  Yeah.

• 16:15Greg Isenberg?

  The average person listening to this podcast is building out their ideas. Is this, does this matter or at all for that person?

• 16:26Speaker 01

  Yeah, I think that's a great question. I think if I were, so I'll speak to the technical and the not technical. To the technical, there's a lot of things that a technical person can do here. I just don't have time, Greg, but one thing I was thinking of was like an MCP app store. And I'll just give this idea out for free because this podcast is all about ideas. Basically, there's a lot of these repos out there of MCP servers. And it'd be cool if someone can go on a site, I even bought the domain. It does nothing. But again, please, anybody like steal this idea. I bought the domain and it'd be cool if someone could go on, like, look at the different MCP servers there. They see the

• 17:09Speaker 01

  GitHub code and whatever, and they can click like install or deploy. And that server's deployed and gives them a specific URL, and then they can paste that in an MCP client and work that out. So for the technical person, if you make millions, all I ask is just, you know, send me a thousand dollars. But for the non-technical person, what I would really focus on is I would just stay up to date with the platforms that are building out MCP capability and just see where the standards are going, right? Because like you said, when the standards are finalized, I don't know if MCP has fully won. I think it needs to be challenged, or I don't know if Anthropic is going to make an update.

• 17:49Speaker 01

  We don't know. It's very early, but I would say keep very close attention to what the final standard is going to be because once that standard is finalized and all these service providers start to like, you know, build out their MCP or whatever thing it is, you can now start to integrate much seamlessly and much easier, right? This is why, again, every week there's a new chatbot interface with new tools and it wins because this part, step number two, is not easy, right? Especially making it cohesive and making it work fast, right? Like I can sit in two hours and build something like this, but building out that user experience, making it flawless, limiting the hallucinations, it's very, very hard.

• 18:35Speaker 01

  I mean, this is a lot of the work we do at Tempo, but this makes it so that integrating is a lot easier and you can think of these as like Lego pieces that you can continue to stack to stack. So for my smart and wise business owners, startup ideas, podcast enjoyers, I would really just keep a close attention, right? I think even for myself, I don't think with this MCP stuff, we're at a place where any shots can be fired that make any smart business decision, but this is one of those things where you just, you sit and you watch and you're just observing and learning. And when the right thing at the right time happens, you strike.

• 19:19Speaker 01

  So I don't see any crazy business opportunities right now for a non-technical person, even for a technical person, like imagine if OpenAI comes with a standard tomorrow and we all just shift to that, right? It's very early stages, but I think understanding how this works means you understand how the next thing works and when that becomes finalized, you hit the ground running.

• 19:41Greg Isenberg?

  Amen. All right. Ross Mike, Professor Ross Mike, there's no one like you. We'll include in the show notes where you can follow him for more really clear explanations around this whole AI coding world. And dude, I'll see you in Miami in a few weeks.

• 20:00Speaker 01

  Yeah, man, I appreciate you. I'm booking my flight soon. So yeah, definitely, bro. I'll see you soon. Thank you, buddy.

• 20:10Speaker 02

  It's break ice and burn.

• 20:14Speaker 02

  It's slipping time, baby.