11:19Matt Pocock · Tutorial
How To De-Slop A Codebase Ruined By AI (with one skill)
AI coding agents accelerate software entropy into shallow mud unless you enforce deep modules, strict seams, and human architectural judgment.
April 29thRead if. Skip if.
READ IF YOU ARE…
- You are an AI engineer looking to connect Claude Desktop or Cursor to proprietary tools and local databases.
- You want to understand the exact client-server-tool flow of the Model Context Protocol without vendor hype.
- You are designing safety controls like human-in-the-loop approvals and prompt-injection guards for autonomous tool execution.
SKIP IF…
- You only need simple one-off Python scripts or standard REST API endpoints without conversational agent interfaces.
- You are seeking a line-by-line coding tutorial rather than high-level architectural Miro boards and live end-to-end testing.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Create a free account →Where the time goes.
00:00 – 01:56
01 · What is MCP?
Definition of Model Context Protocol, the 3 core parts (Client, Server, Tools), and how Claude Desktop acts as the client.
01:56 – 03:06
02 · Why Use an MCP Server?
Contrasting manual copy-paste workflows with conversational execution where Claude coordinates multi-step actions.
03:06 – 04:28
03 · When to Use It (And When Not)
Criteria for choosing MCP: databases, actions, and cross-client tools versus simple one-off scripts and standard APIs.
04:28 – 07:07
04 · Tool Call Step-by-Step
Walkthrough of how Claude reads tool manifests, matches queries to tool descriptions, requests permissions, and synthesizes answers.
07:07 – 08:36
05 · The Big Picture Architecture
Diagramming how Claude Desktop connects to the MCP server, rag-motion RAG system, vector embeddings, and the wger tracking platform.
08:36 – 11:48
06 · How We Built It: M0 to M7
A modular build roadmap from initial Python setup and MCP Inspector testing to full Docker wger integration and automated evals.
11:48 – 13:30
07 · Three Crucial Safety Ideas
Enforcing safety: human approval for data mutations, treating external app notes as untrusted injection vectors, and letting code calculate numbers.
13:30 – 13:57
08 · The wger App Setup
Brief tour of the local Docker wger instance displaying Sarah's client profile and routines.
13:57 – 16:28
09 · Live Demo in Claude Desktop
Running a live query in Claude Desktop, authorizing tool calls, retrieving workout logs, and generating evidence-backed progressions.
16:28 – 16:52
10 · Conclusion & Outro
Summary of MCP benefits and standard YouTube call-to-action to like and subscribe.
Lines worth screenshotting.
- MCP establishes a 3-part topology: the client (e.g., Claude Desktop), the MCP server (the Python or TypeScript bridge), and the external tools/resources.
- Without MCP, every AI model requires unique bespoke integration code for every external tool, database, or API.
- Claude discovers capabilities dynamically: upon establishing connection, the MCP server provides a tool menu containing exact names, descriptions, and schema parameters.
- LLMs should never calculate mission-critical math directly; your deterministic code should execute algorithmic rules and passing identifiers while the model handles interpretation.
- Client database notes must be treated as untrusted data inputs, flagging prompt-injection phrases so the LLM cannot be hijacked by arbitrary user comments.
- Destructive or state-changing tools (such as saving new training programs to a database) should mandate human-in-the-loop confirmation before firing.
- Single-workflow automations and isolated chatbots do not warrant MCP; direct function calls and lightweight API calls remain simpler.
- Testing agentic workflows requires evaluating tool choice accuracy across dozens of prompts with guards enabled and disabled rather than relying on a single working demo.
Building reliable agent systems requires decoupling reasoning from deterministic execution
ARCHITECTURAL BLUEPRINT
Model Context Protocol allows developers to separate natural language reasoning from strict deterministic business rules and database mutations.
01What is MCP?
- MCP standardizes tool access so one server implementation works identically across Claude Desktop, Cursor, and custom agent frontends.
02Why Use an MCP Server?
- Connecting live databases to LLMs transitions conversational interfaces from giving abstract advice into executing concrete system workflows.
03When to Use It (And When Not)
- Avoid MCP overkill: if a workflow is static, linear, or handled cleanly by a single REST endpoint, standard code remains superior.
04Tool Call Step-by-Step
- Tool calling succeeds when description strings clearly declare what questions each tool answers and what schemas it expects.
05The Big Picture Architecture
- Architect systems with distinct layers: the conversational LLM sees only the final tool output, not internal vector retrieval mechanics.
06How We Built It: M0 to M7
- Develop MCP servers progressively by validating minimal single-tool implementations in the MCP Inspector before adding multi-agent logic.
07Three Crucial Safety Ideas
- Never allow LLMs to calculate mission-critical numerical increments or obey instructions embedded within user data fields.
08The wger App Setup
- Local open-source software running in Docker containers provides an ideal sandbox for testing AI tool mutations safely.
09Live Demo in Claude Desktop
- Human approval prompts provide essential verification before irreversible database writes occur.
10Conclusion & Outro
- Production MCP deployments require extensive prompt evaluation sets to verify consistent tool selection under varied phrasing.
Things they pointed at.
00:39toolClaude Desktop
00:41toolClaude Code
00:41toolCursor
01:44toolPython
07:24toolDocker
07:34toolOpenRouter
08:11toolGemini
Lines you could clip.
01:53
“Before MCP, every AI needed its own custom connection to every single tool. So MCP is one connection that works everywhere.”
06:35
“The AI is good at question and writing the answer. Our code is good at facts, rules, and actions. So, MCP lets each part of the system do what it's good at.”
12:00
“one good demo can prove it can work, not that it always works or usually works.”
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
What's up guys? Welcome back to the AI Jentech Bros YouTube channel. Today we're going to be diving into MCP and MCP servers.
I'll be going off the project that I built in the last video where I went over creating rag systems. So if you want to go check that out for some more context and some great information on rag, feel free to do so. All right, so without further ado, let's get straight into this video.
All right, so what exactly is MCP? MCP stands for model context protocol. It's basically a standard way to connect AI assistants to tools and data.
You build one small program which is called the MCP server and any app that speaks MCP can use it. So things like Claude desktop, Claude code, cursor. Most of the time online I've seen people using Claude desktop as the example and that's what we'll use for our example today.
So in three simple parts, you have the app you talk to or the client, Claude desktop. Then you would have our program or our MCP server. For this project we're going to call it Rag Motion MCP.
Then you have the tools, resources, anything else you want your AI assistant or app to be able to talk to. So you have the client which is Claude desktop, the MCP server and then it's able to use that to communicate to these tools and resources. The MCP server is a small program that follows that MCP standard.
So I wrote mine in Python. You can write it in other languages as well. And basically when I open Claude desktop, it starts my server and I can directly use Rag Motion, the rag system that I built, to search my exercise research, build programs, and then save them into my client's workout app.
Why do MCPs matter? Before MCP, every AI needed its own custom connection to every single tool. So MCP is one connection that works everywhere.
Now why would we use an MCP server? So, before using RagMotion as the example, RagMotion lived in its own webpage.
So, a coach would build a program there, copy it by hand or into, you know, a client's app that they're using. And in order to check progress, the coach would open the tracker separately and work out the next steps themselves. Versus now using MCP, the coach is able to talk to Claude.
For example, build Sarah a program, save it to her app, how is she doing? Things like that. Everything can be done from inside Claude because we're able to communicate with these different tools.
Claude uses our tools for each step in the program. Claude uses our tools for each step in the program and her logs live in her real tracker app. Why is better to use an MCP?
You can build it once and use it in any AI app. That AI works with real current data instead of guessing. And also, the AI can take action, so saving a program, um >> [clears throat] >> making the next program based off of, you know, the past couple of months of work, things like that.
It's not just advice. When should you use them and when should you not? You should use an MCP when an AI should use data you have.
So, if you have a database, documents, customers' records, use it when an AI should take actions in your system. So, saving things, sending things, booking and updating. And if you want the same tools in more than one AI app, you don't need an MCP server when you have a one-off script, a single workflow, um s- places where a normal function or API call would just be much more simple.
If you have a chatbot that doesn't need outside data or actions, situations like that, an MCP would either just be unnecessary, overkill, or just not work. So, why does this matter? This The skill is now connecting AI to real systems correctly and safely.
So, MCP is becoming a standard. It's MCP is how so many companies connect AI assistants to their own systems, so their own databases, internal tools, applications. Major AI apps support it, and AI engineering jobs are always looking for MCP experience.
It's It's very easy to connect things. The hard questions are, does it pick the right tool? Does it use data correctly?
And is it safe when it changes things? So, those are the questions this project answers with tests. All right, so how do MCP servers work?
Right here I have a few keywords. You can pause and take a look at that if you need to. Here's what a step-by-step tool call would look like.
So, the coach would go ahead and type into Claude, "How long should Sarah rest between sets?" So, the process that it would follow would be, number one, Claude would read the menu. When it connects, Claude gets our tool list, so each tool's name, description, input rules. So, when we use Rag Motion in our example, Claude is able to see that as a tool that's connected.
So, Claude then would go to step two, pick a tool. It It matches the question to ask {underscore} question, which is a tool within Rag Motion, because that tool description says it answers questions about rest, sets, and rep and reps.
So, number three, the app asks permission. Before any tool runs, the person can allow or deny it. If you use Claude code, it's It's basically just like, "Do you approve this action?" So, you can approve, you can reject.
I I'm pretty sure you can set it to always be able to automatically use certain tools. Then after you hit approve, it would go ahead and the server would go ahead and do the work. So, you have Rag Motions.
So, for our example, Rag Motion searches the research, writes an answer only from what it found, and then checks every citation. The result would come back structured data, and it has the answer, the citation IDs, the source passages, and anything it couldn't answer as well. So, then Claude, after receiving that back, writes the reply, and it would have, for example, 1 to 2 minutes for a beginner, and the citation there from Iverson, 2021.
And longer rests have a small edge for growth, and another citation from there. So, why does it work this way? The AI is good at question and writing the answer.
Our code is good at facts, rules, and actions. So, MCP lets each part of the system do what it's good at. Here's a little illustration of the bigger picture.
So, of the process that we talked about, you would have the coach asking client, the Claude desktop. It would go to our server, the RMCP server here. Now, you're going to see two branch outs here.
This would be Rag Motion would be the tool that we built that's specifically going to answer these questions about uh you know, these fitness coaching questions. >> [clears throat] >> And as you can see here, this is like where the database would be. And you know, open router, we have our embeddings and the models for that.
And then WGR, which is basically just a open-source workout tracker. That's where it would go ahead and be able to, you know, display all the exercises, track the exercises for the client. And because we have the MCP server, cloud from cloud desktop, we're able to actually, you know, save changes, make updates to the um workout app.
So, yeah, there's two kinds of AI plus the code. You have cloud, which is the assistant that talks with the coach, decides which tools to call, writes the final reply. And it only sees what our tools would return.
Then you have rag motions models, so that's what's inside the tool. You know, we have the voyage embeddings, we turn the text into numbers, that allows the search to find passages by meaning. We also have, you know, Gemini that writes rag motions answers.
And it runs its program agent that creates the full programs. Cloud would only see those results, it would never see the steps that we take or that that rag motion process takes by itself. How I built this step by step.
Now, I split into seven simple steps or eight if we count zero. So, module zero, we built a new Python project that imports rag motion instead of copying it. I didn't want to, I just copied the previous project that I did just to be able to, you know, experiment it.
Didn't want to mess up, kind of, you know, what I built before. Um then module one, we had our first tool, which was search exercises. Uh you know, with equipment and level filters, we tested that in the MCP inspector, then in cloud desktop.
So, MCP inspector, and I'll throw it on the screen, is basically is basically a way to view, you know, what's going on on your MCP server, so then you can see, you know, what tools are being called, what functions do you have within those tools, things like that. The reason I did that was to start with the smallest working tool to learn how cloud is finding and to learn how Claude finds things and how it calls certain functions.
Next, module two, we had rag motion as tools. So, what does that mean? We built ask questions with decided answers, searching sources, build programs.
>> [clears throat] >> Those are all, you know, the functions within rag motion. We basically brought the whole rag system and agent into So, now we're able to bring into any AI app. Uh with results with type results, so Claude knows, you know, every field that Next, I had the tracker WGER, which was an open-source workout app.
We I had that running in Docker on the laptop locally. And if we created a fictional client and an API key for her. So, the reason we did that, programs need a real home where the client trains and logs.
That app already had a full API and a phone app. So, it just made it so much easier and straight forward for me to test it out. Module four was saving.
We had a save program to WGER. So, plus the coaches reviewed map of our ex- of our 60 exercises that I had from rag motion. We had those, you know, lined up with the IDs for the exercises in there.
So, the coaches now able to know how is the client doing. And Claude explains it with sources. Module six was super important.
We tested it. We ran evals. So, we had 22 requests for tool choices, planted notes with the guard on and off, and the full loop end to end.
So, we really tried to test everything. The reason why we did so why I did so many is because yeah, one good demo can prove it can work, not that it always works or usually works. Last but not least, you know, made like, you know, the read me, honest rules, you know, the limits and then made the video plan for this.
So, part four was making it safe and proving it works. So, what makes this MCP server um secure and in terms of like is it going to make changes to sensitive parts of the application um without permission, things like that. So, things that I put in place, we had I had three main safety ideas.
Ask before changing data. So, the would change the tool that actually change data, which was saving the programs to the WGER app.
Uh we make I made sure to mark it that way, so that way the app asked the person first. So, I mean, the reason the reason why is because an AI can misunderstand, and a person should approve anything that it writes. So, an example would be save it to her tracker that would always show an allow or deny prompt before anything is saved.
So, we have that human in the loop just for extra security. Text from the app is untrusted. So, notes typed into WGR reach Claude labeled as untrusted data.
So, instruction-like phrases are flagged, and the server rule says never follow them. Now, the reason why I did that is because anyone with the client's login could type a note, and then the AI would read it. So, we ignored those instructions, and then save this program was flagged, shown to the coach as a warning and not obeyed.
Last but not least, the AI does not copy data or pick numbers. So, Claude passes a short program ID instead of retyping the whole program, and the code decides next week's next week's weights. So, AI models aren't reliable copiers of big data, and training numbers must follow the coaches rules exactly, especially when it comes to, you know, these fitness kind of things.
We're actually in the WGR dashboard. Here is the Sarah demo dashboard that I have. As you can see, we didn't put too much here.
I just have the routines, cuz that's what we're mainly focusing on. And, you know, we have full body A, full body B, full body C. And, here are some of the exercises that are available.
I'm going to switch over to Claude Desktop. All right, here I am in Claude Desktop. I'm going to ask it a couple questions, just so you guys can see how exactly Just so you guys can see how exactly Claude Desktop interacts with our Rag Motion tool and the fitness tracker app from via the MCP server.
So, let's go ahead and do a simple message right here. >> [clears throat] >> All right, so Sarah's been doing this three-day workout routine, full body workout routine, for the past month. You analyze the current workout.
Explain to me why you picked that. And then, what should her progression be in the next 2 months? Yeah, let's see what it says to that.
Right there, it's loading tools, so it needs my input. This is what I was talking about, where it's going to ask. This is the human in the loop.
So, yes, allow once. Fetching this information from Rag Motion. Again, it's going to, you know, All right, so this is kind of what I actually expected because it is an actual tracking app and I'm trying to, you know, flash forward hypothetically.
But so after it called the tool, it's showing what the log shows. There is a logging gap. First, only day one has entries.
Yep, because I didn't update it accordingly and October 19th is in the future. >> [clears throat] >> But it was able to call my tool and using the rule from tool, it has right here it has progressions. Two reps in reserve, increase the load plus 5%.
Why the program is built this way and explains why exactly. And here it has all my sources cited. And I'm able to create a document based off of that as well.
So yeah, that's just a quick kind of demo just so you guys can visualize how we're able to talk from Claude desktop or whatever you may be using via the MCP server to different tools that we have. I I hope you guys enjoyed this video. Please like and subscribe and I'll see you guys next video.
The Hook
The bait, then the rug-pull.
The creator introduces Model Context Protocol using a comprehensive Miro board, linking back to his previous RAG build before diving straight into the architectural definitions.
Named ideas worth stealing.
00:53model
The Three Parts of MCP
- Client (e.g., Claude Desktop)
- MCP Server (local Python/Node middleware)
- Tools & Resources (databases, APIs, RAG systems)
The standardized architecture separating conversational user interfaces from server middleware and external computational backends.
Steal forexplaining AI agent system integrations to engineering and product teams
12:21list
Three Safety Ideas for MCP
- Ask before changing data (human in the loop)
- Text from the app is untrusted (prompt injection filtering)
- The AI does not copy data or pick numbers (deterministic logic in code)
Three core security guardrails preventing rogue automated actions, unauthorized database modifications, and LLM hallucinations.
Steal forsystem security reviews before shipping autonomous tool-calling agents
How they asked for the click.
VERBAL ASK
16:38subscribe
“Please like and subscribe and I'll see you guys next video.”
Casual spoken sign-off after completing the live Claude Desktop query demo.
Visual structure at a glance.
