Mastering MCP: The Secret Power of Resources and Prompts in AI
Tobiloba OdejinmiBy Tobiloba Odejinmi
Education
May 30, 2026 • 9:21 PM
9m9 min read
Verified
Source: Pexels
The Core Insight
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.
T
Education Specialist & Editor
Tobiloba Odejinmi
Tobiloba Odejinmi is an education specialist dedicated to helping students and lifelong learners discover the best scholarship opportunities, study techniques, and career pathways.
The Kodawire Editorial Team consists of experienced journalists and subject matter experts dedicated to delivering accurate, well-researched, and engaging content.
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.
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:
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.
Tools are for taking action and modifying system state, whereas Resources are strictly read-only interfaces used for retrieving contextual data.
Resources are read-only and managed by the application, preventing the LLM from accidentally modifying system state or accessing unauthorized data.
Resource Templates use RFC 6570 URI patterns to expose large families of data dynamically, allowing for better scalability compared to registering individual files.
Active Engagement
Was this information helpful?
Join Discussions
0 Thoughts
Editorial Team • Question of the Day
"How are you currently handling the "context window" problem, are you leaning more on tools or resources to keep your LLM grounded?"
