A Resource URI Needs a Freshness Receipt

An agent reads a resource at a URI and uses it to plan work.

Later, the agent sees the same URI again. It is tempting to think it already knows the resource. But the identifier only says which resource was referenced. It does not say what was observed, whether the content is still current, why it was included, or which earlier conclusions depend on it.

That gap becomes costly in long-running work. A context item can be valid when first read, stale when a dependent action is proposed, and silently replaced while a task waits for input. Treating its URI as the complete record turns a live reference into an accidental claim of freshness.

A resource needs a freshness receipt.

Resources are application-driven context

The current MCP Resources specification describes a resource as server-provided context with a unique URI. It deliberately leaves the user interaction model to the host: a host can let a user select resources, filter them, or include them through its own heuristics.

That flexibility is useful, but it means the protocol does not itself decide whether a resource is a fixed snapshot, a live reference, evidence for a consequential conclusion, or incidental background context. Those are application decisions.

The specification also distinguishes two optional signals:

• A list-change notification means the available resource list changed.
• A resource-subscription update means a particular resource watched through subscriptions/listen changed.

Neither signal says what a specific agent conclusion should do next. It is a freshness event, not an automatic instruction to rerun every downstream action.

Identity is different from observation

A URI is an identity reference. An observation is a bounded event: at a particular time, a task read a particular representation and used it for a stated purpose.

The distinction matters because one URI can support several legitimate observation records:

• Situation: An agent rereads an unchanging reference document — Same URI?: Often — Same observation?: Possibly — Appropriate posture: Preserve the earlier receipt if the content and validity boundary remain clear.
• Situation: A project-status resource updates during a task — Same URI?: Yes — Same observation?: No — Appropriate posture: Mark conclusions that depended on the earlier state for selective review.
• Situation: A resource is listed but never read — Same URI?: Yes — Same observation?: No — Appropriate posture: Record availability, not content knowledge.
• Situation: A tool returns a resource link outside the regular listing — Same URI?: Maybe — Same observation?: No — Appropriate posture: Treat the link as a separate context-admission event.

The current MCP Tools specification explicitly allows tool-returned resource links and notes that they are not guaranteed to appear in a resources list. That is another reason an agent should record how context entered the task instead of assuming every reference shares one discovery path.

The Resource Freshness Receipt

A Resource Freshness Receipt is a proposed application-level record for the smallest amount of information needed to revisit a context decision. It is not a copy of the resource, a secret-bearing audit log, or a claim that the resource is verified evidence.

• Receipt element: Resource identity and issuer — Question it answers: Which stable, non-secret source key was referenced, and which declared source provided it? — Why it matters: Separates a safe reference from the content observed through it without copying credentials, signed query parameters, user identifiers, or raw private paths into the record.
• Receipt element: Observation boundary — Question it answers: When was it read, and what representation metadata was available? — Why it matters: Makes an earlier conclusion time-bounded rather than timeless.
• Receipt element: Inclusion purpose — Question it answers: Why did this task need the resource? — Why it matters: Stops broad context accumulation from becoming an unexplained dependency.
• Receipt element: Use boundary — Question it answers: Was it background context, a decision input, an evidence candidate, or a user-visible artifact? — Why it matters: Different uses deserve different refresh and review rules.
• Receipt element: Liveness posture — Question it answers: Was it treated as a snapshot, a subscribed resource, a list-only discovery item, or an unknown-live reference? — Why it matters: Makes the expected change behavior explicit.
• Receipt element: Available freshness signals — Question it answers: Which update capability, notice, or modification metadata was actually available? — Why it matters: Avoids inventing a guarantee that the source did not provide.
• Receipt element: Dependent decisions — Question it answers: Which plan, answer, or proposed effect would need reconsideration if the resource changed? — Why it matters: Enables targeted revalidation instead of restarting the whole task.
• Receipt element: Disposition and retention — Question it answers: What happens on change, expiry, loss of access, or task completion? — Why it matters: Keeps the record useful without indiscriminate retention.

