Tool Result Cache

The cache of the MCPServer’s public tool results.

Every tool of the MCP server is read-only, and its data changes only when a repository, or the blog, is indexed again. So each tool call’s result is cached for TOOL_RESULT_CACHE_TTL seconds, by the server’s scope, the tool’s name and its validated arguments, plus an index generation that changes whenever an index changes. A newly indexed repository or post is therefore found at once, and not an hour later.

call() caches each result with smarter.lib.cache.tool_results.cached_tool_call(), keyed by index_generation().
invalidate_cached_tool_results() starts a new index generation, which makes every cached result stale. receivers calls it when an index changes.

A tool raises SmarterMCPServerToolError on an error, so errors are never cached.

Note

Experimental. The MCPServer was designed and coded by Claude Code (Anthropic’s Claude Opus 5.5), with Lawrence McDaniel as co-author. It is experimental, and will be documented.

smarter.apps.mcpserver.protocol.caching.TOOL_CACHE_NAMESPACE = 'mcpserver': The namespace of the server’s tool results in cached_tool_call().

smarter.apps.mcpserver.protocol.caching.TOOL_RESULT_CACHE_TTL = 3600

one hour.

A new index generation makes a result stale sooner, so the TTL only bounds how long a stale entry stays in Redis.

Type:: Seconds to cache a tool call’s result

smarter.apps.mcpserver.protocol.caching.index_generation()[source]

Return the current index generation, which is part of the key of every cached tool result.

The generation is stored in the cache, without a timeout, by invalidate_cached_tool_results(). Side effect: one cache read.

Return type:: int
Returns:: The time, in nanoseconds, when an index last changed, or 0 if none has since the cache was cleared.

smarter.apps.mcpserver.protocol.caching.invalidate_cached_tool_results()[source]

Start a new index generation, so that every cached tool result is stale and expires with its TTL.

Nothing is deleted: the old results are simply never looked up again, because every new key holds the new generation. That is cheaper, and safer, than finding and deleting every key of the namespace.

Side effects: one cache write, of INDEX_GENERATION_KEY, without a timeout, and an info log message.

Return type:: None