One of the most common mistakes in MCP development is treating everything as a tool.
A surprising number of MCP servers expose data retrieval operations as tools even when those operations have no side effects and simply return information.
The result is often larger tool inventories, more complicated permission systems, worse model behavior, unnecessary approval workflows, and increased operational complexity.
The Model Context Protocol provides two primary ways to expose information: Resources and Tools. Understanding when to use each is one of the most important architectural decisions in MCP design.
If you're new to MCP, start with what an MCP server is before continuing.
What Are MCP Resources?
Resources are read-only pieces of information exposed by an MCP server. They provide context to AI clients without executing actions.
| Resource | Example |
|---|---|
| Documentation | API docs |
| Configuration | Application settings |
| Reports | Analytics reports |
| Logs | Read-only logs |
| Knowledge Bases | Internal documentation |
| Files | Documents and PDFs |
| Customer Data | Read-only records |
Want to analyze your API security?
Import your OpenAPI spec and generate a Security Report automatically.
Generate Security Report →A resource exists primarily to provide context. It does not perform actions. It does not modify systems. It does not trigger workflows. It simply provides information.
What Are MCP Tools?
Tools are executable functions. A tool performs an operation when called.
See MCP Server vs API to understand the broader architectural context.
| Tool | Example |
|---|---|
| Create User | Inserts records |
| Send Email | Triggers communication |
| Create Invoice | Financial action |
| Delete Record | Destructive operation |
| Restart Service | Infrastructure action |
| Deploy Application | Production change |
Tools create side effects. Resources do not. This distinction is the most important rule in MCP architecture.
The Simplest Decision Framework
Ask one question: Does this operation change something?
If the answer is yes: Use a Tool. If the answer is no: Use a Resource.
| Operation | Resource or Tool |
|---|---|
| View customer profile | Resource |
| Create customer | Tool |
| View analytics dashboard | Resource |
| Send marketing campaign | Tool |
| Read documentation | Resource |
| Update documentation | Tool |
| View logs | Resource |
| Delete logs | Tool |
Most confusion disappears when viewed through this lens.
Why Many Teams Overuse Tools
Developers often think: "Everything is a function." Technically that is true. But MCP is not merely a function-calling protocol. It is a context protocol.
The goal is not simply exposing actions. The goal is exposing information and capabilities in a structured way.
Many first-generation MCP servers expose getCustomer(), getInvoice(), getProduct(), getDocumentation(), and getPolicy() as tools. These are often better represented as resources.
Doing so creates cleaner architectures and simpler governance models.
Resources Improve Model Context
Resources exist primarily to improve context quality.
Consider an internal knowledge platform.
Bad design — Tools:
- getPolicy
- getHandbook
- getProcess
- getComplianceGuide
Good design — Resources:
- Policies
- Employee Handbook
- Compliance Documentation
- Operational Procedures
The model can consume these as contextual information rather than repeatedly invoking tools. This often improves response quality while reducing unnecessary executions.
Resources Reduce Operational Complexity
Every tool introduces complexity. Tools typically require permissions, monitoring, audit logging, approval workflows, side-effect classification, and governance reviews.
Resources often avoid many of these requirements.
Tool-Based Design: 20 read operations + 15 write operations = 35 tools requiring governance controls.
Resource-Based Design: 20 resources + 15 tools = only 15 operations require governance controls.
This dramatically simplifies production deployments. Read MCP security best practices for a complete governance framework.
Security Implications
Security teams care about side effects. They care less about context.
When evaluating MCP deployments, security reviews typically focus on tool permissions, credential access, write operations, destructive actions, financial actions, and administrative actions.
Resources usually represent lower risk. That does not mean resources are risk-free. Sensitive resources can still expose PII, financial records, credentials, intellectual property, and regulated information.
However, the risk profile differs significantly from executable tools. See how to secure an MCP server for a complete security framework.
Resource Security Checklist
Before exposing a resource, evaluate:
| Question | Why It Matters |
|---|---|
| Does it contain PII? | Compliance risk |
| Does it contain credentials? | Security risk |
| Does it expose internal architecture? | Reconnaissance risk |
| Does it contain customer information? | Privacy risk |
| Is access logged? | Auditability |
| Can access be restricted? | Governance |
Resources should still participate in production security controls. They simply require different controls than tools.
Governance Considerations
MCP governance often focuses heavily on tools. However, resources should also be governed.
Production governance should define:
Resource Classification: Public, Internal, Confidential, Restricted.
Access Policies: Developer access, Employee access, Service account access, AI agent access.
Audit Logging: Track who accessed resources, when access occurred, and which resources were accessed. This becomes especially important in regulated environments.
When Resources Are Clearly The Right Choice
Documentation Systems — API documentation, engineering guides, runbooks, onboarding documentation. These are classic resource use cases.
Knowledge Bases — Confluence, Notion, Wiki systems. Most retrieval operations belong as resources.
Static Configuration — Application settings, feature definitions, product catalogs. These are read-only context providers.
Analytics Reports — Dashboard snapshots, reporting outputs, metrics exports. If no changes occur, resources are usually appropriate.
File Repositories — PDFs, spreadsheets, contracts, design documents. Resources are typically the correct abstraction.
When Tools Are Clearly The Right Choice
Anything That Writes Data — createCustomer, updateCustomer, deleteCustomer. These are tools.
External API Actions — Create ticket, submit order, send notification. These are tools.
Infrastructure Changes — Restart service, deploy application, scale cluster. These should always be tools.
Financial Operations — Create invoice, issue refund, charge payment. These are tools and frequently require approval workflows. Learn more in how to convert OpenAPI to MCP.
Hybrid Patterns
Many production systems use both.
Example: CRM MCP Server
Resources: Customer Profiles, Product Catalog, Documentation.
Tools: Create Customer, Update Customer, Create Deal, Send Email.
This hybrid architecture often represents the ideal balance. Resources provide context. Tools provide actions.
Want to analyze your MCP security?
Import your OpenAPI spec and generate a Security Report automatically.
Performance Considerations
Resources often scale differently than tools.
Tools frequently require authentication, authorization, side-effect protection, and transaction management.
Resources often benefit from caching, CDN delivery, and pre-computation.
As deployments grow, this distinction becomes increasingly important. Large MCP deployments often discover that resource-heavy workloads are easier to scale than tool-heavy workloads.
Enterprise Deployment Lessons
Large organizations frequently encounter the same pattern:
- Phase 1: Everything becomes a tool.
- Phase 2: Tool inventory grows rapidly.
- Phase 3: Governance becomes difficult.
- Phase 4: Resources are introduced.
- Phase 5: Operational complexity decreases significantly.
This pattern appears repeatedly in enterprise deployments. Resources reduce governance burden without reducing functionality.
Common Mistakes
Mistake #1: Treating read operations as tools.
Mistake #2: Skipping resource access controls.
Mistake #3: Assuming resources are automatically safe.
Mistake #4: Ignoring audit requirements.
Mistake #5: Exposing sensitive internal documents without classification.
Production MCP Observations
Teams often focus on generation. Production teams focus on governance.
As MCP deployments mature, several patterns emerge: tool permissions become critical, approval workflows become necessary, audit logs become mandatory, credentials vault integration becomes common, security reports become deployment requirements, and side effect detection becomes important.
Resources fit naturally into these governance systems because they generally represent lower-risk interactions. However, sensitive resources should still be classified, monitored, and governed appropriately.
What This Means For Production MCP
The biggest lesson is simple: do not expose everything as a tool.
Use resources whenever the primary goal is context delivery. Use tools whenever the primary goal is action execution.
A good MCP server separates context, actions, permissions, and governance. This separation improves security, scalability, maintainability, developer experience, and AI behavior.
In practice, many production MCP deployments become easier to manage once resources and tools are treated as distinct architectural concepts rather than interchangeable mechanisms.
Key Takeaways
- Resources provide context. Tools perform actions.
- Resources are usually read-only. Tools create side effects.
- Security reviews focus heavily on tools.
- Resources still require governance.
- Resource-heavy architectures often scale better.
- Hybrid designs are common in production.
- Classification and audit logging remain important.
- Treating everything as a tool usually creates unnecessary complexity.
Check your MCP security posture
Generate a Security Score, detect risky tools, and review permissions before exposing APIs to AI agents.