Exploring MCP Architecture: How LLMs and Tools Interact

Most RAG systems fail at this simple question: "What's the most common GitHub issue AND what are people saying about it?" Vanilla RAG follows a simple pattern: query -> retrieve -> generate. It's effective for straightforward question-answering, but struggles when tasks get complex. Let's say you ask: "What's the most common GitHub issue from last month, and what are people saying about it in our internal chat?" Traditional RAG would try to match your entire query to one knowledge source. It might find something relevant, but probably not exactly what you need. Agentic RAG works differently: 1. 𝗣𝗹𝗮𝗻𝗻𝗶𝗻𝗴: The agent breaks down your query into subtasks (select a tool to query the GitHub issues from last month, build a query to fetch the most common one, search internal chat for mentions) 2. 𝗧𝗼𝗼𝗹 𝗨𝘀𝗲: It routes the first part to your GitHub database, gets results, then routes the second part to your chat system using context from the first search 3. 𝗥𝗲𝗳𝗹𝗲𝗰𝘁𝗶𝗼𝗻: The agent validates the retrieved information and can re-query if something doesn't look right This is really promising for complex queries that need multiple data sources or multi-step reasoning. 𝗧𝗵𝗲 𝘁𝗿𝗮𝗱𝗲𝗼𝗳𝗳𝘀: Agentic RAG typically requires multiple LLM calls instead of one. This means added latency and cost. It is also much more complex to develop, deploy and maintain. Here's my recommendation: For many use-cases, a simple RAG pipeline is sufficient, but if you are dealing with complex queries, response quality is very important and your users can afford waiting a few extra seconds - an Agentic RAG workflow is probably better suited for your use-case. The architecture can be simple (a single router agent) or complex (multiple specialized agents coordinating). You can have one agent that retrieves from your internal docs, another that searches the web, and a coordinator that decides which to use. For more information, my colleagues did a very nice Blog post about the different Agentic workflow: https://lnkd.in/eS2mFxUF

When your tools are brought into chat, something interesting happens. Queries become documentation. Deployments become teaching moments. Cost checks become shared context. The Glue + Supabase MCP doesn't just save time switching tabs. It makes your team's database knowledge accessible to everyone, right where decisions are being made. Learn how → https://lnkd.in/eeaSkg8D

For Claude Code, what’s the difference between sub agents, skills, mcp, slash commands and hooks? Skills - these are akin to “wake words” in your prompts that trigger a fix set of workflows. They are meant to run in the background to steer Claude. My personal use case: backend testing skill. Instead of repeatedly asking Claude to read a lengthy doc, as we have our own auth; Claude knows how to authenticate in our SaaS setup and test the backend implementations. all I need to say is “test the backend”. Sub agents - extremely useful for refactoring. If you need a lengthy, repeatable task, such as long context data migrations. You can use sub agents to spin up parrallel workers to get the job done. This will make your laptop hot and burn thru credits fast. Worth it! Think of mcp like excel for ai agents, where they will use it in combination with skills to use excel the way you want it to use. My ai agents use my Sql server mcp, one I wrote myself to transverse our development and product databases. Slash commands - useful for intentionally triggering workflows. Like how I like my git commits done. There’s still hooks, sandboxes! So many features in Claude code! There’s never been a better time to learn how to use the CLI to code!

You've been able to set env vars in images since day one (kinda important) and a long time ago one of our users wrote a lib to talk to external secret stores to inject them at runtime, but there are many many times when you can't, or don't want to use an external store but also don't want to store stuff in the image either. It's not like you can just ssh into these things and add these later. However, a new lib cut by yet another one of our illustrious users allows you to now inject them at instance creation time allowing you to use the same image but diff envs by going through the clouds IMDS. Wait.. You can't run random shell scripts or commands or other things like that on a unikernel - there simply is no architectural support (designed on purpose) so user data doesn't make a lot of sense here does it? Not so fast.. At the end of the day the IMDS is just a little webserver that you can stuff data into (it does many other things but this is one function that it provides). Typically user data is done at a "system" level and the "application" level is provisioned differently. That's old school though. Since each application *is* a virtual machine in unikernel land this actually becomes a lot more useful and allows different types of deploy workflows. This also makes a lot more sense to do on a unikernel than on a corresponding linux instance as there isn't the interactive userland nor are there multiple programs, users, etc. and is another example of tighter pairing with cloud primitives as you can find this on all the major public clouds. Finally, we didn't come up with this - one of our users did and shows the type of free thinking that this tooling opens up. Give it a spin - let us know how it goes.

