# Mastering MCP: The Secret Power of Resources and Prompts in AI ## Summary This guide demystifies the 'Resources' primitive within the Model Context Protocol (MCP). Unlike tools, which execute actions, resources serve as read-only knowledge interfaces that provide structured context to LLMs. The article explores the mechanics of text vs. binary resources, the distinction between direct resources and URI templates, and the critical 'application-controlled' access pattern that separates MCP from traditional function-calling architectures. ## Content Beyond Tools: The Three Pillars of MCP What You Need to Know Resources vs. Tools: Tools are for taking action; resources are for reading data. Safety First: Resources are strictly read-only, meaning they cannot modify your system state. Dynamic Discovery: Use Resource Templates (RFC 6570) to handle large datasets without manual registration. Client Control: Unlike tools, which the LLM triggers, resources are managed by your application. In my years of building AI-integrated systems, I’ve seen too many developers treat every interaction as a "function call." We get obsessed with the LLM "doing" things—querying databases, sending emails, or spinning up containers. But if you’ve been following this series, you know that the Model Context Protocol (MCP) is about more than just execution. It’s about the architecture of information. I’ve spent the last week digging into the mechanics of MCP’s three pillars: Tools, Resources, and Prompts. While tools get all the glory for their ability to manipulate the world, resources are the unsung heroes that provide the "knowing" required for an LLM to actually be useful. If tools are the hands, resources are the library. Resources act as the library for your AI agent. (Credit: Mikhail Nilov via Pexels) How I Researched This To bring you this breakdown, I’ve gone through the technical specifications and the practical implementation patterns of the MCP framework. I’ve cross-referenced the lifecycle of resource discovery—from the static resources/list endpoint to the more flexible URI templates—against real-world architectural constraints. My goal here is to strip away the marketing fluff and show you how these primitives actually behave in a production environment. What Are MCP Resources? At its core, a resource is a read-only interface for contextual data. The most important rule here is the "No Side Effects" mandate. When an LLM accesses a resource, it is strictly a retrieval operation. You aren't updating a database row or triggering a webhook; you are simply pulling information into the model's context window. For more on managing this flow, see our guide on why your AI agent needs real memory management. "Resources act as intelligent knowledge bases or reference libraries, allowing models to access and reason about information." Think of it like this: if you give an LLM a tool, you’re giving it a pen to write on your whiteboard. If you give it a resource, you’re handing it a book from the shelf. It can read the book, synthesize the information, and use that to inform its next move, but it cannot rewrite the book itself. This distinction is vital for security and system stability. Types of Data in MCP Resources When you’re setting up your server, you’ll need to decide how to package your data. MCP handles this through two primary formats: Text Resources: These are your bread and butter. UTF-8 encoded data like logs, JSON configurations, or source code. If it’s human-readable, it belongs here. Binary Resources: For everything else—PDFs, images, or audio files—you’ll use base64 encoding. A quick pro-tip from the trenches: don't over-engineer your binary handling. If you’re dealing with massive datasets, ensure your client-side logic is prepared to handle the base64 overhead before pushing it into the context window. Proper memory management is key to avoiding token waste.Related ArticlesWhy MCP Is the 'USB-C' Moment for AI: A Developer’s Crash CourseThe Model Context Protocol (MCP) serves as a universal interface for AI agents, standardizing how models connect to exte...Beyond Chat History: Building Long-Term Memory for AI AgentsThis guide explores the transition from short-term, thread-bound memory to persistent, long-term storage for AI agents. ...Stop Wasting Tokens: The Secret to Efficient AI Agent MemoryThis guide explores the architectural necessity of memory optimization in AI agents. Moving beyond simple stateless mode...Stop Dumping Context: Why Your AI Agent Needs Real Memory ManagementThis guide explores why AI agents are inherently stateless and why relying on massive context windows is a flawed strate...Level Up Your AI Agents: 5 Advanced Steps to Production-Ready SystemsThis guide outlines the second phase of building a robust, agentic content writing system. Moving beyond basic text gene... Understanding binary vs. text resources is essential for efficient data handling. (Credit: Markus Spiske via Pexels) The Hands-On Experience In my testing, I found that the most common point of failure is the URI structure. Because MCP allows for custom schemes, it’s easy to get sloppy. I recommend sticking to a predictable pattern like protocol://domain/path. Remember, if the underlying data changes, the resource doesn't magically update. You have to trigger a reload. If you’re building a dashboard, you’ll need to implement a refresh logic that invalidates the old context. Resource Discovery: Direct vs. Templates How does the client know what’s available? You have two paths: Direct Resources: You use the resources/list endpoint. This is perfect for static, well-defined data. It’s simple, predictable, and easy to debug. Resource Templates: This is where things get interesting. By using RFC 6570 URI templates, you can expose entire families of data. Instead of registering 500 individual log files, you register one template: logs://{date}/{service}. It’s a massive win for scalability. The Other Side of the Story Most people argue that "more tools" make an AI smarter. I disagree. I believe that "more resources" make an AI more reliable. By relying on tools for everything, you increase the surface area for errors and hallucinations. By shifting as much as possible into read-only resources, you create a "grounded" AI that reasons from facts rather than guessing through function calls. This is a core principle when building production-ready agentic systems. The Architecture of Control: Application vs. Model This is the most critical architectural distinction in MCP. Tools are model-controlled; the LLM decides when to call them. Resources are application-controlled; the client application decides what data to fetch and feed to the model. Why does this matter? Security. By keeping resources under application control, you prevent the LLM from "wandering" into sensitive data areas that the application hasn't explicitly authorized for the current context. Application control ensures your AI stays within authorized boundaries. (Credit: Brett Sayles via Pexels) Future-Proofing Your Setup As we move forward, the trend is clearly toward modularity. Avoid hard-coding your resource paths. If you build your server to support dynamic templates now, you won't have to refactor your entire integration when your data volume grows from a few files to a few thousand. Treat your resource definitions as a contract—keep them stable, and your AI will remain predictable. The Decision Matrix Not sure whether to build a Tool or a Resource? Use this simple check:Feature InsightBuild Your First AI Agent Crew: A Step-by-Step Implementation GuideThis guide initiates a multi-part series on constructing a robust, end-to-end agentic content writing system. Moving bey...Build Your Own Multi-Agent AI System: A Python Implementation GuideThis guide explores the transition from monolithic AI agents to multi-agent systems. By decomposing complex tasks into s...Stop Using ReAct: Why Planning Agents Are the Future of AIThis guide explores the transition from reactive AI agent patterns (ReAct) to proactive Planning patterns. It explains w...Stop Using AI Frameworks Blindly: Build Your Own ReAct AgentThis guide demystifies the 'ReAct' (Reasoning and Acting) pattern, the engine behind popular AI agent frameworks like Cr...Stop Building Stateless AI: Mastering Memory in CrewAI AgentsThis guide explores the technical architecture of memory in CrewAI, moving beyond stateless agent design. It details the... Does the operation change the state of the system? Build a Tool. Is the operation purely for reading or referencing data? Build a Resource. Does the LLM need to trigger this based on a user request? Build a Tool. Does the application need to provide context before the LLM even starts thinking? Build a Resource. Tools I Actually Use Postman: Essential for testing your MCP server endpoints before connecting them to an LLM. Claude Desktop: The gold standard for verifying how your resources and tools render in a real-world client. RFC 6570 Validator: A quick web-based tool to ensure your URI templates are syntactically correct. What Do You Think? We’ve covered the "knowing" side of MCP, but the balance between application control and model autonomy is still a hot topic in the dev community. Do you prefer the safety of application-controlled resources, or do you find the model-controlled tool approach more flexible for your specific use cases? I’ll be in the comments for the next 24 hours to discuss your architectural choices. References: RFC 6570: URI Template Model Context Protocol (MCP) Official Documentation Sources:Original Source --- Source: Kodawire (EN)