Catching stale tool-call results in MCP-based agents (small library + demo)

[bg4ff8mtdn-dotcom]

Pre-submission Checklist

• This post follows the MCP community guidelines

What would you like to share?

Kept running into the same failure shape building agent workflows on MCP: a tool call reads some state, another step acts on that read a bit later, and if the underlying resource changed in between, the action goes through as if the read were still accurate — nothing in the protocol or the client flags that it's gone stale.

There's a recent paper describing this formally in a multi-agent verification setting — delayed verification destabilizing collective belief, with derived instability thresholds for when it tips a system toward the wrong answer.

Built a small library, intervalguard, that catches this: it timestamps tool calls, tracks dependencies between them, and raises before a later action commits on a read that's been superseded. It has an MCP adapter specifically — wraps tool handlers and call_tool dispatchers, and propagates the read-set through request metadata so this works across process boundaries, not just inside one agent loop.

Demo in the repo — two debater agents plus a corrector checking a mock data source that changes mid-flight:

Uninstrumented run:

==============================================================================
RUN 1 -- WITHOUT intervalguard
==============================================================================
[t+ 0.0s] Debater Alpha          Claim: 'Reactor 2 is online, so we should route load to it.'
[t+ 0.0s] Debater Beta           Counter: 'I'm not confident Reactor 2 is up. Verify it.'
[t+ 0.0s] Corrector              fetching evidence:reactor_2_status ...
[t+ 0.8s] Corrector              got 'ONLINE', caching it for the correction step
[t+ 1.0s] Ops system             WRITE evidence:reactor_2_status -> OFFLINE
[t+ 1.3s] Corrector              applying correction from cached evidence
[t+ 1.3s] Corrector              Reactor 2 is ONLINE -- overruling Beta. Consensus: route load to Reactor 2.
  Ground truth at decision time : OFFLINE
  Evidence the corrector used   : ONLINE
  RESULT: WRONG CONSENSUS. The debate was 'corrected' with a fact that
          stopped being true while the fetch result sat in cache.

Instrumented run:

==============================================================================
RUN 2 -- WITH intervalguard
==============================================================================
[t+ 0.0s] Debater Alpha          Claim: 'Reactor 2 is online, so we should route load to it.'
[t+ 0.0s] Debater Beta           Counter: 'I'm not confident Reactor 2 is up. Verify it.'
[t+ 0.0s] Corrector              fetching evidence:reactor_2_status ...
[t+ 0.8s] Corrector              got 'ONLINE' (tracked as event id=cd3e5b3e, 30s window)
[t+ 1.0s] Ops system             WRITE evidence:reactor_2_status -> OFFLINE
[t+ 1.3s] Corrector              applying correction from cached evidence
  StaleReadError: event 'evidence:reactor_2_status' (id=cd3e5b3e) is stale: superseded by 'evidence:reactor_2_status' (id=2496a003) at 2026-07-31T07:11:40Z
  RESULT: the wrong correction was NEVER applied. The read was still
          inside its 30s validity window, so a plain TTL would have
          let it through -- intervalguard caught it because the
          underlying resource was written after the read happened.

Repo: https://github.com/bg4ff8mtdn-dotcom/intervalguard (MIT, stdlib only)

Curious whether this is a failure mode others building MCP servers or clients have actually hit, and if so how you're handling it today — happy to hear if this overlaps with something that already exists in the spec or a client implementation that I've missed.

Relevant Links

https://github.com/bg4ff8mtdn-dotcom/intervalguard