MCP resource freshness: re-read changed context before accepting an answer

New resource bytes can leave the old input in place

When an agent answers a question from a changing policy document, fetching the new document is only part of the correction. The host application may still supply an older copy to the next answering step. Check which content reached that step before relying on its answer. This guide addresses that possible read-to-input gap, not a measured failure in a particular product.

Model Context Protocol (MCP) lets servers expose resources identified by a URI, an identifier such as a file-style address. Its 2025-11-25 Resources specification calls resources application-driven: the host determines how to incorporate them into context. It can offer explicit selection or automatic inclusion, and the protocol does not mandate one interaction model.[1] Here, host means the application assembling the model's input, not the resource server.

For an answer that depends on current resource contents, distinguish discovery, a change notice, retrieval, the host's effective input and the checked answer. The proposed procedure below connects those observations. Use it for a changing policy or similar decision-sensitive source; an answer explicitly explaining an archived version may need no refresh.

Separate the catalog from the content

In the captured edition, resource servers MUST declare the resources capability. Its subscribe and listChanged features are separately optional: a server can support neither, either or both.[1] Do not treat list-change support as support for subscriptions to individual resource contents. A declaration also does not establish that a particular subscription was accepted or that notifications reached your client.

For servers declaring listChanged, the specification says they SHOULD send a notification when the list changes.[1] Preserve that requirement level: it is not guaranteed delivery. Silence cannot establish that a resource stayed unchanged. Likewise, optional lastModified annotations are described as hints for use or display, not a mandatory revision scheme or proof that an answer used the latest content.[1]

A procedure for the answer you need now

Use your existing authorized client and the host's supported context-selection or input-assembly path. These steps are proposed application practice, not extra MCP obligations. Keep task-relevant evidence under existing access and retention controls; do not copy credentials or unnecessary sensitive content into a shared log.

• 1. Identify the dependency. Name the authoritative resource URI and the question whose answer could change. Keep a nonsecret server/configuration and caller-scope reference, the actual protocol edition, the content observation used and the dependent draft. These are application records, not new wire fields.
• 2. Classify the trigger. For a list-change notice, refresh discovery if the task needs it and resolve any missing or replaced dependency. For an update naming the dependent URI, suspend reliance on the old draft and re-read that URI. An unrelated URI update need not reopen this answer. When subscriptions are unavailable or continuity is uncertain, choose an explicit on-use read or an existing documented freshness policy; do not treat silence as the check.
• 3. Inspect the read outcome. In this edition, resources/read takes params.uri and returns resource contents.[1] Retain the relevant returned content or an authorized, accessible reference with its observation time. A failed read, permission problem or missing resource leaves the current basis unresolved. It does not establish an empty resource or make the old answer current.
• 4. Check the host input separately. Find the supported resource-selection record or inspectable input assembly for the answering step. Establish that it selects the new observation for this dependency, rather than merely showing a successful fetch or cache write. A model saying it read the latest policy does not replace this check. If the host cannot establish the input binding, stop with use of the new material unresolved.
• 5. Supersede the old source through the supported host path. Select or supply the new observation and prevent an older copy from remaining an unlabeled competing authority. If historical content must remain, label which observation governs this question. Respect the host's and provider's continuation contract; do not manually strip required payloads. If safe selection is unavailable, keep the answer on hold.
• 6. Re-evaluate the affected answer. Regenerate or recompute it when the new content changes the relevant rule, then check it against that content and the user's question. If the conclusion is unchanged, record why the new observation still supports it. Accept only for the stated use and evidence window. A further relevant update before acceptance reopens the check; use existing bounded refresh limits rather than waiting indefinitely for universal stability.

The source's message-flow illustration shows an update notification followed by resources/read and updated contents.[1] It does not show that a host automatically replaces conversation material, nor guarantee that the returned content is an atomic or indefinitely current snapshot. A read establishes the observation obtained. Stronger source-version or consistency assurances need the actual implementation's contract.

