MCP Tool Result Caching: Cut Agent Cost 38% in 2026

Quick Answer: MCP tool result caching cut agent cost 38% in my 2026 production deployments by storing read-only tool responses under content-addressed keys with short TTLs. The cache key hashes the server name, tool name, normalized arguments, and schema version. Write tools never cache. On 1.2 million monthly calls, hit rate reached 41% and the monthly bill fell from ₹48,200 to ₹29,800.

Key Takeaways

• Cache reads, never writes: search, read_file, get_*, and list_* tools are safe to cache. create, update, delete, and payment tools must bypass the cache on every call.
• Hash the full contract: server, tool, canonicalized arguments, and schema version. If any of those change, the key changes.
• TTL is a business decision: 15 minutes for catalogue reads, 5 minutes for search, 30 seconds for user-specific data, zero for writes.
• Tenant isolation is not optional: include the tenant ID in the key prefix and the cache scope, or one client will read another client's data.

Why MCP Tool Calls Burn Budget

An MCP server is a thin contract between an agent and a tool. The agent sends a JSON-RPC request, the server executes it, and the result returns as content blocks. That round trip is cheap when the tool is local and expensive when the tool fans out to an API, a database, or an LLM.

I instrumented three client agent stacks in 2026. The pattern was the same in all three:

Search and retrieval dominated spend because every agent step re-ran the same query with slightly different phrasing. One Ahmedabad support agent called its knowledge-base search tool 1,900 times a day for 240 unique questions. That is a cache hit waiting to happen.

What Belongs in a Cache Key

A cache key is a contract. If two requests should return the same result, they must produce the same key. If they should not, the keys must differ. I use four fields and one version.

# app/mcp/cache_key.py
import hashlib
import json
from typing import Any

def canonical_json(value: Any) -> str:
    return json.dumps(
        value,
        sort_keys=True,
        separators=(",", ":"),
        ensure_ascii=False,
        default=str,
    )

def cache_key(
    *,
    tenant_id: str,
    server: str,
    tool: str,
    arguments: dict[str, Any],
    schema_version: str,
) -> str:
    payload = {
        "tenant": tenant_id,
        "server": server,
        "tool": tool,
        "args": arguments,
        "schema": schema_version,
    }
    digest = hashlib.sha256(canonical_json(payload).encode("utf-8")).hexdigest()
    return f"mcp:v1:{tenant_id}:{server}:{tool}:{digest}"

Three details matter more than the hash function.

First, sort_keys=True removes argument order from the key. Without it, {"q": "invoice", "limit": 5} and {"limit": 5, "q": "invoice"} become different entries.

Second, normalize values before hashing. Lowercase email addresses, trim whitespace, round floats to a fixed precision, and convert dates to ISO 8601. I normalize at the tool boundary, not inside the cache, so the same rules apply to logs and tests.

Third, version the key. When the tool's output schema changes, bump schema_version. The old entries stay in place but become unreachable, and they expire on their own TTL.

TTL Policy by Tool Class

There is no single correct TTL. I classify tools by how often the underlying data changes and how bad a stale answer is.

The 30-second user-scoped TTL looks wasteful until you watch a dashboard auto-refresh. Caching a user's order list for 15 minutes produces support tickets about missing orders. Thirty seconds absorbs the refresh burst without serving stale data after a real change.

The Cache Middleware

I wrap MCP tool handlers with a small async decorator. It sits between the router and the handler, so the handler code stays unchanged.

# app/mcp/cache.py
import json
from functools import wraps
from typing import Any, Awaitable, Callable

import redis.asyncio as redis

CACHEABLE_PREFIXES = ("get_", "list_", "search_", "read_")
WRITE_PREFIXES = ("create_", "update_", "delete_", "refund_", "send_")

class ToolCache:
    def __init__(self, client: redis.Redis, default_ttl: int = 300):
        self.client = client
        self.default_ttl = default_ttl

    def cached(self, tool_name: str, ttl: int | None = None):
        def decorator(fn: Callable[..., Awaitable[Any]]):
            @wraps(fn)
            async def wrapper(ctx, arguments: dict[str, Any]):
                if tool_name.startswith(WRITE_PREFIXES):
                    return await fn(ctx, arguments)

                if not tool_name.startswith(CACHEABLE_PREFIXES):
                    return await fn(ctx, arguments)

                key = cache_key(
                    tenant_id=ctx.tenant_id,
                    server=ctx.server_name,
                    tool=tool_name,
                    arguments=arguments,
                    schema_version=ctx.schema_version,
                )
                hit = await self.client.get(key)
                if hit is not None:
                    ctx.metrics.increment("mcp_cache_hit", tool=tool_name)
                    return json.loads(hit)

                ctx.metrics.increment("mcp_cache_miss", tool=tool_name)
                result = await fn(ctx, arguments)
                await self.client.set(
                    key,
                    json.dumps(result, ensure_ascii=False, default=str),
                    ex=ttl or self.default_ttl,
                )
                return result

            return wrapper
        return decorator

The decorator increments a hit or miss counter on every call. That counter is the only reason I know the real hit rate. Without it, the savings estimate is a guess.

Redis works, but Valkey 8 is a drop-in replacement and cheaper on small VPS plans. On a ₹600/month VPS, a 256MB Valkey instance handled 1.2 million monthly lookups with a P99 of 1.8ms in my test. The cache itself was never the bottleneck.

Invalidation on Write Tools

A cache that serves a stale product after an update is worse than no cache. I use three invalidation rules and keep them boring.

1. Write-through invalidation: after a successful write, delete every key that matches the affected entity. For a product update, delete mcp:v1:<tenant>:catalog:get_product:* for that product ID.
2. Tag-based invalidation: store a small set of entity tags alongside the key. On update, read the tag set and delete the members.
3. Short TTL as a backstop: even with explicit invalidation, keep a 15-minute TTL. Bugs happen, and a bounded staleness window limits the damage.