🌐 Build Your Own MCP Server — and Connect It to *Any* MCP Client (Claude, VSCode, GitHub, and More) Imagine building a tool once… and instantly using it across Claude Desktop, VSCode, GitHub, or any future AI platform that supports MCP. Welcome to the next evolution of AI/tool interoperability. MCP (Model Context Protocol) is an open-source standard designed to enable seamless integration between LLM-based clients and external systems/tools/data sources. :contentReference[oaicite:1]{index=1} It defines how clients (which may wrap chat-apps, IDEs, or other AI interfaces) connect to servers exposing context, tools, resources, and prompts — abstracting away most compatibility issues. :contentReference[oaicite:2]{index=2} You don’t have to reinvent the wheel — there are reference MCP server implementations available to get you started: Repo / SDK / Server Description / Key Features GitHub MCP Server — github/github-mcp-server A server that connects AI clients to GitHub: enables reading repos, managing issues/PRs, analyzing code, automating workflows via natural-language inter https://lnkd.in/gKt5k2MA

🌟 Day 66 of #100DaysOfDevOps | Deploying MySQL on Kubernetes! 🌟 Today’s focus was all about taking a classic database MySQL and giving it a home inside Kubernetes. Moving from stateless to stateful workloads was a major step up in complexity, and a great learning curve toward production-ready architectures. ✅ What I Accomplished 🏗️ Created a PersistentVolumeClaim (PVC) to ensure MySQL data remains intact even if pods restart. 🔐 Used a Kubernetes Secrets to securely store database credentials. ⚙️ Defined a Deployment manifest with volume mounts and environment variables referencing the Secrets. 📡 Exposed MySQL via a NodePort Service, allowing applications to connect safely within the cluster. 🧠 Key Learnings 🔹Stateful applications need persistence, MySQL can’t lose data when a pod restarts. 🔹Secrets management is critical - never hardcode passwords in YAML files. 🔹Declarative configs = predictability - version-controlled YAML keeps deployments consistent across environments. 🔹Learned how to balance storage provisioning, environment configuration, and deployment reliability - the essence of production-grade Kubernetes! 💬 Final Thought 🔹 Each passing day in this challenge reminds me that DevOps mastery is built one YAML, one container, and one deployment at a time. 🔹The #100DaysOfDevOps journey isn’t just about completing tasks - it’s about discipline, curiosity, and community. 🔹Deploying MySQL on Kubernetes wasn’t just another configuration exercise - it was a deep dive into how real-world systems store and safeguard data, even in a dynamic cloud-native world. 🔹As I continue this journey, I’m realizing that DevOps is a mindset - a blend of engineering excellence, automation, and collaboration. 🔹Every day adds a new layer of understanding, and every failure teaches something that books never will. So here’s to persistence - both in storage and in learning. 💪 Keep deploying. Keep breaking. Keep improving. 🔗 Full guide with YAMLs and explanations: GitHub Repo – 100 Days of DevOps https://lnkd.in/gfisdVVC #DevOps #Kubernetes #MySQL #StatefulWorkloads #100DaysOfDevOps #CloudNative #KodeKloud