Completed hypothetical: the cache changed before the answer's input

FICTIONAL EXAMPLE / NOT RUN. Every time, policy, content label, host record and answer below is assumed. No client, subscription, model, endpoint or action was executed. Assume a read-only support assistant using the 2025-11-25 contract, subscribe support and an accepted subscription for file:///demo/escalation-policy.txt. Assume its host can select and record the content used by the next answering step. The URI is fictional; Old and New are local evidence labels, not MCP revision fields.

The user's question is: Which team should handle a severity-2 incident under the current policy? The assistant is preparing an informational answer, not sending an escalation.

• 09:00, initial basis. Old says severity-2 incidents go to customer support. The first draft answers Customer support. The fictional record binds that draft to Old; it does not certify the answer as current indefinitely.
• 09:04, specific update. notifications/resources/updated names file:///demo/escalation-policy.txt. It contains no replacement policy body. The resolved decision is to hold the old draft and read that URI again, not infer a new team from the notice.
• 09:05, successful new read. New says severity-2 incidents go to the duty engineer. The cache holds New, but the host's next-step selection still points to Old. The resolved decision remains HOLD: the new read has not corrected the answer's input.
• 09:06, input corrected. Through the assumed supported selection path, the host selects New and supersedes Old as the applicable policy source. The fictional host record establishes that binding for the new answering step. The assistant now re-answers the question against New.
• 09:07, answer checked. The new draft answers The duty engineer. The check confirms the same URI, the applicable severity-2 rule and New as the step's input. Assume no further relevant update was observed before the check. The completed disposition is ACCEPT for this fictional informational answer within that evidence window. No escalation is sent and no guarantee of ongoing freshness follows.

An assumed list-change countercase has a different disposition. If notifications/resources/list_changed accompanies the addition of a separate formatting guide, refresh discovery when needed. That catalog event alone neither supplies a revised escalation policy nor proves the old one unchanged. If the policy read fails, or New's selection cannot be established, keep the current-policy answer on hold and name that specific unresolved condition. These branches are fictional decisions, not measured outcomes.

Resolve the missing step without rebuilding the workflow

The useful correction depends on the gap. A URI notice without new content calls for a read. New content with Old still selected calls for host-input correction. Correctly selected content with an unsupported conclusion calls for answer correction. Refreshing discovery repeatedly does not fix any of those content-to-answer gaps.

Use inspectable existing facilities where they establish the needed condition. A host that already binds the selected content observation to each answering step does not need a second manual record. If a new read yields unchanged relevant content, the conclusion may remain valid after the applicable input and task checks; a notification need not produce a different answer. A digest can help compare retained bytes, but cannot establish their truth or rule out a later change.

Additional reads and input checks add work and may delay completion. Match that work to the reader's use: an archived explanation and an answer claiming to reflect current escalation policy need different evidence. If repeated updates exhaust existing limits, state that the current-policy answer remains unresolved rather than silently accept the earlier draft. Accepting an informational answer also does not authorize a consequential write.

What was documented, and what was not tested

This guide uses the official 2025-11-25 Resources page, captured as HTML and official Markdown on 13 October 2026 KST.[1] The revision label is not a launch date. The page's editorial publication and update dates were not established. The two captures are representations from one publisher, not independent empirical confirmation. The procedure is intentionally edition-bound; it is not a survey of newer MCP contracts.

The relevant primary passages and message examples were inspected in preserved source bytes. A discovery extractor duplicated code tokens, so this article supplies no copied wire JSON from that extraction. Resources can contain text or binary data; apply the actual content-handling and access contract rather than assume every resource is plain text.[1]

No deployed SDK compatibility, actual subscription delivery, missed-update detection, resource consistency, host replacement behavior or real model answer was tested. No latency, cost or reliability gain is claimed. For a live integration, establish those implementation conditions before automating this procedure. Its reader value is the separate check between a successful new read and the content that actually became the answer's basis.