MCP 101: The Model Context Protocol for AI Agents

In this conversation, Jonny Daenen and Pierre Crochelet explore the Model Context Protocol (MCP), a framework that enhances AI assistants by allowing them to perform various tasks through tools, resources, and prompts. 

They discuss the architecture of MCP, how to build an MCP server, and the developer flow for creating tools. The conversation also touches on the compatibility of MCP with different AI agents and the user experience, highlighting both the potential and limitations of the protocol.

Resources:

• Demo code: https://github.com/datamindedbe/demo-technology-exploration/tree/main/demos/claude_mcp
• MCP servers: https://github.com/modelcontextprotocol/servers
• MCP directory: https://mcp.so/
• Click here to watch a video of this episode.
  
• Full playlist: https://www.youtube.com/playlist?list=PLJ_da7qdfL80rA7byzC_CmyrfJWjcCTnb

Chapters:

• (00:00) - Introduction
• (01:03) - Demo: Claude Desktop & MCP
• (04:43) - What is the Model Context Protocol?
• (07:09) - Tools, Resources & Prompts
• (08:20) - The protocol: Host-Client-Server
• (11:05) - Building your own MCP server
• (16:46) - Prompts, resources & tool functionality
• (19:45) - Developer flow & the Inspector
• (23:31) - Function limitations & return types
• (26:34) - Testing the tool & integrating other agents
• (28:46) - Community MCP servers & current limitations
• (32:11) - Summary & next steps

Data & AI: Technology Explorations is a biweekly show from Dataminded. Each episode a Dataminded engineer demos a tool or technique worth knowing about -- working code, honest takes, no hype.

Music by Aleksandr Karabanov from Pixabay

Creators and Guests

Host

Jonny Daenen

Head of Knowledge at Dataminded

Guest

Pierre Crochelet

Data Engineer at Dataminded

What is Technology Explorations in Data & AI?

Deep dives and practical demos on the technologies shaping modern data and AI development. Join the Dataminded team as we explore, unbox, and critically review the latest tools, from building AI agents and RAG systems to optimizing cloud costs and accelerating data pipelines. We cut through the hype to show you what actually works in real data engineering practice, complete with demo code!

How do you give your AI assistant superpowers? We see people extending their AI systems with all kinds of capabilities, sending emails or adding something to your calendar. How do they do this? Well, one answer, it's MCP, the Model Context Protocol, which is the topic of today.

Let's dive in. All right. Hi, everybody. Welcome to Technology Explorations here at Dataminded. In this series, we have a look at interesting or new technologies and give you a first look. Today, we'll be looking into Model Context Protocol or MCP.

And for that, I have invited Pierre. Welcome, Pierre. Hello. Hi. So you explored MCP and today we're going to focus on the very basics of it, the concepts, a quick demo, and then building our own MCP server. Yes, exactly.

It's really a one-on-one, how to get started, where to get started with MCPs. Okay, cool. I'd say let's dive in. I think the first thing to show is, well, what you can do. So today, we're mostly going to look at Claude Desktop and how it integrates with MCP servers.

And here, I've got a Claude Desktop, which is enabled with a file system MCP server. Wonderful. And for example, LLM agents, they're not able to perform any actions on my desktop. But with this file server, I can ask it, for example, can you list files on my desktop?

And then it will reach out to the MCP server and then it will list a load directories first. And after that, it will ask me to do a list of files. And then it will ask me to do a list of files. And then it will ask me to do a list of files. And after that, it will list all the files into this directory that it has access to. And we can see there will be two files, three files, Hello World, Whispers of Dawn, and just the .DS_Store typical Mac file.

So in this case, the AI agent was able to query your file system using the tools you provided. Yep, exactly. And then we can also... And then we can also... Show, for example, what's inside the Hello World file.

And then it will read the file and it will parse the contents from the file. Okay, nice. And this is all supplying information to the AI assistant? Is it also possible to extract or to let it do things? Because like writing files, this is reading information. What you just showed, can it also push information out?

Yes, exactly. We can indeed write a file. So we can write, for example, a grocery list on my desktop mentioning that I need to buy onions. Onions. Onions.

And then every time you can see the... This is... This is... This is the tool that it uses. And then it came up with a full grocery list, apparently. Not just onions, but I have a lot of stuff to buy now.

