I think it is hard to miss the buzz around the Model Context Protocol (MCP), the so-called USB-C for AI apps. What I noticed is that the main focus is on tools. GitHub integration tools, file system tools, API tools—the list goes on. Tools are powerful, they're exciting, and they let AI agents take action in your development environment.
But the protocol exposes 2 other types of primitives what almost nobody talks about: Resources and Prompts.
And that's a shame, because both might be underrated in the entire MCP specification.
My goal of this post is to give at least MCP Resources the attention it deserves. Let’s dive in!
The tools-only tunnel vision
When Anthropic released MCP, the developer community immediately gravitated toward tools. It makes sense—tools are action-oriented and flashy. They let your AI agent create GitHub issues, run terminal commands, and interact with APIs. That's the kind of capability that makes for great demos.
But MCP wasn't designed around tools alone. The protocol defines three core primitives that work together:
- Tools - Model-controlled actions with side effects
- Resources - Application-controlled context and data
- Prompts - User-controlled interaction workflows
Most tutorials, articles, and examples focus exclusively on tools, treating MCP as if it's just a fancy function-calling protocol. This misses the bigger picture entirely.
What are MCP resources?
Think of resources as context providers for your AI conversations. While tools let the AI do things, resources let the AI know things.
Resources in MCP are any data that can provide context to language models:
- Files and directory structures
- Database schemas and table contents
- API documentation and specifications
- Application logs (potentially with real-time updates)
- Configuration files
- Design assets and specifications
- Really, any structured or unstructured data your AI might need to reference
Each resource is uniquely identified by a URI (like file:///project/readme.md or db://users/schema) and can include metadata like a human-readable name, description, and MIME type.
Why resources matter
Here's the key insight: AI agents need context just as much as they need capabilities.
Imagine asking Claude to help debug your application. With tools alone, Claude could:
- Execute code
- Run tests
- Query your database
But without resources, Claude would be flying blind. It wouldn't have access to:
- Your application logs showing the actual error
- Your database schema to understand the data structure
- Your API documentation to know what endpoints exist
- Your configuration files to see how things are set up
Resources bridge this gap. They give Claude the information it needs to make informed decisions before taking action.
Resources vs Tools: When to use what
The distinction is actually quite elegant:
Use resources when:
- Providing read-only context and information
- Sharing reference materials (docs, schemas, specs)
- Exposing data that changes over time (logs, metrics)
- Giving AI access to your knowledge base
- You want the user/application to control what's shared
Use tools when:
- Performing actions with side effects
- Creating, updating, or deleting data
- Executing commands or running processes
- Triggering external API calls
- You want the AI model to decide when to act
Think of it this way: resources are like giving someone a library card, tools are like giving them a set of keys.
Real-world resource examples?
Here is a sad reality, I checked some of the most popular MCP servers available at MCP Registry but I couldn’t find any that was using resources.
What's next
I only scratched the surface on MCP resources. So I have planned to write some follow-up posts where we'll explore:
- How to use resources in VS Code and Visual Studio
- Building your own MCP resource server from scratch
- Advanced features like templates, subscriptions, and binary resources
MCP resources are not used a lot in the wild but I want to dig deeper…