Why MCP Separates Resources and Tools
Traditional APIs usually expose everything as endpoints. MCP takes a different approach.
| MCP Component | Purpose |
| Resources | Provide context and information |
| Tools | Perform actions and execute operations |
This distinction exists because AI systems consume information differently than humans or traditional applications. A model may need documentation, reference data, product catalogs, or knowledge bases — these are not actions, they are context. Conversely, it may need to create tickets, send emails, update records, or trigger workflows — these are actions that change state.
What Are MCP Resources?
Resources are structured pieces of information that can be provided to an AI client. Think of Resources as readable content.
Examples include: product documentation, knowledge base articles, configuration files, user guides, database schemas, API documentation, pricing information, and internal policies. Resources provide context. They do not perform actions. They do not modify systems. They do not create side effects.
**Resource Example:** An internal engineering MCP server might expose Company API Standards, Security Policies, Infrastructure Runbooks, Database Schema Documentation, and Deployment Procedures as Resources. An AI assistant can read these to answer questions like "What authentication standard do we use?" — no action is executed, nothing changes.
| Characteristic | Resource Behavior |
| Read-only | Yes |
| Side effects | None |
| State changes | None |
| Context provider | Yes |
| Safe to expose broadly | Usually |
| Governance complexity | Lower |
What Are MCP Tools?
Tools are executable capabilities. A Tool allows an AI system to perform an operation. Examples include: create Jira ticket, send Slack message, search CRM, create customer, update invoice, cancel subscription, generate report, query database.
Want to analyze your API security?
Import your OpenAPI spec and generate a Security Report automatically.
Generate Security Report →Unlike Resources, Tools perform work. They execute logic. They interact with external systems.
| Characteristic | Tool Behavior |
| Executable | Yes |
| Side effects | Possible |
| State changes | Common |
| External system access | Often |
| Security risk | Higher |
| Governance complexity | Higher |
Tools introduce operational risk because they can affect real systems. See [how to secure an MCP server](/blog/how-to-secure-an-mcp-server) for a full governance framework.
The Simplest Mental Model
Resources answer questions. Tools perform actions.
| Request | Resource or Tool? |
| Show company security policy | Resource |
| Show API documentation | Resource |
| Show pricing tiers | Resource |
| Create customer account | Tool |
| Delete user | Tool |
| Issue refund | Tool |
| Send email | Tool |
Where Developers Often Get It Wrong
Many first-generation MCP servers expose everything as Tools. This creates several problems.
Documentation as a Tool (bad design):
get_security_policy(), get_api_docs(), get_pricing() — these are actually Resources. Treating them as Tools increases complexity without providing benefits.
**Knowledge Base Search** — sometimes developers create Tools for static content retrieval. A better architecture uses Resources to provide content and Tools to provide search capabilities.
For a deeper look at MCP architecture, see [what is an MCP server](/blog/what-is-an-mcp-server) and [MCP server vs API](/blog/mcp-server-vs-api).
Security Implications
This distinction becomes extremely important when deploying MCP in production.
**Resource Risks:** Even read-only Resources can expose internal documentation, secrets accidentally embedded in files, infrastructure details, customer information, and compliance data. They still require review.
Tool Risks:
| Tool | Risk |
| delete_user | High |
| issue_refund | High |
| update_billing | Critical |
| create_admin | Critical |
| send_email | Medium |
| search_docs | Low |
A Tool can create operational damage. A Resource generally cannot. This is why enterprise security reviews focus heavily on Tool exposure.
Why Governance Is Mostly About Tools
Most governance discussions around MCP revolve around Tools. Questions security teams ask: Who can invoke this Tool? What systems does it access? Does it require approval? Is the action logged? Can it be restricted?
These questions rarely apply to Resources. As a result, production MCP governance frameworks usually center around Tool management — tool permissions, approval workflows, audit logs, security reports, side effect detection, and credentials vault integrations.
See [MCP security best practices](/blog/mcp-security-best-practices) for detailed governance patterns.
Production Example: CRM MCP Server
Resources: Customer Data Model, CRM Documentation, Field Definitions, Workflow Documentation.
Tools: create_customer, update_customer, delete_customer, create_opportunity, close_opportunity.
Notice the separation. Documentation is context. Operations are actions. This architecture is easier to govern and easier to secure.
The Hidden Cost of Overusing Tools
Many developers default to Tools because they feel more powerful. However, overusing Tools creates a larger attack surface (every Tool is a possible execution path), approval delays (security teams often approve Resources quickly but Tools require risk assessment, architecture review, IAM review, compliance review), and operational complexity (audit logging, permission systems, approval workflows, monitoring).
A server exposing 50 Tools will typically face more scrutiny than one exposing 10 Tools and 40 Resources.
Enterprise MCP Design Pattern
Many successful enterprise MCP deployments follow a layered model.
**Layer 1 — Resources:** Documentation, policies, knowledge bases, schemas, runbooks.
**Layer 2 — Low-Risk Tools:** Search, read-only lookups, analytics queries.
**Layer 3 — Side-Effect Tools:** Updates, creation operations, workflow triggers.
**Layer 4 — Critical Tools:** Delete operations, billing changes, refunds, administrative actions.
Each layer receives progressively stronger governance controls. This maps directly to how MCPForge classifies tools when you [import an OpenAPI spec](/login?tab=register).
Tool Classification Framework
| Classification | Example |
| Read-Only | search_customers |
| Low Impact | create_note |
| Medium Impact | send_email |
| High Impact | update_contract |
| Critical Impact | delete_customer |
Resources generally sit outside this classification because they are informational rather than operational.
Compliance Considerations
Organizations operating under SOC 2, ISO 27001, HIPAA, PCI DSS, or GDPR should distinguish Resources and Tools clearly. Auditors care about: who changed data, what changed, when changes occurred, whether approval was required. Those concerns map directly to Tools. Resources fall under access control and information governance.
MCP Security Reviews Often Start Here
Many security reviews begin with: "Which capabilities are Resources and which are Tools?" A poorly designed MCP server that mixes documentation, configuration, search, updates, and deletes under the same Tool abstraction makes risk assessment harder. Clear separation improves review outcomes.
Common Mistakes
**Mistake 1: Everything Is A Tool** — not every capability should be executable. Documentation belongs in Resources.
**Mistake 2: No Risk Classification** — treating search_user() and delete_user() as equivalent operations. They are not.
**Mistake 3: Missing Audit Logs** — Tools that modify systems should generally be logged. Without audit logs, governance becomes difficult.
**Mistake 4: Ignoring Side Effects** — any Tool that changes a system introduces side effects. These should be identified during design.
Resources vs Tools Decision Matrix
| Question | Resource | Tool |
| Is it information? | Yes | No |
| Is it executable? | No | Yes |
| Does it change state? | No | Yes |
| Does it interact with systems? | Rarely | Often |
| Does it need permissions? | Sometimes | Usually |
| Does it need audit logs? | Rarely | Often |
If most answers fall into the right column, it should be a Tool. If most fall into the left column, it should be a Resource.
Key Takeaways
Resources provide context. Tools perform actions. Resources are generally read-only. Tools may create side effects. Governance requirements are higher for Tools. Security reviews focus heavily on Tool exposure. Proper separation simplifies enterprise adoption. Resource-heavy architectures are easier to approve. Tool-heavy architectures require stronger controls.