🤝 The Model Context Protocol: Unifying AI Communication
28:32 Share

Hello, everyone, and welcome to a very special episode of AI Unraveled.

This is The Deep Dive, created and produced by Etienne Newman, Senior Engineer, and we hear a passionate soccer dad up in Canada. That's right. And before we jump in, just a quick reminder to please like and subscribe to AI Unraveled wherever you get your podcasts. It really helps us out. Absolutely. So today we are diving deep, really deep, into a concept that's, well, quietly changing everything in how AI interacts with the real world. We're talking about the Model Context Protocol.

or mcp it's a big one it really is imagine this you're at a huge global conference right brilliant people everywhere ready to share amazing ideas but everyone's speaking a different language total chaos yeah incredibly frustrating well that's pretty much the situation our ai models have been stuck in they're incredibly smart incredibly capable but kind of trapped in their own digital bubbles you know struggling to connect with other ais or even just like

basic external data sources. And that's where MCP comes in. It's this revolutionary open standard designed specifically to tear down those walls, to enable real connectivity for AI. People are calling it the USBC for AI. That's a great analogy, actually. Our mission today.

To break down exactly what MCP is, why it's such a game changer, and how it's literally shaping the future of AI as we speak, we've got some really fascinating source material to work with. And it really starts with addressing that core problem. You mentioned AI exhalation. You know, these large language models, LLMs, for all their incredible power, they've basically been operating like...

Well, like brains in a vat. Right. Powerful but disconnected. Exactly. They can reason brilliantly based on the data they were trained on, but they're cut off from real-time information. Think about your company's CRM, your customer relationship management system, or even just a local database on your machine. Yeah, if it can't see the latest data, it can't give you the latest answers. Precisely. And what's fascinating, or maybe frustrating, is how this isolation severely cripples their potential for practical day-to-day applications.

An AI assistant can't summarize the latest sales report if it has zero access to the sales system. So it needs a way to plug in. It needs a standard way to plug in. This leads to what the source material calls the NEC-M integration problem. You've got N, a growing number of different AI models, and countless external tools, APIs, databases. Okay. N times M. Without a common standard, connecting every single one of those N models to every single one of those M tools...

needs its own custom point-to-point integration. It's a nightmare. It's a combinatorial explosion, as they say. That's the term. It creates this massive amount of redundant development work, a huge maintenance burden, fragmented implementations everywhere. It's just not scalable. So MCP steps in to solve this massive headache. Exactly. MCP isn't just another standard. It's fundamentally a bottleneck breaker. It takes that exponential integration nightmare and turns it into a much simpler linear connection model.

Connect your tool to MCP once and potentially any MCP enabled AI can use it. Connect your AI to MCP once and it can potentially access any MCP enabled tool. That makes AI integration actually feasible, economically speaking. For the first time, really. And, you know, for anyone listening who's navigating this fast moving AI world, understanding these foundational protocols like MCP, well, it isn't just helpful. It's becoming essential if you want to boost your career. Good point.

And for those of you looking to really solidify that expertise, maybe get certified, whether that's for Azure, Google Cloud or AWS, our producer, Etkin Newman, has put together some incredible AI certification prep books. Oh, yeah. Yeah. Things like the Azure AI Engineer Associate Guide, the Google Cloud Generative AI Leader Certification Prep, EWS Certified AI Practitioner Study Guide, Azure AI Fundamentals, even the Google Machine Learning Certification. Really comprehensive stuff. Where can people find those?

You can find all of them over at DJAmgatech.com. DJAmgatech.com. We'll make sure the links are in the show notes for you. Perfect. Okay. So we understand the why, this massive integration problem, but...

How does MCP actually work? Let's unpack the architecture. It sounds complex, but the sources say it's surprisingly elegant. It is, yeah. It really boiled down to three main components working together. Okay, component one. First up, you've got the MCP client. Think of this as the messenger. It lives within the AI application or agent. Its job is to understand what the AI needs,