How to Design Good APIs 👇 A great API feels invisible; it just works. Behind that simplicity are a few core principles that make it predictable, secure, and scalable. Here’s what separates a well-designed API from a confusing one 👇 [𝟭.] 𝗞𝗲𝗲𝗽 𝗜𝘁 𝗜𝗱𝗲𝗺𝗽𝗼𝘁𝗲𝗻𝘁 ◾ Think of idempotent methods like pressing an elevator button — pressing it twice doesn’t make it arrive faster. ◾ GET, HEAD, PUT, and DELETE should always return the same result when called multiple times. ◾ POST and PATCH, on the other hand, can create or modify data, so each call might change something. ◾ For reliability, use idempotency keys stored in Redis or your database. When the client retries with the same key, the server recognises it and returns the original response. [𝟮.] 𝗩𝗲𝗿𝘀𝗶𝗼𝗻 𝗬𝗼𝘂𝗿 𝗔𝗣𝗜 ◾ Use versioning paths like `/api/v1/users`. ◾ It allows you to make improvements without breaking existing clients. [𝟯.] 𝗨𝘀𝗲 𝗡𝗼𝘂𝗻𝘀, 𝗡𝗼𝘁 𝗩𝗲𝗿𝗯𝘀 ◾ Endpoints should represent resources, not actions. ◾ Example: `/api/products` instead of `/api/getProducts` [𝟰.] 𝗦𝗲𝗰𝘂𝗿𝗲 𝗘𝘃𝗲𝗿𝘆 𝗥𝗲𝗾𝘂𝗲𝘀𝘁 ◾ Always use HTTPS to protect data in transit. ◾ Use authentication tokens such as JWTs, which include a header, payload, and signature. ◾ Validate tokens on every call to keep APIs safe. [𝟱.] 𝗛𝗮𝗻𝗱𝗹𝗲 𝗟𝗮𝗿𝗴𝗲 𝗗𝗮𝘁𝗮 𝘄𝗶𝘁𝗵 𝗣𝗮𝗴𝗶𝗻𝗮𝘁𝗶𝗼𝗻 ◾ When returning large datasets, use query parameters like `?limit=10&offset=20`. ◾ This keeps responses efficient and improves performance. Designing APIs isn’t just about making them work. It’s about making them predictable, secure, and easy to maintain. __________ ♻️ Reshare if you found this helpful. ✅Follow Jafar Muzeyin for daily tips 📺 Watch more on my YouTube channel: [https://lnkd.in/eBmq2kuY] Reference -> ByteByteGo

💡 How to Design Good APIs 👇 Reposting this must-read for developers, architects, and engineers building systems that scale and integrate securely. Good API design isn’t just about functionality — it’s about clarity, consistency, and usability. Thank you Jafar Muzeyin A well-designed API helps teams ship faster, reduces integration errors, and improves security by design. 💡 Key Principles of Good API Design: ✅ Simplicity — Keep endpoints clear and predictable. ✅ Consistency — Use uniform naming, structure, and response formats. ✅ Documentation — Provide examples, versioning, and error codes. ✅ Security — Enforce authentication, rate limiting, and input validation. ✅ Maintainability — Design for scalability and backward compatibility. Great APIs are invisible — they just work. Because when you design for developers, you design for success. #API #SoftwareDevelopment #CyberSecurity #DevSecOps #CloudEngineering #Upskillz

This Unified MCP server connects you to 500+ apps and auto-routes queries to the correct MCP server in real-time 🤯 Here’s the problem: Loading an AI agent with 100s of MCP servers looks like the right thing to do. And that’s when you say hello to “context rot”. Open Rube solves this with intelligent tool routing that discovers and loads only the tools you need, when you need them. Instead of bloating your agent's context with hundreds of unused servers, Open Rube's Tool Router identifies the right tools from 500+ app integrations based on your actual intent. Here's what makes it different: → Dynamic tool discovery: Only loads relevant tools per request → Zero manual configuration: No need to pre-define which servers to load → Parallel execution: Runs multiple tools simultaneously when needed → Smart authentication: Handles OAuth and API keys automatically → Session-based architecture: Maintains context without bloat The flow: User Input → LLM analyzes intent → Tool Router discovers relevant tools → Loads only what's needed → Executes → Returns clean response Works with 500+ apps including Slack, GitHub, Notion, Google Calendar, Jira, and HubSpot. No context rot.  No manual tool management.  Just efficient execution. It's 100% open source. Check it out: https://lnkd.in/dJGWBdxr More such AI tools and projects in theunwindai.com: Get access to 100+ AI Agent, RAG, LLM, and MCP tutorials with open-source code - All for FREE.

I didn’t adopt MCP because I’m smart. I was drowning in glue code. I tried it once, and suddenly, everything clicked. Here’s the exact playbook I wish I had 90 days earlier. What MCP is (in one line) → A universal layer for exposing tools and data to LLMs. Think “contract-based API” so everything can talk to everything else, reliably. What happened when we used it ✅ Cursor MCP client → our MCP server → Supabase → webhooks → Claude reply ✅ Legacy trades biz synced, no vendor SDKs ✅ Lead routing shrunk from three microservices to one endpoint ✅ Fewer brittle hacks, more modular, snap-together systems Five fast moves to steal ✅ Pick one workflow. Don’t boil the ocean. ✅ Wrap real tools (DB, files, CRM) as MCP tools, not prompt soup. ✅ Keep glue tight (~30–50 lines per tool). ✅ Track every step (trigger → action → result). ✅ Reuse across teams. Don’t rebuild. When NOT to use MCP If a webhook and a SQL query solves it, do that. Complexity is a tax. Today, most of our ops start with MCP. Fewer meetings. Faster shipping.. If you're building real AI workflows, follow me. Operator-grade builds, no fluff. And resharing this could save someone a week. Props to Daily Dose of Data Science for the original doc.