A tester notices that a server returns a different tools/list depending on which TCP connection asks, even when both connections present the same access token. The developer says it keeps per-connection tool state. How should the tester assess this?
Select an answer to reveal the explanation.
Short Explanation
If you and a colleague carry the same badge, you should see the same doors, no matter which entrance they walked through. Lists can change with credentials, never with the connection. The trap is thinking MCP still has sessions to hang state on.
Full Explanation
Revision 2026-07-28 removed protocol-level sessions, and list endpoints no longer vary per connection. Servers declaring the tools capability must respond to tools/list with the set of tools currently available to the requesting client, and that set must not vary per connection or as a side effect of other requests on the connection. It may vary by the authorization presented on the request, for example returning only the tools the caller's granted scopes permit, because credentials are per-request input rather than connection state. Two connections carrying the same token therefore must see the same list, so the per-connection behavior is non-compliant. Calling a connection a session revives a concept the revision removed; the Mcp-Session-Id header is gone. Requiring an identical list for every caller ignores the explicit allowance for authorization-based filtering. Sending list_changed on each connection does not help: notifications reach only clients that opted in through subscriptions/listen, and they cannot make connection-dependent lists compliant. Exam caveat: the list may still change over time, and servers should keep the order deterministic so clients can cache it. Operational check: call tools/list over two fresh connections with the same token and confirm identical, identically ordered results.