formulate a request, and then go out, fetch the data or execute the action, and bring the result back to the AI. So like if I'm using a coding assistant in my IBE, that assistant is using an MCP client behind the scenes. Exactly. That client might be talking to a local MCP server to access your files, or maybe a remote one for something like GitHub information, all happening silently to help you code. Got it. Client is the messenger. What's next? Next is the MCP server. This is really the translator.

The absolute heart of the protocol. This is the component that exposes the tools and data sources to the AI world. The universal translator, you said? Precisely. It receives those structured requests from an MCP client, figures out how to talk to the specific underlying data source. Maybe it's a database query. Maybe an API call gets the information and then sends it back to the client in that standardized MCP format. Okay. Client makes the request, server translates and fetches.

And the third piece. That's the local source, or you could call it the data vault. This is simply the actual data repository or tool that the MCP server is providing access to. It could be your company's sales database, a specific business application like Salesforce, your local development environment, anything really. Right. The actual information source. Yeah. And it's the strong standardized connection between these three things.

client-server source that forms a complete chain, linking the AI agent to the external world. Let's make that concrete. The sources use a sales report example. How would that play out step by step? Okay, great example. Let's say your manager asks the AI assistant, show me the top five best-selling products from last month.

Simple enough request? For the user, yes. Here's the MCP flow. One, the MCP client inside the assistant interprets that natural language query and formulates a formal structured MCP request. Think of it like an office secretary drafting a precise memo. Okay, memo drafted. Two, that memo goes to the MCP server that's connected to the sales system.

The server reads the memo, understands it needs sales data, and translates it into the specific query the sales database understands. Server talks to the database. Three, the local source of the sales database executes the query and pulls out the raw transaction details, maybe a whole list of sales.

like a records clerk retrieving a big stack of files. Got the raw data, now what? Four, the raw data goes back to the MCP server. The server doesn't just dump it back, it processes it. It sorts the sales, identifies the top five products, and arranges that information neatly, maybe in a JSON format the client expects.

It's like converting messy spreadsheet data into a clear chart. Ah, so it cleans it up. Exactly. And five, the MCP client receives this refined, organized data from the server and passes it back to the AI model.

the AI then uses this clean data to generate that nice, clear summary for the manager. Wow, okay. Compared to building custom API calls and data parsers for every single request type, that sounds incredibly streamlined. It is. What really stands out is how seamlessly it orchestrates that whole process.

abstracting away the complexity for both the AI developer and the tool provider. And what's really wild is how fast this all happened. MCP wasn't around forever, right? Not at all. Its journey from just an idea to becoming an indispensable standard was remarkably swift.

It was introduced and immediately open sourced by Anthropic back in November 2024. Open source from day one. That seems key. Absolutely. It was a very deliberate move. Unlike, say, OpenAI's earlier function calling API, which was powerful but vendor specific, Anthropic positioned MCP as a neutral open source project right from the start. Which builds trust, encourages others to jump in. Exactly. It fostered that trust.

and drove really broad, rapid adoption across the industry, even among competitors. Let's talk about that timeline. It sounds pretty compressed. It really is striking. So November 2024, Anthropic launches it. They provide SDKs, software development kits, and some initial reference server implementations for common tools like Google Drive, Slack, GitHub.

Key early adopters like Block, Replit, Sourcegraph, Zed jump on board immediately. OK, strong start. Then the big one, March 2025. OpenAI, arguably Anthropic's main competitor, announces they're adopting MCP. They integrate it across the ChatGPT desktop app, their agents SDK, their responses API. Sam Waltman himself called it a crucial step.

Wow. OpenAI adopting a standard from Anthropic, that's significant. Hugely significant. It basically cemented MCP's position. Then just a month later, April 2025, Google DeepMind endorses it for their Gemini models. Demis Hassabis stated it was rapidly becoming an open standard. Okay. So Anthropic, OpenAI, Google, the big players are all in. Within months. And by May 2025, the ecosystem just exploded.