And then indeed, we can see on my desktop in this that it has access to the grocery list file with onions and everything else. When you set up the client, so maybe I can show that as well. In Claude, how to set it up, you go to Settings, you go to Developer View, and then there's this Edit Config, which points to where the configuration resides.

I actually have that open right here. So it's this file. And then the way I set it up, this MCP server that I'm using is the server file system, which is in the NPX package. And then this is where I specify where in my desktop, it has access to.

So it only has access to the MCP demo folder. Okay. And so when Claude starts up, it will read this file. It will see I have an extension, and the extension is then loaded with a specific argument limiting your scope. Yes, that is 100% correct.

Anyone can build an MCP server. It's actually fairly easy. It all resolves into some key concepts that we can have a look at. And then once you've got those nailed, you can get started and a couple lines of code, and you've got your MCP server ready.

Okay. So let's dive into the MCP concept. Yeah, perfect. So into MCP, the architecture revolves around three main concepts, the host, the client, and the server. The host is the entity that will run your large language more.

So the client is the model agent, and it's also responsible for creating and managing client to server connections. The client is going to be your bridge between your large language model agent and your server. Each connection between the client and the server is a one-to-one connection. It's a stateful connection, and it happens in three stages, with the first stage being the server, then you're having a protocol negotiation or an initialization phase, then you've got the operation phase, and then just the shutdown phase.

And then the server, that's the interesting part. That's the MCP. That's what provides external capabilities to your agent. So in what we just saw, the external capabilities were listing files on my computer, writing files, reading files.

Those are all things that, and then a little bit more, that the agent in itself is not able to do. But by connecting it to an MCP server, we add those capabilities. It exposes those capabilities as MCP primitives.

And there's three types of primitives, resources, tools, and prompts. We'll get back to this just in a couple of slides. And the interesting part of MCP is that it's made to be completely independent of the client. It's not independent of the agent itself.

So whether you're using an OpenAI agent, an Anthropic agent, or Gemini, or whatever agent, your MCP server does not change. It stays exactly the same every time. So as I mentioned, there's three main primitives that are exposed today.

There's server primitives, so tools, resources, and prompts. Tools are, I would say, to the 90-95% of what an MCP server is. It's all of the actions that the LLM can take on your behalf. And it's controlled by the model. So I ask a question to my LLM agent, and the agent itself decides whether it's going to use a tool or not.

Then you've got resources. Resources are informations that, well, we can provide to the LLM that it then reads. And it's just extra information, extra context for it to answer a specific question.

And then prompts, they're just templates. They're just instructions that you can give to an LLM agent. And then it just uses them, basically. So that happens in three stages. First, you've got the initialization. That's where the client connects to the server.

The server connects back. And both exchange their capabilities. And for now, mostly the server shows capabilities in the three primitives that I mentioned. It seems like there's some vision in the future for the client to expose capabilities as well.

That's not completely ironed out yet. And then once those capabilities are, known from both the client and the server, we enter the operation phase, where the client can query the server for specific capabilities that it knows the server can do, because it knows it learned about them in the initialization phase.

So in our example that we showed before, the server exposes a capability that is list files. And then when I ask my LLM in Claude to list the files in my desktop, it can then query the server to use that capability, that tool.

And then it can list the files. And then the rest of the connection is just a disconnect or a shutdown. And so in this case, in the case of Claude, you have the host and client bundled together. If you would write that yourself, you have to write your own host and use like an MCP client to connect.

In the case of Claude, it makes it about a bit more easy because you can just supply the server and they have the mechanism to connect those together. And when you connect that server then, it means it discovers the tools and the operations that you offer it, so it can use them when you prompt.

Yeah, that's indeed. That's the benefit of using a managed solution like the Claude Desktop application. You don't actually have to implement the protocol. You don't have to implement the handling of the clients, the managing the connections.

All of that is abstracted away. We just point in the config to where the server is, and then the exchange happens seamlessly. Okay. And so how does all of this magic happen? Well, basically it's code behind the scenes.

So tools, they're defined as mcp.tool, resources, just mcp.resources. And prompt, mcp.prompt. And these form the basis of what the server can offer. That's about everything you need to get started building your own.

