The agent asks the same thing all the time

In a typical agent turn, the model may invoke the same tool several times in a row to assemble a summary, compare, or verify before acting:

• "Let me check stock before modifying it." → list_inventory_items()
• "OK, now I add 5 units." → add_inventory()
• "Let's confirm the result." → list_inventory_items() (again)

If your tool touches an external API, a slow DB, or a service with a rate limit, that triple call costs you money, latency, and sometimes it'll trip the rate limiter on you.

The solution is an old, well-known pattern: cache with TTL. The novelty when applied to agent tools:

• The agent doesn't know the cache exists, nor cares. To the agent, the tool just answers fast.
• The cache is transparent. Same input, same output. The only thing that changes is the latency and a cached: true flag for diagnosis.
• TTL depends on the domain. Weather data changes slowly (60s OK). Financial prices change fast (5s or none). Inventory stock: depends.

What to cache

✓ Read tools (naturally idempotent). get_X, list_X, lookup_X.

✓ Tools whose data changes slowly. Configuration, catalogs, reference data.

✓ Expensive tools (high latency or per-call cost).

What NOT to cache

✗ Write tools. Each call does something different. Doesn't make sense.

✗ Tools whose data changes fast. If your TTL is longer than the actual change frequency, you return stale data as if it were fresh.

✗ Tools with results dependent on the user without keying them separately. If you cache get_my_bookings() with key "default", everyone sees the first user's bookings. The cache key has to include the context that distinguishes.

Typical structure

const cache = new Map(); // key → { data, fetchedAt }
const TTL_MS = 60_000;

async function handle({ deck }) {
  const key = deck;
  const cached = cache.get(key);
  if (cached && Date.now() - cached.fetchedAt < TTL_MS) {
    return { ok: true, data: cached.data, cached: true };
  }
  const data = await atmosphericApi.read(deck);
  cache.set(key, { data, fetchedAt: Date.now() });
  return { ok: true, data, cached: false };
}

The cached: true is information too

Returning the flag cached: true on hit lets the agent make interesting decisions:

• "Weather data for deck A (captured 25 seconds ago)" instead of stating it as if live.
• In debugging, distinguish old behavior (cached) from current behavior.
• If the agent needs fresh data (critical decision), it can bypass the cache. heads up: that's another pattern (force-refresh), optional but useful.

Your task

On the right you have get_weather with no cache. Add it: in-memory cache with 60s TTL, keyed by deck, with the cached flag.

Good caching is one of the cheapest, highest-impact optimizations in real MCPs. One hour of work, one order of magnitude less in API cost.