The source mentions over 5,000 public MCP servers listed on Glamour, which has become sort of the central directory for finding these MCP-enabled tools and services. 5,000 servers in roughly six months. That's incredible growth. It really speaks to the power of that open collaborative ecosystem. You know, the fact that it's open source prevents vendor lock-in. Developers aren't tied to one LOM provider or one set of tools.

They have flexibility. And there's official support too, right? Like a GitHub organization? Yes. The official model context protocol GitHub organization is the central hub. Anthropic still manages it, but it's open for community contributions. That's where you find the spec, the multi-language SDKs, TypeScript, Python, Java, C-sharp, Go, Kotlin. So tools for everyone. Pretty much.

And crucially, they also provide the MCP inspector. This is a visual testing tool, absolutely indispensable for developers building MCP servers. It lets them test and debug their implementation without needing a full AI client application. Speeds things up massively. That makes sense. You know, the source drives a really good analogy here. MCP is like foundational infrastructure.

It's similar to how the Language Server Protocol, or LSP. Ah, LSP, yeah. That revolutionized code editor. Exactly. LSP decoupled language intelligence, like auto-completion or error checking from the specific editor. MCP does something similar for AI agents.

It decouples the agent's reasoning capabilities from the specific tools it uses. Okay, so let's get a bit more technical then. If it's this universal language, what's it actually built on? How do these messages fly back and forth? Under the hood, MCP is built on a well-established standard called JSON-RPC 2.0. JSON-RPC. Okay, what's that?

Think of it as a very lightweight, simple way for systems to make remote procedure calls, basically, to ask another system to run a function using JSON, which is just human readable text. It's stateless, text-based, really efficient. So it's not some brand new complicated transport layer. It uses existing stuff. Right. It builds on proven technology. And the communication within MCP follows a clear structure. You've got three main message types. First, requests.

These are messages that ask for something to be done, like tools list to ask a server what tools it offers. They always have a unique id so the client can match the response later. And they can go both ways, client to server or server to client. Got it. Requests need an answer. Exactly. Which brings us to...

Responses. These are the replies to requests. They carry the same ID as the request they're answering, and they contain either the result of the operation or an error if something went wrong. Makes sense. Request, response. What's the third? Notifications. These are one-way messages. Just sending information without expecting a reply. Think status updates like processing your request or maybe the server notifying the client that a file has changed. They don't have an ID. Okay. Requests, responses, notifications. Simple enough. And

How does the connection itself work? Do they just start chatting? No, there's a proper lifecycle. It starts with an initialization phase, a handshake, where the client and server exchange capabilities and agree on the protocol version. Then they enter the operation phase where they actually exchange all those requests, responses, and notifications.

And finally, there's a defined shutdown process to close the connection cleanly. And how do they physically connect over the network? It supports two main ways. For local integrations, like that IDE example where the tool might be running on your own machine, it often uses Stadio standard impute output.

Basically, the server runs as a child process and they communicate directly. Okay, local connection. For remote connections, like talking to a server hosted elsewhere, it uses streamable HTTP, often with server-sent events, or SSE. This allows for efficient, real-time, bi-directional communication over standard web protocols. Right, so it covers both local and network scenarios. Now, you mentioned capabilities earlier. The source talks about primitives. What are those? Ah, yes, the primitives. This is where the real power lies, I think.

They're the fundamental building blocks, the standardized types of things an MCP server can offer to an AI client. They're designed to map directly to what an advanced AI agent actually needs. Okay, so what can a server offer? On the server side, there are three main primitives. First,

Tools. These are functions the AI can execute. Things like query database, send slack message, create a zip issue. Critically, each tool advertises its own schema. Its name, description, what inputs it needs, what output it produces. So the AI can discover and learn how to use tools on the fly. Exactly. Runtime discovery is key. Second, resources.

Think of these as file-like, read-only pieces of context data. It could be the content of a text file, a specific row from a database, the response from an API call. Their job is just to provide information the AI needs to reason or complete its task. Okay. Tools for actions, resources for information. Third. Third, prompts.

These are reusable, predefined templates or workflows. They can guide the AI, or even the human user, through a specific task. Imagine a server offering a code review prompt that structures the interaction for reviewing code effectively. Interesting. Tools, resources, prompts, that's what servers offer? But you said communication is bi-directional? Right. Clients, or rather the host applications that contain the clients, can also offer capabilities back to the server.

This enables much more sophisticated interactions. Like what? One key one is sampling. This allows the MCP server to ask the host application, like your IDE or AI assistant, to use its underlying LLM to generate some text or make a decision. Wait, the server asks the client's LLM to think? Yeah. It enables this recursive thought-action loop. The server might need the LLM's help to interpret something or plan the next step.

Very powerful for complex agentic behavior. Okay, that's cool. What else? There's routes where the client tells the server about relevant file system boundaries, like the root directory in the current project. This helps the server operate safely within the right context.

And elicitation, where the server can realize it's missing some information needed to run a tool, and it can ask the host application to pop up a UI element and ask the user for clarification or the missing parameter. Ah, so the server can ask the user for help through the client interface. Precisely. It avoids the interaction just failing silently. You know, when you put all these primitives together, tools, resources, prompts on the server side, sampling, routes, elicitation on the client side,

How do you think they enable these much more dynamic, intelligent interactions compared to just calling a fixed API? Well, it feels much more flexible. The runtime discovery, the server asking the LLM to think, asking the user for input. It's less like a rigid script and more like a conversation between the AI, the tools, and the user. Exactly. It moves beyond simple function calls into genuine collaboration.

So for developers listening, how hard is it to actually build something with MCP? The sources mention a tutorial. Yeah, there's a great getting started guide. It walks you through building your first MCP server specifically, a simple GitHub issue fetcher in both Python and TypeScript, which covers the most popular languages. What does that involve? Pretty standard stuff, actually.

setting up your development environment, installing the MCP SDK, then defining a tool, maybe called get-issues, that takes a repository name and returns open issues, and maybe exposing a resource, like get-troporadme, to fetch the URIAD-EME file for context.

And that MCP inspector tool you mentioned helps here. Massively. Once you've written your basic server code, you fire up the inspector. You can connect to your running server, see if it correctly lists the get tissues tool and the get report admin resource. You can check their schemas, even try invoking the tool with test inputs right there in the inspector and see the results or any errors. So you can test the server completely independently before even writing a client. Exactly. It's plug and play debugging. And it reinforces that dynamic discovery.

The inspector, like any client, just connects and asks session.list tools and session.list sources to see what the server offers at that moment. And then integrating it into an actual AI app from the client side. That's covered too. How to connect to these servers, whether they're local ones running via Stereo or remote ones over HTTP.

A really good case study mentioned is enhancing an IDE, like Cursor, which is known for its AI features. How would an IDE use MCP? Well, the IDE acts as the host application. It could manage multiple MCP clients simultaneously. Maybe one client connects to a local MCP server that understands your project's file structure. Another client could connect to a remote MCP server for, say, your company's documentation stored in Notion.

Ah, so it gathers context from multiple places using MCP. Precisely. It orchestrates these clients to gather all the relevant context, the code you're working on, the project style guide from Notion, and feeds all that context to its LLM to provide really accurate context-aware coding assistance. That makes a lot of sense. You know, if people are feeling inspired by this and want to actually start building AI applications, maybe using MCP or other tools,

Is there something to help them get started? Absolutely. Our producer Etienne Newman hasn't just done certification guides. He's also put together the AI Unraveled Builder's Toolkit. A Builder's Toolkit? What's in that? It's specifically designed for people who want to get hands-on. It includes a series of AI tutorials in PDF format, more machine learning certification guides, and even AI tutorials in audio and video formats.

basically resources to help you jumpstart building your own AI projects. That sounds incredibly useful for listeners ready to take the next step. For sure. And again, you can find the links for the toolkit right there in the show notes at DJMGateTech.com. Perfect. Now we're talking about giving AI access to all sorts of tools and data, executing functions. Security must be a massive concern here.

