FastMCP client_supports_extension returns False when 2026-07-28 request advertises extension without clientInfo

Finding: In an external report on PrefectHQ/fastmcp issue #5192, FastMCP 4.0.5 with MCP 2.2.0 (Python 3.12.0, Windows 11, protocol 2026-07-28) is said to return False from ctx.client_supports_extension("io.modelcontextprotocol/ui") when the request envelope advertises that extension in client capabilities but omits the optional clientInfo (https://github.com/PrefectHQ/fastmcp/issues/5192). This is an external report only; KFA did not reproduce it. Reported symptom: on the same request, session.client_capabilities.extensions reportedly holds the UI extension, yet the check returns False. When the reporter adds clientInfo, it returns True. A server that gates behavior on this check would therefore drop the feature for a client that conforms to the protocol, with no error raised. The reporter's script posts the raw envelope to a stateless HTTP app, because FastMCP's own Client sends clientInfo and so only exercises the passing branch (source: issue body). Reported cause (hypothesis, not maintainer-confirmed): the reporter says client_supports_extension in fastmcp_slim/fastmcp/server/low_level.py returns early when session.client_params is None. On 2026-07-28 the SDK reportedly sets client_capabilities in either case and creates client_params only when clientInfo arrives. The reporter also notes that the SDK documentation on the property in mcp/server/session.py prefers client_capabilities over client_params.capabilities. The reporter checked main at commit 9c35c017cd89e4d50a9f512c8eafde68c301ec70 and reported low_level.py unchanged at that time. Diagnostic hint (source-backed, not verified by KFA): if a gated feature disappears for a client on this protocol version, compare the result of the check with session.client_capabilities.extensions on the same request, and check whether the client sends clientInfo. Status: the issue is closed, but the captured timeline contains no maintainer comment, no linked PR, no fix commit and no release reference. The reporter offered to open a PR. Whether the behavior was fixed, declined, or closed for another reason is UNKNOWN. Comment coverage is partial, so omitted comments may contain more information. Limitations: single external report, no independent reproduction, and the code-path explanation is the reporter's reading. Do not treat closure as evidence of a shipped fix.