Tools perform parameterized actions in MCP. Resources expose URI-addressable context or data that a host/application can read. The host generally controls how resources are discovered and used, while the model may select tools to call when a user prompt requires an action. One MCP server can expose both resources and tools, and good server design keeps those roles distinct.
The short version: use resources for reusable context and read-only data; use tools for operations, parameterized work, writes, calculations, transformations, and external API calls.
MCP Resources vs Tools: Quick Comparison
| Dimension | Resources | Tools |
|---|---|---|
| Purpose | Expose context or data for the client/model to read | Perform an operation or computation |
| Control model | Application/host-controlled; the host decides how resources are presented and read | Model-controlled; the model can discover and invoke tools based on context |
| Discovery | resources/list returns resource metadata | tools/list returns tool definitions and input schemas |
| Invocation/read method | resources/read with a URI | tools/call with a tool name and arguments |
| Parameters | Usually identified by URI; dynamic resources may use URI templates | Explicit arguments validated by an input schema |
| Side effects | Should be read-only and not change external state | May have side effects, including writes or external API operations |
| URI use | Core identifier, such as docs://api/authentication | Tools are identified by name; tool results may include resource links |
| Security risk | Information disclosure, sensitive data exposure, stale or overbroad access | State changes, destructive actions, privilege abuse, external communication |
| Example | docs://engineering/deployment-runbook | create_support_ticket |
What Is an MCP Resource?
An MCP resource is a URI-addressable piece of context exposed by an MCP server. The official MCP resources specification describes resources as server-provided data that clients can list and read, such as files, documents, configuration, schemas, or other application-specific context.
Small verified-style example:
{
"uri": "docs://api/authentication",
"name": "API Authentication Guide",
"description": "OAuth and token rules for production API calls",
"mimeType": "text/markdown"
}
A resource answers a question. It should not create a ticket, update a record, deploy code, send a message, or mutate a database. For deeper resource design guidance, see when to use MCP resources.
What Is an MCP Tool?
An MCP tool is an executable capability exposed by a server. The official MCP tools specification describes tools as capabilities that language models can invoke to interact with external systems, query databases, call APIs, or perform computations.
Small verified-style example:
{
"name": "create_support_ticket",
"description": "Create a support ticket for a customer issue",
"inputSchema": {
"type": "object",
"properties": {
"customerId": { "type": "string" },
"summary": { "type": "string" }
},
"required": ["customerId", "summary"]
}
}
A tool performs work. It may be read-only in practice, such as a search tool, but it is still an executable operation that accepts input and runs logic.
MCP Resource vs Tool: The Main Difference
The main difference between an MCP resource and an MCP tool is control and side effect: a resource is addressable context that a host can read by URI, while a tool is an executable action the model may choose to call with parameters. If the capability helps the model understand, use a resource. If it performs work, use a tool.
This is why the distinction matters for what an MCP server is: a server is not just a bag of functions. It can expose both context and actions in a structured way.
When Should You Use an MCP Resource Instead of a Tool?
Use an MCP resource when the capability is primarily read-only context that the application can retrieve and place into the model context.
Good resource candidates include:
- product documentation
- internal files or runbooks
- read-only context needed before action
- database schemas, known records, or datasets exposed as resources where the URI is stable and access is authorized
- reusable contextual data such as policies, configuration references, or product catalogs
- application-controlled retrieval where the host decides when to read the data
Resources are especially useful when the same context may be reused across many prompts or tools. They reduce the need to expose every read as a separate executable function.
When Should You Use an MCP Tool Instead of a Resource?
Use an MCP tool when the capability performs an action, takes parameters, runs business logic, or may create side effects.
Good tool candidates include:
- creating, updating, or deleting records
- sending messages or external notifications
- parameterized searches or queries
- external API operations
- calculations or transformations
- database queries that depend on user-provided filters
- deployment, billing, identity, or administrative operations
If your design starts to resemble a REST or RPC endpoint, compare it with MCP server vs API before deciding whether it belongs in MCP as a tool, resource, or both.
Can an MCP Server Expose Both Resources and Tools?
Yes. Most useful MCP servers expose both. A customer-support MCP server might expose docs://refund-policy, schema://ticket, and config://sla as resources while also exposing tools such as search_customer_records, create_support_ticket, and update_ticket_status.
That architecture lets the model read policies before acting. The resource supplies context; the tool performs the operation. The same design principle applies to production security: context and actions should have different authorization, approval, and audit rules.
Resources vs Tools Security Differences
Tools can have side effects, so they usually need stronger controls: authorization, confirmation prompts, audit logging, rate limits, idempotency, and monitoring. Resources do not execute actions, but they can still expose secrets, customer data, internal architecture, or compliance evidence.
Read-only does not automatically mean safe. Authorization is needed for both resources and tools, and clients should not blindly trust tool descriptions or resource metadata without considering server trust, user identity, and policy. See how to secure an MCP server and MCP security best practices for production controls.
Practical Resource and Tool Examples
| Capability | Resource or tool? | Why |
|---|---|---|
| Read product documentation | Resource | Stable context with no side effect |
| Search customer records | Tool | Requires parameters, filtering, authorization, and execution |
| Create support ticket | Tool | Writes to an external system |
| Retrieve a known file | Resource | URI-addressable read-only content |
| Run a database query | Tool | Executes logic and may expose sensitive data based on parameters |
| Update CRM record | Tool | Mutates a system of record |
| Expose configuration reference | Resource | Read-only context for reasoning |
| Trigger deployment | Tool | High-impact side effect requiring approval and audit |
Security Implications of Resources and Tools
One of the biggest reasons Model Context Protocol separates Resources from Tools is security.
From a security perspective, not every capability carries the same level of risk.
Reading documentation is fundamentally different from deleting production data.
Although both capabilities may be exposed through the same MCP server, their security implications are completely different.
Enterprise security teams, therefore, evaluate Resources and Tools using different risk models.
Resources primarily expose information.
Tools primarily execute operations.
That distinction determines how permissions, approvals, audit logs, monitoring, and governance should be implemented.
Why Tools Receive More Security Attention
Imagine reviewing two capabilities.
docs://security/password-policy
and
delete_customer
Both are exposed by the same server.
Both are accessible to AI clients.
Only one of them can permanently modify production systems.
Security teams naturally spend far more time reviewing executable capabilities than informational ones.
Every Tool introduces another execution path.
Every execution path increases the attack surface.
This is one reason enterprise MCP servers usually expose relatively few Tools but many Resources.
Resources Are Not Automatically Safe
A common misconception is:
"Resources are read-only, therefore they are safe."
This is not true.
Read-only does not mean harmless.
A Resource may still expose highly sensitive information.
Examples include:
- employee records
- customer data
- architecture diagrams
- penetration testing reports
- production configuration
- API credentials accidentally stored in documentation
- compliance evidence
- financial reports
- security investigations
Reading such information may have serious security consequences even if nothing is modified.
Resources should therefore be classified according to the sensitivity of the information they expose rather than whether they perform operations.
Security Classification for Resources
Many organizations classify Resources into multiple security levels.
Example:
| Classification | Example |
|---|---|
| Public | Product documentation |
| Internal | Engineering guides |
| Confidential | Customer procedures |
| Restricted | Security documentation |
| Highly Restricted | Incident response evidence |
Not every AI agent should receive every Resource.
Classification should drive authorization decisions.
The principle of least privilege applies to Resources just as much as it applies to Tools.
Security Classification for Tools
Tools are usually classified according to operational impact.
Example:
| Classification | Example |
|---|---|
| Low Risk | search_documentation |
| Medium Risk | create_note |
| High Risk | update_customer |
| Critical Risk | delete_customer |
| Critical Risk | issue_refund |
| Critical Risk | create_admin |
Unlike Resources, Tool classification focuses on side effects rather than information sensitivity.
The Principle of Least Privilege
One of the oldest principles in information security is least privilege.
MCP servers should follow the same philosophy.
Every AI client should receive only the Resources and Tools necessary to perform its task.
For example:
A documentation assistant may require access to:
- documentation
- API references
- schemas
It probably does not require:
- refund capabilities
- production deployments
- billing administration
Likewise, an operations assistant may require deployment Tools but should not automatically receive unrestricted access to customer information.
Resources and Tools should both be filtered according to user identity, permissions, and organizational policy.
Why Approval Workflows Mostly Belong to Tools
Approval workflows are expensive.
They interrupt automation.
They require human review.
Therefore they should only be used where necessary.
Examples requiring approval:
deploy_production
delete_customer
issue_refund
cancel_subscription
grant_admin_role
Examples rarely requiring approval:
docs://deployment/runbook
schema://customer
kb://engineering/onboarding
report://security/latest
Reading information usually does not require human approval.
Changing systems often does.
Separating Resources from Tools allows organizations to apply approvals only where they create value.
Audit Logging
Both Resources and Tools can benefit from audit logging, but for different reasons.
For Tools, audit logs answer operational questions.
Examples:
- Who deleted the customer?
- Who created the invoice?
- When was production deployed?
- Which model invoked the Tool?
For Resources, audit logs answer information access questions.
Examples:
- Who opened the penetration testing report?
- Which AI client accessed customer documentation?
- When was the security policy viewed?
- Which confidential Resources were requested?
Organizations operating under SOC 2, ISO 27001, HIPAA, PCI DSS, or GDPR often log access to sensitive Resources even though those Resources are read-only.
Resource Security Checklist
Before exposing a Resource, ask:
✓ Does it contain personally identifiable information?
✓ Does it expose confidential business information?
✓ Does it contain credentials?
✓ Does it reveal internal architecture?
✓ Does it require authentication?
✓ Should access be audited?
✓ Should access be restricted to specific users?
✓ Is the content properly classified?
If any answer is "yes", additional controls may be appropriate.
Tool Security Checklist
Before exposing a Tool, ask:
✓ Can it modify production systems?
✓ Can it delete data?
✓ Can it move money?
✓ Can it communicate externally?
✓ Can it access privileged systems?
✓ Should approval be required?
✓ Should every invocation be logged?
✓ Is rate limiting required?
✓ Can the Tool be abused?
These questions should be answered before production deployment rather than after a security incident.
Common Security Mistakes
Mistake 1 - Everything Is a Tool
Large Tool inventories increase review effort, governance complexity, and attack surface.
Many informational capabilities belong in Resources.
Mistake 2 - Assuming Resources Are Safe
Read-only Resources may still expose highly sensitive information.
Information disclosure remains a security issue.
Mistake 3 - No Classification
Treating every Resource or Tool equally makes policy enforcement difficult.
Classification enables proportionate security controls.
Mistake 4 - Missing Audit Logs
Without audit trails, organizations lose visibility into both operational changes and information access.
Audit logging is often essential for incident response and regulatory compliance.
Mistake 5 - Overusing Approval Workflows
Approvals should protect high-risk operations.
Requiring approval for every action creates unnecessary friction without improving security.
A mature MCP deployment balances usability with risk management.
Security Best Practices
Production MCP servers should generally follow these principles:
- expose context as Resources
- expose operations as Tools
- classify Resources by information sensitivity
- classify Tools by operational impact
- implement least privilege
- log high-risk Tool invocations
- audit sensitive Resource access
- keep Resource URIs stable
- document Resource ownership
- review Tool inventories regularly
Following these practices makes MCP deployments easier to review, easier to secure, and easier to scale as organizations adopt more AI workflows.
Common Design Mistakes
Even experienced engineering teams blur the resource/tool boundary. The most common mistakes are:
Exposing Every Read as a Tool
Documentation, schemas, policies, reports, and static configuration should not automatically become functions such as get_api_docs() or get_security_policy(). If the information is addressable and reusable, a resource is usually cleaner.
Using Resources for State-Changing Operations
A resource should not create, update, delete, deploy, send, approve, or mutate. If reading the URI changes the outside world, the design is really a tool and should be governed as one.
Creating Generic "execute" Tools
Avoid tools such as execute_query, run_action, or call_api unless they have tight schemas, authorization, and validation. Generic execution tools make policy review and model behavior harder to control.
Returning Excessive Data
Resources and tools should return only the information needed for the task. Dumping entire databases, logs, or document libraries into context wastes tokens and increases disclosure risk.
Confusing Resources With Prompts
Resources provide data. Prompts provide reusable interaction templates. A troubleshooting runbook can be a resource; a prewritten diagnostic workflow may be a prompt. Do not use one abstraction merely because it is easier to name.
Relying Only on Names Instead of Schemas and Authorization
A friendly name like safe_customer_lookup is not a control. Validate tool input schemas, enforce authorization for both resources and tools, and classify sensitive information explicitly.
Resource Design Checklist
Before exposing a new Resource, ask:
- Does this provide information?
- Is the content useful before taking action?
- Can multiple AI clients benefit from this?
- Is the URI stable?
- Is the Resource clearly named?
- Does it have meaningful metadata?
- Is the correct MIME type specified?
- Does it require access control?
- Should access be audited?
If the answer is "yes" to most of these questions, the capability is likely a good Resource.
Tool Design Checklist
Before exposing a new Tool, ask:
- Does it perform an action?
- Does it execute business logic?
- Can it modify data?
- Can it trigger workflows?
- Does it require user input?
- Can it create side effects?
- Should it require approval?
- Should every invocation be logged?
- Does it require rate limiting?
If the answer is "yes", the capability is probably a Tool.
Practical Design Decision Table
| Use case | Resource, tool, or both? | Why |
|---|---|---|
| Read product documentation | Resource | Stable read-only context that the host can retrieve by URI |
| Search customer records | Tool | Requires parameters, authorization, filtering, and execution |
| Create support ticket | Tool | Creates a record and has side effects |
| Retrieve a known file | Resource | Addressable content with no state change |
| Run a database query | Tool | Executes logic and may need parameter validation and row-level authorization |
| Update CRM record | Tool | Mutates a system of record |
| Expose configuration reference | Resource | Reusable read-only context |
| Trigger deployment | Tool | High-risk operation requiring approval, audit logging, and rollback planning |
Whenever you are uncertain, ask one question: if this capability disappeared tomorrow, would users lose knowledge or functionality? Knowledge usually points to a resource. Functionality usually points to a tool.
The Enterprise Pattern
Across enterprise MCP deployments, a common architecture emerges.
AI Client
│
▼
┌─────────────────────┐
│ MCP Server │
└─────────────────────┘
│ │
┌──────────┘ └──────────┐
▼ ▼
Resources Tools
Documentation Create
Policies Update
Schemas Delete
Reports Deploy
Files Send
Knowledge Base Execute
│ │
└──────────────┬──────────────────┘
▼
Governance Layer
Permissions
Authentication
Audit Logs
Approvals
Rate Limiting
Monitoring
Notice that governance sits above both Resources and Tools, but the controls applied to each are different.
Resources focus on protecting information.
Tools focus on controlling actions.
That distinction keeps systems secure without making them unnecessarily complex.
Final Thoughts
Resources and Tools are complementary building blocks of the Model Context Protocol.
Resources provide context.
Tools provide capability.
The most successful MCP servers resist the temptation to expose everything as executable functions.
Instead, they present information through Resources and reserve Tools for operations that genuinely require execution.
This separation improves:
- AI reasoning
- server maintainability
- discoverability
- governance
- security
- developer experience
- enterprise adoption
Whenever you're unsure which abstraction to choose, remember one simple principle:
If the capability helps the model understand, expose it as a Resource.
If the capability changes the outside world, expose it as a Tool.
Following this principle consistently will lead to MCP servers that are easier to understand, easier to secure, and significantly easier to evolve as AI applications become more sophisticated.
Summary
Resources answer questions.
Tools perform actions.
Resources reduce unnecessary execution.
Tools encapsulate business logic.
Resources improve reasoning.
Tools extend capability.
Resources organize knowledge.
Tools automate work.
Keeping these concepts separate results in MCP servers that are easier to document, easier to secure, easier to govern, and significantly easier for AI models to use effectively.
As Model Context Protocol continues to evolve, this distinction will remain one of the core architectural principles behind well-designed MCP ecosystems.
Official References
The concepts discussed in this guide are based on the official Model Context Protocol specification and related standards.
- Model Context Protocol Documentation
- Model Context Protocol Specification
- Resources Specification
- Tools Specification
- Model Context Protocol GitHub
- JSON-RPC 2.0 Specification
Related Resources
- When To Use MCP Resources
- What Is an MCP Server?
- MCP Server vs API: What's the Difference?
- How to Secure an MCP Server
- MCP Security Best Practices
- Running MCP in Production
- MCP Verify
Want to analyze your API security?
Import your OpenAPI spec and generate a Security Report automatically.
Verify Your MCP Server
Designing Resources and Tools correctly is only one part of building a production-ready MCP server.
Before deploying to Claude, Cursor, Windsurf, ChatGPT, or any other MCP-compatible client, verify that your server follows security, compatibility, governance, and quality best practices.
At MCPForge you can:
- Verify any MCP server
- Generate a security report
- Review Tool permissions
- Identify high-risk capabilities
- Analyze governance readiness
- Detect protocol issues
- Share public verification reports