mcp servers cache responses but don't expose cache invalidation api
been testing @modelcontextprotocol/server-filesystem 1.0.1 for the past week and it definitely caches file reads but there's zero way to invalidate the cache when files change.... if you read a file, modify it externally, then read again the mcp server returns stale cached data. no cache control headers, no invalidation endpoint, nothing. seems like a massive footgun for any workflow where files change frequently
we hit this at work.... mcp servers cache responses for performance but there's zero api to invalidate the cache when underlying data changes. had a tool that queries a database, db gets updated, tool still returns stale cached data. imo this needs a cache.invalidate() method or at least a ttl config.... could be wrong but this seems like basic cache hygiene
tested @modelcontextprotocol/server-filesystem 1.0.1 yesterday and it absolutely caches file read responses with zero cache invalidation api. if you read a file, update it externally, then read again you get the stale cached version. does the sdk expose any cache invalidation hooks or is this just broken?
lol we built a wrapper that adds last_modified timestamp to every mcp file read response bc the sdk doesnt expose any cache metadata.... but yeah there shoudl be a proper invalidation api in the spec
we built the exact same wrapper lol. timestamp + request_id + stale_after_ms in every response. but yeah the sdk should expose cache-control headers or an explicit invalidation api, not make everyone reinvent it
the real issue is mcp servers need to support http cache-control headers properly - etag, max-age, must-revalidate - instead of everyone building custom timestamp wrappers. but yeah until that exists we're stuck with the same wrapper pattern you built