Docs and docstrings catch up with recent contract changes

- extensions.md interception section: call_next returns the handler's
  result, short-circuits are serialized and stamped like handler
  results, the validated params argument decides the tool invocation,
  and no middleware is involved either way.
- whats-new client recap: server_info is Implementation | None.
- Server.server_info and a transport-test helper docstring still
  described the removed package-version fallback.
- _stamp_server_info docstring states the explicit-null posture (null
  reads as absent, mirroring clientInfo).

No-Verification-Needed: docs and docstring-only edits

Author: maxisbey

docs/advanced/extensions.md

@@ -133,14 +133,21 @@ or veto a tool call:
 ```
 
 * `params` is the validated `CallToolRequestParams`: you get `params.name` and
-  `params.arguments` without touching raw JSON.
-* `call_next(ctx)` runs the rest of the chain. Return its result unchanged (observe),
-  return something else (replace), or raise an `MCPError` (refuse).
+  `params.arguments` without touching raw JSON. It is also what decides which
+  tool call runs: passing a rewritten context through `call_next` changes what
+  the handler observes on `ctx`, not the tool invocation. Wire-level request
+  rewriting belongs to [Middleware](middleware.md).
+* `call_next(ctx)` runs the rest of the chain and returns the handler's result.
+  Return it unchanged (observe), return something else (replace), or raise an
+  `MCPError` (refuse). Whatever you return is serialized like any handler
+  result, including the 2026-era `serverInfo` identity stamp, so a
+  short-circuiting interceptor never produces an anonymous or off-schema
+  response.
 * With several extensions, interceptors nest in registration order: the first
   extension in `extensions=[...]` is outermost.
 * The default implementation is a pass-through, and a server whose extensions never
-  override this hook installs **no** middleware at all. You don't pay for what
-  you don't use.
+  override this hook keeps the bare `tools/call` handler untouched. You don't
+  pay for what you don't use.
 
 The hook wraps `tools/call` and nothing else. For every-message concerns, use
 [Middleware](middleware.md). That is what it is for.

docs/whats-new.md

@@ -44,7 +44,7 @@ v1 handed you three nested layers: a transport context manager yielding raw stre
 --8<-- "docs_src/client/tutorial001.py"
 ```
 
-`Client` takes a server object (in memory, no transport: the testing story), a URL (Streamable HTTP), or any transport context manager such as `stdio_client(...)`. Entering `async with` connects and negotiates the protocol version, whichever era the server speaks; `client.server_info`, `client.server_capabilities`, and `client.protocol_version` are simply there afterwards. The sampling and elicitation callbacks you registered in v1 still work (their bodies see the same snake_case attribute rename as everything else on this page), they now also answer the 2026-style requests-inside-results (below), and they run concurrently instead of one at a time. `ClientSession` is still underneath for anyone who wants the low-level surface, and `client.session` hands it to you; it moved too (it runs on the new dispatcher engine, and some of its own signatures changed), so read the **[Migration Guide](migration.md#clientsession-now-runs-on-jsonrpcdispatcher-basesession-removed)** before you drop down.
+`Client` takes a server object (in memory, no transport: the testing story), a URL (Streamable HTTP), or any transport context manager such as `stdio_client(...)`. Entering `async with` connects and negotiates the protocol version, whichever era the server speaks; `client.server_capabilities` and `client.protocol_version` are simply there afterwards, and `client.server_info` is too when the server identifies itself (it is `Implementation | None` now, since 2026-era identity is optional). The sampling and elicitation callbacks you registered in v1 still work (their bodies see the same snake_case attribute rename as everything else on this page), they now also answer the 2026-style requests-inside-results (below), and they run concurrently instead of one at a time. `ClientSession` is still underneath for anyone who wants the low-level surface, and `client.session` hands it to you; it moved too (it runs on the new dispatcher engine, and some of its own signatures changed), so read the **[Migration Guide](migration.md#clientsession-now-runs-on-jsonrpcdispatcher-basesession-removed)** before you drop down.
 
 **[The Client](client/index.md)** introduces it, **[Client transports](client/transports.md)** covers the three connection forms, **[Client callbacks](client/callbacks.md)** covers the callbacks themselves, and **[Testing](get-started/testing.md)** shows the in-memory pattern that replaces v1's `create_connected_server_and_client_session()` helper.
 

src/mcp/server/lowlevel/server.py

@@ -628,8 +628,8 @@ def get_capabilities(
     def server_info(self) -> types.Implementation:
         """The `serverInfo` block describing this implementation.
 
-        Derived from the constructor's identity fields. `version` falls back to
-        the installed `mcp` package version when not supplied explicitly.
+        Derived from the constructor's identity fields. An unversioned server
+        reports an empty `version`; the SDK never substitutes its own.
         """
         return types.Implementation(
             name=self.name,

src/mcp/server/runner.py

@@ -382,8 +382,11 @@ def _serialize(self, method: str, version: str, result: HandlerResult) -> dict[s
     def _stamp_server_info(self, version: str, result: dict[str, Any]) -> dict[str, Any]:
         """Fill the `serverInfo` `_meta` stamp on a 2026-era result (spec #3002).
 
-        A handler-authored value wins, a non-mapping `_meta` is the handler's
-        to own, and handshake-era results are never stamped. `result` is
+        A handler-authored value wins; an explicit `null` reads as absent and
+        is stamped over, mirroring the request-side `clientInfo` posture (a
+        `null` is not a valid `Implementation`, so presence means a value). A
+        non-mapping `_meta` is the handler's to own, and handshake-era results
+        are never stamped. `result` is
         pipeline-owned (`_dump_result` copies dicts; the spec-method sieve
         re-dumps), but `_meta` may still be the handler's object, so the stamp
         replaces it rather than writing into it. `server_info_stamp` is a

tests/interaction/transports/test_hosting_http_modern.py

@@ -80,9 +80,8 @@ def _meta_envelope() -> dict[str, object]:
 def _server(*, on_meta: Callable[[dict[str, Any]], None] | None = None) -> Server:
     """A low-level server with one `add` tool for the raw-httpx2 tests below.
 
-    The explicit version pins the `_meta` serverInfo stamp every 2026 result carries, so
-    wire-level snapshots stay deterministic (the default falls back to the installed package
-    version).
+    The explicit version gives the `_meta` serverInfo stamp every 2026 result
+    carries a non-empty value for the wire-level snapshots.
     """
 
     async def list_tools(ctx: ServerRequestContext, params: PaginatedRequestParams | None) -> ListToolsResult: