Building Agents With MCP And Data Streams by Tim Berglund 🔗 **Source:** [Building Agents With MCP And Data Streams by Tim Berglund](https://www.youtube.com/watch?v=FTbSKV-zPAw) > [!note]+ Document Notes > tags: [mcp, ai-agents, microservices] > author: Tim Berglund > source: YouTube > reference: https://www.youtube.com/watch?v=FTbSKV-zPAw > date created: 2024-12-20 10:00 > > # 🏷️ Title: Building Agents With MCP And Data Streams > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Evaluate MCP servers for standardized tool integration — avoid writing custom API integrations #mcp - [H2] Design agents as microservices with state machines — manage context windows efficiently #architecture - [H3] Consider event-driven architectures for multi-agent systems — use Kafka for agent communication #kafka ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Model Context Protocol Documentation](https://modelcontextprotocol.io) - [Confluent MCP Server](https://github.com/confluentinc/mcp-server-confluent) ## 📝 Summary - **What happened**: Tim Berglund explains Model Context Protocol (MCP) and its role in building AI agents that can access external resources and tools - **Why it matters**: MCP provides standardized interfaces for agent-to-service communication, solving the problem of custom API integrations for every external service - **Key stakeholders**: Developers building AI agents, platform providers exposing services, enterprises implementing agentic architectures - **Risks and tradeoffs**: Synchronous request-response model may limit scalability; over-engineering for single service/consumer scenarios - **Bottom line**: AI agents are essentially microservices that call LLMs, and MCP enables standardized discovery and interaction with external resources and tools ## 📖 Main Content The Model Context Protocol (MCP) addresses fundamental limitations of Large Language Models (LLMs) in enterprise environments. LLMs are stateless probabilistic completion engines that know only their training data and cannot take actions. They lack knowledge of proprietary company data and cannot interact with external systems. MCP provides a standardized JSON-RPC protocol for agents to discover and interact with external resources and tools. Unlike Retrieval Augmented Generation (RAG), which pre-embeds documents in vector databases, MCP enables dynamic discovery of capabilities through standardized interfaces. The protocol defines three primitives: Resources (context data), Tools (actionable functions), and Prompts (engineered templates). MCP servers expose these capabilities through HTTP endpoints, while agents act as clients that discover available resources and tools at runtime. This architecture enables composition and discoverability - agents only need a server URL to learn what capabilities are available, rather than hard-coding integrations to specific APIs. ## 🗒️ Notes #### ⏱️ [00:00](https://www.youtube.com/watch?v=FTbSKV-zPAw?t=0) — [H1] Introduction to MCP and Agent Architecture - Key idea: MCP provides standardized interfaces for AI agents to interact with external services - Evidence: "MCP exists for a reason and it is that to that reason that I'm building up" #### ⏱️ [03:23](https://www.youtube.com/watch?v=FTbSKV-zPAw?t=203) — [H2] LLM Limitations Drive Need for Agents - Key idea: LLMs are stateless completion engines that cannot access private data or take actions - Evidence: "They are completely stateless probabilistic completion engines. You put tokens in and what it thinks are the most likely most appropriate tokens come out" #### ⏱️ [07:45](https://www.youtube.com/watch?v=FTbSKV-zPAw?t=465) — [H2] Context Window as Scarce Resource - Key idea: Managing context windows is critical for agent performance and cost control - Evidence: "Managing what goes into the context is a problem. Whether you're a chatbot or you're an agent, it's a scarce resource" #### ⏱️ [09:12](https://www.youtube.com/watch?v=FTbSKV-zPAw?t=552) — [H3] RAG Pattern for Context Enhancement - Key idea: RAG enriches prompts with relevant enterprise data through vector database lookups - Evidence: "We go and look up the documents that are kind of about the same thing as the prompt" #### ⏱️ [12:30](https://www.youtube.com/watch?v=FTbSKV-zPAw?t=750) — [H2] Tool Calling Enables Agent Actions - Key idea: Tool calling allows agents to invoke external services and take concrete actions - Evidence: "That's what we call it when we have an AI agent that can go and take some action can call some service out on the web" #### ⏱️ [14:15](https://www.youtube.com/watch?v=FTbSKV-zPAw?t=855) — [H1] Agents Are Microservices - Key idea: AI agents follow microservice patterns but make slow LLM calls - Evidence: "AI agents are microservices. They're microservices that call LLMs and they take action" #### ⏱️ [16:45](https://www.youtube.com/watch?v=FTbSKV-zPAw?t=1005) — [H2] Problems with Custom Integrations - Key idea: Building custom API integrations for every external service creates maintenance burden - Evidence: "Tool integrations. What are those? Those are just API calls, right? And as we all know, most APIs are terrible" #### ⏱️ [19:30](https://www.youtube.com/watch?v=FTbSKV-zPAw?t=1170) — [H1] MCP Provides Standardized Discoverability - Key idea: MCP enables standard interfaces for tools and resources with built-in discovery mechanisms - Evidence: "Standard tool interface, standard resource interface and standardized way of handling discoverability" #### ⏱️ [21:20](https://www.youtube.com/watch?v=FTbSKV-zPAw?t=1280) — [H2] MCP Server Architecture - Key idea: MCP servers expose standardized JSON-RPC interfaces over HTTP to bridge proprietary APIs - Evidence: "It is in general a server process... making these JSON RPC calls over streamable HTTP to it" #### ⏱️ [24:10](https://www.youtube.com/watch?v=FTbSKV-zPAw?t=1450) — [H3] Remote vs Local MCP Usage - Key idea: Remote MCP servers over HTTP are more valuable than local desktop integrations - Evidence: "I think the remote case is more interesting. That's where there is a remote process running sort of in your network" #### ⏱️ [26:30](https://www.youtube.com/watch?v=FTbSKV-zPAw?t=1590) — [H2] MCP Client Responsibilities - Key idea: MCP clients (agents) manage LLM API keys and implement domain-specific logic - Evidence: "It is the client that calls the LLM. An MCP server isn't really supposed to have LLM API keys" #### ⏱️ [29:45](https://www.youtube.com/watch?v=FTbSKV-zPAw?t=1785) — [H2] MCP Protocol Primitives - Key idea: Resources provide context, tools enable actions, prompts offer engineered templates - Evidence: "Resources and tools and prompts... Resources that's going to end up as context... tools those are calls that we place" #### ⏱️ [32:15](https://www.youtube.com/watch?v=FTbSKV-zPAw?t=1935) — [H3] Dynamic Resource Discovery - Key idea: Agents can query MCP servers for available resources and let LLMs decide which to use - Evidence: "You get to ask your LLM. You're an agent. You have an LLM based on this prompt that I've got from the user. Does any of this sound useful?" #### ⏱️ [35:00](https://www.youtube.com/watch?v=FTbSKV-zPAw?t=2100) — [H3] Tool Schema Integration - Key idea: Modern LLM APIs natively support tool schema definitions for structured interactions - Evidence: "The model APIs now let me describe the schema to the model... it can say, well, this is the tool that you ought to call" #### ⏱️ [37:30](https://www.youtube.com/watch?v=FTbSKV-zPAw?t=2250) — [H1] MCP Benefits: Context, Standards, Discovery - Key idea: MCP provides context management, standardized tool interfaces, and automatic capability discovery - Evidence: "Help with context... gives you a standard way to invoke tools... discovery... composition" #### ⏱️ [40:15](https://www.youtube.com/watch?v=FTbSKV-zPAw?t=2415) — [H2] When to Use Agents - Key idea: Build agents for unstructured input processing where probabilistic results are acceptable - Evidence: "Probably some kind of unstructured or natural language input... when we are okay with the results being probabilistic" #### ⏱️ [42:45](https://www.youtube.com/watch?v=FTbSKV-zPAw?t=2565) — [H1] Future: Event-Driven Multi-Agent Systems - Key idea: Multi-agent architectures will likely use event streams rather than synchronous protocols - Evidence: "We're going to find those are microservices and they're going to talk through event logs probably through Kafka" ## 📚 References - [Model Context Protocol Specification](https://modelcontextprotocol.io) - [Confluent MCP Server](https://github.com/confluentinc/mcp-server-confluent) - [Claude Desktop MCP Integration](https://claude.ai/desktop) ## 🗣️ Paraphrase - MCP solves the integration problem by providing standardized interfaces for agents to discover and interact with external services, eliminating the need to write custom API integrations for each service - AI agents are fundamentally microservices that process unstructured input through LLMs and take actions, requiring careful context window management and state machine logic - Multi-agent systems will likely evolve toward event-driven architectures using message brokers like Kafka for inter-agent communication, rather than synchronous request-response patterns ## 📰 Newsletter **Standardizing AI Agent Integrations with Model Context Protocol** The Model Context Protocol (MCP) is emerging as a key standard for AI agent development, addressing the integration challenges developers face when building agents that need to access external services and data sources. **Key Benefits:** - **Standardized Discovery**: Agents can automatically discover available resources and tools from MCP servers without hardcoded integrations - **Context Management**: Efficient handling of the scarce context window resource through dynamic resource selection - **Tool Integration**: One API to learn instead of dozens of different service APIs **Practical Applications:** - Enterprise agents accessing internal databases and APIs - Multi-service workflows (calendar + reservation systems) - Composable agent architectures with server-to-server communication **Getting Started:** Many platforms now offer MCP servers, including Confluent for Kafka operations. Consider MCP when building agents that need to interact with multiple external services, especially in scenarios with many consumers of the same services. Resources: [MCP Documentation](https://modelcontextprotocol.io), [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create MCP integration examples and tutorials, demo agent architectures at conferences - Education: Develop workshops on agent design patterns, context window optimization techniques - Developer experience: Improve MCP server documentation, create SDK wrapper libraries - Developer marketing: Content series on "Agents as Microservices", MCP vs RAG comparisons - Community management: Foster MCP server ecosystem, curate integration examples #### OSPO - Policy & Governance: Establish guidelines for MCP server contributions, agent security policies - License Compliance: Review MCP-related dependencies, ensure compatible licensing - Security Management: Define security standards for agent-to-service communication - Software Inventory: Track MCP server dependencies and versions across projects - Developer Support: Training on secure agent development practices - Community Engagement: Support open source MCP server development - Strategic Alignment: Align agent architecture standards with enterprise goals #### Community - Maintainers: Develop MCP server reference implementations, governance templates for multi-agent systems - Contributors: Create first-issue programs for MCP server contributions - Sponsors: Fund development of critical MCP integrations, agent tooling - Ecosystem: Coordinate standards between different MCP server providers #### WordPress - Core: Evaluate MCP server for WordPress REST API, content management agent integration - Core Performance: Profile agent-driven WordPress operations, context window optimization - Core AI: Develop MCP server for WordPress AI features, content generation agents - Community: Create educational content on WordPress + MCP integration patterns - Training: Develop curriculum on building WordPress-connected agents - Documentation: Document MCP integration patterns for plugin developers - Meta: Consider MCP server for WordPress.org API access, plugin directory integration ## 🧪 Hypotheses - MCP adoption will accelerate when major cloud providers offer standardized MCP servers for their services - Agents built with MCP will demonstrate better composability and maintainability than custom-integrated agents - Context window management through MCP resource discovery will prove more efficient than pre-embedded RAG approaches - Event-driven multi-agent architectures will emerge as the dominant pattern for complex enterprise AI systems ### 📊 Methodology - Compare development time and maintenance costs between MCP-integrated vs custom-integrated agents - Measure context window utilization efficiency in MCP vs RAG implementations - Analyze composition patterns in multi-agent systems using MCP vs direct service calls ### ❓ Questions - How will MCP handle authentication and authorization across different enterprise security models? - What are the performance implications of synchronous MCP calls versus asynchronous event-driven patterns? - How will MCP servers handle rate limiting and quota management for shared enterprise resources? ### 🔮 Future Research - Development of asynchronous MCP extensions for streaming data sources - Integration patterns between MCP and existing enterprise service mesh architectures - Standardization efforts for agent-to-agent communication protocols beyond A2A ### 💡 Implications - Practice: Shift from custom API integrations to standardized MCP server consumption patterns - Policy: Need for enterprise governance around MCP server deployment and agent authorization - Security: New attack vectors through MCP servers require updated security frameworks - Education: Developer training programs need to include agent architecture and MCP integration patterns - Funding: Budget allocation toward MCP server development and maintenance versus custom integrations ### 🧠 Learning Styles Assessment Reading level estimate: 11th-12th grade #### 👀 Visual learners - Present: Architecture diagrams showing MCP client-server relationships, flow charts of agent decision processes - Improve: Additional sequence diagrams for MCP discovery process, visual comparison of RAG vs MCP approaches #### 🔊 Aural learners - Present: Conference presentation format with clear verbal explanations - Improve: Audio summary highlighting key MCP benefits and implementation steps #### 🗣️ Verbal learners - Present: Clear definitions of MCP primitives, analogies comparing agents to microservices - Improve: Glossary of MCP terminology, story-driven examples of agent workflows #### 🧩 Kinesthetic learners - Present: Code examples implied through API descriptions - Improve: Step-by-step MCP server setup guides, hands-on agent building tutorials #### 🧠 Logical learners - Present: Clear protocol structure, systematic breakdown of MCP primitives - Improve: Decision trees for when to <!-- deep-read:sections end --> ## 📺 Video ![](https://www.youtube.com/watch?v=FTbSKV-zPAw) --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=FTbSKV-zPAw)* **[00:05]** Hey, thanks for being here everybody. Uh, it is true. I am Tim Bergland. I work for a company called Confluent. Uh, I run the developer relations team there and occasionally they let me do things like this and I enjoy it and it's not possible if you don't come to the room. So, thank you for being here. Uh when I think about agents, I either think about uh Agent Smith, uh The Matrix, obviously. Uh when I think about MCP, I think about we did a panel a little **[00:36]** while ago. I mentioned the first Tron movie. I'm not obsessed with the first Tron movie, but it just it comes up, right? And the MCP was this bad guy. It was like this overgrown sort of totalitarian operating system. Um and I just can't that's this is the picture I have in my head. happily the protocol the the model context protocol is is is just a lot better. It's not mean. It doesn't want to take over everything. Uh it's I think a pretty useful technology. There are a few things and I I want you to think in **[01:07]** your head. You you came to this room for a reason. We have the next about 40 minutes to spend together. 38 minutes something like that. Uh you came here for a reason. There is something you are hoping to get from today. I'm going to give you a rough idea of what I'm going to cover, but I just want you to think kind of lock in in your mind why you are here. It's too big of a room. I would normally ask for hands and kind of talk to some people. There's too many people here. There's too too big geographically of a room. But just think what are you trying to get? What I'm going to tell **[01:37]** you about is uh what MCP is. I want to give you a a good concise explanation of the protocol itself and more importantly why it is. Uh, and to talk about why it is, we have to talk about what large language models are, what they aren't, what they're good at, what they're not good at, and what it means to write an AI agent. What is an AI agent? And uh, those are that's kind of the the big picture. And where does streaming enter **[02:09]** the chat? It's a thing I work with a lot. Why is it here? Well, you'll see at the end. Um, I I'm going to make some claims about what agents actually are and some predictions about how agentic architectures and how our code that we create, the agents that we write will tend to evolve. And I think uh, oddly Kafka is going to end up being a part of that picture in part. Uh, it's not top of the list when we think about AI, but uh, when we think about agents, it is uh, an element that just needs to be in **[02:40]** your mind. So that's what today's about. And if when you made that little mental list of what you were after, if it's something like what I just described, you're in the right place. If it's not, and you're seated in the middle of the big I regret that. I'm sorry. It's going to be awkward for you to get out, but um that's just so you so you know what to expect. Now, what uh what do LLM do by themselves? They are uh completely stateless probabilistic completion engines. You **[03:11]** put tokens in and uh what it thinks are the most likely most appropriate tokens come out and they have no state and they cannot do anything. They just emit tokens. That's what they do. They don't know anything about you. They know only what they've read on the internet. Uh generally that's what the training data is. And you presumably your company probably has data that is we hope not on the internet. your wiki, your support **[03:42]** tickets, uh any private GitHub repos and issues, uh your all of your company Google Docs. If that stuff's all public, we might read about it next week. That could be embarrassing for somebody. So, the LM doesn't know anything about your data. That's a problem. And the LM can't do anything. That's a problem. It just it just it just emits tokens. And most of us and certainly what what's uh OpenAI claim? 800 million monthly active users for chat GPT. the vast majority of whom are not software developers, they know it as a chatbot, right? They type **[04:12]** stuff in and it says stuff back and maybe they ask to create an image and it gives them an image or maybe they paste in an image and say who's this person and it says I don't know uh whatever you know it's that that sort of interaction. It's a chat interaction. Uh they don't do anything. can't ask chat GPT Claude Grock to go make you reservations for dinner because it it doesn't it's not able to take action. Those are both problems we want to solve. Um which is what creating agents is all about. **[04:43]** There's also the context window problem and this comes to the forefront. This is a thing that is constantly with us when we're thinking about agentic architectures and how we how it is we build agents. there's a certain number of tokens that that remember stateless LLM can take as input and beyond that uh that that's it that's the whole thing that you're that you're you're giving to the LLM looking for some kind of output and that chat again as as you know an ordinary sort of user experiences it uh there's just sort of a back and forth of **[05:13]** um you know I I ask a question and it gives me an answer and I ask another follow-up question and this is all the context right this is all the stuff that's in the context window. But when we get past that, say with a chat interaction, there's stuff at the beginning of the chat that falls off the edge of the world. I don't know if you've experienced this if you're um you know, sort of for me before coding agents just kind of doing some back and forth about a coding problem. Uh one time that's memorable, I was asking for **[05:45]** some some C code. Uh was running on a micro microcontroller and after a little while it started giving me Python. I'm like, well, I I wonder if you could not do that. Um, that's because I had there's stuff that had just rolled off the the end of the context window and it forgot. I had to remind it and it was fine. But this managing what goes into the context is a problem. Whether you're a chatbot or you're an agent, it's a scarce resource. Uh, and it's a thing we're going to have to manage. We we'll we'll talk about that. So uh remember they these these **[06:16]** foundation models that you can buy on the internet they know only what they read on the internet they don't know anything about you your company anything like that what your your domain so the first pass that we as a as a community using AI and this is this pattern is uh easily two and a half years old as a popular thing but so-called retrieval augmented generation um a lot of people like to talk about this like it's old and busted. I'm not sure maybe but uh the basic idea is there is some prompt. **[06:48]** Okay. And there's a presumption there by the way that an agent an agent that you write that does some kind of work in the company that you work for this is not an agent that you configure into claude desktop. This is and this is not uh you know some some thing you find out on the web. This is an actual agent that you build. It's going to take some kind of natural language input. I'll come back to that point in a minute. But there is some prompt. There's some free form text prompt that comes in to your service and **[07:19]** for this this rag pattern, it's going to go and calculate an embedding. Uh we're not going to get into what that is, but that's just this this uh you know turning that text into a string of numbers and look that up in a vector database. I think there's some really great talks here uh on vector databases. There's one that happened this morning. It's too late. If you didn't go to Ricardo's talk on vector databases, you can't go. It already happened. Um, uh, there may may yet be some in the future. I haven't checked the schedule, but anyway, the way that in a single **[07:51]** slide, the way this works, all of the enterprise data is somehow or all of it that we want to be able to be included is included in that vector database. We go and look up the documents that are kind of about the same thing as the prompt. Um, and what that does is that gets a bunch of text out of that vector database that you append to the prompt. So now you've got the prompt and it's enriched with all this other stuff that the LLM doesn't know. But here you go, LLM. I now have larger context for you, **[08:23]** enhanced by what's in uh my vector database that can now go to this poor, ignorant large language model that knows only what it has read on the internet. Now it knows some things that uh we've told it about the company. So that's one thing you can do, right? That's fine. Um and you know it's the cool kids talk about this like it's we don't need this anymore. Honestly, I think it's just fine. I think it's a perfectly fine pattern uh that has a place in your AI **[08:54]** stack potentially. I will say that uh in some ways in the margins MCP competes with this. MCP is going to give us some ways of finding that context out in the world and putting it into the the prompt that we send to the LLM. So, if you hear this idea, we don't need this anymore, I'd say be careful with that claim. Um, if you are using it and you somehow feel shame because it's a two-year-old idea and you should be on to newer and cooler things than that, don't don't do that. Totally fine. **[09:25]** and in the margins uh there is some overlap with MCP that that may encroach on what rag does. We'll just have to see the other thing. Remember the two problems with the the large language models. They don't know anything about you and they can't do anything. This is where tool calling comes into the world. Uh that's what we call it when we have an AI agent that can go and take some action can call some service out on the web uh presumably connected uh over HTTP. So those two things, what makes an **[09:57]** agent? It's a small program. It calls an LLM, hopefully enriched with some sort of context that you found. You're going to have to manage that context window and it takes an action. That is what an agent does. It's a small program uses an LLM and it takes an action. If it doesn't use an LLM, it's not an AI agent. It's just some other kind of program that does something. **[10:28]** Now, there is another word we use for a small program that maybe takes some input and does some things whether there's an LLM involved or not. And you might just say, "My definition of an agent kind of sounds like a microser that makes this very slow call out to an LLM that takes a few seconds to to return things." And you would be right. I think they really are as Pam would say the same picture. I am very **[10:59]** comfortable saying that AI that AI agents are microservices. They're microservices that call LLMs and they take action. It's as simple as that. Uh now that point is going to come back at the very end. We're going to talk about um what happens when our agents get large and complex where there's some lessons that we've just been through in the last 10 years about how to write microservices and I'm not going to let you forget them. So this is a good thing that agents really just kind of look like microservices. Nothing nothing wrong with that at all. Um **[11:34]** and so we could roll our own. What would that look like? Okay, so again we have some prompt. If it's an agent, it's calling an LLM. That assumes that there is either some kind of natural language request or big chunk of otherwise unstructured data, not big but not too big chunk of otherwise unstructured data that is coming in as a prompt. It's it's not **[12:04]** just a database row. It's not something where we have carefully imposed structure on the data and the data types and validated it and all that kind of stuff. That's just a normal micros service because our agent is calling an LLM. The input is going to be something unstructured. And it's good if for now for simplicity you just think of that as a text prompt whatever it is something in the business some you have to build now you get to build it where people can just ask with words what they want uh instead of more structured input. So **[12:35]** that prompt comes in to your microser. Your microser is now going to have to presumably access other resources. It has to go get more context. It could go query databases directly. That's fine. It could be consuming from Kafka topics. There's lots of places it could go and get those things from the business from the other systems that maybe you've built. Uh and those interfaces, how do you query a database? How do you get a Kafka topic? How do you go read from **[13:06]** whatever other kind of information source you have in your your company? You know how to do that or you can find out. If you don't know, ask an LLM. they're actually really good at that stuff. Uh so you know how to go and connect to those other resources in your company and and that's completely fine. Um you know or you can learn how to use uh an LLM's API. You can submit that prompt with that extra context to the LLM. Maybe it's also already wrapped with retrieval augmented generation. **[13:37]** That LLM box can can be rag or not. you can just kind of let that be in there and then that that prompt comes back that result comes back and then you go do things you can go do things those are the tools that you can call you interface with external systems on the outside world so this is kind of the single agent I'm going to propose this as our single agent reference architecture a prompt comes in it talks to other things in your in your business known only to you it calls an LLM and then it takes action on the outside world so there there you go there is your reference architecture and there **[14:09]** isn't anything in general wrong with this. But MCP exists for a reason and it is that to that reason that I'm building up. What's wrong here? Well, number one, tool integrations. What are those? Those are just API calls, right? And as we all know, most APIs are uh terrible. You'd rather not learn all of them, right? Okay, that's an overstatement. They're not all that bad, but that's a pain. I don't know. whatever kinds of effects you want to go cause. Now, that's code **[14:39]** you have to write to some arbitrary set of services. Once again, that happens to be code that AI is pretty good at because it's read the docs. It's seen the examples. It could probably kind of scaffold you most of the way towards a working integration with whatever service, you know, Google Calendar, Yelp, uh, Open Table, whatever other kind of stuff you want to do for the agent you're building. Uh, but you don't want to have to write all those API integrations yourself. That's a pain. Uh, because they're all different and they're all differently bad. Um, also **[15:11]** the resource integrations. Again, you kind of know how to do this within your world. If it's a database, if it's stuff that's in Kafka, if it's uh uh, you know, maybe the wiki, okay, that's probably an API you'd have to go and learn and I imagine it would be unpleasant. Um, but those are things that you can do. But do you necessarily want to? It's again there's one you one agent and there's many tool interfaces, many resource integrations and that's kind of **[15:43]** a pain if you are exposing tools and resources to the general public. So uh I actually made up just now OpenT. I don't know if OpenTable has an MTP server. I haven't looked. I'm going to look after this talk. But imagine we wanted to make an agent where I could uh schedule dinner or lunch or coffee or something with a friend and I just want to say I want to get coffee with Peter next week. That's my intent. And the agent goes and **[16:15]** figures things out. Well, it's going to have to know things about calendars. Uh it's going to have to know things about how to uh uh you know, how to uh make that reservation out there in the world. And if I am a service like again ruthlessly making this up, OpenT, somebody like that where I've got access to resources and tools and things I want you to do. What if I want those resources and tools to be discoverable by you? **[16:47]** Okay, they already are. There's going to be a developer site, an API, and docs and everything, but I'd like a standard way for those to be discoverable by AI agents, by my agentic microservices that I'm writing. And that is a key part, I think, of the value proposition of MCP. It's really cool, the discoverability stuff. So, standard tool interface, uh, standard resource interface and standardized way of handling discoverability. That is what MCP brings us. **[17:20]** Let's look at the pieces. Okay, when we talk about MCP, we're usually talking about an MCP server because that's the product that somebody's going to release. Confluent, for example, we have an MCP server that lets you uh get at and manipulate the resources of your Confluent Cloud account. So if you want to learn uh what topics you've got configured, what Flink queries are running, uh if you want to read something from a Kafka top, you want to **[17:50]** create a new query or topic or something like that, those are all tools and resources that that we'd expose. And it's the server that we are releasing. So we always we always kind of talk about the server because that's really the product that is this now standardized interface in front of whatever sort of service I have on the back end. So it is in general a server process. Um you get to write your own and you get **[18:21]** pretty much the language bindings you'd want mostly TypeScript, Python, Go, Cotlin, Swift, Java, even Ruby now, Rust, C. There's there's pretty good selection of language bindings for you to create this server. Um here's a key point. When you go read about MCP, find blog posts about people saying, "I did this cool thing with MCP, uh, explainer videos, whatever it is you find online, there is a heavy focus on the local use case where that MCP server **[18:53]** is a process that runs on my laptop and say I plug it into claw desktop." So Claude desktop can now uh look at code on my computer or uh access my running data in Strava or whatever it is. And now I can write I can write prompts in cloud desktop that rely on those resources and it connects to them. But there's an emphasis on this local use case of the server running locally. And that's fine. There's lots of cool things you can do there. I don't **[19:24]** think that's the real power and I don't think that's the real future of uh this spec. Um I think the remote case is more interesting. That's where there is a remote process running sort of in your network and you don't talk to it by piping data over standard IO which is the local case but it's actually an HTTP endpoint and you make JSON RPC calls over streamable HTTP connecting to that server. So you're going to see these two **[19:56]** cases one where the MCP thing runs on your laptop. That's what most people are going to talk about. And as we think about the agents we're going to build, that's probably not where you're going to go. You're probably going to have this server running uh that you're talking to over streamable HTTP making these JSON RPC calls to it. So, and that that J you should get that RPC mindset in your head. There really is this synchronous request response thing that's going on with the server. Um, and **[20:27]** let's just just keep that keep that kind of as you as you are forming a mental model here. Keep that in there. And there are three kinds of primitives that an MP MCP server exposes. Resources and tools and prompts. I've been telling you about resources and tools. Prompts are kind of this third thing. I think they're going to end up to be, you know, sort of number three child in the uh scope of, you know, what is important about MCP. People don't talk about the prompts as much, but we'll get to them. **[20:59]** Now, if there's a server, there's a client. What is that client? Well, that client is uh a in your agent. This is this is your agent calling the server. So what MCP is doing is it's giving new capabilities to the agent you write and that client is uh it talks to the server written in all all the same language bindings available. Um it is the client that calls the LLM. An MCP server isn't **[21:29]** really supposed to have LLM API keys. That's it's it's doable, but it would be considered a little bit naughty. Uh there's even a mechanism in the protocol if the server decides it needs to call an LLM, it can actually ask the client to do that on its behalf. So it's the client that has the API keys that's doing the actual AI stuff. The MCP server is doing relatively boring interfacing of those APIs back there to this standard JSON RPC over streamable **[22:00]** HTTP API here. So there is now this one way that our agents get to do things and ask about things and the MCP server is bridging to the billion ways of all the stuff that is in the arbitrary number of services back there. Any domain specific logic that your that exists that that your agent is going to implement and there had better be some there's going to be some kind of state machine in there that lives in the client. Uh now there's a distinction between MCP **[22:33]** host and MCP client. And I would like you not to get too wrapped around the axle about this. Uh there is uh a difference, but that stuff that's not the server, that's your agent. That's what you need to know. That's what's important there. So you got the server, you got the agent. um this host really is properly speaking the microser process that's running or it could be clawed desktop or whatever kind of local uh uh sort of AI shell you **[23:05]** can tell an agent about um and the reason why there's a distinction between host and client is because in fact a host can contain multiple clients which will be super clear in just a second like I said there is this request response paradigm here And normally I'm not that guy. I'm I'm the streaming guy. I want everything to be asynchronous and you know you have a result, you just put it in a Kafka topic and some other service consumes that and everything everything all just choreographs. It's beautiful. Well, that's not how **[23:36]** everything works and MCP servers are synchronous. Um so there is a request and a response for most of the uh operations that the the spec defines and there is also a way for the service asynchronously to send indications back to the client if it needs to do that for progress updates or for example asking for the client to call an LLM on its behalf other things like that. And the real reason why there's a client host distinction is because the host again **[24:08]** that's your service that's your agent that's the code that you're writing and if you are talking to multiple MCP servers you will create multiple MCP clients that's just going to be uh some some object that you create some state in there and some connections and and you know networking things underneath. uh but that that uh client is the actual connection to the server and when you got multiple servers you have multiple clients in a onetoone kind of situation. Um and I said you know an agent that **[24:41]** gets me coffee with somebody based on a prompt. I don't know it sounds fun. We could have a calendaring agent and we could have a a geospatial search coffee shop agent or just arbitrary sort of meeting place agent. All right, let's talk about the primitives on the client and the server side and the operations that that bridge. This is the meat of the protocol uh the actual, you know, JSON RPC calls and endpoints uh that are in there. I'm not going to take you through the schema of all the calls. Those are in the docs, but I just want to give you an idea of **[25:12]** what exists uh that we're able to interact with. So you can see very concretely, you can imagine your agentic microser interacting with an MCP server. So, uh, on the server side, we have resources. Uh, that's that's going to end up as context. That's stuff that's going to go in the prompt we send to the LLM. Uh, that rag was one way of getting that, but this is a different way. This is stuff that maybe maybe we have uh a rag **[25:42]** system built up around the foundation model that we use, but there are other resources that are provided by something out there that aren't a part of our pipeline. We don't ingest that data. They are part of some service that we're consuming on the outside world. So we can get those resources from the MCP server tools. Those are calls that we place. We tell the MCP server with this uniform JSON RPC call with a defined schema uh go do this thing. Passing it data **[26:13]** gives us data back. Uh so there's one way that our agents can call tools and interface with all those APIs out in the world. Uh prompts are again this tends not to get as much attention but if you you could imagine uh the agent gives the user some kind of list like what are the five things you want to do? Do you want to get coffee to talk something through with a friend? Do you want like a romantic meal? Is this a business lunch? **[26:43]** And maybe those are different prompts that you've done some work or the folks who built the server have done some work and and figured out that we've got this engineered prompt that does a good job with those things. It can actually provide those prompts to the agent. The agent can then take and you'd again the idea is you'd present them to the user. Which of these things is what you want to do? The user picks one and and uses that prompt. So again, probably not as important as tools and resources, but it's a thing that an MCP server can do. What can we do with resources? I can get **[27:14]** a list of them. What's really important here is that this list of resources includes descriptions. Those descriptions matter because those are going to go into our prompt. imagine you're an agent or you're writing an agent and you intend to connect your agent to an MCP server that's out there and you know that that **[27:45]** server has some resources in it that might be important for different kinds of things your agent might do but you don't rightly know which agent or pardon me which resource is always the relevant one and if querying that resource involves some parameters a range of values or a key or something. My guess is querying that resource is going to require some parameters. Um, you don't know yet what resources to use and how to query **[28:16]** them. You get a list as an agent. You can say, "Would you please tell me, Mr. Server, what are the resources you have?" And now you have a text description of those resources. And you actually get to ask your LLM. You're an agent. You have an LLM based on this prompt that I've got from the user. Does any of this sound useful? That is a potential flow through your agent. Uh I've got these resources. Do we need any of these? Because remember what the scarce resource is here besides money because we're getting tokens back. **[28:47]** But it's context. You don't want to just get everything you possibly can and mush it into the context window. It's number one, you'll run out of window. Number two, it's an increasingly uh believable wellattested result that more isn't necessarily better for the results that we're getting out, right? So, you want to be parsimonious. You want to be careful and only put in the context what you need. So, with that list of resources with text descriptions, you get to ask the LLM, do we need any of these? And it can actually you can ask **[29:20]** it tell me which of these should I query and you can get you know a rough conclusion there. That's something that the the agent in cooperation with the model can do without you as the agent author quite knowing what all the resources even are right now because that can change on the MCP side. Um of course I can also read uh a resource uh and depending on the resource there could be query parameters I pass in there. So there could be a range of values, a key lookup or whatever it is that I'm doing. Um, **[29:53]** resources that change, I can get asynchronous notifications. Again, that's the the server asynchronously sending me things back as to the client uh as those resources change. If there's some kind of streaming or real-time data source that the server is fronting, then that subscription uh model could make a lot of sense. Tools, same deal. list and uh the listing a tool gets me text descriptions that I give get to give to the LLM and schemas and good news the model APIs now let me **[30:25]** describe the schema to the model I don't actually I don't even have to do a bunch of weird string appending and create some big prompt thing I can tell the model I have these tools available to me and this is how I call them and this is what I get back and in the response from the model. If I have in my prompt indicated that I might want to take some action like schedule lunch with a friend, it can say, well, this is the tool that you ought to call to do that and that's in the API. So, uh, that's that's kind of a nice thing. Resources not in the API. That's **[30:57]** the thing we kind of have to talk back and forth with the model with, but um, the the tool schema and all that baked in. So, tool calling is kind of a thing that the models expect that you're going to want to do and MCP uh, helps you with that. So I can list and of course I can call because what's going to happen is I'm going to get a list of tools. I'm going to get a list of resources and I'm going to say hey based on this prompt uh I have these resources uh to do a good job. Do I need to get more information about any of these things? The model **[31:28]** will say, "Yeah, it' probably be nice to know when uh your friend has time open next week and when you have time open next week." And it would be nice to know uh where you both live and uh how far you want to drive. And you know, you can kind of work these things out in the flow of the agent. You might need to make several calls to the model. Uh but with those two MCP servers out there, one for calendaring and one for finding places to meet, uh I can in interacting with the model eventually get to the point where I know what to call uh to **[32:02]** make the to create the calendar event, make the reservation prompts. I keep saying this isn't very important. I you know, look, if you have an FCP server and you want to publish prompts, that's great. you can list them and uh I can get a particular prompt uh from uh the server. Okay. On the client side, the client also has some primitives uh roots which are parts of the file system that it has unrestricted access to. This is very much for the local case that I am personally less interested in. I am more **[32:33]** interested in us creating agentic microservices that can do AI powered valuable things in the companies we work for. um sampling that's the um when the server determines that it it needs an AI answer. It needs to call an LLM. So the server can ask the client would you please go call and potentially you know one of these models and and give me or all of these models and and give me the answers back. uh and the **[33:04]** server can also ask the client, ask the agent to ask the user a question. Um so sometimes the server might say we really ought to have some interaction with this. I'm going to elicit some input from the user. Now the agent can drop that. Doesn't have to ask the user. If it wants to be Skynet, it can. But you know, the idea is we we would like to be able to build in user interaction at appropriate times. Um, yeah, let's just bounce through those. **[33:36]** So, building an agent with MCP is potentially a little simpler. I have my prompt, I have my micros service, and uh, now I've got servers that I can call. I don't have to go figure out how to interface to every resource and every tool. I just get to uh directly call that MCP server. How do I do that? And at the level of the agent I am **[34:07]** building, how is it that I learned? How does my agent learn about all these things? Well, the discovery mechanism is I think one of the coolest things about this. Um the uh every every uh MCP server exposes a I believe there's a typo there. There's a typo that says agent exposes capabilities. That's a lie. The server exposes the capabilities. Don't take a picture of the slide. It's inaccurate. Uh yeah, the server exposes this **[34:38]** capabilities URL that reports that that returns a document that says these are the tools and these are the resources that I have. So um the resources have descriptions, the tools have descriptions. So like I said, all these things the model gets to figure out. What do you need as an agent? The URL. You just need the address of the server. The server tells you what it does and what it has. Now uh like I said, your agent is going to have a state machine. It's going to have code. **[35:09]** Okay? It's not just prompt MCP model. uh then you really are out of a job because you only need to write that code once. You're going to have to do things to make the otherwise unpredictable flow of uh what you're going to get back from an LLM relatively more predictable, but you don't have to build in too much smarts about the resources and tools you're getting back because they're self-describing. And that's to me one of the coolest things. You just need a URL. So, how are we on time? **[35:41]** We have just under five minutes. I will end on time, don't you worry. What does MCP give you? Help with context. That is a scarce resource in interacting with an LLM. It helps you get the right context, be smarter about the context you have. Uh, gives you a standard way to invoke tools. You have one API to learn, one language binding, not every dang API in the world. If the service you need exposes an MCP server, it's **[36:11]** covered. And I don't know if you've noticed lately, but everybody's making an MCP server right now. Also, discovery talked about that. You just kind of learn what the server has. And uh not a minor point, but composition. If you are building an MCP server, it can itself be the client of other MCP servers uh and have a little bit of smarts in it. So you have this composable uh aspect. Uh, I made a explainer video on this and got a bunch of comments. Most of which **[36:42]** were, "Is he writing backwards?" because it's a thing where I write on the glass and it's we actually use computers to flip the video. I I don't know if that's disappointing. Seems obvious to me, but a lot of people that's that's the most frequently asked question is, "Are you writing backwards?" I'm not. The the the most frequent good criticism was, "Isn't this just over complicated? Why are you doing all this? Can't you just call the services you need and just get the resources you need? And yes, potentially if if everything you're **[37:14]** doing really is all internal to your enterprise, you might be better off with just hand coding all that yourself. You probably got examples and libraries and ways of doing it. It's all well known. You don't need to stand one of these up in turn in front of your own resources. But when there is one service with many consumers out there that you don't know, it's very very valuable. If there's one service and one consumer, it might be a little too much. So you don't need to rush into it, but it's an excellent idea **[37:46]** and you are much more likely as the writer of agents to be a consumer of MCP uh than the builder of an MCP service. So uh a few other just quick thoughts uh on agents and and where all this is going. Why are we writing agents? Well, like I said, probably some kind of unstructured or natural language input, right? Uh and when we are okay with the results being probabilistic because the results we you're not going to get the **[38:17]** same result every time through the LLM. That's just not how it works. So you're you're okay with it kind of working things out and sometimes working and sometimes not. Uh it's not a good idea to write an agent because they're cool. Uh right. It's it's they're just not it it's a very useful thing and I think we're going to be discovering the right kind of corners of our enterprises to be adding this functionality. But don't rush into it because it's cool. I think that's going to be disappointing. And I personally I don't want to see the **[38:48]** paradigm get a bad name of a bunch of bad implementations because it seemed neat. You have to wait for the right thing. You have to make sure it's a proper use of AI processing natural language input. And as agents evolve wrapping up, they're microservices, right? They're going to grow. one service becomes a little bit big and a little I don't know monolithic and what do you do? You split it up into other services. **[39:20]** I think if you start by building one agent, it's not going to stay one agent. It's going to become lots of agents. There's a protocol that that is often mentioned in the same breath as MCP called agent to agent or a toa. Very similar. If you look under the covers, it kind of feels similar. Very very different kind of thing. And it it's recommending that your microservices talk to each other synchronously. And I think this is probably going to get less traction. I'm just going to make that prediction in closing. I think what we'll more likely see for our multi-agentic architectures as this as **[39:50]** we discover the actual value creating things to do with AI in the enterprise, we build these microservices that call LLMs and do amazing things that we couldn't do before and now we start to, you know, break those into many many agents. We're going to find those are microservices and they're going to talk through event logs probably through Kafka just as much as they always did. So we have event- driven microservices, we'll have event- driven agents in our future. I think that's a thing that we have to look forward to. Love to talk to you more about it at some point. **[40:22]** Thanks for having me here.