Add mcp.types as a permanent alias for mcp_types (#3190)

docs/handlers/dependencies.md

@@ -138,7 +138,7 @@ That's the right default for a precondition: no answer, no order. When declining
 
 Elicitation is one of the three questions a resolver can ask, and the multi-round-trip flow allows no others. The other two go to the **client** rather than the user: return `Sample(...)` to run an LLM call through the client (a `sampling/createMessage` request), or `ListRoots()` to fetch the client's current roots. Neither has an accept/decline outcome; the consumer annotates the result type directly, `CreateMessageResult` (`CreateMessageResultWithTools` when the request carries `tools` or `tool_choice`) or `ListRootsResult`:
 
-```python title="server.py" hl_lines="11-16 22"
+```python title="server.py" hl_lines="10-15 21"
 --8<-- "docs_src/dependencies/tutorial004.py"
 ```
 

docs/handlers/elicitation.md

@@ -128,7 +128,7 @@ Look at the second tool. When your server learns the out-of-band flow finished (
 
 Servers ask. Clients answer by passing an **`elicitation_callback`** to `Client(...)`:
 
-```python title="client.py" hl_lines="7-8 19"
+```python title="client.py" hl_lines="6-7 18"
 --8<-- "docs_src/elicitation/tutorial003.py"
 ```
 

docs/handlers/multi-round-trip.md

@@ -21,7 +21,7 @@ That's the whole protocol. Every leg is an ordinary request from the client to t
 
 On `@mcp.tool()` you rarely build this by hand: declare a dependency that asks the user (`Elicit`), samples the client's LLM (`Sample`), or lists its roots (`ListRoots`) and the SDK returns the `InputRequiredResult` for you; that form is the **[Dependencies](dependencies.md)** page. The two forms don't mix: a call has one `input_responses`/`request_state` channel, so a tool that uses `Resolve(...)` parameters cannot also return `InputRequiredResult` from its body. A declared `InputRequiredResult` return is rejected at registration (`InvalidSignature`), and an undeclared one fails the call at runtime. The manual form is the **low-level** `Server`, whose `on_call_tool` handler is allowed to return either result type:
 
-```python title="server.py" hl_lines="44-47"
+```python title="server.py" hl_lines="43-46"
 --8<-- "docs_src/mrtr/tutorial001.py"
 ```
 
@@ -35,7 +35,7 @@ Everything else in that file (the explicit `input_schema`, the hand-built `CallT
 
 `tools/call` is not special: at 2026-07-28 a server may answer `prompts/get` and `resources/read` the same way. On `MCPServer`, an `@mcp.prompt()` function — or an `@mcp.resource()` **template** function — returns the `InputRequiredResult` itself and reads the retry's answers off the context:
 
-```python title="server.py" hl_lines="21 23 25"
+```python title="server.py" hl_lines="20 22 24"
 --8<-- "docs_src/mrtr/tutorial004.py"
 ```
 
@@ -51,7 +51,7 @@ Everything else in that file (the explicit `input_schema`, the hand-built `CallT
 
 Register the callbacks the server might ask for (`elicitation_callback`, `sampling_callback`, `list_roots_callback`) and call the tool. When an `InputRequiredResult` arrives, `Client` dispatches each entry in `input_requests` to the matching callback, retries with the answers and the echoed `request_state`, and keeps going until a `CallToolResult` comes back:
 
-```python title="client.py" hl_lines="12 13"
+```python title="client.py" hl_lines="11 12"
 --8<-- "docs_src/mrtr/tutorial003.py"
 ```
 
@@ -76,7 +76,7 @@ The auto-loop is enough for a single-process client. Own the loop instead when:
 
 Drop to the underlying session, where `allow_input_required=True` hands you the union directly:
 
-```python title="client.py" hl_lines="13 14 20"
+```python title="client.py" hl_lines="12 13 19"
 --8<-- "docs_src/mrtr/tutorial002.py"
 ```
 

docs/handlers/sampling-and-roots.md

@@ -11,7 +11,7 @@ Both still work, on every protocol version the SDK speaks. But read the warning
 
 A resolver returns `Sample(...)` and the tool receives the completion, through the same dependency mechanism that runs `Elicit` in **[Dependencies](dependencies.md)**:
 
-```python title="server.py" hl_lines="11-16 20"
+```python title="server.py" hl_lines="10-15 19"
 --8<-- "docs_src/sampling_and_roots/tutorial001.py"
 ```
 
@@ -24,7 +24,7 @@ A resolver returns `Sample(...)` and the tool receives the completion, through t
 
 Roots are the folders the client says the server may operate on. They are informational guidance, not an access-control mechanism. A resolver returns `ListRoots()`:
 
-```python title="server.py" hl_lines="11-12 16"
+```python title="server.py" hl_lines="10-11 15"
 --8<-- "docs_src/sampling_and_roots/tutorial002.py"
 ```
 

docs/handlers/subscriptions.md

@@ -56,7 +56,7 @@ Two things the stream is *not*:
 
 Here is a client on the other side of that stream, following the board:
 
-```python title="client.py" hl_lines="16"
+```python title="client.py" hl_lines="15"
 --8<-- "docs_src/subscriptions/tutorial003.py"
 ```
 
@@ -119,7 +119,7 @@ async def tools_reloaded() -> None:
 
 Down on the low-level `Server` there is no pre-wired anything, and the same parts assemble in three lines:
 
-```python title="server.py" hl_lines="9-10 48"
+```python title="server.py" hl_lines="8-9 47"
 --8<-- "docs_src/subscriptions/tutorial002.py"
 ```