I've created here a very simple mcp server. So the way it works in Python, it's fairly easy. There is an SDK to get started with mcp, which is the mcp SDK. And then you can just import fast mcp and create your server as easy as that.

And then you can define your tools, your resources and prompts. So here I've got two tools. One is a mcp.tool. And the other is a mcp.tool. One to read a file.

One to write a file. I've got one resource which is gonna fetch one of my inventories which is the item inventories. And then I've got one prompt which is to define what is an item that needs to be restocked. restocked. And so a prompt in this case is merely an example prompt or something like a shortcut.

Exactly. It's really just a template. So you can see it as something that you would often ask to an LLM agent. And instead of typing it over and over and over again, you just define it into a prompt and then you can just drag and drop it. And then the resources and the tool. So a tool is meant more like an operation and the resources is basically a piece of information that you want to have available. Yes, exactly. So the tool is, in my view, usually more dynamic. The read file tool, for example, I'm not especially telling it which file to read. So it could read any file.

Whereas if I'm looking at the get stock resource, well, technically it's doing the same thing, except that it always will ever read the items file. And so once you've got all of that, you can go back to this configuration. And now, instead of pointing it to the NPX server file system, I will point it to my demo server and hide it. How do we run it? We run it through uv. This is where my demo server is. And then the main file is this one basically.

Yep. The protocol exchange, as we saw, it happens only one at the initialization phase. So what this means when you're using Claude Desktop is that right now, I can't see my demo server, I can't see my tools, I still will always see the file system. So to force reloading here, we're just going to kill the application and then start it again.

And now it did the new initialization phase between client and server. So now I have my demo server with my two tools, read file and write file. And I also have my prompt here and my resource. So the tools appear in a separate menu than the resources and then the prompts. So I assume this is a different way of working when you need to use them. Yes, indeed.

And I'm not exactly sure why that is. I think that's something called Anthropic. It's not really decided. But indeed, here the resources and the prompts, since you're adding them, they appear next to everything else that you can add, like upload a file, use a project. And then the tools, they appear next to all other capabilities like connecting to Gmail or a drive.

So the tools I can just discuss with my model. And you can see that it's not just a simple file. It's a new file on my desktop. And then it does see write file and read file. Okay. It does say there, Claude can make mistakes.

Indeed. But I think it's just expecting me to give it a content. I don't know. I don't know. Content. Content.

World. And then it does it. Ah, yes. Now it asks you for permission. And it also shows you the exact arguments it will pass to your tool. Okay.

The way I've configured it, it always asks me before using a tool. You can also configure it so that it just runs the tool seamlessly. And now if we look here, I have my hello world file. So it used the tool that we defined here, the write file tool to create this hello world file. So that's for tools.

Now for prompts and resources, as I mentioned, you have to select them. So here I can get the resource. And then how many mouses do I have? This gives it the resource. And in my resource, I said I have two mouses. So then it reads the file from the resource and it exports it.

Now I'm curious about the prompts. Unless you have something else on the resources still to show? No, no, no. What I can show is... Well, you can add both at the same time, right? So here I've got my resource, which is my stock.

And then I've got a prompt, which explains to find the items to restock and the definition of what I call an item to restock. And then if I just pass both of these, I don't even have to say anything. Okay. It will combine the two. And then these are the items that I need to restock.

Okay, nice. So it does know the difference between the two attachments there, even though it's not showing anything. It does know that one is a prompt and one is a file. Or is it merely because of the contents that it now just looks at everything as one big flat file and because of that identifies the prompt? I don't have a definite answer. I have my best guess.

And my best guess is that it just dumps everything and then reads everything at once. It doesn't really make a difference between the two. Yeah. Okay, cool. It seems to me that what you showed me, the tools are very useful and can be very flexible. The resources and prompts, it feels like something that is still not very clear on how to use it.

And also, as you said also in the beginning, it requires user action to be added into the context. So it's still a manual action. The biggest value to me, it seems, the tools which are selected by the agent and are also invoked by the agent. So it's a more hands-off way of adding information. Yes, I completely agree with that.

