The read is one expression deep. A tool handler takes its injected `RequestContext<CallToolRequestParams>` and pulls `request.JsonRpcRequest.Context?.ClientCapabilities`, then asks whether `Extensions` contains the key it cares about [5]. Keys are reverse-DNS strings, and the sample gates on `com.example/report-export` [3]. Keeping that lookup beside the decision it drives is the entire discipline here, because the alternative is a field somewhere holding a value that was true for some other call [9].
The null cases are where the design shows. There are three states, not two [10]. A missing request context means you never received an affirmative declaration. An empty `extensions` dictionary means the client sent a valid capability object that does not include your extension. A present key means it does. Collapsing the first two into "disabled" is defensible. Collapsing either into "whatever the previous handler saw" is the bug the revision creates [9].
The fixture in the dev.to post by ssukhpinder is the part I would steal. It stands up an ASP.NET Core TestServer, so the real Streamable HTTP endpoint gets exercised without opening a port [12]. Two `tools/call` requests go in concurrently, one advertising the extension and one sending an empty map, with a one-shot barrier holding both handlers until both have arrived [13]. The expected output is `enabled-request:request=enabled,server=null` and `disabled-request:request=disabled,server=null` [14]. Two of the two assertion lines end in `server=null`, which is the useful arithmetic: the connection-level property carries no information in either branch, so a handler reading it cannot be right by accident [17]. A property that is deliberately null is odd as API surface and excellent as a smoke alarm.
For this to matter to your service, one thing has to be true: your traffic has to vary. A single well-behaved client that sends the same extension map on every call will make a cached, connection-scoped read look correct indefinitely. The post's own account of the failure mode is overlap, a load test or proxy or compatibility client mixing modern requests with different extension maps inside one process, where code that passed with one caller fails only under concurrency [16]. That is also why a sequential happy-path test proves so little [15].
One boundary worth stating before anyone wires this into a permission check. A declared capability is a self-reported protocol feature, not authentication, authorization, or trusted identity, and a protected report export still needs validated claims and application policy behind it [11]. The declaration tells you what response shape the caller can handle. It tells you nothing about who the caller is.
This is one engineer's reading plus a working sample, not a spec I can quote back at you. The load-bearing claims are checkable, though: the sample runs on the stable `ModelContextProtocol.AspNetCore` 2.2.0 package rather than a preview API [7], and the writeup says the official `JsonRpcMessageContext` reference already names the current request as authoritative [6]. If both hold, the migration is a search for cached capability state, and the sessionless model gives you a real deployment benefit in exchange: separate instances can serve calls from the same client with no sticky routing and no shared session store [2].
