Question on intended semantics of McpResource and side effects

[vinsguru]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

I have a question about the intended usage of Resource in MCP.

From the protocol, resources appear to be client-initiated and read-oriented, but there is no explicit guidance on whether resource handlers are expected to be side-effect free.

In particular:

• Is it considered acceptable for a resource handler to:
  • perform sampling (LLM calls), and
  • persist derived results (enrichment, annotations, insights) to a database?

This would not be an authoritative state change, but rather post-processing or enrichment based on existing domain events. The authoritative mutation happens elsewhere; the resource materializes insights.

I understand tools are intended for LLM-initiated actions, which makes them a poor fit for client-initiated enrichment workflows.

Is this usage:

• considered acceptable but undocumented?
• discouraged?
• or something the protocol intentionally leaves open?

Clarification on whether resources are expected to be logically read-only vs side-effect free would be very helpful.

Thanks.

[isheng-eqi]

This is a sharp question that hits a genuine ambiguity in the spec. Let me give you the answer based on how the protocol designers and major implementations interpret it.

The short answer

Resources are expected to be logically read-only, but they are NOT required to be side-effect free. The distinction matters.

What the spec actually says

The MCP specification states that resources represent "read-only data" that the client can access. The word "read-only" describes the semantic contract — the client reads data, the data appears immutable from the client's perspective. It does not say "pure function" or "no side effects."

This is intentionally looser than a pure functional requirement.

Why the distinction matters for your use case

Your scenario — reading a resource that triggers enrichment/persistence — maps perfectly to the "logically read-only but not side-effect-free" category.

Concrete example that is widely accepted:

Resource: analysis://user/{id}/insights

When the client reads this resource:

1. The server checks if cached insights exist → returns them (pure read)
2. If no cache → the server generates insights (calls LLM, runs analysis) → persists the result → returns it

The key property that makes this acceptable: the client perceives it as a read. The client asks for data and gets data. The fact that the server cached/derived/enriched the data internally is an implementation detail, not a protocol violation.

The boundary line

What crosses the line into "this should be a tool":

Acceptable (resource)	Unacceptable (use a tool instead)
Cache-on-read: generate + persist insights on first access	Mutating authoritative state (updating a user record)
Audit logging: record that a resource was accessed	Triggering a deployment or CI pipeline
Derived data: compute a summary from existing events	Sending an email or notification
Sampling for enrichment: call LLM to annotate existing data	Creating or deleting entities

The rule of thumb: if the primary intent of the call is to change state, use a tool. If the primary intent is to read data and any state change is a secondary optimization (caching, logging, enrichment), a resource is fine.

Why the spec leaves this open

The protocol intentionally does not mandate pure-functional resources because:

1. Real-world data is not static. A resource representing "current system health" will change between reads, but it is still logically a resource.
2. Caching is a legitimate implementation strategy. Requiring resources to be side-effect-free would forbid write-through caches, which are standard in production systems.
3. Enrichment is a core use case. Your pattern — materializing insights from domain events — is exactly the kind of value resources should provide.

Your specific case: recommended approach

Your enrichment workflow (read events → LLM analysis → persist insights) is acceptable as a resource if:

• The URI is named as a read (e.g., insights://domain/{id} not compute://insights/{id})
• The response is deterministic given the same state (same domain events → same insights)
• The persistence is append-only enrichment, not authoritative mutation

If you want to be extra safe, split it: a resource that reads cached insights, and a separate tool that triggers re-computation. But for most practical purposes, the combined resource pattern is fine.