I think currently tools make up 95% of the MCP specification. Everything that I would want an MCP server to do, I would do it through tools. Yeah. The only exception is maybe prompts sometimes could be useful to just reduce redundancy. If I know that I always make the same request to my LLM agent, then I can create a prompt and then it's just a simple drag and drop.

And that's it. Right. Can we maybe add something to the code and then see what the developer flow would look like? We can. We can completely. It's as easy as just decorating a function with mcp.tool.

That then creates a new tool. Then I'm going to add a function to list the files under a certain directory. And then from my understanding, I can add a new tool. Signature is quite important because this is also given to the LLM agent during protocol negotiation. So that it understands what the tool actually does.

Ah yes. So the MCP framework translates whatever you do here to the protocol where it offers that tool to the MCP client with the right signature. And the right documentation in this case. Yes indeed. And then that helps the LLM agent understand what the tool actually does.

Yeah. So it knows when to select it and also how to structure the arguments. So I imagine you can also add examples of arguments in this doc string. Yes, exactly. We could have it. So args.txt.

For example, this shows an example of how to call the tool with this directory, which is where I've got all of my inventory here. And then I can just... And just like that, that's a new tool. And then I can just... And just like that, that's a new tool.

And then I can just... And just like that, that's a new tool. And then I can just... And just like that, that's a new tool. Something that's quite cool to show is the developer view or what they call the inspector. The inspector is basically a graphical user interface where you can see all of my resources, all of my prompts, all of my files, all of my tools.

And then you can try them. If I want, for example, to use the list file tool that I just created. Well, I can use it. This way you can quickly test your function without going through the agent or without going through Claude in this case, because you also don't know how reliable that is.

And the development cycle is, I guess, also a bit annoying as you have to restart it all the time. In this case, you just trigger your functions with the right arguments. Another thing that I've seen is sometimes Claude will swallow the output. So if there's a simple, I don't know, indexation error in your tool, then you don't actually see the indexation error. Claude just tells you, hey, there's something wrong with the function and you don't really get a feedback.

So this is a way to actually see the Python error as it would show up. Yeah, then it will pop up here, of course, and then you can actually debug your code. Yeah, exactly. And is there a limitation? Because you wrote this function.

Is there a limitation on the arguments and the return type? Not that I've encountered. The only thing similar that I've encountered there is the inputs to a function where at one point I was trying to create a tool with a custom class as an input.

And that was a bit tricky to get working because, well, Claude does not know how to do that. How to pass in that argument for the custom class that you've created. There might be a way to make it work.

I couldn't. But yeah, that was maybe a limitation. There needs to be translation, of course, to the clause or data clause or whatever you're using there. Yeah, indeed.

The simplest is just to pass in strings and lists and stuff that's like Python native. Primitive types, yeah. And also, the return type, is it always a list of strings that you use?

So if you do calculations, I can imagine you would want your function to be a bit more strict and just return a float. Would that also work? Maybe we can test that out. Would you like to have a tool that returns a float?

Yes. Naming is difficult, so that's maybe called return float. Okay, that's good. I'm wondering, if you use the decorator, if it will use the type hints in its contract with the MCP server.

Because in the end, I guess the decorator makes sure that whatever your server provides as an API is generated automatically based on these functions and their signatures. Oh, no, you do see a return type.

Ah. It's just, in a JSON format. So if you reload this with our float function, we should be able to see a return type of, I expect float, but not sure.

It is a number. Ah, yes. Okay, because it's probably materialized as a JSON. Yeah, indeed. In JSON, so the JSON type would be number in this case.

Yes, probably. Okay. The, the actual protocol is written on top of JSON RPC. So, indeed, I guess input types and return types are all materialized into JSON.

And then this just returns my beautiful float. It works. So now our Claude application should be able to access our new tools.

Indeed. Given a restart. Given a restart of always. Always. And a quick check is always to check here.

And then you can see, indeed, it has return floats. It has list files. Provide a float number. This is a killer app.

Yeah, indeed. I'm also very inspired. And then you can see, indeed, it's using the newly created tool. And it's, it's, it has returns.

Very nice Pierre. Okay. Looks good. So we basically extended your MCP server with some custom new functions. And we explored the three different types. The tools, the resources and the prompts.

And we got our Claude Desktop working with those tools. Yep. Indeed. What about changing your AI assistant you showed us Claude Desktop.

