mcp: ClientSession.ReadResource keeps uncacheable and expired results until the session ends

Start in the mcp package by locating ClientSession.ReadResource, readResourceCache.put, and the cache eviction logic, then find the corresponding cache tests. Run the issue's in-memory transport reproduction to confirm heap growth with zero-TTL resources. Done means zero-TTL results are not retained, expired entries are bounded without affecting the list caches, and tests cover the behavior.

Checklist

• I searched the existing issues, and this has not been reported before.
• This is a real problem that I ran into myself, using the latest release of the SDK.
• I ran into it in a production system, not in a toy example, a benchmark, or an automated or AI-driven scan of the code.
• I (a human) examined the relevant SDK code, and wrote or reviewed every line of this report. It is not unreviewed AI output.
• This report is brief and concise, and sticks to the facts needed to understand the problem.

What happened?

On a 2026-07-28 session, ClientSession.ReadResource stores each result in the session's resource cache whatever its ttlMs, and in most cases keeps it until the session ends. A client that reads many distinct URIs, for example through a resource template, holds all of their contents in memory. In the program below, a client reads 4000 distinct 64 KiB resources from a server that sets no TTL. On a 2026-07-28 session the heap grows by about 70 MiB per 1000 reads; on a 2025-11-25 session it stays at 2 MiB.

ReadResource calls readResourceCache.put without checking ttlMs, so it also stores results with ttlMs 0, which get never returns. A Go SDK server sends 0 unless a handler or ServerOptions.SetCacheable sets a TTL. An entry is removed only when its URI is read again after it expired, or when the server sends notifications/resources/updated for it, so results with a positive ttlMs also stay after they expire if their URI is not read again. Nothing reads expired entries: a failed read returns the error rather than a stale result.

Expected: a result with ttlMs 0 is not retained (the caching specification says it "SHOULD be considered immediately stale"), and expired entries do not accumulate for the life of the session. For comparison, the Python SDK does not store results with ttlMs 0, and the Python and TypeScript SDKs bound their default in-memory caches (to 1024 entries and to 512 resources/read entries).

If you agree, I'd like to fix this myself. My approach: ReadResource stores a result only when its ttlMs is positive, and the resource cache removes its expired entries each time it has doubled in size, so the cost is amortized over the reads. The list caches stay as they are, because lookupTool relies on stale tools/list entries (#1053). I have this working locally with tests, and I'm happy to go a different way if you prefer, for example a fixed cap like the TypeScript SDK's.

AI disclosure: I found this while reading the client cache code with Claude Code, which also helped write the reproduction and this report. I ran the reproduction and reviewed the code and the report myself.

How to reproduce

package main

import (
	"context"
	"fmt"
	"log"
	"runtime"
	"strings"

	"github.com/modelcontextprotocol/go-sdk/mcp"
)

func main() {
	ctx := context.Background()

	// Every resource is 64 KiB of text. The server sets no TTL.
	body := strings.Repeat("x", 64<<10)
	server := mcp.NewServer(&mcp.Implementation{Name: "server", Version: "v0.0.1"}, nil)
	server.AddResourceTemplate(&mcp.ResourceTemplate{Name: "doc", URITemplate: "mem://docs/{id}"},
		func(_ context.Context, req *mcp.ReadResourceRequest) (*mcp.ReadResourceResult, error) {
			return &mcp.ReadResourceResult{Contents: []*mcp.ResourceContents{{URI: req.Params.URI, Text: body}}}, nil
		})

	for _, version := range []string{"2025-11-25", "2026-07-28"} {
		t1, t2 := mcp.NewInMemoryTransports()
		if _, err := server.Connect(ctx, t1, nil); err != nil {
			log.Fatal(err)
		}
		client := mcp.NewClient(&mcp.Implementation{Name: "client", Version: "v0.0.1"}, nil)
		cs, err := client.Connect(ctx, t2, &mcp.ClientSessionOptions{ProtocolVersion: version})
		if err != nil {
			log.Fatal(err)
		}
		for i := 1; i <= 4000; i++ {
			res, err := cs.ReadResource(ctx, &mcp.ReadResourceParams{URI: fmt.Sprintf("mem://docs/%d", i)})
			if err != nil {
				log.Fatal(err)
			}
			if i%1000 == 0 {
				runtime.GC()
				var m runtime.MemStats
				runtime.ReadMemStats(&m)
				fmt.Printf("%s: %d resources read (ttlMs %d), heap in use %d MiB\n",
					cs.InitializeResult().ProtocolVersion, i, res.TTLMs, m.HeapInuse>>20)
			}
		}
		cs.Close()
	}
}

// Sample output with v1.8.0 (the figures vary slightly between runs):
//
//	2025-11-25: 1000 resources read (ttlMs 0), heap in use 2 MiB
//	2025-11-25: 2000 resources read (ttlMs 0), heap in use 2 MiB
//	2025-11-25: 3000 resources read (ttlMs 0), heap in use 2 MiB
//	2025-11-25: 4000 resources read (ttlMs 0), heap in use 2 MiB
//	2026-07-28: 1000 resources read (ttlMs 0), heap in use 71 MiB
//	2026-07-28: 2000 resources read (ttlMs 0), heap in use 140 MiB
//	2026-07-28: 3000 resources read (ttlMs 0), heap in use 209 MiB
//	2026-07-28: 4000 resources read (ttlMs 0), heap in use 278 MiB

Where did you hit this?

Not in a production system; see the disclosure above.

Go MCP SDK version

v1.8.0 (also main at 0fa5e84)

Go version

go version go1.25.0 windows/amd64

Logs

No response