Oh, absolutely critical. And what's fascinating and maybe a bit counterintuitive is that the MCP specification deliberately shifts the primary security burden onto the host application. So not the protocol itself or the server, but the application the user is interacting with, like the IDE or the AI Assistant app. Exactly. The protocol provides the framework for secure interaction.

But it's the host, the thing the user ultimately trusts, that has to enforce the rules and act as the gatekeeper. What are the core principles there? The sources lay out several key ones. First and foremost, user consent and control. The user must be the ultimate arbiter.

Any potentially sensitive action, like running a tool that modifies files or accessing private data, requires an explicit UI prompt from the host application asking for the user's permission. No silent actions. Okay. User is in charge. Makes sense. Second, data privacy. Similar idea. Explicit user content is needed before any potentially private user data is exposed to an MCP server as a resource or tool input.

Third, tool safety. This is crucial. Tools offered by a server could potentially do anything right. They represent arbitrary code execution. So the host application must treat them with extreme caution. It cannot implicitly trust the description a server provides for its tool. It must get explicit user consent before invoking any tool, especially from untrusted servers. And finally, LLM sampling controls.

If a server uses that sampling capability to ask the host's LLM to generate text... The host needs to control that too. Yes. The user should ideally be able to approve the sampling request, see the exact prompt the server wants to use, and control what parts of the LLM's response the server gets back.

full transparency and control. It sounds like the host application has a lot of responsibility. It does. And this raises an important question, especially for businesses. How absolutely crucial is embedding this security by design philosophy right from the start for the widespread enterprise adoption of MCP? Yeah, enterprises aren't going to touch this if it's seen as insecure.

Exactly. The source material even gets into threat modeling the MCP lifecycle, thinking about potential attacks like name collision, where a malicious server impersonates a legitimate one, or installer spoofing, or even sandbox escape from a poorly secured server. So what are the recommendations? It's multilayered for server developers. Validate and sanitize all inputs rigorously. Implement the principle of least privilege. Keep dependencies secure.

For those client developers, build those robust user consent flows we talked about, validate and verify results coming back from servers, implement secure logging. And for the enterprises deploying this? They should aim for zero standing privilege models, maybe maintain a curated registry of trusted MCP servers their employees can connect to, and use immutable infrastructure where possible for running servers. It's a combined effort, but this proactive security stance is what allows organizations to leverage MCP's power confidently.

OK, so MCP is this powerful security conscious connector. How does it fit into the bigger picture? It's not the only standard or protocol out there in the AI world, right? No, definitely not. It operates within a larger ecosystem. It's important to understand how it relates to other things. For instance, traditional APIs like REST or GraphQL. Is MCP replacing those? Not really. MCP is better thought of as an AI native abstraction layer built on top of those existing mechanisms.

A server might use a REST API internally to fulfill a request, but it exposes that capability through the standardized MCP interface. The key difference is that dynamic runtime discovery of MCP versus the static documentation you usually rely on for traditional APIs. Okay. What about something like ONNX, Open Neural Network Exchange? Complimentary. ONNX standardizes the format of the machine learning model itself, the brain, you could say.

MCP standardizes the runtime interaction, how that brain, once it's running, talks to the outside world, its senses and hands. They solve different problems. And MLflow? Also complimentary. MLflow is more of an MLOps platform managing the whole machine learning lifecycle, like experiment tracking, model deployment, model registries. MCP is purely focused on that runtime communication after a model or agent is deployed. Got it. But the source highlights one comparison as particularly critical.

MCP versus A2A. What's A2A? A2A stands for agent-to-agent protocol. And this is really important. MCP and A2A are explicitly designed to work together. They address two distinct problems.

But reloaded types of communication needed for complex AI systems. OK, so how are they different? MCP, as we've discussed, defines agent to tool communication. It's about how a single AI agent connects to its toolbox, the various APIs, databases, file systems, etc., that it needs to do its job. Agent talking to its tools. Right. A2A, on the other hand, which was developed initially by Google and is now managed by the Linux Foundation, defines agent to agent communication.

