This is a client-side behavior, not something MCP Manager does. The gateway reads each response in full to check it for leaked secrets and injected content, then passes it straight through to the client. It returns fresh data on every call and keeps no copy. The staleness lives inside how the client stores and reuses that response, so the fix is in how you prompt the client rather than anything you configure on the gateway.
Why Claude sometimes shows stale data
When Claude calls a tool, the result becomes part of the conversation, and Claude may answer a later question from that earlier result instead of calling the tool again. When it does, you see the data as it was at the first call, not as it is now. Large responses make this more likely. In Claude Code specifically, a large tool result is written to a temporary file and Claude reads from that file rather than keeping the whole result inline, so a follow-up question can be answered from that snapshot. The exact mechanism differs by client — Claude.ai, Claude Desktop, and Claude Code each manage long conversations differently, and it is an internal behavior that can change without notice — but the effect is the same everywhere: an earlier result gets reused in place of a fresh call. The trigger is response size. A broad query early in a long conversation is the most likely to be reused, because it returns the most data. A small, targeted response is more likely to be re-fetched the next time you ask.How to spot it
A few signs that Claude may be answering from an earlier result:- You updated a record after asking Claude about it, and Claude’s answer does not reflect the change.
- Claude’s answer contradicts what you see directly in the tool, for example in Jira, Notion, or Salesforce.
- Claude refers back to data from earlier in the conversation without making a fresh tool call.
Confirm it with your gateway logs
The reliable way to tell whether Claude made a live call is to check the gateway’s audit log — not to ask Claude. Every tool call through your gateway is logged. Open Viewing Logs and look for a request at the moment Claude claims it queried. If there is no matching log entry, Claude answered from an earlier result rather than a live call.How to prompt around it
Fetch specific records by ID
Ask Claude to fetch a specific record directly instead of running a broad query. A direct fetch by ID or key returns a small response that is much less likely to be reused from an earlier snapshot. Instead of:What are my open Jira tasks?Try:
Fetch ME-1110 directly and tell me its current status.
Tell Claude the data may have changed
Say plainly that the data might be out of date and ask Claude to query again. Narrowing the scope at the same time keeps the response small, so the fresh result is more likely to stay inline.That data might be stale. Can you re-query Jira for just the issues in Implementing status?
Start a new conversation
Reused results only live within a single conversation. Starting a new chat clears them, so Claude has no earlier result to fall back on and has to query again.Query patterns that lower the risk
The golden rule
If you are about to take an action based on what Claude told you, such as reassigning a ticket, closing an issue, or making a decision, fetch that specific record directly first. Bulk query results are good for exploration and overview. A direct fetch by ID is the source of truth.Further reading
Connect your AI client
Add a gateway to Claude, Cursor, or VS Code and start calling tools.
Viewing Logs
Confirm what Claude actually called, and when, in your gateway’s audit log.
Architecture & Trust
How the gateway reads each response and passes live data through to the client.
FAQ
Short answers to common questions about how MCP Manager behaves.