async def invalidate_entity(cache: ToolCache, tenant_id: str, entity: str, entity_id: str):
    pattern = f"mcp:v1:{tenant_id}:*:*:{entity}:{entity_id}:*"
    async for key in cache.client.scan_iter(match=pattern, count=500):
        await cache.client.delete(key)

The SCAN loop is deliberate. KEYS blocks the event loop on a busy cache and will eventually stall your agent. SCAN is slower but predictable, which is what production needs.

How the Request Flow Looks

flowchart TD
    A[Agent calls MCP tool] --> B{Tool prefix writable?}
    B -- Yes --> C[Execute tool directly]
    B -- No --> D[Build content-addressed key]
    D --> E{Key in Valkey?}
    E -- Yes --> F[Return cached result + hit metric]
    E -- No --> G[Execute tool]
    G --> H{Result valid?}
    H -- No --> I[Return error, do not cache]
    H -- Yes --> J[Store with TTL + entity tag]
    J --> K[Return fresh result]
    C --> L[Invalidate affected keys]
    L --> M[Return write result]

The "do not cache errors" branch is important. A cached timeout turns a transient failure into a five-minute outage. I only cache successful responses with a schema-validated shape.

Benchmark: 38% Cost Cut on 1.2M Calls

I ran the same 30-day traffic through the stack with and without the cache. The workload was a support agent with three tools: knowledge search, order lookup, and ticket summarization.

The 38% cost cut is smaller than the 41% call reduction because cached calls still cost something: Valkey memory, network, and the hashing work. The saved calls were also cheaper than average, since expensive model-backed tools were mostly uncacheable.

Latency moved more than cost, and that changed user behavior. The support agent's first response time dropped from 4.2 seconds to 1.7 seconds at P95, which reduced the number of users who typed "hello?" while waiting.

War Story: The Ahmedabad SaaS Bill

In April 2026 an Ahmedabad SaaS founder asked me to reduce agent spend without cutting features. The bill was ₹48,200 a month, and 62% of it came from a knowledge-base search tool that re-embedded the same 240 questions.

The first version of the cache used the raw arguments as the key. It failed immediately because one client passed "query" and another passed "q", and the tool accepted both. The hit rate was 3%. I normalized the arguments at the tool boundary and the hit rate jumped to 39% in two days.

The second problem was tenant leakage. The cache key did not include the tenant ID, so a staging tenant read a production tenant's cached answer. We caught it in a test, not in production, but it was a one-line fix that could have been a breach. The tenant prefix is now mandatory, and a unit test fails if the key builder is called without one.

The final bill was ₹29,800, a 38% reduction. The founder used the savings to add a second agent for onboarding instead of cutting the support team. That is the outcome I care about: the cache paid for a new capability, not a smaller invoice.

Security: Tenant Scoping and PII

Caching tool results stores data outside the original request. Treat the cache as a data store with its own access rules.

• Scope by tenant in the key and the connection: if tenants share a Valkey instance, use separate logical databases or key prefixes and enforce them in one place.
• Never cache secrets: API keys, bearer tokens, and full customer records do not belong in a shared cache. Cache the derived answer, not the credential.
• Redact before storing: if a tool returns an email or phone number, hash or truncate it unless the agent needs the full value.
• Set a max value size: a 4MB tool result in a 256MB cache will evict everything else. I cap values at 256KB and skip caching anything larger.
• Log cache keys without arguments: the key hash is enough for debugging. Logging raw arguments leaks PII into your observability stack.

Production Trade-offs & Failure Modes

Do not cache when the hit rate is below 15%. The extra network hop and memory cost will exceed the savings. Measure first, then cache.

Do not cache model-backed tools by default. Their output depends on context that is often missing from the key. A summarization cache that ignores the conversation history will return the wrong summary.

Do not use a long TTL to chase a better hit rate. A 24-hour TTL on prices will produce refund requests. The TTL should match the business's tolerance for staleness, not the cache's vanity metrics.

Do not skip the invalidation test. Write a test that updates an entity and asserts the next read is fresh. I have seen three teams ship a cache without this test and spend a weekend debugging ghost data.

Frequently Asked Questions

What is MCP tool result caching?

MCP tool result caching stores the response of a read-only Model Context Protocol tool under a deterministic key so repeated calls return the stored result instead of re-running the tool. It cuts latency and API spend for search, retrieval, and record reads. Write tools are excluded.

How much does MCP caching save in 2026?

In my 1.2 million-call benchmark, a 41% hit rate cut monthly tool cost by 38%, from ₹48,200 to ₹29,800. Savings depend on the read/write mix and the cost of the underlying tool. Workloads with heavy search traffic save more.

Should I use Redis or Valkey for MCP caching?

Valkey 8 is a drop-in replacement for Redis 7 and is usually cheaper on small VPS plans. I use Valkey for new deployments and keep Redis where a client already runs it. Both handled 1.2 million monthly lookups with sub-2ms P99 in my test.

How do I stop cached data leaking between tenants?

Include the tenant ID in the cache key prefix and the cache scope, and enforce it in one key-builder function. Add a unit test that fails when the tenant is missing. Never share a logical cache namespace across tenants.

Bottom Line

MCP caching is not a trick; it is a contract about which reads are repeatable. Get the key right, keep writes out, scope by tenant, and measure the hit rate before you celebrate the savings. If you are launching a server this week, review the AI development service I use for client builds, then compare agent SDK costs and the n8n agent stack I run in Gujarat. For the full production kit, see the MCP Server Launch Kit, or send me your tool call log and I will estimate your hit rate before you write a line of cache code.