It's about how multiple, potentially autonomous, potentially independently owned AI agents can collaborate, delegate tasks to each other, negotiate and communicate effectively. Ah, so MCP is one agent using many tools. A2A is many agents talking to each other. You've got it. The source uses a great analogy here, too. If your AI agent is, say, a car mechanic, MCP is the universal standard for all the tools in their toolbox.

The sockets, wrenches, diagnostic scanners. It ensures they can connect their tools to any make or model of car that comes into the shop. Right. The tools work with the car. A2A, then, is the standardized language the mechanic uses to talk to other people, the parts supplier to order a specific part,

maybe another specialist mechanic to consult on a tricky problem, or even the customer to explain the repair. Okay, that clarifies it nicely. MCP for tools, A2A for teamwork. Exactly. And you can see how for complex real-world workflows, like maybe orchestrating an entire supply chain using AI, you'd almost certainly need both protocols working together effectively.

So looking ahead, what's next for MCP? Where is this all going? Well, the roadmap outlined in the sources is pretty exciting. There are some key areas they're focusing on. One huge one is standardized authentication and authorization. Right now, securely connecting to remote MCP servers, especially ones that require payment or handle sensitive data, is still a bit of an unsolved challenge. They need standard ways to handle logins and permissions. Yeah, that seems critical for real-world use. Definitely.

Another push is for an official trusted server registry. This would help combat those security threats like name collision or users connecting to malicious servers. Having a central vetted directory would build a lot of confidence. Like an app store, but for MCP servers. Sort of, yeah. Yeah. And of course, just ongoing protocol enhancements, making streaming data more efficient and

potentially allowing servers to be more proactive in pushing updates to clients, things like that. And beyond the core protocol, is research pushing it further? Oh, yeah. People are already looking at things like centralized security oversight for enterprise deployments, better ways to manage state for really long, complex agent workflows, ensuring MCP scales well in multi-tenant cloud environments. And even connecting to the physical world. That's a fascinating area, integration with smart environments, the Internet of Things, IoT, industrial automation.

Imagine AI agents using MCP not just to access databases, but to interact with sensors and controls in a factory or a smart home. Wow. So pulling it all together, what really becomes possible because of MCP? The sources summarize it nicely.

Lower integration costs. Obviously, that NILAM problem becomes manageable. Dramatically improved AI capabilities. Suddenly, your AI isn't just a brain in a vat. It's connected to potentially thousands of specialized tools and data sources, like having thousands of experts on call. Enhanced security, too, if implemented right. Enhanced security through standardization and those clear responsibility lines.

and accelerated development engineers can stop wasting time on bespoke connectors and focus on building unique AI features and value. It really does sound like more than just a technical standard. It's a paradigm shift. It's transforming AI models from these isolated theoretical brains into versatile, practical, effective doers they can actually interact with and affect the real world. Which leads to a pretty deep final thought. If MCP is the universal connector letting AI plug into all the world's data and tools...

What entirely new ethical or societal questions pop up when these connected AIs start becoming truly autonomous, truly pervasive in our everyday lives?

Something to chew on. Definitely something to think about. Well, thank you so much for diving deep with us today into the model context protocol. Hopefully this gave you, our listener, a really solid understanding of what MCP is, why it matters, and the, frankly, immense potential it holds. It's definitely a space to watch. Absolutely. And if this deep dive has sparked your curiosity and maybe you're thinking about getting hands-on, definitely check out Etienne Newman's

AI certification prep books we mentioned earlier for Azure, Google Cloud, AWS, and also that AI Unraveled Builder's Toolkit. Great resources to bridge the gap between understanding and doing. For sure. All of Etienne's materials are available over at djamgate.tech.com. And like we said, all the links you need are right there in our show notes.

We also really encourage you to check out the official MCP resources themselves, like the GitHub repository and Anthropix documentation. Yeah, dig into the source material. Thank you again for joining us on the Deep Dive. Until next time, keep learning, keep questioning, and keep connecting those dots.