8. Technical trade-offs and comparison · Protocol guide · technical comparison
MCP Resource vs Tools
On a narrow screen, scroll each comparison table horizontally. Focus a table region to scroll with the keyboard.
To understand MCP Resources and Tools, start with two questions: What information does the application need to give the model? What capabilities does the model need to call?
Resources organize information as readable context. Tools expose operations as callable functions. They can work together, and both can return data. Treating the distinction as simply “one reads, the other writes” misclassifies read-only tools such as search, queries and calculations.
This article follows MCP version 2026-07-28, with a document review date of October 24, 2026. The business names and URIs below are illustrative examples, not claims that a particular service implements them or has passed testing. Official specification
The version boundary matters: this explanation uses the 2026-07-28 specification, while the CapaLens 0.4.8 acceptance record cited below reports protocol version 2025-11-25. This article does not claim that the running service has migrated to the newer version. Actual capabilities depend on the implementation and the scope of its acceptance checks.
1. Definitions: context and callable capabilities
| Dimension | Resources | Tools |
|---|---|---|
| Core definition | Data or content supplied by a server to provide context for a model | Executable functions exposed by a server to retrieve information, perform calculations or carry out operations |
| Interaction design | Application-driven / application-controlled: the host application organizes, selects and includes content in context | Model-controlled: the model proposes tool calls in response to the task |
| Main question | “What information is available to consult?” | “What capability needs to be called now?” |
| Common examples | File contents, database schemas and product documentation | Search, queries, calculations, and creating or updating records |
Here, “controlled” describes the intended interaction pattern, not a mandatory interface or permission rule. An application can let users choose resources manually or add relevant content automatically. Tool calls still pass through client execution and the application's authorization mechanisms. “Model-controlled” does not mean the model can bypass the user's permissions. Server capabilities overview, MCP architecture
2. Scenarios: decide what you are providing
The following are interface design suggestions, not protocol rules assigning each business scenario to one category.
| Scenario | A good fit for Resources | A good fit for Tools |
|---|---|---|
| Coding assistant | Project README, interface documentation and source files | Searching code with filters, running checks and making changes |
| Data analysis | Table schemas, field definitions and metric definitions | Querying data by date and filters, and calculating statistics |
| Customer support assistant | Product information, return policies and frequently asked questions | Looking up a specific order, creating a ticket and starting an after-sales workflow |
| Travel assistant | Travel policies and destination information | Searching flights by departure point and date, and creating an itinerary |
For example, a travel policy makes useful, reusable context. “Find flights departing from Shanghai next Monday” is better understood as a parameterized operation. It can be a Tool even when it makes no changes to external state. The flight search example in the official learning material uses a tool interface. Understanding MCP servers
A practical rule is to start with a Resource when the focus is accessing an identifiable content object, and a Tool when the focus is expressing an operation and its parameters. A single data source can offer both; there is no need to classify the entire service as one or the other.
3. Interfaces and examples: two entry points into the same system
The following fictional customer support system illustrates the interface differences. The tool calls in the table are conceptual notation, not complete JSON-RPC messages.
| Comparison | Resource example | Tool example |
|---|---|---|
| Identifier | support://policies/refund identifies the refund policy |
search_orders identifies an order search capability |
| Discovery | resources/list; parameterized resources are discovered through resources/templates/list |
tools/list returns tool definitions and input schemas |
| Use | resources/read, with the target URI |
tools/call, with the tool name and arguments |
| Parameterized example | Expand the template support://orders/{order_id} and read the resulting order resource |
search_orders({status: "pending", limit: 10}) searches orders using filters |
| Result | Text or binary resource contents | Content such as text and images; results can also include structured data or resource links |
A Resource is not necessarily a static file. Resource content can be generated dynamically from an API or database, and URI templates can express parameterized content access. Whether a server offers templates depends on its implementation. The presence of Resources alone does not establish template support. Resources specification
A Tool's result need not be separate from Resources. An order search tool could return links to order resources that the application reads as needed. The specification explicitly notes that resource links returned by tools are not guaranteed to appear in resources/list. An empty resource list therefore does not, by itself, establish that the service has no readable resources. Tools specification
4. Three misconceptions that can affect your choice
1. “Tools always modify data”
Search, weather lookups and calculations can all be read-only Tools. The specification's readOnlyHint indicates whether a tool is expected to leave its environment unchanged. It is a server-provided behavioral hint, not runtime isolation or a security certification. In particular, declarations from an untrusted server should not be treated as verified facts. ToolAnnotations definition
2. “Resource support means real-time synchronization”
Resource content update notifications and resource list change notifications are separate, optional capabilities. Check what the server declares, then verify what the client actually supports. Version 2026-07-28 uses subscriptions/listen to subscribe to updates for the relevant resources; do not apply an older subscription workflow directly to a newer implementation. Receiving a change notification also does not mean the application has refreshed the model's context. Resource subscriptions and capability declarations
In that version, subscription URIs are supplied in params.notifications.resourceSubscriptions, and resource update notifications use notifications/resources/updated. resources.subscribe remains an optional capability declaration field, not the RPC method used here. Subscriptions specification
3. “Resources are read-only, so they are inherently safe”
Read-only access can still expose sensitive information, permit unauthorized reads or introduce untrusted content. Resource access needs permission checks, and tool execution needs appropriate user control. MCP specifies interfaces; implementations still need authorization, data protection and clear security boundaries. The protocol cannot replace those measures. Security and trust principles
5. Applying this to CapaLens: judge capabilities by test evidence
The purpose of distinguishing Resources from Tools is to make a better judgment about whether an MCP service suits your application.
What the 0.4.8 evidence covers
| Subject | Recorded evidence | Limits |
|---|---|---|
| CapaLens public MCP | The October 21, 2026 release record documents initialize and selected detail calls through local and HTTPS entry points. tools/list returned 15 definitions across two pages: 8 and then 7. |
The recorded protocol version is 2025-11-25. Discovery does not mean all 15 tools were individually called and passed, or that every dataset was fully traversed. |
| CapaLens read-only Resources | The same release's source code implements read-only resource access for seven business collections, covering actions, mappings, sources, gaps and path materials, using capalens://business-needs/read. It declares that subscriptions are not supported. |
That production acceptance record contains no resources/list, resources/read or resources/templates/list call results. It therefore does not establish production verification of resource discovery, reading or templates. |
| Vendor workflows and testing | Directory entries retain their documentation and verification status, and the platform's directory query tools can provide read-only access. | The release did not call vendors' business interfaces. The number of listed entries is not a count of tested services, and does not mean an intelligent testing engine is live. |
These are historical results for a specified version and set of use cases, not continuous monitoring or a guarantee of long-term availability. See Connect your AI and Sources and verification boundaries for the current page explanations. Documentation review and actual testing still need to be distinguished for each item.
When choosing a service through CapaLens, “supports an interface” is only a starting point. A useful test conclusion should explain what was tested, under which conditions and with what result. In particular, these four evidence states should be understood separately:
| Evidence state | What it can establish | What it does not establish on its own |
|---|---|---|
| Listed | An entry and its sources have been organized | A successful connection or call |
| Automated check | A specified automated check produced a recorded result in a particular environment and at a particular time | Human verification, or a guarantee that a business task can be completed |
| Human review | A person reviewed explicitly identified items and evidence | Coverage of every function, permission and scenario |
| Business workflow test | End-to-end validation was completed for a specified client, permission set, version and use case | Success in other environments, or long-term service stability |
For a Resource, checks might cover whether the target content can be read, whether permission boundaries hold, and whether the application can use updates correctly. For a Tool, checks might cover whether arguments and results meet the contract, whether failures are handled, and whether operations with side effects are properly constrained. These are suggested dimensions for verification, not a claim that CapaLens has completed every check.
When reading a CapaLens Intelligent Access (IA) entry, give the specific test record, coverage and limitations more weight than a capability label. An item without test evidence should not be treated as verified merely because it is listed. Nor should this article be read as an announcement that a CapaLens intelligent testing engine is live.
Resources help applications supply appropriate context. Tools help models request appropriate operations. The testing value CapaLens should present is a clear, reviewable basis for each claim of availability.