This receipt does not make a resource true. It makes the agent's use of that resource inspectable.

Choose a liveness posture deliberately

The protocol supports resource-specific updates through subscriptions/listen, but subscription support is optional. A safe system should therefore distinguish what it knows from what it wishes it knew.

• Liveness posture: Bounded snapshot — What the system can claim: The task used one observed representation within its declared window. — What it should do before a consequential step: Re-read if the window expires or a relevant condition changes.
• Liveness posture: Subscribed resource — What the system can claim: The task can receive an update signal for this resource while the corresponding resourceSubscriptions filter is active. — What it should do before a consequential step: Mark dependent work pending review, then refresh only what the change could affect.
• Liveness posture: List-only discovery — What the system can claim: The system can learn that availability changed, but not necessarily which read content changed. — What it should do before a consequential step: Re-list and decide whether any listed item must be reread.
• Liveness posture: Unknown or unavailable liveness — What the system can claim: The task has no reliable update signal. — What it should do before a consequential step: Do not describe the prior observation as current; refresh before relying on it for a high-impact decision.

The useful word here is selective. A changed reference should not force an agent to discard every unrelated result. It should make the receipt's declared dependencies visible so the system can ask a narrower question: what was this context used to justify?

Last-Modified Metadata Is One Freshness Signal

The current MCP Resources specification allows optional annotations such as audience, priority, and last-modified time. A host can use these to prioritize context or display recency.

That can improve decisions, but it is not a universal provenance or integrity system. The metadata may be absent, may be coarse, and may not answer whether a semantic conclusion changed. A resource updated five seconds ago might be irrelevant to the task; a resource unchanged for a month might still be wrong for the user's current objective.

Treat available metadata as one input to a receipt, together with task purpose and consequence. Do not promote it into proof the source did not offer.

The MCP Caching specification adds two more useful inputs. ttlMs says how long a client may consider a complete response fresh, while cacheScope distinguishes public reuse from reuse limited to the same authorization context. The specification explicitly treats TTL as a hint rather than a guarantee, and a relevant notification invalidates an otherwise fresh cached response. A receipt should record which signals were actually present and still apply its task-specific revalidation rule before a consequential decision.

Preserve the difference between context and evidence

Context helps an agent orient itself. Evidence supports a claim. A freshness receipt helps with a third question: is this context observation still appropriate to rely on now?

Those questions should remain separate:

1. Is this resource relevant enough to include?
2. Is the material claim supported by an appropriate source?
3. Has the task's observation of this resource remained valid for the next decision?

Conflating them causes familiar failures. A resource can be relevant but stale. It can be current but non-authoritative. It can be authoritative but outside the user's approved scope. The receipt does not solve every question; it prevents the system from losing track of which question it is answering.

Start with receipts at decision boundaries

Teams do not need to receipt every piece of incidental context. Start where a resource can change a plan, recommendation, external proposal, or acceptance decision.

For each such resource, capture the purpose, the observed-at boundary, the liveness posture, and the downstream rule. If a later change occurs, show the user or reviewer a precise message: this conclusion depended on this resource observation, and it needs refresh before proceeding.

That is more honest than saying the agent already knows a URI. It knows only what it observed, for what purpose, under what freshness assumptions.

A Virillio Code Editorial Perspective

Virillio Code Editorial presents the Resource Freshness Receipt as a product-neutral application framework. It does not describe a shipped, in-development, or planned Virillio Code capability.

Sources and further reading

• Resources — Model Context Protocol — The current specification defines resources as application-driven context with unique URIs, optional list-change and resource-subscription signals, optional last-modified annotations, and host-controlled inclusion.
• Tools — Model Context Protocol — The current specification permits tool-returned resource links that clients may fetch or subscribe to and says those links need not appear in resources/list.
• Caching — Model Context Protocol — The current specification defines ttlMs as a freshness hint rather than a guarantee, constrains reuse with cacheScope, and makes relevant notifications immediate invalidation signals.

Editorial disclosure

This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.