What if I would use OpenAI. in AI, if I would use Gemini, are they using the same features? Have you looked into that? Right. So, well, the ultimate goal is indeed that you can use any AI agent. Now, the AI agent has to implement the MCP protocol.

So it has to know about tools, it has to know about resources, it has to know about prompts. As far as I know today, the only one that we looked at was OpenAI. And OpenAI is limited to only tools. And I think only two types of tools, which is search and fetch, I believe. So in your MCP server, you can only have two tools, one called search, one called fetch, and that's it. But again, I believe with all the traction that there is around MCP, and this is a very fast-moving world, I believe this is something that we can expect to grow quite recently in the future.

I thought this was a cool part. There is a lot of MCP server from community that you can connect to, try out. This is basically all the list. So you can host these locally on your machine and then give it to Claude and have all the tools that you need. And then you can also have all the tools that you need.

And then you can have all the tools that you need. And then you can have all the tools that you need. And then you can have all the tools that you need. And then you can have all these MCP servers there. And then I can control my Spotify or whatever. Yes, exactly.

Exactly. There is indeed one from Spotify. I've tested this one. It was quite funny. So I can just have a conversation with Claude and it's created a playlist. It's muted my Spotify.

It paused it, played it, can do a bunch of stuff. Okay. Something I was wondering. I'm a heavy user of the voice mode of ChatGPT. Claude has one as well, I think. Are these MCP servers also available in that mode?

Because I believe in OpenAI, they don't allow it in that setting. That's a very good question. I have never tried this. Because that's a bit of an annoying thing. I've experimented with the built-in connectors. Claude has these as well for Gmail or Google Calendar.

OpenAI has offered them as well. But they're not available in voice mode. So I'm not sure. So when I'm driving, I cannot use them to check my calendar. It's a first world problem, I know. But it's still quite annoying.

Yeah, I'm wondering. Okay, you need to get back to me on that, Pierre. I will get back to you, yes. I also see these default connectors. So they're also available, I guess. You can search or drive Gmail and Calendar.

But they're only listed as search. So they're not offering actions yet. It's only pulling out information and feeding that to your LLM. It's not doing anything yet at this point. Yes, indeed. I'm not sure these are full, complete MCP servers.

I think they're just still quite limited. What is your basic takeaway in terms of experience? Positive and negative? Positive? I think it's... I think it's pretty cool.

And I do see some value in repetitive tasks. I think that's the main thing that I would use an MCP server for. For repetitive tasks, if you... I don't know. If you always go to the same URL to begin the day and you want to do that through a chat interface, then I think it can be quite useful.

The less... The funny part is that it still feels pretty new and pretty rough around the edges. So we see that with the resources, the prompts, even the tools somehow feel a little bit limited in what they can do.

So I'm really looking forward to how this can evolve and all of the extra capabilities that we can have from it. Okay, nice. So I'm going to try to summarize what we covered today. So if I understand correctly, we have looked into MCP, the Model Context Protocol.

It does allow you to extend AI assistance like Claude, which we looked at with new functionality. That functionality can be prompts, resources, and tools. The real power comes from the tools. And there we have full flexibility in terms of code that we couldn't put behind.

We explored that in a local setup. That can be lifted to a more production setup when we host that. We haven't looked into security or anything like that. That's a topic for a whole new session, I think. But you still feel it's still quite clunky. It's still not entirely stabilized.

The concepts are still evolving. And then also many questions still around the development cycle and how it will evolve. Yes, I think that's a perfect summary. Maybe a good point is you have a code room, a repository created with some demo code for people to try out, right?

Yes, indeed. It's a public repository. It's here. There's a quick kickstart. But as you've seen during the demo, it's very easy. This is how you set up the Claude Config.

And then that's it. You can extend it with whatever you want. Any tool, any resource, any prompt, anything. Okay, cool. We'll add the link to the notes. And I think we can wrap it up here.

Yes. Well, thank you for hosting. Thanks for giving us the first MCP 101. So it was quite insightful. Good view on the theory and how to bring it into practice. So thanks a lot, Pierre.

So thanks, everybody, for watching. I hope we gave you a good overview of the first version of MCP. And I'll see you next time. Bye-bye. Bye.