FreshCtx™

tools/call execution boundary

Freshness protection at the MCP tool boundary

An MCP tool call can be authenticated, authorized and technically valid while the evidence that justified the action has already changed.

FreshCtx MCP Guard adds a separate check immediately before configured MCP tool execution: is the evidence that justified this specific action still current?

Screen recording of the FreshCtx MCP stale-action scenario: an agent observes an available balance of $10,000 and reasons toward an $8,000 transfer. The balance drops to $2,000, and when the agent issues the MCP tools/call for transfer_money($8,000), FreshCtx marks the reasoning STALE_REASONING and the protected handler never executes.
  1. 1. Observe

    available_balance = $10,000

  2. 2. Reason

    transfer = $8,000

  3. 3. Reality changes

    available_balance = $2,000

  4. 4. MCP tools/call

    transfer_money($8,000)

  5. 5. FreshCtx

    STALE_REASONING

  6. 6. Result

    Protected handler did not execute.

This is a controlled reproducible scenario, not a production customer result.

Three outcomes at tools/call

CURRENT

Protected tool proceeds.

STALE_REASONING

Protected tool is blocked before its handler executes.

UNVERIFIABLE

Protected tool is blocked because required evidence could not be confirmed.

Unprotected tools continue normally.

install MCP Guard
python -m pip install 'freshctx[mcp-guard]==0.9.0'

Run the reproducible three-outcome scenario:

reproducible scenario
python examples/mcp_balance_guard.py

Separate-process example:

separate process
python examples/mcp_guard_external_host.py

How the boundary works

  1. 1. Reason from evidence

    The agent forms a decision from an observed MCP-reachable source.

  2. 2. Declare dependencies

    The protected tool declares the observation identifiers its action depends on.

  3. 3. MCP tools/call

    The MCP client issues the tool call for the protected action.

  4. 4. FreshCtx revalidates

    MCP Guard intercepts the call and rechecks the declared evidence before the handler.

  5. 5. CURRENT: execute

    Declared evidence is still equivalent, so the real tool handler runs.

  6. 6. STALE_REASONING / UNVERIFIABLE: block

    The call returns a structured MCP tool error and the protected handler never starts.

What FreshCtx protects

FreshCtx revalidates the evidence declared for a protected MCP tool immediately before its handler runs. CURRENT proceeds; STALE_SOURCE, STALE_REASONING and UNVERIFIABLE return a structured MCP tool error and the handler does not start.

Where the pre-action boundary sits

The boundary is the MCP server's native tools/call interception point, before the real tool handler. Unprotected tools pass through unchanged, and two protected tools may declare independent dependency sets.

Limitations

  • The blocked result excludes dependency values, tool arguments, credentials, and raw business payloads.
  • Authentication, authorization, transactions, retries, idempotency, and the correctness of the declared dependency map remain application responsibilities.
  • MCP Guard is distinct from the MCP safe-reader evidence adapter, which supplies read-only evidence rather than controlling tool execution.

Installation

install
python -m pip install 'freshctx[mcp-guard]==0.9.0'

Minimal example

MCP Guard · minimal example
from mcp.server.mcpserver import MCPServer
from freshctx.integrations.mcp_guard import FreshCtxMCPGuard

server = MCPServer(
    "payments",
    extensions=[
        FreshCtxMCPGuard(
            depends_on={"transfer_money": [approval]},
            store=store,
            protected_tools=["transfer_money"],
        )
    ],
)

Important limitations

MCP Guard does not replace:

  • MCP authentication
  • MCP authorization
  • transaction controls
  • idempotency
  • tool-level safety
  • application business rules

FreshCtx checks the narrower boundary between the evidence used to justify an action and the execution of that action.

Developer links

Continue

Third-party names and logos are trademarks of their respective owners. Their appearance identifies compatible integration surfaces and does not imply endorsement or partnership.