chore: import upstream snapshot with attribution

2026-07-13 12:10:27 +08:00
commit 49b9bb6724
992 changed files with 161690 additions and 0 deletions
@@ -0,0 +1,118 @@
 Review the pull request: $ARGUMENTS
 Follow these steps carefully. Use the `gh` CLI for all GitHub interactions.
 ## Step 1: Resolve the PR
 Parse `$ARGUMENTS` to determine the PR. It can be:
 - A full URL like `https://github.com/owner/repo/pull/123`
 - A `owner/repo#123` reference
 - A bare number like `123` (use the current repo)
 - A description — search for it with `gh pr list --search "<description>" --limit 5` and pick the best match
 Once resolved, fetch the PR metadata:
 ```bash
 gh pr view <PR> --json number,title,body,author,state,baseRefName,headRefName,url,labels,milestone,additions,deletions,changedFiles,createdAt,updatedAt,mergedAt,reviewDecision,reviews,assignees
 ```
 ## Step 2: Gather the diff
 Get the full diff of the PR:
 ```bash
 gh pr diff <PR>
 ```
 If the diff is very large (>3000 lines), focus on the most important files first and summarize the rest.
 ## Step 3: Collect PR discussion context
 Fetch all comments and review threads:
 ```bash
 gh api repos/{owner}/{repo}/pulls/{number}/comments --paginate
 gh api repos/{owner}/{repo}/issues/{number}/comments --paginate
 gh api repos/{owner}/{repo}/pulls/{number}/reviews --paginate
 ```
 Pay attention to:
 - Reviewer feedback and requested changes
 - Author responses and explanations
 - Any unresolved conversations
 - Approval or rejection status
 ## Step 4: Find and read linked issues
 Look for issue references in:
 - The PR body (patterns like `#123`, `fixes #123`, `closes #123`, `resolves #123`)
 - The PR branch name (patterns like `issue-123`, `fix/123`)
 - Commit messages
 For each linked issue, fetch its content:
 ```bash
 gh issue view <number> --json title,body,comments,labels,state
 ```
 Read through issue comments to understand the original problem, user reports, and any discussed solutions.
 ## Step 5: Analyze and validate
 With all context gathered, analyze the PR critically:
 1. **Intent alignment**: Does the code change actually solve the problem described in the PR and/or linked issues?
 2. **Completeness**: Are there aspects of the issue or requested feature that the PR doesn't address?
 3. **Scope**: Does the PR include changes unrelated to the stated goal? Are there unnecessary modifications?
 4. **Correctness**: Based on the diff, are there obvious bugs, edge cases, or logic errors?
 5. **Testing**: Does the PR include tests? Are they meaningful and do they cover the important cases?
 6. **Breaking changes**: Could this PR break existing functionality or APIs?
 7. **Unresolved feedback**: Are there reviewer comments that haven't been addressed?
 ## Step 6: Produce the review summary
 Present the summary in this format:
 ---
 ### PR Review: `<title>` (<url>)
 **Author:** <author> | **Status:** <state> | **Review decision:** <decision>
 **Base:** `<base>` ← `<head>` | **Changed files:** <n> | **+<additions> / -<deletions>**
 #### Problem
 <1-3 sentences describing what problem this PR is trying to solve, based on the PR description and linked issues>
 #### Solution
 <1-3 sentences describing the approach taken in the code>
 #### Key changes
 <Bulleted list of the most important changes, grouped by theme. Include file paths.>
 #### Linked issues
 <List of linked issues with their title, state, and a one-line summary of the discussion>
 #### Discussion highlights
 <Summary of important comments from reviewers and the author. Flag any unresolved threads.>
 #### Concerns
 <List any issues found during validation: bugs, missing tests, scope creep, unaddressed feedback, etc. If none, say "No concerns found.">
 #### Verdict
 <One of: APPROVE / REQUEST CHANGES / NEEDS DISCUSSION, with a brief justification>
 #### Suggested action
 <Clear recommendation for the reviewer: what to approve, what to push back on, what to ask about>
 ---
@@ -0,0 +1,150 @@
 ---
 name: test-quality
 description: Test quality bar for this repo. Read when writing, reviewing, or designing tests — covers naming, abstraction level, assertions, determinism, and the process for agent-driven test work.
 ---
 # Test & code quality guide
 What "best practice for new work" means in this repo. Each rule carries its recorded reasoning
 where one exists; a rule with no stated why is a convention — follow it anyway.
 ## Naming & shape
 - **Test names are behaviour sentences** stating the observable outcome, not the feature being
  poked: `test_elicit_form_decline_returns_no_content`, never `test_elicit_form_decline`.
 - Plain top-level `test_*` functions; no `Test` classes (legacy files have them — don't copy).
 - **Docstrings: 1–2 sentences of behaviour, honest about provenance** — spec-mandated,
  SDK-defined, or pinning a known gap? Say which: provenance is the triage key when the test
  later fails. A pinned-gap assertion breaking usually means a change *fixed* the gap; a
  spec-mandated assertion breaking means a regression.
 - Define things in dependency order; nothing forward-references. For client↔server tests:
  handlers → server construction → client setup → act → assert — the test reads in the order
  the conversation happens.
 - Inline the server (or equivalent setup) in the test, so the whole observable behaviour fits
  on one screen. Lift to a file-level fixture only when several tests in *that file* genuinely
  share it; never share across files.
 - A big multi-step test is fine when the property is irreducibly multi-step (e.g. resumability).
  Split when a failure wouldn't tell you which claim broke — not for shortness. Compensate with
  a numbered "Steps:" docstring so a reader sees the choreography before the body.
 ## Level of abstraction
 - **Drive through the highest-level public API that can observe the property.** Hand-built wire
  requests are brittle and don't prove the user-facing contract; tests that stay above the
  internals keep working when the internals change. Drop to raw HTTP only when the assertion is
  about something the high-level API *cannot* observe (status codes, headers, wire framing).
 - **Scripting a peer over raw streams is a last resort**, reserved for behaviour the typed API
  cannot *produce* (malformed input, an impossible peer response). First ask what it would take
  for the public API to express it — often a small helper suffices. Every such test's docstring
  states why the public API couldn't do it.
 - **In-memory / in-process first.** HTTP-, SSE-, and auth-shaped behaviour can all be driven
  through an in-process ASGI transport; threads only when necessary, subprocesses only when the
  process boundary is itself the thing under test. In-process isn't just faster — it surfaces
  bugs (a real stream leak was found this way) that subprocess indirection masks.
 - **Tests read like real user code**: no aliasing shims in conftest, no walls of suppressions,
  no private imports unless that is genuinely the documented way to do the thing.
 - The assertion must prove the round trip — no side-channel state. What the server saw comes
  back through the protocol, or via a closure-captured list asserted after the call. Handlers
  assert their dispatch identity first (`assert params.name == "add"`), proving the request
  that arrived is the request the test sent.
 ## Assertions
 - **Transformations** (input → output the SDK produced) → full-object `snapshot(...)` equality,
  so an added or dropped field fails. Regenerate with `--inline-snapshot=fix` so intentional
  changes arrive as a reviewable diff; never hand-edit snapshot literals.
 - **Pass-through values** (opaque tokens, `_meta`, cursors) → identity against the same
  variable you sent. A snapshot of a pass-through value only "matches" because a human checked
  two literals correspond — it proves nothing.
 - **Errors** → `pytest.raises` + `.code` against the named constant; snapshot SDK-authored
  messages; never `match=` on message text. Third-party text (pydantic, jsonschema) → stable
  prefix only — never pin text that changes with a dependency upgrade — with a comment saying so.
 ## Determinism
 - **No sleeps, ever.** A sleep guesses at timing instead of waiting on the condition, so it
  either flakes or pads the run — sleeps head the list of the older test code's failure modes.
  Coordinate with `anyio.Event` so the wait ends exactly when the condition holds (that
  discipline is why 529 e2e tests run in ~10 s). Sole exception: tests *of* time-based
  features, with a comment.
 - Bound every indefinite wait with `anyio.fail_after(5)`. **5 is the standard** — widening it
  needs an articulable reason; "10 to be safe" is covering up a flake, not fixing one, and
  unexplained widenings propagate (one agent used 10 and every later one copied it).
 - **Never assert wall-clock time, even with huge margins.** `elapsed < 0.9` on a ~0.01 s
  operation — a 90× margin — was still rejected in review. `fail_after` bounding a hang is the
  only timing primitive allowed.
 - **Concurrency tests must prove genuine interleaving.** Without barriers the scheduler is free
  to serialize — "a" can start, finish, and return before "b" even begins — so two `start_soon`
  calls prove nothing. Gate with events so all parties are mid-flight before any proceeds, emit
  interleaved, then assert the demux.
 - **Don't over-synchronize either.** When delivery ordering is guaranteed (notifications
  emitted during a request you're awaiting, over a single ordered in-memory stream), a plain
  collected list asserted after the call is correct; events are for messages not tied to an
  awaited operation. Verify the ordering guarantee actually holds for your transport first.
 - Async tests use anyio, not asyncio.
 ## Behaviour philosophy
 - **Pin current behaviour; never xfail.** A green suite asserting what actually happens is a
  regression bar for any refactor; an xfail proves nothing about it. Where current behaviour
  falls short of spec, pin the divergent output and record the gap as data — a tracking issue,
  with the docstring naming the known gap (suites with a requirements manifest record it as a
  divergence entry). Not hidden, not skipped.
 - **Hollow-proof check**: before claiming a test covers a behaviour, re-read the claim and ask
  "which assertion proves *this*?" A passing test near a behaviour is not proof of it — a full
  review of the e2e suite found two such cases even under this discipline.
 ## Hygiene
 - No new `# pragma`, `# type: ignore`, `# noqa` by default — restructure first; a suppression
  usually means a test or a type is missing. The narrow sanctioned escape hatches (and the
  audit to run before pushing) are in AGENTS.md. In tests, narrow types with `assert
  isinstance`; never `Any`/`object` when a real type exists.
 - **Warnings raised during tests are findings, not noise** (the repo runs
  `filterwarnings = error`). Fix the cause; if the fix can't land in the same change, scope the
  suppression to the one fixture that needs it and track the real fix explicitly.
 - Registered-but-never-invoked handler bodies are `raise NotImplementedError`, so they cannot
  silently become load-bearing.
 - Comments live next to the line they explain, not in docstrings; single backticks for code
  refs; match the surrounding comment density (one-liners next to one-liners). No
  `from __future__ import annotations` (py310+ repo).
 - Test work doesn't change `src/` as a side effect — the one mechanical exception is deleting a
  pragma a new test now covers. If a test can't be written without a library change, raise it
  as a finding or defer the test; don't quietly edit `src/`.
 ## Process (for agent-driven work)
 - **Small chunks.** ≤10 tests per human-reviewed batch; when fanning out to multiple agents,
  ≤5 per agent. Review quality scales inversely with batch size: the observed shortcuts
  (over-stacked tests, a timing assertion, wrong abstraction level) all surfaced in one
  oversized 27-test batch.
 - **Design → review → implement, as separate steps.** The design deliverable is not just the
  plan — it's the judgement calls (abstraction level, deferrals, contested assertions) stated
  explicitly, so the reviewer vetoes them before implementation rather than discovering them
  in the diff.
 - **High-stakes areas get fresh adversarial reviewers** on both the design and the
  implementation — fresh, because whoever designed it (or saw the proposed fix) anchors on the
  same layer. SERIOUS findings (wrong assertion, missed MUST/SHOULD, an unrecorded known gap)
  re-loop; style doesn't. Reserve the full panel for areas where being wrong is worse than
  being slow.
 - **Investigations pair a full-context look with a fresh agent given only the problem** —
  never the proposed fix — and compare conclusions. The unbiased read regularly catches
  anchoring on the wrong layer.
 - **When review questions a decision, reconsider genuinely**: re-derive the tradeoff, state the
  options, recommend with reasons. Defending the original choice is a valid outcome;
  reflexively agreeing with every challenge is as bad as ignoring it.
 - **Validate the reference artifact before building on it.** Whatever you treat as ground truth
  (a spec import, a baseline, a generated list), check it *first* — discovering it was
  incomplete after five batches costs far more than before batch one.
 - **Verify as you go**: per-file `uv run --frozen pytest <file> -q` + pyright + ruff while
  iterating; full suite, coverage, and `./scripts/test` (when `src/` was touched) at
  integration.
 - **Every agent writes notes**: what it did, what broke, and — most importantly — what it
  couldn't decide, so open questions surface instead of being silently resolved by whoever hit
  them.
 - **Quality over speed is a stated goal, not a preference** ("rushing something out the door is
  not the goal here, explicitly so"). Don't quietly de-scope agreed work mid-stream;
  renegotiate scope explicitly.
 - **Don't copy patterns from existing test code by default** — much of the repo's older test
  code is below the current bar (sleeps, mocks, `Test` classes, raciness). These rules define
  the bar for new work.
@@ -0,0 +1,5 @@
 # Applied 120 line-length rule to all files: https://github.com/modelcontextprotocol/python-sdk/pull/856
 543961968c0634e93d919d509cce23a1d6a56c21
 # Added 100% code coverage baseline with pragma comments: https://github.com/modelcontextprotocol/python-sdk/pull/1553
 89e9c43acf7e23cf766357d776ec1ce63ac2c58e
@@ -0,0 +1,2 @@
 # Generated
 uv.lock  linguist-generated=true
@@ -0,0 +1,55 @@
 name: 🐛 MCP Python SDK Bug
 description: Report a bug or unexpected behavior in the MCP Python SDK
 labels: ["need confirmation"]
 body:
  - type: markdown
    attributes:
      value: Thank you for contributing to the MCP Python SDK! ✊
  - type: checkboxes
    id: checks
    attributes:
      label: Initial Checks
      description: Just making sure you're using the latest version of MCP Python SDK.
      options:
        - label: I confirm that I'm using the latest version of MCP Python SDK
          required: true
        - label: I confirm that I searched for my issue in https://github.com/modelcontextprotocol/python-sdk/issues before opening this issue
          required: true
  - type: textarea
    id: description
    attributes:
      label: Description
      description: |
        Please explain what you're seeing and what you would expect to see.
        Please provide as much detail as possible to make understanding and solving your problem as quick as possible. 🙏
    validations:
      required: true
  - type: textarea
    id: example
    attributes:
      label: Example Code
      description: >
        If applicable, please add a self-contained,
        [minimal, reproducible, example](https://stackoverflow.com/help/minimal-reproducible-example)
        demonstrating the bug.
      placeholder: |
        from mcp.server.mcpserver import MCPServer
        ...
      render: Python
  - type: textarea
    id: version
    attributes:
      label: Python & MCP Python SDK
      description: |
        Which version of Python and MCP Python SDK are you using?
      render: Text
    validations:
      required: true
@@ -0,0 +1 @@
 blank_issues_enabled: false
@@ -0,0 +1,29 @@
 name: 🚀 MCP Python SDK Feature Request
 description: "Suggest a new feature for the MCP Python SDK"
 labels: ["feature request"]
 body:
  - type: markdown
    attributes:
      value: Thank you for contributing to the MCP Python SDK! ✊
  - type: textarea
    id: description
    attributes:
      label: Description
      description: |
        Please give as much detail as possible about the feature you would like to suggest. 🙏
        You might like to add:
        * A demo of how code might look when using the feature
        * Your use case(s) for the feature
        * Reference to other projects that have a similar feature
    validations:
      required: true
  - type: textarea
    id: references
    attributes:
      label: References
      description: |
        Please add any links or references that might help us understand your feature request better. 📚
@@ -0,0 +1,33 @@
 name: ❓ MCP Python SDK Question
 description: "Ask a question about the MCP Python SDK"
 labels: ["question"]
 body:
  - type: markdown
    attributes:
      value: Thank you for reaching out to the MCP Python SDK community! We're here to help! 🤝
  - type: textarea
    id: question
    attributes:
      label: Question
      description: |
        Please provide as much detail as possible about your question. 🙏
        You might like to include:
        * Code snippets showing what you've tried
        * Error messages you're encountering (if any)
        * Expected vs actual behavior
        * Your use case and what you're trying to achieve
    validations:
      required: true
  - type: textarea
    id: context
    attributes:
      label: Additional Context
      description: |
        Please provide any additional context that might help us better understand your question, such as:
        * Your MCP Python SDK version
        * Your Python version
        * Relevant configuration or environment details 📝
@@ -0,0 +1,59 @@
 name: v2 feedback
 description: Bugs, API friction, or docs gaps in v2 of the SDK
 title: "[v2] "
 labels: ["v2-alpha"]
 body:
  - type: markdown
    attributes:
      value: |
        Thanks for trying v2. Anything that broke, surprised you, or slowed you down is useful — API feedback is explicitly welcome while v2 is in pre-release.
        Docs: https://py.sdk.modelcontextprotocol.io/v2/ · Migration from v1: https://py.sdk.modelcontextprotocol.io/v2/migration/
  - type: textarea
    id: what
    attributes:
      label: What happened?
      description: What did you do, and what went wrong (or felt wrong)? Paste error output verbatim if there is any.
    validations:
      required: true
  - type: textarea
    id: expected
    attributes:
      label: What did you expect?
    validations:
      required: false
  - type: textarea
    id: repro
    attributes:
      label: Code to reproduce
      description: The smallest snippet or repository that shows it. For docs feedback, link the page instead.
      render: Python
    validations:
      required: false
  - type: input
    id: version
    attributes:
      label: SDK version
      description: The published version (`pip show mcp`) or commit.
    validations:
      required: false
  - type: dropdown
    id: area
    attributes:
      label: Area
      options:
        - Server
        - Client
        - Transports
        - Auth
        - Documentation
        - Migration
        - Other
    validations:
      required: false
@@ -0,0 +1,614 @@
 """MCP unified conformance test client.
 This client is designed to work with the @modelcontextprotocol/conformance npm package.
 It handles all conformance test scenarios via environment variables and CLI arguments.
 Contract:
    - MCP_CONFORMANCE_SCENARIO env var -> scenario name
    - MCP_CONFORMANCE_CONTEXT env var -> optional JSON (for client-credentials scenarios)
    - MCP_CONFORMANCE_PROTOCOL_VERSION env var -> spec version the harness mock
      server is speaking (e.g. "2025-11-25", "2026-07-28"). Always set; when
      --spec-version is omitted the harness picks per-scenario (LATEST_SPEC_VERSION
      for active scenarios, DRAFT_PROTOCOL_VERSION for draft-only ones).
    - Server URL as last CLI argument (sys.argv[1])
    - Must exit 0 within 30 seconds
 Scenarios:
    initialize                              - Connect, initialize, list tools, close
    tools_call                              - Connect, call add_numbers(a=5, b=3), close
    sse-retry                               - Connect, call test_reconnection, close
    json-schema-ref-no-deref                - Connect, list tools (no $ref deref)
    request-metadata                        - Connect with all callbacks; client stamps _meta
    http-standard-headers                   - Connect, call a tool (Mcp-* headers checked)
    http-invalid-tool-headers               - List tools, call every surfaced tool (x-mcp-header filter)
    elicitation-sep1034-client-defaults     - Elicitation with default accept callback
    sep-2322-client-request-state           - Drive the MRTR auto-loop (SEP-2322)
    auth/client-credentials-jwt             - Client credentials with private_key_jwt
    auth/client-credentials-basic           - Client credentials with client_secret_basic
    auth/enterprise-managed-authorization   - SEP-990 ID-JAG (RFC 8693 + RFC 7523 jwt-bearer)
    auth/*                                  - Authorization code flow (default for auth scenarios)
 """
 import asyncio
 import json
 import logging
 import os
 import sys
 from collections.abc import Callable, Coroutine
 from typing import Any, cast
 from urllib.parse import parse_qs, urlparse
 import httpx
 import mcp_types as types
 from mcp_types.version import MODERN_PROTOCOL_VERSIONS
 from pydantic import AnyUrl
 from mcp.client.auth import OAuthClientProvider, TokenStorage
 from mcp.client.auth.extensions.client_credentials import (
    ClientCredentialsOAuthProvider,
    PrivateKeyJWTOAuthProvider,
    SignedJWTParameters,
 )
 from mcp.client.auth.extensions.identity_assertion import IdentityAssertionOAuthProvider
 from mcp.client.auth.utils import build_protected_resource_metadata_discovery_urls
 from mcp.client.client import Client
 from mcp.client.context import ClientRequestContext
 from mcp.client.streamable_http import streamable_http_client
 from mcp.shared.auth import AuthorizationCodeResult, OAuthClientInformationFull, OAuthClientMetadata, OAuthToken
 # Set up logging to stderr (stdout is for conformance test output)
 logging.basicConfig(
    level=logging.DEBUG,
    format="%(asctime)s - %(name)s - %(levelname)s - %(message)s",
    stream=sys.stderr,
 )
 logger = logging.getLogger(__name__)
 #: Spec version the harness is running this scenario at (e.g. "2025-11-25",
 #: "2026-07-28"). The harness always sets this (when --spec-version is omitted
 #: it picks per-scenario: LATEST_SPEC_VERSION for active scenarios,
 #: DRAFT_PROTOCOL_VERSION for draft-only ones), so None means we were invoked
 #: outside the harness.
 PROTOCOL_VERSION: str | None = os.environ.get("MCP_CONFORMANCE_PROTOCOL_VERSION")
 def client_mode() -> str:
    """Pick the Client(mode=) for the harness leg.
    On a modern leg (2026-07-28+) -> 'auto' so Client.discover() runs and the
    _meta envelope + MCP-Protocol-Version header are stamped on every request.
    On a handshake-era leg -> 'legacy' so the initialize handshake runs exactly
    as before (no server/discover probe is sent against a mock that would 400 it).
    Outside the harness -> 'auto' (probe + fallback).
    """
    if PROTOCOL_VERSION is None or PROTOCOL_VERSION in MODERN_PROTOCOL_VERSIONS:
        return "auto"
    return "legacy"
 # Type for async scenario handler functions
 ScenarioHandler = Callable[[str], Coroutine[Any, None, None]]
 # Registry of scenario handlers
 HANDLERS: dict[str, ScenarioHandler] = {}
 def register(name: str) -> Callable[[ScenarioHandler], ScenarioHandler]:
    """Register a scenario handler."""
    def decorator(fn: ScenarioHandler) -> ScenarioHandler:
        HANDLERS[name] = fn
        return fn
    return decorator
 def get_conformance_context() -> dict[str, Any]:
    """Load conformance test context from MCP_CONFORMANCE_CONTEXT environment variable."""
    context_json = os.environ.get("MCP_CONFORMANCE_CONTEXT")
    if not context_json:
        raise RuntimeError(
            "MCP_CONFORMANCE_CONTEXT environment variable not set. "
            "Expected JSON with client_id, client_secret, and/or private_key_pem."
        )
    try:
        return json.loads(context_json)
    except json.JSONDecodeError as e:
        raise RuntimeError(f"Failed to parse MCP_CONFORMANCE_CONTEXT as JSON: {e}") from e
 class InMemoryTokenStorage(TokenStorage):
    """Simple in-memory token storage for conformance testing."""
    def __init__(self) -> None:
        self._tokens: OAuthToken | None = None
        self._client_info: OAuthClientInformationFull | None = None
    async def get_tokens(self) -> OAuthToken | None:
        return self._tokens
    async def set_tokens(self, tokens: OAuthToken) -> None:
        self._tokens = tokens
    async def get_client_info(self) -> OAuthClientInformationFull | None:
        return self._client_info
    async def set_client_info(self, client_info: OAuthClientInformationFull) -> None:
        self._client_info = client_info
 class ConformanceOAuthCallbackHandler:
    """OAuth callback handler that automatically fetches the authorization URL
    and extracts the auth code, without requiring user interaction.
    """
    def __init__(self) -> None:
        self._auth_code: str | None = None
        self._state: str | None = None
        self._iss: str | None = None
    async def handle_redirect(self, authorization_url: str) -> None:
        """Fetch the authorization URL and extract the auth code from the redirect."""
        logger.debug(f"Fetching authorization URL: {authorization_url}")
        async with httpx.AsyncClient() as client:
            response = await client.get(
                authorization_url,
                follow_redirects=False,
            )
            if response.status_code in (301, 302, 303, 307, 308):
                location = cast(str, response.headers.get("location"))
                if location:
                    redirect_url = urlparse(location)
                    query_params: dict[str, list[str]] = parse_qs(redirect_url.query)
                    if "code" in query_params:
                        self._auth_code = query_params["code"][0]
                        state_values = query_params.get("state")
                        self._state = state_values[0] if state_values else None
                        iss_values = query_params.get("iss")
                        self._iss = iss_values[0] if iss_values else None
                        logger.debug(f"Got auth code from redirect: {self._auth_code[:10]}...")
                        return
                    else:
                        raise RuntimeError(f"No auth code in redirect URL: {location}")
                else:
                    raise RuntimeError(f"No redirect location received from {authorization_url}")
            else:
                raise RuntimeError(f"Expected redirect response, got {response.status_code} from {authorization_url}")
    async def handle_callback(self) -> AuthorizationCodeResult:
        """Return the captured auth code, state, and iss."""
        if self._auth_code is None:
            raise RuntimeError("No authorization code available - was handle_redirect called?")
        result = AuthorizationCodeResult(code=self._auth_code, state=self._state, iss=self._iss)
        self._auth_code = None
        self._state = None
        self._iss = None
        return result
 # --- Stub callbacks (declare capabilities in _meta without doing real work) ---
 async def stub_sampling_callback(
    context: ClientRequestContext,
    params: types.CreateMessageRequestParams,
 ) -> types.CreateMessageResult | types.ErrorData:
    return types.CreateMessageResult(
        role="assistant",
        content=types.TextContent(type="text", text=""),
        model="conformance-stub",
    )
 async def stub_list_roots_callback(context: ClientRequestContext) -> types.ListRootsResult | types.ErrorData:
    return types.ListRootsResult(roots=[])
 async def default_elicitation_callback(
    context: ClientRequestContext,
    params: types.ElicitRequestParams,
 ) -> types.ElicitResult | types.ErrorData:
    """Accept elicitation and apply defaults from the schema (SEP-1034)."""
    content: dict[str, str | int | float | bool | list[str] | None] = {}
    # For form mode, extract defaults from the requested_schema
    if isinstance(params, types.ElicitRequestFormParams):
        schema = params.requested_schema
        logger.debug(f"Elicitation schema: {schema}")
        properties = schema.get("properties", {})
        for prop_name, prop_schema in properties.items():
            if "default" in prop_schema:
                content[prop_name] = prop_schema["default"]
        logger.debug(f"Applied defaults: {content}")
    return types.ElicitResult(action="accept", content=content)
 # --- Scenario Handlers ---
@register("initialize")
 async def run_initialize(server_url: str) -> None:
    """Connect, initialize, list tools, close."""
    async with Client(server_url, mode=client_mode()) as client:
        logger.debug("Initialized successfully")
        await client.list_tools()
        logger.debug("Listed tools successfully")
@register("json-schema-ref-no-deref")
 async def run_json_schema_ref_no_deref(server_url: str) -> None:
    """Initialize and list tools; the scenario fails only if the client fetches a network $ref.
    The client never walks inputSchema or resolves $refs, so listing is enough (SEP-2106).
    Pinned to mode='legacy': the harness reports PROTOCOL_VERSION=2026-07-28 for this
    scenario but its mock server only speaks the handshake-era lifecycle and 400s a
    modern-stamped tools/list. The check is lifecycle-agnostic so this is harmless.
    """
    async with Client(server_url, mode="legacy") as client:
        await client.list_tools()
@register("tools_call")
 async def run_tools_call(server_url: str) -> None:
    """Connect, list tools, call add_numbers(a=5, b=3), close."""
    async with Client(server_url, mode=client_mode()) as client:
        await client.list_tools()
        result = await client.call_tool("add_numbers", {"a": 5, "b": 3})
        logger.debug(f"add_numbers result: {result}")
@register("sse-retry")
 async def run_sse_retry(server_url: str) -> None:
    """Connect, list tools, call test_reconnection, close."""
    async with Client(server_url, mode=client_mode()) as client:
        await client.list_tools()
        result = await client.call_tool("test_reconnection", {})
        logger.debug(f"test_reconnection result: {result}")
@register("request-metadata")
 async def run_request_metadata(server_url: str) -> None:
    """Connect on the modern path with every client capability declared.
    The scenario inspects every request's `_meta` envelope (SEP-2575) for
    protocolVersion / clientInfo / clientCapabilities, and the matching
    MCP-Protocol-Version header. mode='auto' makes the SDK send
    server/discover (covering the unsupported-version retry check), then adopt
    and stamp the envelope on the follow-up requests.
    """
    async with Client(
        server_url,
        mode=client_mode(),
        sampling_callback=stub_sampling_callback,
        list_roots_callback=stub_list_roots_callback,
        elicitation_callback=default_elicitation_callback,
    ) as client:
        await client.list_tools()
        result = await client.call_tool("add_numbers", {"a": 5, "b": 3})
        logger.debug(f"add_numbers result: {result}")
@register("http-standard-headers")
 async def run_http_standard_headers(server_url: str) -> None:
    """Connect on the modern path so Mcp-Method / Mcp-Name / MCP-Protocol-Version are sent (SEP-2243)."""
    async with Client(server_url, mode=client_mode()) as client:
        await client.list_tools()
        result = await client.call_tool("add_numbers", {"a": 5, "b": 3})
        logger.debug(f"add_numbers result: {result}")
 def _stub_required_args(input_schema: dict[str, Any]) -> dict[str, Any]:
    """Minimal arguments satisfying a tool inputSchema's required list."""
    by_type: dict[str, Any] = {
        "string": "x",
        "integer": 0,
        "number": 0,
        "boolean": False,
        "object": {},
        "array": [],
        "null": None,
    }
    properties = input_schema.get("properties", {})
    return {name: by_type.get(properties.get(name, {}).get("type"), "x") for name in input_schema.get("required", [])}
@register("http-invalid-tool-headers")
 async def run_http_invalid_tool_headers(server_url: str) -> None:
    """List tools, then call every tool the SDK surfaces (SEP-2243).
    The harness mock advertises one valid tool plus several with malformed
    x-mcp-header annotations (empty, non-primitive type, duplicate, invalid
    chars). The scenario passes if valid_tool is called and the malformed
    ones are not -- so a conforming client filters them out of the list_tools
    result and the loop below never sees them. The scenario sets
    allowClientError, so a per-call failure is logged and skipped rather
    than aborting the whole run.
    """
    async with Client(server_url, mode=client_mode()) as client:
        listed = await client.list_tools()
        logger.debug(f"Surfaced tools: {[t.name for t in listed.tools]}")
        for tool in listed.tools:
            try:
                await client.call_tool(tool.name, _stub_required_args(tool.input_schema))
            except Exception:
                logger.exception(f"call_tool({tool.name!r}) failed")
@register("http-custom-headers")
 async def run_http_custom_headers(server_url: str) -> None:
    """List tools, then replay the harness's `toolCalls` so x-mcp-header args mirror into headers (SEP-2243).
    The scenario supplies the exact arguments to send (including the null/edge-case values that
    exercise omission and Base64 encoding) via the context `toolCalls`; using them verbatim is
    what drives every per-parameter check. `list_tools` first so the SDK caches each tool's
    annotations; a tool the SDK dropped (invalid annotations) is skipped. Per-call failures are
    logged and skipped rather than aborting the run.
    """
    tool_calls: list[dict[str, Any]] = []
    if os.environ.get("MCP_CONFORMANCE_CONTEXT"):
        tool_calls = get_conformance_context().get("toolCalls", [])
    async with Client(server_url, mode=client_mode()) as client:
        listed = await client.list_tools()
        surfaced = {tool.name for tool in listed.tools}
        logger.debug(f"Surfaced tools: {sorted(surfaced)}")
        for call in tool_calls:
            name = call["name"]
            if name not in surfaced:
                logger.debug(f"skipping {name!r}: not surfaced by list_tools")
                continue
            try:
                await client.call_tool(name, call.get("arguments") or {})
            except Exception:
                logger.exception(f"call_tool({name!r}) failed")
@register("elicitation-sep1034-client-defaults")
 async def run_elicitation_defaults(server_url: str) -> None:
    """Connect with elicitation callback that applies schema defaults."""
    async with Client(server_url, mode=client_mode(), elicitation_callback=default_elicitation_callback) as client:
        await client.list_tools()
        result = await client.call_tool("test_client_elicitation_defaults", {})
        logger.debug(f"test_client_elicitation_defaults result: {result}")
@register("sep-2322-client-request-state")
 async def run_mrtr_client(server_url: str) -> None:
    """Drive the SEP-2322 client mock through `Client.call_tool`'s auto-loop.
    The mock inspects raw `tools/call` params, so registering an
    `elicitation_callback` and letting the driver run is enough to satisfy
    all five wire-shape checks: the driver echoes `request_state` byte-exact
    and omits it when the server sent none, every retry mints a fresh
    JSON-RPC id, the unrelated call between auto-loops carries no MRTR
    params, and the no-`resultType` response parses as a terminal
    `CallToolResult` so the driver never retries it.
    """
    async def confirm(
        context: ClientRequestContext, params: types.ElicitRequestParams
    ) -> types.ElicitResult | types.ErrorData:
        return types.ElicitResult(action="accept", content={"confirmed": True})
    async with Client(server_url, mode=client_mode(), elicitation_callback=confirm) as client:
        await client.list_tools()
        await client.call_tool("test_mrtr_echo_state", {})
        await client.call_tool("test_mrtr_unrelated", {})
        await client.call_tool("test_mrtr_no_state", {})
        result = await client.call_tool("test_mrtr_no_result_type", {})
        assert isinstance(result, types.CallToolResult)
@register("auth/client-credentials-jwt")
 async def run_client_credentials_jwt(server_url: str) -> None:
    """Client credentials flow with private_key_jwt authentication."""
    context = get_conformance_context()
    client_id = context.get("client_id")
    private_key_pem = context.get("private_key_pem")
    signing_algorithm = context.get("signing_algorithm", "ES256")
    if not client_id:
        raise RuntimeError("MCP_CONFORMANCE_CONTEXT missing 'client_id'")
    if not private_key_pem:
        raise RuntimeError("MCP_CONFORMANCE_CONTEXT missing 'private_key_pem'")
    jwt_params = SignedJWTParameters(
        issuer=client_id,
        subject=client_id,
        signing_algorithm=signing_algorithm,
        signing_key=private_key_pem,
    )
    oauth_auth = PrivateKeyJWTOAuthProvider(
        server_url=server_url,
        storage=InMemoryTokenStorage(),
        client_id=client_id,
        assertion_provider=jwt_params.create_assertion_provider(),
    )
    await _run_auth_session(server_url, oauth_auth)
@register("auth/client-credentials-basic")
 async def run_client_credentials_basic(server_url: str) -> None:
    """Client credentials flow with client_secret_basic authentication."""
    context = get_conformance_context()
    client_id = context.get("client_id")
    client_secret = context.get("client_secret")
    if not client_id:
        raise RuntimeError("MCP_CONFORMANCE_CONTEXT missing 'client_id'")
    if not client_secret:
        raise RuntimeError("MCP_CONFORMANCE_CONTEXT missing 'client_secret'")
    oauth_auth = ClientCredentialsOAuthProvider(
        server_url=server_url,
        storage=InMemoryTokenStorage(),
        client_id=client_id,
        client_secret=client_secret,
        token_endpoint_auth_method="client_secret_basic",
    )
    await _run_auth_session(server_url, oauth_auth)
@register("auth/enterprise-managed-authorization")
 async def run_enterprise_managed_authorization(server_url: str) -> None:
    """SEP-990 enterprise-managed authorization: RFC 8693 token-exchange at the
    enterprise IdP for an ID-JAG, then RFC 7523 jwt-bearer at the MCP
    authorization server."""
    context = get_conformance_context()
    client_id = context.get("client_id")
    client_secret = context.get("client_secret")
    idp_client_id = context.get("idp_client_id")
    idp_id_token = context.get("idp_id_token")
    idp_token_endpoint = context.get("idp_token_endpoint")
    if not client_id:
        raise RuntimeError("MCP_CONFORMANCE_CONTEXT missing 'client_id'")
    if not client_secret:
        raise RuntimeError("MCP_CONFORMANCE_CONTEXT missing 'client_secret'")
    if not idp_client_id:
        raise RuntimeError("MCP_CONFORMANCE_CONTEXT missing 'idp_client_id'")
    if not idp_id_token:
        raise RuntimeError("MCP_CONFORMANCE_CONTEXT missing 'idp_id_token'")
    if not idp_token_endpoint:
        raise RuntimeError("MCP_CONFORMANCE_CONTEXT missing 'idp_token_endpoint'")
    # IdentityAssertionOAuthProvider takes the AS issuer as configuration (the
    # SEP-990 trust model: the resource server is never asked which AS to use).
    # The harness does not put the issuer in context, so for conformance we
    # learn it from the harness's PRM document (RFC 9728); production
    # deployments would supply it as static configuration instead.
    prm_url = build_protected_resource_metadata_discovery_urls(None, server_url)[0]
    async with httpx.AsyncClient(timeout=30.0) as http:
        prm = (await http.get(prm_url)).raise_for_status().json()
    as_issuer = prm["authorization_servers"][0]
    async def fetch_id_jag(audience: str, resource: str) -> str:
        """Leg 1 - RFC 8693 token-exchange at the enterprise IdP."""
        async with httpx.AsyncClient(timeout=30.0) as http:
            resp = await http.post(
                idp_token_endpoint,
                data={
                    "grant_type": "urn:ietf:params:oauth:grant-type:token-exchange",
                    "requested_token_type": "urn:ietf:params:oauth:token-type:id-jag",
                    "subject_token": idp_id_token,
                    "subject_token_type": "urn:ietf:params:oauth:token-type:id_token",
                    "audience": audience,
                    "resource": resource,
                    "client_id": idp_client_id,
                },
            )
            resp.raise_for_status()
            return resp.json()["access_token"]
    oauth_auth = IdentityAssertionOAuthProvider(
        server_url=server_url,
        storage=InMemoryTokenStorage(),
        client_id=client_id,
        client_secret=client_secret,
        issuer=as_issuer,
        assertion_provider=fetch_id_jag,
        token_endpoint_auth_method="client_secret_basic",
    )
    await _run_auth_session(server_url, oauth_auth)
 async def run_auth_code_client(server_url: str) -> None:
    """Authorization code flow (default for auth/* scenarios)."""
    callback_handler = ConformanceOAuthCallbackHandler()
    storage = InMemoryTokenStorage()
    # Check for pre-registered client credentials from context
    context_json = os.environ.get("MCP_CONFORMANCE_CONTEXT")
    if context_json:
        try:
            context = json.loads(context_json)
            client_id = context.get("client_id")
            client_secret = context.get("client_secret")
            if client_id:
                await storage.set_client_info(
                    OAuthClientInformationFull(
                        client_id=client_id,
                        client_secret=client_secret,
                        redirect_uris=[AnyUrl("http://localhost:3000/callback")],
                        token_endpoint_auth_method="client_secret_basic" if client_secret else "none",
                    )
                )
                logger.debug(f"Pre-loaded client credentials: client_id={client_id}")
        except json.JSONDecodeError:
            logger.exception("Failed to parse MCP_CONFORMANCE_CONTEXT")
    oauth_auth = OAuthClientProvider(
        server_url=server_url,
        client_metadata=OAuthClientMetadata(
            client_name="conformance-client",
            redirect_uris=[AnyUrl("http://localhost:3000/callback")],
            grant_types=["authorization_code", "refresh_token"],
            response_types=["code"],
        ),
        storage=storage,
        redirect_handler=callback_handler.handle_redirect,
        callback_handler=callback_handler.handle_callback,
        client_metadata_url="https://conformance-test.local/client-metadata.json",
    )
    await _run_auth_session(server_url, oauth_auth)
 async def _run_auth_session(server_url: str, oauth_auth: httpx.Auth) -> None:
    """Common session logic for all OAuth flows."""
    http_client = httpx.AsyncClient(auth=oauth_auth, timeout=30.0)
    transport = streamable_http_client(url=server_url, http_client=http_client)
    async with Client(transport, mode=client_mode(), elicitation_callback=default_elicitation_callback) as client:
        logger.debug("Initialized successfully")
        tools_result = await client.list_tools()
        logger.debug(f"Listed tools: {[t.name for t in tools_result.tools]}")
        # Call the first available tool (different tests have different tools)
        if tools_result.tools:
            tool_name = tools_result.tools[0].name
            try:
                result = await client.call_tool(tool_name, {})
                logger.debug(f"Called {tool_name}, result: {result}")
            except Exception as e:
                logger.debug(f"Tool call result/error: {e}")
    logger.debug("Connection closed successfully")
 def main() -> None:
    """Main entry point for the conformance client."""
    if len(sys.argv) < 2:
        print(f"Usage: {sys.argv[0]} <server-url>", file=sys.stderr)
        sys.exit(1)
    server_url = sys.argv[1]
    scenario = os.environ.get("MCP_CONFORMANCE_SCENARIO")
    logger.debug(f"Conformance protocol version: {PROTOCOL_VERSION!r} -> mode={client_mode()!r}")
    if scenario:
        logger.debug(f"Running explicit scenario '{scenario}' against {server_url}")
        handler = HANDLERS.get(scenario)
        if handler:
            asyncio.run(handler(server_url))
        elif scenario.startswith("auth/"):
            asyncio.run(run_auth_code_client(server_url))
        else:
            print(f"Unknown scenario: {scenario}", file=sys.stderr)
            sys.exit(1)
    else:
        logger.debug(f"Running default auth flow against {server_url}")
        asyncio.run(run_auth_code_client(server_url))
 if __name__ == "__main__":
    main()
@@ -0,0 +1,25 @@
 # Expected failures for the carried-forward 2026-07-28 legs
 # (`--suite all --spec-version 2026-07-28` for both server and client).
 #
 # This baseline is separate from expected-failures.yml because entries are
 # keyed by scenario name only: a scenario that passes at its default version
 # in the 2025 legs but fails when forced to 2026-07-28 (or vice versa) cannot
 # be expressed in a shared file (the passing leg would flag the entry as
 # stale). Like expected-failures.yml, this single file covers both
 # directions: the client 2026 leg reads the `client:` section and the server
 # 2026 leg reads the `server:` section. Both burn down independently of the
 # 2025 legs.
 #
 # Baseline established against the harness pinned via CONFORMANCE_PKG in
 # .github/workflows/conformance.yml. New conformance releases are adopted by
 # deliberately bumping that pin and reconciling both this file and
 # expected-failures.yml in the same change.
 #
 # Entries are grouped by what unblocks them. As each gap closes the
 # corresponding scenarios start passing and MUST be removed from this list
 # (the runner fails on stale entries), so the baseline burns down per
 # milestone.
 client: []
 server: []
@@ -0,0 +1,34 @@
 # Conformance scenarios not yet passing against the Python SDK on main.
 # CI exits 0 if only these fail, exits 1 on unexpected failures or stale entries.
 #
 # Baseline established against the harness pinned via CONFORMANCE_PKG in
 # .github/workflows/conformance.yml. New conformance releases are adopted by
 # deliberately bumping that pin and reconciling both this file and
 # expected-failures.2026-07-28.yml in the same change.
 #
 # Entries are grouped by SEP. As each SEP lands in the SDK the corresponding
 # scenarios start passing and MUST be removed from this list (the runner fails
 # on stale entries), so the baseline burns down per milestone.
 client: []
 server:
  # SEP-2663 (io.modelcontextprotocol/tasks): the SDK does not implement the
  # tasks extension yet. These extension-tagged scenarios are selected only by
  # the bare `--suite all` leg — extension scenarios never match a
  # --spec-version filter and the active/draft suites exclude them — so these
  # entries are inert for the other legs that read this file.
  #
  # `tasks-status-notifications` is intentionally NOT listed: the harness
  # skips it unconditionally (pending its rewrite against subscriptions/
  # listen), and a baseline entry for a scenario with no failing checks is
  # flagged stale.
  - tasks-lifecycle
  - tasks-capability-negotiation
  - tasks-wire-fields
  - tasks-request-state-removal
  - tasks-mrtr-input
  - tasks-request-headers
  - tasks-dispatch-and-envelope
  - tasks-required-task-error
  - tasks-mrtr-composition
@@ -0,0 +1,104 @@
 #!/bin/bash
 # Run a client conformance suite, re-verifying unexpected failures solo.
 # Concurrent suite runs on a 2-vCPU runner can push scenarios with real-time
 # waits past tolerance; solo, a real failure fails again while a contention
 # artifact passes. Failures that only reproduce under concurrency are excused.
 set -uo pipefail
 : "${CONFORMANCE_PKG:?set CONFORMANCE_PKG (pinned in .github/workflows/conformance.yml)}"
 # One attempt: a solo failure on the quiet runner disproves the contention
 # hypothesis; a second try would be the blind retry this script avoids.
 SOLO_ATTEMPTS="${CONFORMANCE_SOLO_ATTEMPTS:-1}"
 # Relative args resolve from the repo root; same contract as run-server.sh.
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 cd "$SCRIPT_DIR/../../.." || exit 1
 log="$(mktemp)"
 trap 'rm -f "$log"' EXIT
 npx --yes "$CONFORMANCE_PKG" client "$@" 2>&1 | tee "$log"
 rc=${PIPESTATUS[0]}
 if [ "$rc" -eq 0 ]; then
    exit 0
 fi
 plain="$(sed 's/\x1b\[[0-9;]*m//g' "$log")"
 # If the harness's summary wording changes, the list comes up empty and the
 # original exit code passes through - never a false green.
 mapfile -t scenarios < <(
    printf '%s\n' "$plain" |
        sed -n '/^Unexpected failures (not in baseline):$/,/^$/p' |
        sed -n 's/^  ✗ //p'
 )
 if [ "${#scenarios[@]}" -eq 0 ]; then
    exit "$rc"
 fi
 for scenario in "${scenarios[@]}"; do
    if ! [[ "$scenario" =~ ^[A-Za-z0-9/_-]+$ ]]; then
        echo "Extracted unexpected-failure name '${scenario}' does not look like a scenario name; passing the suite failure through." >&2
        exit "$rc"
    fi
 done
 # A stale baseline entry is a configuration error a solo rerun cannot excuse.
 # Here-string, not a pipe: grep -q quitting early would SIGPIPE printf and,
 # under pipefail, skip this guard exactly when the pattern is present.
 if grep -q '^Stale baseline entries' <<<"$plain"; then
    echo "Suite also reported stale baseline entries; not retrying." >&2
    exit "$rc"
 fi
 # Drop the suite-only flags: --scenario replaces --suite, and solo runs are
 # judged directly rather than against the baseline.
 rerun_args=()
 output_dir=""
 skip_next=0
 expect_output_dir=0
 for arg in "$@"; do
    if [ "$skip_next" -eq 1 ]; then
        if [ "$expect_output_dir" -eq 1 ]; then
            output_dir="$arg"
        fi
        skip_next=0
        expect_output_dir=0
        continue
    fi
    case "$arg" in
    --output-dir)
        skip_next=1
        expect_output_dir=1
        ;;
    --suite | --expected-failures) skip_next=1 ;;
    --output-dir=*) output_dir="${arg#--output-dir=}" ;;
    --suite=* | --expected-failures=*) ;;
    *) rerun_args+=("$arg") ;;
    esac
 done
 if [ -n "$output_dir" ]; then
    rerun_args+=(--output-dir "${output_dir}-solo")
 fi
 for scenario in "${scenarios[@]}"; do
    passed=0
    for attempt in $(seq 1 "$SOLO_ATTEMPTS"); do
        echo ""
        echo "Re-running '${scenario}' solo (attempt ${attempt}/${SOLO_ATTEMPTS})..."
        if npx --yes "$CONFORMANCE_PKG" client --scenario "$scenario" "${rerun_args[@]}"; then
            passed=1
            break
        fi
    done
    if [ "$passed" -ne 1 ]; then
        echo "'${scenario}' still fails when run alone: real failure, not suite contention." >&2
        exit 1
    fi
 done
 if [ -n "$output_dir" ]; then
    mkdir -p "$output_dir"
    printf '%s\n' "${scenarios[@]}" > "$output_dir/FLAKE_RESCUED"
 fi
 echo "All ${#scenarios[@]} unexpected failure(s) passed when re-run solo; the suite failures were parallel-run contention."
 exit 0
@@ -0,0 +1,51 @@
 #!/bin/bash
 set -e
 PORT="${PORT:-3001}"
 SERVER_URL="http://localhost:${PORT}/mcp"
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 cd "$SCRIPT_DIR/../../.."
 # Refuse to start if something is already listening on the port. The readiness
 # check below cannot tell our server apart from a stale one, so a leftover
 # listener would mean silently running conformance against old code.
 if (: > "/dev/tcp/localhost/${PORT}") 2>/dev/null; then
    echo "Error: port ${PORT} is already in use." >&2
    echo "Stop the stale process first (lsof -ti:${PORT} -sTCP:LISTEN | xargs kill) or set PORT to a free port." >&2
    exit 1
 fi
 echo "Starting mcp-everything-server on port ${PORT}..."
 uv run --frozen mcp-everything-server --port "$PORT" &
 SERVER_PID=$!
 cleanup() {
    echo "Stopping server (PID: ${SERVER_PID})..."
    kill $SERVER_PID 2>/dev/null || true
    wait $SERVER_PID 2>/dev/null || true
 }
 trap cleanup EXIT
 # Wait for server to be ready. --max-time keeps a hung listener from wedging
 # the loop, and a dead server process fails fast instead of retrying.
 echo "Waiting for server to be ready..."
 MAX_RETRIES=30
 RETRY_COUNT=0
 while ! curl -s --max-time 2 "$SERVER_URL" > /dev/null 2>&1; do
    if ! kill -0 $SERVER_PID 2>/dev/null; then
        echo "Server process exited unexpectedly" >&2
        exit 1
    fi
    RETRY_COUNT=$((RETRY_COUNT + 1))
    if [ $RETRY_COUNT -ge $MAX_RETRIES ]; then
        echo "Server failed to start after ${MAX_RETRIES} retries" >&2
        exit 1
    fi
    sleep 0.5
 done
 echo "Server ready at $SERVER_URL"
 npx --yes "${CONFORMANCE_PKG:?set CONFORMANCE_PKG (pinned in .github/workflows/conformance.yml)}" \
    server --url "$SERVER_URL" "$@"
@@ -0,0 +1,22 @@
 version: 2
 updates:
  - package-ecosystem: "uv"
    directory: "/"
    schedule:
      interval: monthly
    cooldown:
      default-days: 14
    groups:
      python-packages:
        patterns:
          - "*"
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: monthly
    cooldown:
      default-days: 14
    groups:
      github-actions:
        patterns:
          - "*"
@@ -0,0 +1,42 @@
 # Source: https://github.com/anthropics/claude-code-action/blob/main/docs/usage.md
 name: Claude Code
 on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
  issues:
    types: [opened, assigned]
  pull_request_review:
    types: [submitted]
 jobs:
  claude:
    if: |
      (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude') && !startsWith(github.event.comment.body, '@claude review')) ||
      (github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude')) ||
      (github.event_name == 'pull_request_review' && contains(github.event.review.body, '@claude')) ||
      (github.event_name == 'issues' && (contains(github.event.issue.body, '@claude') || contains(github.event.issue.title, '@claude')))
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read
      issues: read
      id-token: write
      actions: read # Required for Claude to read CI results on PRs
    steps:
      - name: Checkout repository
        uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
        with:
          fetch-depth: 1
          persist-credentials: false
      - name: Run Claude Code
        id: claude
        uses: anthropics/claude-code-action@d5726de019ec4498aa667642bc3a80fca83aa102 # v1.0.148
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} # zizmor: ignore[secrets-outside-env]
          use_commit_signing: true
          additional_permissions: |
            actions: read
@@ -0,0 +1,168 @@
 name: Conformance Tests
 on:
  push:
    branches: [main]
  pull_request:
  workflow_dispatch:
 concurrency:
  group: conformance-${{ github.ref }}
  cancel-in-progress: true
 permissions:
  contents: read
 env:
  # Pinned conformance harness package spec (passed verbatim to `npx --yes`).
  # Use a published version, e.g. @modelcontextprotocol/conformance@0.2.0-alpha.7.
  # Bump deliberately and reconcile both
  # .github/actions/conformance/expected-failures*.yml files in the same change.
  #
  # Temporarily pinned to the pkg.pr.new build of conformance main@4944b268
  # (0.2.0-alpha.8, which includes #372: fail checks whose prerequisite is
  # missing instead of skipping them) — alpha.8 is not published to npm yet.
  # Pinned by commit SHA so the tarball cannot move under us;
  # CONFORMANCE_PKG_SHA256 pins the bytes and the fetch-and-verify step below
  # downloads, checks the digest, and repoints CONFORMANCE_PKG at the
  # verified local copy. Repin to the next published @modelcontextprotocol/
  # conformance release (>=0.2.0-alpha.8) once it ships, then drop
  # CONFORMANCE_PKG_SHA256 and the fetch-and-verify steps.
  CONFORMANCE_PKG: "https://pkg.pr.new/@modelcontextprotocol/conformance@4944b268"
  CONFORMANCE_PKG_SHA256: "0f70c035782d319d72ab427653c5275db5c50429d59fae0241a645b33aeda1a7"
 jobs:
  server-conformance:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
        with:
          persist-credentials: false
      - uses: astral-sh/setup-uv@fac544c07dec837d0ccb6301d7b5580bf5edae39 # v8.2.0
        with:
          enable-cache: true
          version: 0.9.5
      - uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6.4.0
        with:
          node-version: 24
      - name: Fetch and verify conformance harness
        # Only when CONFORMANCE_PKG is a URL: download, check the recorded
        # sha256, and re-point CONFORMANCE_PKG at the verified local tarball.
        # When CONFORMANCE_PKG is a registry spec, this step is a no-op (npm's
        # own integrity check applies).
        run: |
          case "$CONFORMANCE_PKG" in
            https://*)
              curl -fsSL "$CONFORMANCE_PKG" -o /tmp/conformance.tgz
              echo "$CONFORMANCE_PKG_SHA256  /tmp/conformance.tgz" | sha256sum -c -
              echo "CONFORMANCE_PKG=file:/tmp/conformance.tgz" >> "$GITHUB_ENV"
              ;;
          esac
      - run: uv sync --frozen --all-extras --package mcp-everything-server
      - name: Run server conformance (active suite)
        run: >-
          ./.github/actions/conformance/run-server.sh
          --suite active
          --expected-failures ./.github/actions/conformance/expected-failures.yml
          --output-dir conformance-results/server-active
      - name: Run server conformance (draft suite)
        run: >-
          ./.github/actions/conformance/run-server.sh
          --suite draft
          --expected-failures ./.github/actions/conformance/expected-failures.yml
          --output-dir conformance-results/server-draft
      - name: Run server conformance (2026-07-28 wire, all suite)
        run: >-
          ./.github/actions/conformance/run-server.sh
          --suite all
          --spec-version 2026-07-28
          --expected-failures ./.github/actions/conformance/expected-failures.2026-07-28.yml
          --output-dir conformance-results/server-2026-07-28
      - name: Run server conformance (all suite, extension scenarios)
        # A bare `--suite all` (no --spec-version) selects every scenario
        # shipped with the pinned harness — including the extension-tagged
        # tasks-* scenarios and pending-listed ones like server-sse-polling,
        # which no other leg reaches (extension scenarios never match a
        # --spec-version filter, and the pending list keeps them out of the
        # active suite). Running the full set keeps unimplemented surfaces
        # visible as baselined known failures in expected-failures.yml instead
        # of silent exclusions, and stays robust to scenarios moving between
        # harness suite lists across pin bumps. `--suite pending` would cover
        # the same union slightly faster; the full set is preferred for the
        # self-contained run and for parity with typescript-sdk's CI.
        run: >-
          ./.github/actions/conformance/run-server.sh
          --suite all
          --expected-failures ./.github/actions/conformance/expected-failures.yml
          --output-dir conformance-results/server-all
      - name: Upload conformance results
        # The log has only summary counts; per-check data is in checks.json.
        if: failure()
        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
        with:
          name: server-conformance-results
          path: conformance-results/
          if-no-files-found: ignore
  client-conformance:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
        with:
          persist-credentials: false
      - uses: astral-sh/setup-uv@fac544c07dec837d0ccb6301d7b5580bf5edae39 # v8.2.0
        with:
          enable-cache: true
          version: 0.9.5
      - uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6.4.0
        with:
          node-version: 24
      - name: Fetch and verify conformance harness
        # Only when CONFORMANCE_PKG is a URL: download, check the recorded
        # sha256, and re-point CONFORMANCE_PKG at the verified local tarball.
        # When CONFORMANCE_PKG is a registry spec, this step is a no-op (npm's
        # own integrity check applies).
        run: |
          case "$CONFORMANCE_PKG" in
            https://*)
              curl -fsSL "$CONFORMANCE_PKG" -o /tmp/conformance.tgz
              echo "$CONFORMANCE_PKG_SHA256  /tmp/conformance.tgz" | sha256sum -c -
              echo "CONFORMANCE_PKG=file:/tmp/conformance.tgz" >> "$GITHUB_ENV"
              ;;
          esac
      # --compile-bytecode: without it, ~40 concurrently spawned interpreters
      # race to byte-compile site-packages during the timing-sensitive window.
      - run: uv sync --frozen --all-extras --package mcp --compile-bytecode
      - name: Pre-compile bytecode (editable sources)
        run: uv run --frozen python -m compileall -q src .github/actions/conformance
      - name: Run client conformance (all suite)
        # The harness runs all scenarios via unbounded Promise.all; with 40
        # scenarios on a 2-core runner the slowest one (sse-retry, which has a
        # real-time SSE reconnect wait) needs more than the 30s default budget.
        # `.venv/bin/python` (not `uv run`) avoids lockfile re-checks in ~40
        # concurrent spawns; run-client.sh re-runs unexpected failures solo.
        run: >-
          ./.github/actions/conformance/run-client.sh
          --command '.venv/bin/python .github/actions/conformance/client.py'
          --suite all
          --timeout 60000
          --expected-failures ./.github/actions/conformance/expected-failures.yml
          --output-dir conformance-results/client-all
      - name: Run client conformance (2026-07-28 wire, all suite)
        run: >-
          ./.github/actions/conformance/run-client.sh
          --command '.venv/bin/python .github/actions/conformance/client.py'
          --suite all
          --timeout 60000
          --spec-version 2026-07-28
          --expected-failures ./.github/actions/conformance/expected-failures.2026-07-28.yml
          --output-dir conformance-results/client-2026-07-28
      - name: Upload conformance results
        # The log has only summary counts; per-check data is in checks.json.
        # Also on FLAKE_RESCUED: rescued-flake evidence is otherwise discarded.
        if: failure() || hashFiles('conformance-results/**/FLAKE_RESCUED') != ''
        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
        with:
          name: client-conformance-results
          path: conformance-results/
          if-no-files-found: ignore
@@ -0,0 +1,64 @@
 name: Deploy Docs
 on:
  push:
    branches:
      - main
      - v1.x
    paths:
      - docs/**
      # docs pages include their code blocks from these files via `--8<--`, so a
      # change here changes the rendered site even when no .md file moves.
      - docs_src/**
      - mkdocs.yml
      - src/mcp/**
      - src/mcp-types/**
      - scripts/build-docs.sh
      - scripts/docs/**
      - pyproject.toml
      - uv.lock
      - .github/workflows/deploy-docs.yml
  workflow_dispatch:
 concurrency:
  group: deploy-docs
  cancel-in-progress: false
 jobs:
  deploy-docs:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pages: write
      id-token: write
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    steps:
      - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
        with:
          persist-credentials: false
      - name: Install uv
        uses: astral-sh/setup-uv@fac544c07dec837d0ccb6301d7b5580bf5edae39 # v8.2.0
        with:
          enable-cache: true
          version: 0.9.5
      - name: Build combined docs (v1.x at /, main at /v2/)
        run: bash scripts/build-docs.sh site
      - name: Configure Pages
        uses: actions/configure-pages@45bfe0192ca1faeb007ade9deae92b16b8254a0d # v6.0.0
      - name: Upload Pages artifact
        uses: actions/upload-pages-artifact@fc324d3547104276b827a68afc52ff2a11cc49c9 # v5.0.0
        with:
          path: site
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@cd2ce8fcbc39b97be8ca5fce6e763baed58fa128 # v5.0.0
@@ -0,0 +1,44 @@
 name: Docs Preview Cleanup
 # Deletes Cloudflare Pages preview deployments for a PR when it closes.
 # Runs as pull_request_target so secrets are available for fork PRs; it never
 # checks out PR code, so there is no untrusted-code execution risk.
 on:
  pull_request_target: # zizmor: ignore[dangerous-triggers] never checks out PR code
    types: [closed]
 permissions: {}
 jobs:
  cleanup:
    runs-on: ubuntu-latest
    steps:
      - name: Delete preview deployments for this PR
        env:
          CF_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          CF_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          CF_PROJECT: ${{ vars.CLOUDFLARE_PAGES_PROJECT }}
          BRANCH: pr-${{ github.event.pull_request.number }}
        run: |
          set -euo pipefail
          if [ -z "$CF_API_TOKEN" ] || [ -z "$CF_ACCOUNT_ID" ] || [ -z "$CF_PROJECT" ]; then
            echo "Cloudflare credentials/project not configured; skipping cleanup."
            exit 0
          fi
          base="https://api.cloudflare.com/client/v4/accounts/$CF_ACCOUNT_ID/pages/projects/$CF_PROJECT/deployments"
          # Collect matching ids across all pages first, then delete — deleting
          # mid-pagination would shift later pages and skip entries.
          ids=""
          for page in $(seq 1 200); do
            resp=$(curl -fsS -H "Authorization: Bearer $CF_API_TOKEN" "$base?env=preview&per_page=25&page=$page")
            ids="$ids $(jq -r --arg b "$BRANCH" '.result[]? | select(.deployment_trigger.metadata.branch == $b) | .id' <<<"$resp")"
            [ "$(jq '.result | length' <<<"$resp")" -lt 25 ] && break
          done
          deleted=0
          for id in $ids; do
            echo "Deleting deployment $id"
            curl -fsS -X DELETE -H "Authorization: Bearer $CF_API_TOKEN" "$base/$id?force=true" > /dev/null
            deleted=$((deleted + 1))
          done
          echo "Deleted $deleted deployment(s) for $BRANCH."
@@ -0,0 +1,249 @@
 name: Docs Preview
 # Builds the docs site for a PR and deploys it to Cloudflare Pages.
 #
 # Security: the build executes Python from the PR (mkdocstrings imports
 # src/mcp, `!!python/name:` config directives run, and heads may ship their
 # own build scripts). The build is gated by `authorize` (admin sender for
 # auto-preview, admin/maintainer commenter for /preview-docs) and isolated
 # from Cloudflare secrets — `build` runs PR code with no secrets and hands
 # the static site to `deploy` via an artifact, so PR code never shares a
 # runner with the Cloudflare token.
 #
 # Required configuration:
 #   - secrets.CLOUDFLARE_API_TOKEN   (scope: Account → Cloudflare Pages → Edit)
 #   - secrets.CLOUDFLARE_ACCOUNT_ID
 #   - vars.CLOUDFLARE_PAGES_PROJECT  (existing Pages project, e.g. mcp-python-sdk-docs)
 on:
  pull_request_target: # zizmor: ignore[dangerous-triggers] build is permission-gated and secret-isolated; see header comment
    types: [opened, reopened, synchronize]
    paths:
      - docs/**
      - docs_src/**
      - mkdocs.yml
      - scripts/docs/**
      - pyproject.toml
  issue_comment:
    types: [created]
 permissions: {}
 concurrency:
  # Workflow-level concurrency is evaluated when the run is queued — before any
  # job-level `if:` — so an unrelated PR comment would otherwise cancel an
  # in-flight build. Only runs that actually produce a preview share a group;
  # everything else falls through to a unique run_id group.
  group: >-
    docs-preview-pr-${{
      github.event_name == 'pull_request_target' && github.event.pull_request.number
      || (github.event.issue.pull_request && startsWith(github.event.comment.body, '/preview-docs') && github.event.issue.number)
      || github.run_id
    }}
  cancel-in-progress: true
 jobs:
  authorize:
    if: >-
      github.event_name == 'pull_request_target' ||
      (github.event.issue.pull_request && startsWith(github.event.comment.body, '/preview-docs'))
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read
    outputs:
      authorized: ${{ steps.check.outputs.authorized }}
      pr_number: ${{ steps.check.outputs.pr_number }}
      head_sha: ${{ steps.check.outputs.head_sha }}
      slash_attempt: ${{ steps.check.outputs.slash_attempt }}
    steps:
      - name: Determine authorization
        id: check
        uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8.0.0
        with:
          script: |
            const { owner, repo } = context.repo;
            async function permissionFor(username) {
              const { data } = await github.rest.repos.getCollaboratorPermissionLevel({ owner, repo, username });
              return { level: data.permission, role: data.role_name };
            }
            let authorized = false;
            let prNumber = '';
            let headSha = '';
            let slashAttempt = false;
            if (context.eventName === 'pull_request_target') {
              // Gate on the *sender* (whoever caused this run — on synchronize that
              // is the pusher), not the PR author, so a non-admin pushing to an
              // admin-opened branch does not get an automatic build.
              const actor = context.payload.sender.login;
              prNumber = String(context.payload.pull_request.number);
              headSha = context.payload.pull_request.head.sha;
              const perm = await permissionFor(actor);
              authorized = perm.level === 'admin';
              core.info(`pull_request_target by ${actor} (level=${perm.level}, role=${perm.role}) → authorized=${authorized}`);
            } else {
              // issue_comment: the job-level `if:` already guarantees this is a PR
              // comment starting with /preview-docs.
              slashAttempt = true;
              const actor = context.payload.comment.user.login;
              prNumber = String(context.payload.issue.number);
              const perm = await permissionFor(actor);
              authorized = perm.level === 'admin' || perm.role === 'maintain';
              if (authorized) {
                const { data: pr } = await github.rest.pulls.get({ owner, repo, pull_number: Number(prNumber) });
                if (pr.state !== 'open') {
                  authorized = false;
                  core.info(`PR #${prNumber} is ${pr.state}; refusing to preview.`);
                } else {
                  headSha = pr.head.sha;
                }
              }
              core.info(`/preview-docs by ${actor} (level=${perm.level}, role=${perm.role}) → authorized=${authorized}`);
            }
            core.setOutput('authorized', String(authorized));
            core.setOutput('pr_number', prNumber);
            core.setOutput('head_sha', headSha);
            core.setOutput('slash_attempt', String(slashAttempt));
  build:
    needs: authorize
    if: needs.authorize.outputs.authorized == 'true'
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
        with:
          ref: ${{ needs.authorize.outputs.head_sha }}
          persist-credentials: false
      - name: Install uv
        uses: astral-sh/setup-uv@fac544c07dec837d0ccb6301d7b5580bf5edae39 # v8.2.0
        with:
          # pull_request_target runs share the base-branch Actions cache; saving
          # a cache populated while untrusted PR code ran would let it poison
          # later trusted workflows. Mirrors publish-pypi.yml.
          enable-cache: false
          version: 0.9.5
      # pull_request_target runs this workflow file from the base branch, so
      # the whole recipe — dependency sync included — must come from the
      # checkout itself: heads that ship scripts/docs/build.sh (the Zensical
      # toolchain) build with it; older heads, and v1.x heads previewed via
      # /preview-docs, still build with MkDocs. Both arms must write the site
      # to site/. Keep the detection in sync with build_site() in
      # scripts/build-docs.sh.
      - run: |
          if [ -f scripts/docs/build.sh ]; then
            bash scripts/docs/build.sh
          else
            uv sync --frozen --group docs
            # The env var silences mkdocs-material's MkDocs 2.0 warning banner.
            NO_MKDOCS_2_WARNING=1 uv run --frozen --no-sync mkdocs build
          fi
      - uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
        with:
          name: site
          path: site/
          retention-days: 1
          # An empty site/ means the build arm broke its output contract; fail
          # here instead of surfacing as a confusing download error in deploy.
          if-no-files-found: error
  deploy:
    needs: [authorize, build]
    if: needs.authorize.outputs.authorized == 'true'
    runs-on: ubuntu-latest
    permissions: {}
    outputs:
      deployment_url: ${{ steps.wrangler.outputs.deployment-url }}
      alias_url: ${{ steps.wrangler.outputs.pages-deployment-alias-url }}
    steps:
      - uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
        with:
          name: site
          path: site
      - name: Deploy to Cloudflare Pages
        id: wrangler
        uses: cloudflare/wrangler-action@ebbaa1584979971c8614a24965b4405ff95890e0 # v4.0.0
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          packageManager: npm
          command: >-
            pages deploy ./site
            --project-name=${{ vars.CLOUDFLARE_PAGES_PROJECT }}
            --branch=pr-${{ needs.authorize.outputs.pr_number }}
            --commit-hash=${{ needs.authorize.outputs.head_sha }}
            --commit-dirty=true
  comment:
    needs: [authorize, build, deploy]
    if: >-
      always() &&
      needs.deploy.result != 'cancelled' &&
      (needs.authorize.outputs.authorized == 'true' || needs.authorize.outputs.slash_attempt == 'true')
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    steps:
      - name: Post or update preview comment
        uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8.0.0
        env:
          AUTHORIZED: ${{ needs.authorize.outputs.authorized }}
          PR_NUMBER: ${{ needs.authorize.outputs.pr_number }}
          HEAD_SHA: ${{ needs.authorize.outputs.head_sha }}
          DEPLOY_RESULT: ${{ needs.deploy.result }}
          DEPLOYMENT_URL: ${{ needs.deploy.outputs.deployment_url }}
          ALIAS_URL: ${{ needs.deploy.outputs.alias_url }}
          RUN_URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
        with:
          script: |
            const { owner, repo } = context.repo;
            const env = process.env;
            const issue_number = Number(env.PR_NUMBER);
            const marker = '<!-- docs-preview -->';
            async function upsert(body) {
              const comments = await github.paginate(github.rest.issues.listComments, { owner, repo, issue_number, per_page: 100 });
              const existing = comments.find(c => c.user?.login === 'github-actions[bot]' && c.body?.includes(marker));
              if (existing) {
                await github.rest.issues.updateComment({ owner, repo, comment_id: existing.id, body });
              } else {
                await github.rest.issues.createComment({ owner, repo, issue_number, body });
              }
            }
            if (env.AUTHORIZED !== 'true') {
              await github.rest.issues.createComment({
                owner, repo, issue_number,
                body: `@${context.actor} — only repository admins or maintainers can run \`/preview-docs\` (and the PR must be open).`,
              });
              return;
            }
            if (env.DEPLOY_RESULT !== 'success') {
              await upsert(
                `${marker}\n### 📚 Documentation preview\n\n` +
                `❌ Preview build **failed** for \`${env.HEAD_SHA.slice(0, 7)}\` — [workflow logs](${env.RUN_URL}).`
              );
              return;
            }
            const previewUrl = env.ALIAS_URL || env.DEPLOYMENT_URL;
            const ts = new Date().toISOString().replace('T', ' ').replace(/\.\d+Z$/, ' UTC');
            await upsert(
              `${marker}\n### 📚 Documentation preview\n\n` +
              `| | |\n|---|---|\n` +
              `| **Preview** | ${previewUrl} |\n` +
              `| **Deployment** | ${env.DEPLOYMENT_URL} |\n` +
              `| **Commit** | \`${env.HEAD_SHA.slice(0, 7)}\` |\n` +
              `| **Triggered by** | @${context.actor} |\n` +
              `| **Updated** | ${ts} |\n`
            );
@@ -0,0 +1,23 @@
 name: CI
 on:
  push:
    branches: ["main", "v1.x"]
    tags: ["v*.*.*"]
  pull_request:
 permissions:
  contents: read
 jobs:
  checks:
    uses: ./.github/workflows/shared.yml
  all-green:
    if: always()
    needs: [checks]
    runs-on: ubuntu-latest
    steps:
      - uses: re-actors/alls-green@05ac9388f0aebcb5727afa17fcccfecd6f8ec5fe # v1.2.2
        with:
          jobs: ${{ toJSON(needs) }}
@@ -0,0 +1,64 @@
 name: Publishing
 on:
  release:
    types: [published]
 permissions:
  contents: read
 jobs:
  release-build:
    name: Build distribution
    runs-on: ubuntu-latest
    needs: [checks]
    steps:
      - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
        with:
          persist-credentials: false
      - name: Install uv
        uses: astral-sh/setup-uv@fac544c07dec837d0ccb6301d7b5580bf5edae39 # v8.2.0
        with:
          enable-cache: false
          version: 0.9.5
      - name: Set up Python 3.12
        run: uv python install 3.12
      - name: Build
        run: |
          uv build --package mcp
          uv build --package mcp-types
      - name: Upload artifacts
        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
        with:
          name: release-dists
          path: dist/
  checks:
    uses: ./.github/workflows/shared.yml
  pypi-publish:
    name: Upload release to PyPI
    runs-on: ubuntu-latest
    environment: release
    needs:
      - release-build
    permissions:
      id-token: write # IMPORTANT: this permission is mandatory for trusted publishing
    steps:
      - name: Retrieve release distributions
        uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
        with:
          name: release-dists
          path: dist/
      - name: Publish package distributions to PyPI
        uses: pypa/gh-action-pypi-publish@cef221092ed1bacb1cc03d23a2d87d1d172e277b # release/v1
        with:
          # Lets a re-run after a partially failed upload publish the remaining
          # files instead of erroring on the ones already on PyPI.
          skip-existing: true
@@ -0,0 +1,177 @@
 name: Shared Checks
 on:
  workflow_call:
 permissions:
  contents: read
 env:
  COLUMNS: 150
 jobs:
  pre-commit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
        with:
          persist-credentials: false
      # setup-uv's manifest fetch is a single request with a hard 5s timeout
      # (astral-sh/setup-uv#869); retry once. Drop when upstream adds a retry.
      - name: Install uv
        id: setup-uv
        continue-on-error: true
        uses: astral-sh/setup-uv@fac544c07dec837d0ccb6301d7b5580bf5edae39 # v8.2.0
        with:
          enable-cache: true
          version: 0.9.5
      - name: Install uv (retry)
        if: steps.setup-uv.outcome == 'failure'
        uses: astral-sh/setup-uv@fac544c07dec837d0ccb6301d7b5580bf5edae39 # v8.2.0
        with:
          enable-cache: true
          version: 0.9.5
      - name: Install dependencies
        run: uv sync --frozen --all-extras --python 3.10
      - uses: pre-commit/action@2c7b3805fd2a0fd8c1884dcaebf91fc102a13ecd # v3.0.1
        with:
          extra_args: --all-files --verbose
      - name: Surface types match vendored schema
        run: |
          uv sync --group codegen --frozen
          uv run --frozen --group codegen python scripts/gen_surface_types.py --check
      # Resolves only mcp-types' declared dependencies into an empty environment,
      # so an import of the SDK or anything from its stack fails here.
      - name: mcp-types installs and imports standalone
        run: |
          uv run --isolated --no-project --with ./src/mcp-types python -c \
            "import mcp_types, mcp_types.jsonrpc, mcp_types.methods, mcp_types.version, mcp_types.v2025_11_25, mcp_types.v2026_07_28"
  test:
    name: test (${{ matrix.python-version }}, ${{ matrix.dep-resolution.name }}, ${{ matrix.os }})
    runs-on: ${{ matrix.os }}
    timeout-minutes: 10
    strategy:
      fail-fast: false
      matrix:
        python-version: ["3.10", "3.11", "3.12", "3.13", "3.14"]
        dep-resolution:
          - name: lowest-direct
            install-flags: "--upgrade --resolution lowest-direct"
          - name: locked
            install-flags: "--frozen"
        os: [ubuntu-latest, windows-latest]
    steps:
      - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
        with:
          persist-credentials: false
      # setup-uv's manifest fetch is a single request with a hard 5s timeout
      # (astral-sh/setup-uv#869); retry once. Drop when upstream adds a retry.
      - name: Install uv
        id: setup-uv
        continue-on-error: true
        uses: astral-sh/setup-uv@fac544c07dec837d0ccb6301d7b5580bf5edae39 # v8.2.0
        with:
          enable-cache: true
          version: 0.9.5
      - name: Install uv (retry)
        if: steps.setup-uv.outcome == 'failure'
        uses: astral-sh/setup-uv@fac544c07dec837d0ccb6301d7b5580bf5edae39 # v8.2.0
        with:
          enable-cache: true
          version: 0.9.5
      - name: Install the project
        run: uv sync ${{ matrix.dep-resolution.install-flags }} --all-extras --python ${{ matrix.python-version }}
      - name: Run pytest with coverage
        shell: bash
        env:
          # tests/examples/test_stories_smoke.py is gated on this var; it spawns real
          # stdio + uvicorn subprocesses, so run it on exactly one matrix cell.
          MCP_EXAMPLES_SMOKE: ${{ matrix.os == 'ubuntu-latest' && matrix.python-version == '3.12' && matrix.dep-resolution.name == 'locked' && '1' || '' }}
        run: |
          uv run --frozen --no-sync coverage erase
          uv run --frozen --no-sync coverage run -m pytest -n auto
          uv run --frozen --no-sync coverage combine
          uv run --frozen --no-sync coverage report
      - name: Check for unnecessary no cover pragmas
        if: runner.os != 'Windows'
        run: uv run --frozen --no-sync strict-no-cover
  readme-snippets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
        with:
          persist-credentials: false
      # setup-uv's manifest fetch is a single request with a hard 5s timeout
      # (astral-sh/setup-uv#869); retry once. Drop when upstream adds a retry.
      - name: Install uv
        id: setup-uv
        continue-on-error: true
        uses: astral-sh/setup-uv@fac544c07dec837d0ccb6301d7b5580bf5edae39 # v8.2.0
        with:
          enable-cache: true
          version: 0.9.5
      - name: Install uv (retry)
        if: steps.setup-uv.outcome == 'failure'
        uses: astral-sh/setup-uv@fac544c07dec837d0ccb6301d7b5580bf5edae39 # v8.2.0
        with:
          enable-cache: true
          version: 0.9.5
      - name: Install dependencies
        run: uv sync --frozen --all-extras --python 3.10
      - name: Check README snippets are up to date
        run: uv run --frozen scripts/update_readme_snippets.py --check
  # `scripts/docs/build.sh` is the whole gauntlet: build_config.py fails on
  # nav entries without a page and pages without a nav entry, `zensical build
  # --strict` fails on broken .md links, `pymdownx.snippets: check_paths:
  # true` fails on a deleted `docs_src/` include, and the post-build steps
  # fail on unresolved cross-references, inventory download failures, and
  # broken non-markdown link targets.
  # Until this job existed the docs were only ever built post-merge by
  # `deploy-docs.yml`, so those failures went green on the PR and broke the next
  # deploy of main. This is the check path; `deploy-docs.yml` stays the deploy
  # path.
  docs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
        with:
          persist-credentials: false
      # setup-uv's manifest fetch is a single request with a hard 5s timeout
      # (astral-sh/setup-uv#869); retry once. Drop when upstream adds a retry.
      - name: Install uv
        id: setup-uv
        continue-on-error: true
        uses: astral-sh/setup-uv@fac544c07dec837d0ccb6301d7b5580bf5edae39 # v8.2.0
        with:
          enable-cache: true
          version: 0.9.5
      - name: Install uv (retry)
        if: steps.setup-uv.outcome == 'failure'
        uses: astral-sh/setup-uv@fac544c07dec837d0ccb6301d7b5580bf5edae39 # v8.2.0
        with:
          enable-cache: true
          version: 0.9.5
      - name: Build the docs in strict mode
        run: bash scripts/docs/build.sh
@@ -0,0 +1,25 @@
 name: GitHub Actions Security Analysis
 on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["**"]
 permissions: {}
 jobs:
  zizmor:
    runs-on: ubuntu-latest
    permissions:
      security-events: write # Required for upload-sarif (used by zizmor-action) to upload SARIF files.
    steps:
      - name: Checkout repository
        uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
        with:
          persist-credentials: false
      - name: Run zizmor 🌈
        uses: zizmorcore/zizmor-action@5f14fd08f7cf1cb1609c1e344975f152c7ee938d # v0.5.6
@@ -0,0 +1,182 @@
 .DS_Store
 scratch/
 # Byte-compiled / optimized / DLL files
 __pycache__/
 *.py[cod]
 *$py.class
 # C extensions
 *.so
 # Distribution / packaging
 .Python
 build/
 develop-eggs/
 dist/
 downloads/
 eggs/
 .eggs/
 lib/
 lib64/
 parts/
 sdist/
 var/
 wheels/
 share/python-wheels/
 *.egg-info/
 .installed.cfg
 *.egg
 MANIFEST
 # PyInstaller
 #  Usually these files are written by a python script from a template
 #  before PyInstaller builds the exe, so as to inject date/other infos into it.
 *.manifest
 *.spec
 # Installer logs
 pip-log.txt
 pip-delete-this-directory.txt
 # Unit test / coverage reports
 htmlcov/
 .tox/
 .nox/
 .coverage
 .coverage.*
 .cache
 nosetests.xml
 coverage.xml
 *.cover
 *.py,cover
 .hypothesis/
 .pytest_cache/
 .ruff_cache/
 cover/
 # Translations
 *.mo
 *.pot
 # Django stuff:
 *.log
 local_settings.py
 db.sqlite3
 db.sqlite3-journal
 # Flask stuff:
 instance/
 .webassets-cache
 # Scrapy stuff:
 .scrapy
 # Sphinx documentation
 docs/_build/
 # PyBuilder
 .pybuilder/
 target/
 # Jupyter Notebook
 .ipynb_checkpoints
 # IPython
 profile_default/
 ipython_config.py
 # pyenv
 #   For a library or package, you might want to ignore these files since the code is
 #   intended to run in multiple environments; otherwise, check them in:
 .python-version
 # pipenv
 #   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
 #   However, in case of collaboration, if having platform-specific dependencies or dependencies
 #   having no cross-platform support, pipenv may install dependencies that don't work, or not
 #   install all needed dependencies.
 #Pipfile.lock
 # poetry
 #   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
 #   This is especially recommended for binary packages to ensure reproducibility, and is more
 #   commonly ignored for libraries.
 #   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
 #poetry.lock
 # pdm
 #   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
 #pdm.lock
 #   pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
 #   in version control.
 #   https://pdm.fming.dev/latest/usage/project/#working-with-version-control
 .pdm.toml
 .pdm-python
 .pdm-build/
 # PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
 __pypackages__/
 # Celery stuff
 celerybeat-schedule
 celerybeat.pid
 # SageMath parsed files
 *.sage.py
 # Environments
 .env
 .venv
 env/
 venv/
 ENV/
 env.bak/
 venv.bak/
 # Spyder project settings
 .spyderproject
 .spyproject
 # Rope project settings
 .ropeproject
 # documentation
 /site
 /.worktrees/
 # Generated at build time by scripts/docs/ (the API reference tree and the
 # concrete Zensical config spliced from mkdocs.yml).
 /docs/api/
 /mkdocs.gen.yml
 # mypy
 .mypy_cache/
 .dmypy.json
 dmypy.json
 # Pyre type checker
 .pyre/
 # pytype static type analyzer
 .pytype/
 # Cython debug symbols
 cython_debug/
 # PyCharm
 #  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
 #  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
 #  and can be added to the global gitignore or merged into this file.  For a more nuclear
 #  option (not recommended) you can uncomment the following to ignore the entire idea folder.
 .idea/
 # vscode
 .vscode/
 .windsurfrules
 **/CLAUDE.local.md
 # claude code
 results/
 # conformance CI local runs
 conformance-results/
@@ -0,0 +1,62 @@
 fail_fast: true
 repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v6.0.0
    hooks:
      - id: end-of-file-fixer
  - repo: https://github.com/pre-commit/mirrors-prettier
    rev: v3.1.0
    hooks:
      - id: prettier
        types_or: [yaml, json5]
  - repo: https://github.com/igorshubovych/markdownlint-cli
    rev: v0.45.0
    hooks:
      - id: markdownlint
        args:
          [
            "--fix",
            "--config",
            "pyproject.toml",
            "--configPointer",
            "/tool/markdown/lint",
          ]
        types: [markdown]
  - repo: local
    hooks:
      - id: ruff-format
        name: Ruff Format
        entry: uv run --frozen ruff
        args: [format]
        language: system
        types: [python]
        pass_filenames: false
      - id: ruff
        name: Ruff
        entry: uv run --frozen ruff
        args: ["check", "--fix", "--exit-non-zero-on-fix"]
        types: [python]
        language: system
        pass_filenames: false
      - id: pyright
        name: pyright
        entry: uv run --frozen pyright
        language: system
        types: [python]
        pass_filenames: false
      - id: uv-lock-check
        name: Check uv.lock is up to date
        entry: uv lock --check
        language: system
        files: ^(pyproject\.toml|uv\.lock)$
        pass_filenames: false
      - id: readme-snippets
        name: Check README snippets are up to date
        entry: uv run --frozen python scripts/update_readme_snippets.py --check
        language: system
        files: ^(README\.md|docs_src/.*\.py|scripts/update_readme_snippets\.py)$
        pass_filenames: false
@@ -0,0 +1,162 @@
 # Development Guidelines
 ## Branching Model
 <!-- TODO: drop this section once v2 ships and main becomes the stable line -->
 - `main` is currently the V2 rework.
 - Breaking changes are expected here — removing or replacing an API must be
  intentional. Adding a replacement API or `@deprecated` shim must likewise be
  a deliberate design choice, not bolted on for free.
 - Breaking changes (including those softened by a backwards-compatibility
  shim) must be documented in `docs/migration.md`.
 - `v1.x` is the release branch for the current stable line. Backport PRs target
  this branch and use a `[v1.x]` title prefix.
 - `README.md` documents v2. The v1 README lives on the `v1.x` branch.
 ## Package Management
 - ONLY use uv, NEVER pip
 - Installation: `uv add <package>`. Exception: the root project's runtime
  dependencies are dynamic (the published `mcp` wheel exact-pins `mcp-types`),
  so `uv add` cannot edit them — add the requirement to
  `[tool.hatch.metadata.hooks.uv-dynamic-versioning].dependencies` in
  `pyproject.toml` by hand, then run `uv lock`. Dependency groups, extras, and
  the example packages still take plain `uv add`.
 - Running tools: `uv run --frozen <tool>`. Always pass `--frozen` so uv doesn't
  rewrite `uv.lock` as a side effect.
 - Cross-version testing: `uv run --frozen --python 3.10 pytest ...` to run
  against a specific interpreter (CI covers 3.10–3.14).
 - Upgrading: `uv lock --upgrade-package <package>`
 - FORBIDDEN: `uv pip install`, `@latest` syntax
 - Don't raise dependency floors for CVEs alone. The `>=` constraint already
  lets users upgrade. Only raise a floor when the SDK needs functionality from
  the newer version, and don't add SDK code to work around a dependency's
  vulnerability. See Kludex/uvicorn#2643 and python-sdk #1552 for reasoning.
 ## Code Quality
 - Type hints required for all code
 - Public APIs must have docstrings. When a public API raises exceptions a
  caller would reasonably catch, document them in a `Raises:` section. Don't
  list exceptions from argument validation or programmer error.
 - `src/mcp/__init__.py` defines the public API surface via `__all__`. Adding a
  symbol there is a deliberate API decision, not a convenience re-export.
 - IMPORTANT: All imports go at the top of the file — inline imports hide
  dependencies and obscure circular-import bugs. Only exception: when a
  top-level import genuinely can't work (lazy-loading optional deps, or
  tests that re-import a module).
 ## Testing
 - When writing or reviewing tests, conform to `.claude/skills/test-quality/SKILL.md`
  — it defines the bar for naming, abstraction level, assertions, and determinism.
 - Framework: `uv run --frozen pytest`
 - Async testing: use anyio, not asyncio
 - Do not use `Test` prefixed classes — write plain top-level `test_*` functions.
  Legacy files still contain `Test*` classes; do NOT follow that pattern for new
  tests even when adding to such a file.
 - IMPORTANT: Tests should be fast and deterministic. Prefer in-memory async execution;
  reach for threads only when necessary, and subprocesses only as a last resort.
 - For end-to-end behavior, an in-memory `Client(server)` is usually the
  cleanest approach (see `tests/client/test_client.py` for the canonical
  pattern). For narrower changes, testing the function directly is fine. Use
  judgment.
 - Test files mirror the source tree: `src/mcp/client/stdio.py` →
  `tests/client/test_stdio.py`. Add tests to the existing file for that module.
 - Avoid `anyio.sleep()` with a fixed duration to wait for async operations. Instead:
  - Use `anyio.Event` — set it in the callback/handler, `await event.wait()` in the test
  - For stream messages, use `await stream.receive()` instead of `sleep()` + `receive_nowait()`
  - Exception: `sleep()` is appropriate when testing time-based features (e.g., timeouts)
 - Wrap indefinite waits (`event.wait()`, `stream.receive()`) in `anyio.fail_after(5)` to prevent hangs
 - Pytest is configured with `filterwarnings = ["error"]`, so warnings fail
  tests. Don't silence warnings from your own code; fix the underlying cause.
  Scoped `ignore::` entries for upstream libraries are acceptable in
  `pyproject.toml` with a comment explaining why.
 - New features from the 2026-07-28 spec must have a matching test in the
  [conformance suite](https://github.com/modelcontextprotocol/conformance)
  that passes against this SDK (CI runs it via
  `.github/workflows/conformance.yml`). If no matching test exists, stop and
  tell the user so they can raise an issue on the conformance repo.
 ### Coverage
 CI requires 100% (`fail_under = 100`, `branch = true`).
 - Full check: `./scripts/test` (~23s). Runs coverage + `strict-no-cover` on the
  default Python. Not identical to CI: CI runs 3.10–3.14 × {ubuntu, windows}
  × {locked, lowest-direct}, and some branch-coverage quirks only surface on
  specific matrix entries.
 - Targeted check while iterating (~4s, deterministic):
  ```bash
  uv run --frozen coverage erase
  uv run --frozen coverage run -m pytest tests/path/test_foo.py
  uv run --frozen coverage combine
  uv run --frozen coverage report --include='src/mcp/path/foo.py' --fail-under=0
  # UV_FROZEN=1 propagates --frozen to the uv subprocess strict-no-cover spawns
  UV_FROZEN=1 uv run --frozen strict-no-cover
  ```
  Partial runs can't hit 100% (coverage tracks `tests/` too), so `--fail-under=0`
  and `--include` scope the report. `strict-no-cover` has no false positives on
  partial runs — if your new test executes a line marked `# pragma: no cover`,
  even a single-file run catches it.
 Avoid adding new `# pragma: no cover`, `# type: ignore`, or `# noqa` comments.
 In tests, use `assert isinstance(x, T)` to narrow types instead of
 `# type: ignore`. In library code (`src/`), a `# pragma: no cover` needs very
 good reasoning — it usually means a test is missing. Audit before pushing:
 ```bash
 git diff origin/main... | grep -E '^\+.*(pragma|type: ignore|noqa)'
 ```
 What the existing pragmas mean:
 - `# pragma: no cover` — line is never executed. CI's `strict-no-cover` (skipped
  on Windows runners) fails if it IS executed. When your test starts covering
  such a line, remove the pragma.
 - `# pragma: lax no cover` — excluded from coverage but not checked by
  `strict-no-cover`. Use for lines covered on some platforms/versions but not
  others.
 - `# pragma: no branch` — excludes branch arcs only. coverage.py misreports the
  `->exit` arc for nested `async with` on Python 3.11+ (worse on 3.14/Windows).
 ## Breaking Changes
 When making breaking changes, document them in `docs/migration.md` — including
 changes softened by a backwards-compatibility shim. Include:
 - What changed
 - Why it changed
 - How to migrate existing code
 Search for related sections in the migration guide and group related changes together
 rather than adding new standalone sections.
 ## Documentation
 When a change affects public API or user-visible behaviour, update the relevant
 page(s) under `docs/` in the same PR. Docs are organised by the `nav:` sections
 in `mkdocs.yml` (Get started, Servers, Inside your handler, Running your server,
 Clients, Advanced), not by the on-disk directory names. Find the page covering
 the feature you touched in `mkdocs.yml` rather than adding a new one.
 ## Formatting & Type Checking
 - Format: `uv run --frozen ruff format .`
 - Lint: `uv run --frozen ruff check . --fix`
 - Type check: `uv run --frozen pyright`
 - Pre-commit runs all of the above plus markdownlint, a `uv.lock` consistency
  check, and README checks — see `.pre-commit-config.yaml`
 ## Exception Handling
 - **Always use `logger.exception()` instead of `logger.error()` when catching exceptions**
  - Don't include the exception in the message: `logger.exception("Failed")` not `logger.exception(f"Failed: {e}")`
 - **Catch specific exceptions** where possible:
  - File ops: `except (OSError, PermissionError):`
  - JSON: `except json.JSONDecodeError:`
  - Network: `except (ConnectionError, TimeoutError):`
 - **FORBIDDEN** `except Exception:` - unless in top-level handlers
@@ -0,0 +1 @@
@AGENTS.md
@@ -0,0 +1,128 @@
 # Contributor Covenant Code of Conduct
 ## Our Pledge
 We as members, contributors, and leaders pledge to make participation in our
 community a harassment-free experience for everyone, regardless of age, body
 size, visible or invisible disability, ethnicity, sex characteristics, gender
 identity and expression, level of experience, education, socio-economic status,
 nationality, personal appearance, race, religion, or sexual identity
 and orientation.
 We pledge to act and interact in ways that contribute to an open, welcoming,
 diverse, inclusive, and healthy community.
 ## Our Standards
 Examples of behavior that contributes to a positive environment for our
 community include:
 * Demonstrating empathy and kindness toward other people
 * Being respectful of differing opinions, viewpoints, and experiences
 * Giving and gracefully accepting constructive feedback
 * Accepting responsibility and apologizing to those affected by our mistakes,
  and learning from the experience
 * Focusing on what is best not just for us as individuals, but for the
  overall community
 Examples of unacceptable behavior include:
 * The use of sexualized language or imagery, and sexual attention or
  advances of any kind
 * Trolling, insulting or derogatory comments, and personal or political attacks
 * Public or private harassment
 * Publishing others' private information, such as a physical or email
  address, without their explicit permission
 * Other conduct which could reasonably be considered inappropriate in a
  professional setting
 ## Enforcement Responsibilities
 Community leaders are responsible for clarifying and enforcing our standards of
 acceptable behavior and will take appropriate and fair corrective action in
 response to any behavior that they deem inappropriate, threatening, offensive,
 or harmful.
 Community leaders have the right and responsibility to remove, edit, or reject
 comments, commits, code, wiki edits, issues, and other contributions that are
 not aligned to this Code of Conduct, and will communicate reasons for moderation
 decisions when appropriate.
 ## Scope
 This Code of Conduct applies within all community spaces, and also applies when
 an individual is officially representing the community in public spaces.
 Examples of representing our community include using an official e-mail address,
 posting via an official social media account, or acting as an appointed
 representative at an online or offline event.
 ## Enforcement
 Instances of abusive, harassing, or otherwise unacceptable behavior may be
 reported to the community leaders responsible for enforcement at
 <mcp-coc@anthropic.com>.
 All complaints will be reviewed and investigated promptly and fairly.
 All community leaders are obligated to respect the privacy and security of the
 reporter of any incident.
 ## Enforcement Guidelines
 Community leaders will follow these Community Impact Guidelines in determining
 the consequences for any action they deem in violation of this Code of Conduct:
 ### 1. Correction
 **Community Impact**: Use of inappropriate language or other behavior deemed
 unprofessional or unwelcome in the community.
 **Consequence**: A private, written warning from community leaders, providing
 clarity around the nature of the violation and an explanation of why the
 behavior was inappropriate. A public apology may be requested.
 ### 2. Warning
 **Community Impact**: A violation through a single incident or series
 of actions.
 **Consequence**: A warning with consequences for continued behavior. No
 interaction with the people involved, including unsolicited interaction with
 those enforcing the Code of Conduct, for a specified period of time. This
 includes avoiding interactions in community spaces as well as external channels
 like social media. Violating these terms may lead to a temporary or
 permanent ban.
 ### 3. Temporary Ban
 **Community Impact**: A serious violation of community standards, including
 sustained inappropriate behavior.
 **Consequence**: A temporary ban from any sort of interaction or public
 communication with the community for a specified period of time. No public or
 private interaction with the people involved, including unsolicited interaction
 with those enforcing the Code of Conduct, is allowed during this period.
 Violating these terms may lead to a permanent ban.
 ### 4. Permanent Ban
 **Community Impact**: Demonstrating a pattern of violation of community
 standards, including sustained inappropriate behavior,  harassment of an
 individual, or aggression toward or disparagement of classes of individuals.
 **Consequence**: A permanent ban from any sort of public interaction within
 the community.
 ## Attribution
 This Code of Conduct is adapted from the [Contributor Covenant][homepage],
 version 2.0, available at
 <https://www.contributor-covenant.org/version/2/0/code_of_conduct.html>.
 Community Impact Guidelines were inspired by [Mozilla's code of conduct
 enforcement ladder](https://github.com/mozilla/diversity).
 [homepage]: https://www.contributor-covenant.org
 For answers to common questions about this code of conduct, see the FAQ at
 <https://www.contributor-covenant.org/faq>. Translations are available at
 <https://www.contributor-covenant.org/translations>.
@@ -0,0 +1,160 @@
 # Contributing
 Thank you for your interest in contributing to the MCP Python SDK! This document provides guidelines and instructions for contributing.
 ## Before You Start
 We welcome contributions! These guidelines exist to save everyone time, yours included. Following them means your work is more likely to be accepted.
 **All pull requests require a corresponding issue.** Unless your change is trivial (typo, docs tweak, broken link), create an issue first. Every merged feature becomes ongoing maintenance, so we need to agree something is worth doing before reviewing code. PRs without a linked issue will be closed.
 Having an issue doesn't guarantee acceptance. Wait for maintainer feedback or a `ready for work` label before starting. PRs for issues without buy-in may also be closed.
 Use issues to validate your idea before investing time in code. PRs are for execution, not exploration.
 ### AI-Assisted Contributions
 > [!IMPORTANT]
 > If you used AI assistance for a contribution, disclose it in the PR or issue.
 We use AI tooling constantly and have no problem with you using it too. But somewhere in the loop there has to be a human who actually understands the change. We have a large backlog and limited reviewer time—we're not spending it on code nobody has read. Not disclosing is also just rude to the people on the other end.
 - **Disclose it.** One line in the PR or issue description. That's it.
 - **Own it.** You can explain the change in your own words. When a maintainer asks a question, the answer comes from you, not pasted from a chat window.
 - **No drive-by agents.** PRs, issues, or comments produced by an autonomous agent with no human review get closed on sight. If your agent is auto-filing PRs against our open issues, stop.
 Undisclosed AI contributions get closed. Repeat offenders get banned from the `modelcontextprotocol` org.
 ### The SDK is Opinionated
 Not every contribution will be accepted, even with a working implementation. We prioritize maintainability and consistency over adding capabilities. This is at maintainers' discretion.
 ### What Needs Discussion
 These always require an issue first:
 - New public APIs or decorators
 - Architectural changes or refactoring
 - Changes that touch multiple modules
 - Features that might require spec changes (these need a [SEP](https://github.com/modelcontextprotocol/modelcontextprotocol) first)
 Bug fixes for clear, reproducible issues are welcome—but still create an issue to track the fix.
 ### Finding Issues to Work On
 | Label | For | Description |
 |-------|-----|-------------|
 | [`good first issue`](https://github.com/modelcontextprotocol/python-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) | Newcomers | Can tackle without deep codebase knowledge |
 | [`help wanted`](https://github.com/modelcontextprotocol/python-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) | Experienced contributors | Maintainers probably won't get to this |
 | [`ready for work`](https://github.com/modelcontextprotocol/python-sdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22ready+for+work%22) | Maintainers | Triaged and ready for a maintainer to pick up |
 Issues labeled `needs confirmation` or `needs maintainer action` are **not** ready for work—wait for maintainer input first.
 Before starting, comment on the issue so we can assign it to you. This prevents duplicate effort.
 ## Development Setup
 1. Make sure you have Python 3.10+ installed
 2. Install [uv](https://docs.astral.sh/uv/getting-started/installation/)
 3. Fork the repository
 4. Clone your fork: `git clone https://github.com/YOUR-USERNAME/python-sdk.git`
 5. Install dependencies:
 ```bash
 uv sync --frozen --all-extras --dev
 ```
 6. Set up pre-commit hooks:
 ```bash
 uv tool install pre-commit --with pre-commit-uv --force-reinstall
 ```
 ## Development Workflow
 1. Choose the correct branch for your changes:
   | Change Type | Target Branch | Example |
   |-------------|---------------|---------|
   | New features, breaking changes | `main` | New APIs, refactors |
   | Security fixes for v1 | `v1.x` | Critical patches |
   | Bug fixes for v1 | `v1.x` | Non-breaking fixes |
   > **Note:** `main` is the v2 development branch. Breaking changes are welcome on `main`. The `v1.x` branch receives only security and critical bug fixes.
 2. Create a new branch from your chosen base branch
 3. Make your changes
 4. Ensure tests pass:
 ```bash
 uv run pytest
 ```
 5. Run type checking:
 ```bash
 uv run pyright
 ```
 6. Run linting:
 ```bash
 uv run ruff check .
 uv run ruff format .
 ```
 7. Update README snippets if you modified `docs_src/` code embedded in the README:
 ```bash
 uv run scripts/update_readme_snippets.py
 ```
 8. (Optional) Run pre-commit hooks on all files:
 ```bash
 pre-commit run --all-files
 ```
 9. Submit a pull request to the same branch you branched from
 ## Code Style
 - We use `ruff` for linting and formatting
 - Follow PEP 8 style guidelines
 - Add type hints to all functions
 - Include docstrings for public APIs
 ## Pull Requests
 By the time you open a PR, the "what" and "why" should already be settled in an issue. This keeps reviews focused on implementation.
 ### Scope
 Small PRs get reviewed fast. Large PRs sit in the queue.
 A few dozen lines can be reviewed in minutes. Hundreds of lines across many files takes real effort and things slip through. If your change is big, break it into smaller PRs or get alignment from a maintainer first.
 ### What Gets Rejected
 - **No prior discussion**: Features or significant changes without an approved issue
 - **Scope creep**: Changes that go beyond what was discussed
 - **Misalignment**: Even well-implemented features may be rejected if they don't fit the SDK's direction
 - **Overengineering**: Unnecessary complexity for simple problems
 - **Undisclosed or unreviewed AI output**: See [AI-Assisted Contributions](#ai-assisted-contributions)
 ### Checklist
 1. Update documentation as needed
 2. Add tests for new functionality
 3. Ensure CI passes
 4. Address review feedback
 ## Code of Conduct
 Please note that this project is released with a [Code of Conduct](CODE_OF_CONDUCT.md). By participating in this project you agree to abide by its terms.
 ## License
 By contributing, you agree that your contributions will be licensed under the MIT License.
@@ -0,0 +1,21 @@
 MIT License
 Copyright (c) 2024 Anthropic, PBC
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
 in the Software without restriction, including without limitation the rights
 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 copies of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:
 The above copyright notice and this permission notice shall be included in all
 copies or substantial portions of the Software.
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
@@ -0,0 +1,129 @@
 # MCP Python SDK
 <div align="center">
 <strong>Python implementation of the Model Context Protocol (MCP)</strong>
 [![PyPI][pypi-badge]][pypi-url]
 [![MIT licensed][mit-badge]][mit-url]
 [![Python Version][python-badge]][python-url]
 [![Documentation][docs-badge]][docs-url]
 [![Protocol][protocol-badge]][protocol-url]
 [![Specification][spec-badge]][spec-url]
 </div>
 > [!CAUTION]
 > **This README documents v2 of the MCP Python SDK — a pre-release (alpha/beta) line under active development. Do not use v2 in production.** Pre-releases are published to PyPI as `2.0.0aN` / `2.0.0bN`, and **each pre-release may contain breaking changes from the previous one**. Pin an exact version and expect to update your code when you bump the pin.
 >
 > **v1.x is the only stable release line and remains recommended for production.** It lives on the [`v1.x` branch](https://github.com/modelcontextprotocol/python-sdk/tree/v1.x) and continues to receive critical bug fixes and security patches; see [the v1.x README](https://github.com/modelcontextprotocol/python-sdk/blob/v1.x/README.md) for its documentation. `pip` and `uv` don't select a pre-release unless you explicitly request one, so existing installs are unaffected. **If your package depends on `mcp`, add a `<2` upper bound to your version constraint (for example `mcp>=1.27,<2`) before the stable release lands.**
 >
 > v2 is a major rework of the SDK, both to support the [2026-07-28 MCP specification release](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/) and to fix long-standing architectural issues. See [What's new in v2](https://py.sdk.modelcontextprotocol.io/v2/whats-new/) for the tour of what changed, and the [migration guide](https://py.sdk.modelcontextprotocol.io/v2/migration/) for every breaking change. Stable v2 is targeted for 2026-07-27, alongside the spec release. Try the pre-releases and [tell us what breaks](https://github.com/modelcontextprotocol/python-sdk/issues/new?template=v2-feedback.yaml), or discuss in [#python-sdk-dev on the MCP Contributors Discord](https://discord.gg/6CSzBmMkjX).
 ## Documentation
 **The documentation lives at <https://py.sdk.modelcontextprotocol.io/v2/>.**
 It has a [Get started guide](https://py.sdk.modelcontextprotocol.io/v2/get-started/), [What's new in v2](https://py.sdk.modelcontextprotocol.io/v2/whats-new/), the [API reference](https://py.sdk.modelcontextprotocol.io/v2/api/mcp/), and the [migration guide](https://py.sdk.modelcontextprotocol.io/v2/migration/).
 ## What is MCP?
 The [Model Context Protocol](https://modelcontextprotocol.io) lets you build servers that expose data and functionality to LLM applications in a secure, standardized way. Think of it like a web API, but designed for LLM interactions. With this SDK you can:
 - **Build MCP servers** that expose tools, resources, and prompts to any MCP host
 - **Build MCP clients** that connect to any MCP server
 - Speak every standard transport: stdio, Streamable HTTP, and SSE
 ## Requirements
 Python 3.10+.
 ## Installation
 ```bash
 uv add "mcp[cli]==2.0.0b1"          # or: pip install "mcp[cli]==2.0.0b1"
 ```
 The pin matters while v2 is in pre-release: an unpinned install resolves to the latest stable v1.x, which this README does not describe. Check [PyPI](https://pypi.org/project/mcp/#history) for the newest pre-release, and use `uv run --with "mcp==2.0.0b1"` for one-off commands.
 ## A server in 15 lines
 Create a `server.py`:
 <!-- snippet-source docs_src/index/tutorial001.py -->
 ```python
 from mcp.server import MCPServer
 mcp = MCPServer("Demo")
@mcp.tool()
 def add(a: int, b: int) -> int:
    """Add two numbers."""
    return a + b
@mcp.resource("greeting://{name}")
 def greeting(name: str) -> str:
    """Greet someone by name."""
    return f"Hello, {name}!"
 ```
 _Full example: [docs_src/index/tutorial001.py](https://github.com/modelcontextprotocol/python-sdk/blob/main/docs_src/index/tutorial001.py)_
 <!-- /snippet-source -->
 That's a complete MCP server: one tool, one templated resource. Open it in the [MCP Inspector](https://github.com/modelcontextprotocol/inspector):
 ```bash
 uv run mcp dev server.py
 ```
 Call `add` with `a=1`, `b=2` and you get `3` back.
 Notice what you did **not** write: no JSON Schema (`a: int, b: int` _is_ the schema), no request parsing, no validation code, no protocol handling. Two type-hinted Python functions and a docstring.
 [Get started](https://py.sdk.modelcontextprotocol.io/v2/get-started/) takes it from here.
 ## A client in 10 lines
 The same package is a full MCP **client**. `Client` connects to a URL, a stdio subprocess, a custom transport, or (for tests) straight to a server object in memory with no transport at all:
 ```python
 import asyncio
 from mcp import Client
 from server import mcp
 async def main() -> None:
    async with Client(mcp) as client:
        result = await client.call_tool("add", {"a": 1, "b": 2})
        print(result.structured_content)  # {'result': 3}
 asyncio.run(main())
 ```
 Swap `mcp` for `"http://localhost:8000/mcp"` and the exact same code talks to a remote server.
 ## Contributing
 We are passionate about supporting contributors of all levels of experience and would love to see you get involved in the project. See the [contributing guide](https://github.com/modelcontextprotocol/python-sdk/blob/main/CONTRIBUTING.md) to get started.
 ## License
 This project is licensed under the MIT License. See the [LICENSE](https://github.com/modelcontextprotocol/python-sdk/blob/main/LICENSE) file for details.
 [pypi-badge]: https://img.shields.io/pypi/v/mcp.svg
 [pypi-url]: https://pypi.org/project/mcp/
 [mit-badge]: https://img.shields.io/pypi/l/mcp.svg
 [mit-url]: https://github.com/modelcontextprotocol/python-sdk/blob/main/LICENSE
 [python-badge]: https://img.shields.io/pypi/pyversions/mcp.svg
 [python-url]: https://www.python.org/downloads/
 [docs-badge]: https://img.shields.io/badge/docs-python--sdk-blue.svg
 [docs-url]: https://py.sdk.modelcontextprotocol.io/v2/
 [protocol-badge]: https://img.shields.io/badge/protocol-modelcontextprotocol.io-blue.svg
 [protocol-url]: https://modelcontextprotocol.io
 [spec-badge]: https://img.shields.io/badge/spec-spec.modelcontextprotocol.io-blue.svg
 [spec-url]: https://modelcontextprotocol.io/specification/latest
@@ -0,0 +1,7 @@
 # WeHub 来源说明
 - 原始项目：`modelcontextprotocol/python-sdk`
 - 原始仓库：https://github.com/modelcontextprotocol/python-sdk
 - 导入方式：上游默认分支的最新快照
 - 原作者、版权和许可证信息以原始仓库及本仓库 LICENSE 为准
 - 本文件仅用于记录来源，不代表 WeHub 是原项目作者
@@ -0,0 +1,69 @@
 # Release Process
 ## Bumping Dependencies
 1. Change the dependency version in `pyproject.toml`. The root `mcp` project's
   runtime dependencies are dynamic and live under
   `[tool.hatch.metadata.hooks.uv-dynamic-versioning].dependencies`.
 2. Upgrade lock with `uv lock --resolution lowest-direct`
 ## Major or Minor Release
 Stable releases are cut from the `v1.x` branch. Create a GitHub release via UI
 with the tag being `vX.Y.Z` where `X.Y.Z` is the version and the release title
 being the same, and **set the tag's target to the `v1.x` branch** — the UI
 defaults to `main`, which is the v2 rework, and a v1 tag created there would
 publish the v2 codebase as a stable release. Then ask someone to review the
 release.
 The package version will be set automatically from the tag.
 ## v2 Pre-releases
 v2 pre-releases are cut from `main` with a PEP 440 pre-release tag: `v2.0.0aN`
 for alphas, later `bN`/`rcN` for betas and release candidates.
 A release publishes two distributions, `mcp` and `mcp-types`, at the same
 version, and the `mcp` wheel exact-pins `mcp-types`. Before the first release
 that includes both, the `mcp-types` PyPI project must be given the same
 trusted publisher as `mcp` (this repository, workflow `publish-pypi.yml`,
 environment `release`) and the same owners — without it the `mcp-types`
 upload is rejected. If only some of the files upload, fix the cause and re-run
 the publish job — `skip-existing` makes it skip whatever already landed. The
 `Development Status` classifier in both `pyproject.toml` files is permanently
 `5 - Production/Stable`; it is not bumped as part of any release.
 1. Update the pre-release version examples in `README.md` and the docs
   (grep the outgoing version — the pins live in the README Installation
   section, `docs/index.md`, `docs/get-started/installation.md`, and `docs/get-started/real-host.md`) so the tagged
   commit — and therefore the README PyPI publishes — names the version
   being released. When entering a new phase (alpha → beta → rc), update
   the banner wording too.
 2. Check the full test matrix is green on the release commit. The publish
   workflow re-runs the checks and blocks publishing until they pass, so a
   red leg there means re-running the failed jobs on the Publishing run.
 3. Create the release as a pre-release, passing the exact commit verified in
   step 2 as `--target` (otherwise the tag is created from whatever `main`'s
   HEAD is by then). The tagged commit determines everything about the
   release — the workflows that run and the package metadata (readme,
   classifiers) that gets published — so it must contain the current release
   tooling, not just pass tests. `--target` is ignored if the tag already
   exists: when re-creating a release, delete the old tag first and
   double-check where the new tag points. The pre-release flag keeps GitHub's
   "Latest" badge and `/releases/latest` pointing at the stable v1.x line:
   ```shell
   gh release create v2.0.0aN --prerelease --title v2.0.0aN --target <commit-sha>
   ```
 4. Curate the release notes instead of relying on auto-generated ones: what
   changed since the previous pre-release, what is known-incomplete, the
   install line (`pip install mcp==2.0.0aN`), and a link to the migration
   guide. Use the absolute URL
   (`https://github.com/modelcontextprotocol/python-sdk/blob/main/docs/migration.md`)
   because relative links don't resolve in GitHub release bodies.
 5. If a pre-release turns out to be broken, yank it on PyPI and cut the next
   one. Never delete a release from PyPI — version numbers cannot be reused.
   Yanking doesn't stop `==` pins from installing the broken version, so set
   the yank reason (and edit the GitHub release notes) to point at the
   replacement version.
@@ -0,0 +1,30 @@
 # Security Policy
 Thank you for helping keep the Model Context Protocol and its ecosystem secure.
 ## Supported Versions
 Security fixes are released for the most recent stable (v1.x) release line.
 v2 pre-releases (`2.0.0aN`, …) are development snapshots: fixes land only in
 the newest pre-release, and already-published pre-releases are not patched. If
 you are testing the v2 line, track the latest pre-release; for production use,
 stay on the latest stable release.
 ## Reporting Security Issues
 If you discover a security vulnerability in this repository, please report it through
 the [GitHub Security Advisory process](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability)
 for this repository.
 Please **do not** report security vulnerabilities through public GitHub issues, discussions,
 or pull requests.
 ## What to Include
 To help us triage and respond quickly, please include:
 - A description of the vulnerability
 - Steps to reproduce the issue
 - The potential impact
 - Any suggested fixes (optional)
@@ -0,0 +1 @@
 <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 180 180"><path fill="none" d="M23.5996 85.2532L86.2021 22.6507C94.8457 14.0071 108.86 14.0071 117.503 22.6507C126.147 31.2942 126.147 45.3083 117.503 53.9519L70.2254 101.23" stroke="currentColor" stroke-width="11.0667" stroke-linecap="round"/><path fill="none" d="M70.8789 100.578L117.504 53.952C126.148 45.3083 140.163 45.3083 148.806 53.952L149.132 54.278C157.776 62.9216 157.776 76.9357 149.132 85.5792L92.5139 142.198C89.6327 145.079 89.6327 149.75 92.5139 152.631L104.14 164.257" stroke="currentColor" stroke-width="11.0667" stroke-linecap="round"/><path fill="none" d="M101.853 38.3013L55.553 84.6011C46.9094 93.2447 46.9094 107.258 55.553 115.902C64.1966 124.546 78.2106 124.546 86.8543 115.902L133.154 69.6025" stroke="currentColor" stroke-width="11.0667" stroke-linecap="round"/></svg>
@@ -0,0 +1,160 @@
 # MCP Apps
 An **MCP App** is a tool with a face: alongside its data, the tool points at an HTML
 document the host renders as an interactive surface.
 Two parts, always two parts:
 1. **A tool** that does the work and returns data, like any other tool.
 2. **A `ui://` resource** containing the HTML the host shows for it.
 The tool carries a `_meta.ui.resourceUri` reference to the resource. The host fetches
 it with `resources/read`, renders it in a **sandboxed iframe**, and pushes the tool's
 result into that iframe via `postMessage`. Your server never sends or receives any
 `ui/*` messages: that traffic is between the host and the iframe. You serve a tool
 and an HTML document; the host does the theater.
 The SDK ships this as the built-in `Apps` extension (`io.modelcontextprotocol/ui`).
 If [Extensions](extensions.md) are new to you, skim that page first. One minute,
 then come back.
 ## A clock with a face
 ```python title="server.py" hl_lines="18 21 29 31"
 --8<-- "docs_src/apps/tutorial001.py"
 ```
 Four moves:
 * `Apps()`: one instance holds your UI-bound tools and their resources.
 * `@apps.tool(resource_uri="ui://clock/app.html")`: a regular tool, plus the
  `_meta.ui.resourceUri` stamp. Everything `@mcp.tool()` accepts (name, title,
  description, ...) passes through.
 * `apps.add_html_resource("ui://clock/app.html", CLOCK_HTML)`: the matching
  resource, served as `text/html;profile=mcp-app`. That exact MIME type is what
  tells a host "this is an app, render it".
 * `MCPServer("clock", extensions=[apps])`: opt in. The server now advertises
  `io.modelcontextprotocol/ui` under `capabilities.extensions`.
 The HTML itself listens for the host's `postMessage` and shows the result. For real
 apps, use the official [`@modelcontextprotocol/ext-apps`](https://github.com/modelcontextprotocol/ext-apps)
 browser SDK inside your HTML. It gives you `ontoolresult`, `callServerTool`,
 `getHostContext`, and `onhostcontextchanged` instead of raw message events.
 ## Graceful degradation
 Not every client renders apps. The spec is blunt about what that means for you:
 > Tools **MUST** return a meaningful `content` array even when UI is available.
 The model reads `content`; the iframe is for humans. A UI-capable host still feeds
 the text result to the model, and a text-only client gets *only* that. So the
 canonical pattern is one tool, two answers. Look at `get_time` again:
 ```python title="server.py" hl_lines="22-26"
 --8<-- "docs_src/apps/tutorial001.py"
 ```
 `client_supports_apps(ctx)` is `True` only when the client declared the
 `io.modelcontextprotocol/ui` extension **and** listed `text/html;profile=mcp-app`
 in its `mimeTypes` settings. The field is required, so a client that omits it
 does not count. That is exactly what `main()` in the same file declares: the
 client half of the negotiation, and the rich answer comes back.
 !!! warning
    Never return a placeholder like `"[Rendered UI]"` as the only content. If the
    fallback text is useless, the tool is useless to every text-only client and to
    the model itself. Write the sentence.
 ## Locking the iframe down
 The resource side carries the security metadata: what the iframe may load, which
 browser permissions it wants, how it would like to be framed:
 ```python title="server.py" hl_lines="9 19-22"
 --8<-- "docs_src/apps/tutorial002.py"
 ```
 `csp` and `permissions` are **requests to the host**, not server behaviour. The host
 builds the iframe's Content-Security-Policy and Permissions-Policy from them, and it
 may refuse. Feature-detect in your JS rather than assuming a grant.
 `ResourceCsp`, field by field (Python name, wire key, what the host does with it):
 | Python | Wire (`_meta.ui.csp`) | Controls |
 |---|---|---|
 | `connect_domains` | `connectDomains` | `connect-src`: where `fetch`/XHR may go |
 | `resource_domains` | `resourceDomains` | `img-src`, `style-src`, ...: static assets |
 | `frame_domains` | `frameDomains` | `frame-src`: nested iframes |
 | `base_uri_domains` | `baseUriDomains` | `base-uri`: what `<base>` may point at |
 `ResourcePermissions`: each field requests a browser permission for the iframe.
 | Python | Wire (`_meta.ui.permissions`) |
 |---|---|
 | `camera` | `camera` |
 | `microphone` | `microphone` |
 | `geolocation` | `geolocation` |
 | `clipboard_write` | `clipboardWrite` |
 !!! note
    CSP and permissions live on the **resource**, never on the tool. The spec's tool
    metadata has no slot for them, and hosts ignore them there. The SDK makes the
    mistake unrepresentable: `@apps.tool()` simply has no `csp` parameter.
 ### Visibility
 `visibility=["app"]` on a tool says "this exists for the iframe, not the model":
 * `"model"`: the model may call it.
 * `"app"`: the iframe may call it (via `callServerTool`).
 * Omitted: both, which is the default.
 Filtering is the **host's** job. Your server lists app-only tools in `tools/list`
 like any other; the host hides them from the model. Don't filter server-side.
 ## The rules the SDK enforces
 All of these fail at startup, not in production:
 * A `resource_uri` or resource URI that isn't `ui://...` is a `ValueError` at
  decoration/registration time.
 * A tool bound to a URI with **no matching registered resource** is a `ValueError`
  when `MCPServer(extensions=[apps])` consumes the extension. A tool advertising
  HTML that 404s on `resources/read` is a misconfiguration, so it refuses to
  construct.
 * `meta={"ui": ...}` on `@apps.tool()` is a `ValueError`. The decorator owns
  `_meta["ui"]`; say it with `resource_uri=` and `visibility=`. Other `meta=` keys
  merge fine alongside.
 Neither the TypeScript ext-apps SDK nor FastMCP catches any of these today; we'd
 rather you find out before a host does.
 ## Beyond inline HTML
 `add_html_resource` covers the common case: a string of HTML. For anything else,
 HTML on disk or generated content, build the resource yourself and hand it over:
 ```python title="server.py" hl_lines="12 18"
 --8<-- "docs_src/apps/tutorial003.py"
 ```
 `add_resource` fills in the `text/html;profile=mcp-app` MIME type when the resource
 doesn't set one explicitly, and rejects an explicit mismatch: a `ui://` resource
 under any other MIME type is one no host will render.
 !!! tip
    Targeting a pre-GA host that still reads the deprecated flat
    `_meta["ui/resourceUri"]` key? Merge it yourself:
    `@apps.tool(resource_uri="ui://x", meta={"ui/resourceUri": "ui://x"})`.
    The nested `ui` object is the spec shape; the flat key is on its way out.
 ## See it run
 The `apps` story in `examples/stories/` is this page as a runnable pair: a server
 with a UI-bound clock tool and a client that negotiates Apps, reads the tool's
 `_meta.ui.resourceUri`, fetches the HTML, and calls the tool.
 ```bash
 uv run python -m stories.apps.client
 ```
@@ -0,0 +1,249 @@
 # Extensions
 An **extension** is an opt-in bundle of MCP behaviour behind one identifier.
 On a server it can contribute tools, resources, and new request methods, and it can wrap
 `tools/call`. On a client it can claim extra `tools/call` result shapes and observe vendor
 notifications. Each side advertises under its own `capabilities.extensions`, and nothing
 changes for anyone who didn't ask for it. That is the contract ([SEP-2133](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2133)), and
 it has one golden rule: **extensions are off by default**.
 ## Using an extension
 Pass instances at construction:
 ```python title="server.py"
 --8<-- "docs_src/extensions/tutorial001.py"
 ```
 Done. The server now advertises `io.modelcontextprotocol/ui` under
 `capabilities.extensions` and serves everything the extension contributes.
 `Apps` is the built-in reference extension, and it gets its own page: **[MCP Apps](apps.md)**.
 !!! note
    Extensions are fixed at construction. There is no `add_extension` to call later:
    a server's capability map should not change while clients are connected to it.
 The capability map rides `server/discover`, which is a **2026-07-28** path. A legacy
 `initialize` handshake has nowhere to put it, so a legacy client simply doesn't see
 the extension. Design for that: an extension *augments* a server, it must not be the
 only way the server is usable.
 ## Writing your own
 Subclass `Extension` and override only what you need. Every method has a default.
 ### The identifier
 ```python
 --8<-- "docs_src/extensions/tutorial002.py"
 ```
 The identifier is a `vendor-prefix/name` string following the spec's `_meta` key
 grammar: dot-separated labels (each starts with a letter, ends with a letter or
 digit), a slash, then the name. It is validated **when the class is defined**, so a
 typo doesn't wait for a server to boot:
 ```text
 TypeError: Stamps.identifier must be a `vendor-prefix/name` string
 (reverse-DNS prefix required), got 'stamps'
 ```
 Use a domain you control as the prefix. `io.modelcontextprotocol/*` is for extensions
 specified by the MCP project itself.
 ### Contributing tools
 The smallest useful extension is one tool and a settings map:
 ```python title="server.py" hl_lines="17 19-20 22-23 26"
 --8<-- "docs_src/extensions/tutorial003.py"
 ```
 * `tools()` returns `ToolBinding`s. The server registers each one exactly as if you
  had called `mcp.add_tool(...)` yourself: same schema generation, same `Context`
  injection, same everything.
 * `settings()` is the value advertised at `capabilities.extensions["com.example/stamps"]`.
  Return `{}` (the default) to advertise the extension with no settings.
 * The extension never receives the server. It declares contributions as data;
  `MCPServer` consumes them. There is no `self.server` to mutate.
 And `main()` is the proof, an in-memory client straight against `mcp`:
 ```python title="server.py" hl_lines="29-34"
 --8<-- "docs_src/extensions/tutorial003.py"
 ```
 ### Serving your own methods
 An extension can register **new request methods**: its own verbs, served next to the
 spec's:
 ```python title="server.py" hl_lines="16-22 31 40-48"
 --8<-- "docs_src/extensions/tutorial004.py"
 ```
 * `SearchParams` subclasses `RequestParams`, so the 2026 `_meta` envelope parses
  uniformly and your handler gets validated params, never a raw dict. Bound what
  the client controls: `Field(ge=1, le=100)` rejects an absurd `limit` before
  your code allocates anything for it.
 * `require_client_extension(ctx, EXTENSION_ID)` is the gate: a client that did not
  declare the extension gets the `-32021` (missing required client capability) error,
  with the machine-readable `requiredCapabilities` payload the spec asks for.
 * `protocol_versions=frozenset({"2026-07-28"})` pins the method to one wire version.
  At any other version the client gets `METHOD_NOT_FOUND`, exactly as if the method
  didn't exist there. For that client, it doesn't.
 Methods are **strictly additive**. The SDK enforces this at construction, not at
 runtime:
 * A `MethodBinding` for a spec-defined method (`tools/list`, `completion/complete`, ...)
  raises `ValueError` when the binding is constructed. Core verbs belong to the server.
 * Two extensions binding the same method raise when the second one registers.
  Last-write-wins is how plugins corrupt each other; we don't do that.
 * An empty `protocol_versions` set raises too: a method that can never be served
  is a bug, not a configuration.
 ### The client side
 The same file's `main()` is the whole client story, both halves of it:
 ```python title="server.py" hl_lines="54-58"
 --8<-- "docs_src/extensions/tutorial004.py"
 ```
 * `Client(..., extensions=[advertise(EXTENSION_ID)])` declares the extension. The
  declarations become `ClientCapabilities.extensions`: on a 2026-07-28 connection
  the map travels in the per-request `_meta` envelope, so the server sees it on
  **every** request; on a legacy connection it rides the `initialize` handshake.
  Server code doesn't care which: `require_client_extension(ctx, ...)` and
  `ctx.session.check_client_capability(...)` read the right source on both paths.
 * Vendor methods drop one layer to `client.session.send_request(...)`; `Client`
  only grows first-class methods for spec verbs. `send_request` accepts any
  `Request` subclass, so the vendor request passes as-is.
 ### Intercepting `tools/call`
 The one interceptive hook. Override `intercept_tool_call` to observe, short-circuit,
 or veto a tool call:
 ```python title="server.py" hl_lines="18-25"
 --8<-- "docs_src/extensions/tutorial005.py"
 ```
 * `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).
 * 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.
 The hook wraps `tools/call` and nothing else. For every-message concerns, use
 [Middleware](middleware.md). That is what it is for.
 ## Using a client extension
 A **client extension** is the same contract from the consuming side: a bundle of
 client-side behaviour behind one identifier. Pass instances to
 `Client(extensions=[...])` and call tools normally:
 ```python title="client.py" hl_lines="67-69"
 --8<-- "docs_src/extensions/tutorial006.py"
 ```
 `call_tool("buy", ...)` returns a plain `CallToolResult`, like every other call. What
 the extension changed: the server may now answer `buy` with a `receipt` **result
 shape** instead of a final result, and `Receipts` finishes it (here by redeeming the
 receipt with a follow-up call) before `call_tool` returns. Nothing about the call
 site moves.
 Drop the extension and none of this exists: the server's gate refuses a client
 that did not declare it (error -32021), and a claimed shape from a server that
 skips the gate fails validation, exactly as the spec requires for an
 unrecognized `resultType`. Off by default, on both ends of the wire.
 To advertise an identifier with **no** client-side behaviour (the server gates on
 the capability, the client does nothing, as in the search client above), use
 `advertise()`:
 ```python
 from mcp.client import advertise
 client = Client(mcp, extensions=[advertise("com.example/search")])
 ```
 ## Writing a client extension
 Subclass `ClientExtension` and override only what you need. Three contribution
 kinds, each with a default: `settings()`, `claims()`, and `notifications()`.
 ```python title="client.py" hl_lines="18-19 44-45 47-48"
 --8<-- "docs_src/extensions/tutorial006.py"
 ```
 * The identifier follows the same grammar as the server's, validated when the class
  is defined.
 * `claims()` returns `ResultClaim`s: a wire tag, the model that parses it, and the
  resolver that finishes it. The model must pin the tag with
  `result_type: Literal["receipt"]` and must not subclass the verb's core result
  types; both are enforced when the claim is constructed. Vendor fields like
  `receipt_token` ride the wire as-is: a substituted shape reaches the client
  verbatim.
 * The resolver receives the parsed model and a `ClaimContext`; `ctx.session` is the
  same public handle as `client.session`, so follow-ups are ordinary session calls.
  It returns the verb's normal `CallToolResult`.
 * `settings()` is the value advertised at `ClientCapabilities.extensions[identifier]`,
  read once at `Client` construction.
 `notifications()` declares vendor server notifications to observe:
 ```python
 def notifications(self) -> Sequence[NotificationBinding[Any]]:
    return [NotificationBinding(method="notifications/receipts", params_type=ReceiptEvent, handler=self.on_receipt)]
 ```
 The handler receives validated params one at a time, in dispatch order. It observes; it cannot veto
 or reply.
 Two quiet rules. Claims are active on 2026-07-28 connections only, and the capability
 ad follows them: on a legacy connection the claims dissolve and the identifier drops
 out of the ad with them, so the client never advertises an extension whose shapes it
 would reject. And when you want the claimed shape yourself instead of the resolver,
 call `client.session.call_tool(..., allow_claimed=True)`; without that flag, a
 claimed shape reaching a session-tier caller raises `UnexpectedClaimedResult`.
 ### Extension verbs
 An extension's own request methods need no client-side registration. A vendor request
 type subclasses `mcp_types.Request` and goes through `client.session.send_request`,
 as in [Serving your own methods](#serving-your-own-methods). One addition: when a
 params key must ride the `Mcp-Name` header (extension specs such as tasks require
 this for their verbs), the request type declares `name_param`:
 ```python title="client.py" hl_lines="23-26 47-48"
 --8<-- "docs_src/extensions/tutorial007.py"
 ```
 The session mirrors `params["jobId"]` into `Mcp-Name` on every send path, and a
 missing value fails loudly rather than silently omitting a required header.
 ## What an extension cannot do
 The contribution surface is **closed** on purpose. On the server: settings, tools,
 resources, methods, one `tools/call` interceptor. On the client: settings, result
 claims, notification bindings. An extension cannot:
 * **Reach into the host.** It declares data; it holds no server or client reference.
 * **Replace core behaviour.** Spec methods and core result tags are rejected at
  construction (`initialize` is reserved by the runner outright); a notification
  binding shadowed by core vocabulary goes quiet with a warning instead.
 * **Register late.** After `MCPServer(...)` or `Client(...)` returns, the extension
  set is what it is.
 If you are fighting these walls, you are not writing an extension. You are writing
 a fork. The walls are the feature: a user reading `extensions=[Apps(), Stamps()]`
 knows *everything* those two can have touched.
@@ -0,0 +1,29 @@
 # Advanced
 Everything an ordinary server or client needs has a topical home in the sections above.
 This section is the escape hatches you reach for when `MCPServer`'s convenience
 layer is in the way:
 * **[The low-level Server](low-level-server.md)**: the class `MCPServer` is built on.
  Hand-written schemas, `on_*` handlers, nothing checked for you, and custom JSON-RPC
  methods of your own.
 * **[Pagination](pagination.md)** and **[Middleware](middleware.md)**: two things you
  can *only* do on the low-level `Server`.
 * **[Extensions](extensions.md)** and **[MCP Apps](apps.md)**: the protocol's
  extension surface. Compose extension packages into a server, or write your own.
 A few things you might reasonably look for here live where you'd actually use them
 instead:
 * **Authorization** is under **[Running your server](../run/index.md)** because you
  protect a server where you deploy it.
 * **OAuth**, **identity assertion**, connecting to **multiple servers**, and the
  response **cache** are all under **[Clients](../client/index.md)**.
 * **Multi-round-trip requests** and **Subscriptions** are under
  **[Inside your handler](../handlers/index.md)** because both are things a
  handler *does*.
 * **URI templates** is under **[Servers](../servers/index.md)**, next to Resources.
 * **[Protocol versions](../protocol-versions.md)** and
  **[Deprecated features](../deprecated.md)** each have their own top-level page.
 If you're not sure whether you need this section, you don't.
@@ -0,0 +1,199 @@
 # The low-level Server
 `@mcp.tool()` is a layer. Underneath it is a second server class, `Server`, that speaks raw MCP: you hand it the protocol objects and it puts them on the wire, unchanged.
 `MCPServer` is built on top of it. You drop down when the convenience layer is in the way:
 * You need to emit an **exact** schema (loaded from a file, generated from a database), not one derived from a Python signature.
 * You need full control of the result: `_meta`, `is_error`, every key of `structured_content`.
 * You need to handle a method MCP doesn't define.
 For everything else, stay on `MCPServer`.
 ## The same tool, by hand
 This is the `search_books` tool that **[Tools](../servers/tools.md)** writes in nine lines of `@mcp.tool()`, with the sugar removed:
 ```python title="server.py" hl_lines="23 27 33"
 --8<-- "docs_src/lowlevel/tutorial001.py"
 ```
 Three things changed, and they are the whole low-level API:
 * **Handlers are constructor parameters.** `on_list_tools=` and `on_call_tool=` go into `Server(...)`. There are no decorators down here, and every handler has the same shape: `async (ctx, params) -> result`.
 * **You write the input schema.** `Tool.input_schema` is a plain JSON Schema `dict`. Nobody derives it from type hints, because there are no type hints to derive it from.
 * **You build the result.** `CallToolResult(content=[TextContent(...)])`, by hand. Nothing is wrapped, converted, or inferred from a return annotation.
 `params` is the parsed request: `CallToolRequestParams` gives you `.name` and `.arguments`. `ctx` is a `ServerRequestContext`: `ctx.session` for talking back to the client, `ctx.lifespan_context`, `ctx.request_id`, and `ctx.meta`, the request's inbound `_meta`.
 !!! info
    If you've used FastAPI, you already know this relationship. `MCPServer` is the decorators-and-type-hints layer; `Server` is the Starlette underneath. They are not rivals: `MCPServer` constructs a `Server` and registers handlers exactly like these on it.
 ### Try it
 There is no Inspector for this one: `mcp dev` and `mcp run` only accept an `MCPServer`. The in-memory `Client` doesn't care; it takes a low-level `Server` exactly like it takes an `MCPServer`:
 ```python title="main.py"
 import asyncio
 from mcp import Client
 from server import server
 async def main() -> None:
    async with Client(server) as client:
        result = await client.call_tool("search_books", {"query": "dune", "limit": 5})
        print(result.content)
 asyncio.run(main())
 ```
 ```text
 [TextContent(type='text', text="Found 3 books matching 'dune' (showing up to 5).", annotations=None, meta=None)]
 ```
 The same text the `@mcp.tool()` version produced. Two honest differences:
 * `result.structured_content` is `None`. The high-level server wraps a `-> str` into `{"result": ...}` for you; here nobody builds what you didn't build.
 * `list_tools` returns the schema **you** typed, character for character. The high-level version had `"title": "Query"` on every property and a `"title": "search_booksArguments"` at the root: Pydantic artifacts. Down here, if it's on the wire, you put it there.
 ## Nothing is checked for you
 `MCPServer` rejects a bad argument before your function ever runs, validating the call against the schema it generated (**[Tools](../servers/tools.md)**).
 `Server` does not do that. Your `input_schema` is *advertised* to the client; it is never *applied* to `params.arguments`.
 !!! check
    Call `search_books` without `limit` and your `args["limit"]` raises `KeyError`. The client sees:
    ```text
    MCPError: Internal server error
    ```
    A JSON-RPC error, code `-32603`, with a deliberately generic message: the SDK won't leak your traceback to a remote caller. The model never finds out what it did wrong, so it can't retry. (In a test, `raise_exceptions=True` surfaces the real exception instead; see **[Testing](../get-started/testing.md)**.)
 That generalises. An exception raised from a low-level handler is **always** a protocol error, never an `is_error=True` tool result. If you want the model to read the failure and recover, validate `params.arguments` yourself and return `CallToolResult(content=[TextContent(...)], is_error=True)`. The two kinds of failure are the subject of **[Handling errors](../servers/handling-errors.md)**.
 ## Two tools, one handler
 `on_call_tool` is the single entry point for every tool on the server. You route on `params.name`:
 ```python title="server.py" hl_lines="39-44"
 --8<-- "docs_src/lowlevel/tutorial002.py"
 ```
 * `list_tools` advertises both. `call_tool` dispatches on the name.
 * The `else` branch matters: `Server` will happily forward a `tools/call` for a name you never listed straight into your handler. Raising there turns the call into the same `-32603` as above.
 ## Structured output, by hand
 Declare `output_schema` on the `Tool` and put `structured_content` on the result. Both are yours:
 ```python title="server.py" hl_lines="20-24 37"
 --8<-- "docs_src/lowlevel/tutorial003.py"
 ```
 Call it and the result carries both representations:
 ```json
 {
  "content": [{"type": "text", "text": "Found 3 books matching 'dune'."}],
  "structuredContent": {"matches": 3, "query": "dune"},
  "isError": false,
  "resultType": "complete"
 }
 ```
 The server never compares the two fields. This SDK's `Client` does: return `structured_content` that doesn't satisfy the `output_schema` you declared and `call_tool` raises a `RuntimeError` that starts with `Invalid structured content returned by tool search_books` and goes on to quote the `jsonschema` failure. Promising a schema is cheap; keeping it is on you. The whole ladder of return types and schemas is in **[Structured Output](../servers/structured-output.md)**.
 ## `_meta`: for the application, not the model
 `content` is the part of the answer the model reads. `structured_content` is the same answer as typed data. `_meta` is the third channel: data that rides along with the result for the **client application**, without being part of the answer at all.
 Use it for record IDs, trace IDs, anything your UI needs and your prompt doesn't:
 ```python title="server.py" hl_lines="38"
 --8<-- "docs_src/lowlevel/tutorial004.py"
 ```
 * You construct it as `_meta=`, the wire name. The client reads it back as `result.meta`.
 * Namespace your keys (`bookshop/record_ids`). The `io.modelcontextprotocol/*` keys are reserved by the protocol.
 !!! warning
    `_meta` is a convention between you and the client application, not a guarantee about what reaches
    the model. The host decides what it renders. Never put a secret in any part of a tool result.
 ## Capabilities follow your handlers
 A `Server` advertises exactly the method families you gave it handlers for. The `Bookshop` above passes `on_list_tools` and `on_call_tool` and nothing else, so a client connecting to it sees:
 ```json
 {"tools": {"listChanged": false}}
 ```
 No `resources`, no `prompts`: there is nothing to back them. Pass `on_list_prompts` and `prompts` appears; pass `on_completion` and `completions` appears.
 `MCPServer` always advertises tools, resources and prompts, whether you registered any or not, because its managers always exist. Down here the declaration *is* the constructor call.
 ## The lifespan generic
 `Server` is generic in the type its lifespan yields. Annotate it once and the object is typed everywhere it surfaces:
 ```python title="server.py" hl_lines="25-27 45-46 51"
 --8<-- "docs_src/lowlevel/tutorial005.py"
 ```
 * The lifespan is a `Callable[[Server[Catalog]], AbstractAsyncContextManager[Catalog]]`; `@asynccontextmanager` on an `async` generator gives you exactly that.
 * Whatever it `yield`s becomes `ctx.lifespan_context`, and because the handlers are annotated `ServerRequestContext[Catalog]`, `.search(...)` autocompletes and type-checks.
 * It is entered once when the server starts and exited once when it stops. Startup, teardown, and `MCPServer`'s version of the same idea are in **[Lifespan](../handlers/lifespan.md)**.
 Without a `lifespan=`, `ctx.lifespan_context` is an empty `dict`.
 ## A method of your own
 The constructor covers the methods MCP defines. `add_request_handler` covers everything else:
 ```python title="server.py" hl_lines="35-36 39-40 43-44 48"
 --8<-- "docs_src/lowlevel/tutorial006.py"
 ```
 * The first argument is the method string. Notifications have a twin, `add_notification_handler`.
 * `params_type` is the model the incoming `params` are validated against **before** your handler runs, so custom methods *do* get the validation tools don't. Subclass `RequestParams` so the `_meta` field parses like every other method's.
 * The handler returns a `BaseModel`, a `dict`, or `None`. The SDK serialises it into the JSON-RPC result.
 One honest caveat: the high-level `Client` only has verbs for the methods MCP defines, so there is no `client.reindex()`. A vendor method is for a peer that already knows it exists: a client you also ship, or another service of yours speaking JSON-RPC.
 One method you cannot claim:
 ```text
 ValueError: 'initialize' is handled by the server runner and cannot be overridden;
 use Server.middleware to observe or wrap initialization
 ```
 The handshake belongs to the runner. `server/discover`, `ping`, and every other built-in are yours to replace.
 !!! tip
    `Server.middleware`, mentioned in that error, wraps **every** inbound message, including `initialize`. If what you want is to observe or rewrite traffic rather than answer a new method, start at **[Middleware](middleware.md)**.
 ## The other handlers
 Each of these is one idea you now have the vocabulary for; each has its own page.
 * `on_call_tool`, `on_get_prompt`, and `on_read_resource` may return an `InputRequiredResult` instead of their normal result to pause the call and ask the client for input; see **[Multi-round-trip requests](../handlers/multi-round-trip.md)**. True to this tier, nothing is installed for you: where `MCPServer` seals `requestState` by default, here the `request_state` you set crosses the wire exactly as written until you opt in with `server.middleware.append(RequestStateBoundary(RequestStateSecurity(keys=[...]), default_audience=server.name))`: one line (both names import from `mcp.server.request_state`) for the identical sealing and verification `MCPServer` performs (**[Protecting `requestState`](../handlers/multi-round-trip.md#protecting-requeststate)**).
 * `on_list_resources`, `on_read_resource`, `on_list_prompts`, `on_get_prompt`, `on_completion` are the same `(ctx, params) -> result` shape for the other primitives.
 * `on_subscriptions_listen` serves the 2026-07-28 `subscriptions/listen` stream. Pass a `ListenHandler` built over a `SubscriptionBus` and publish events to the bus from your other handlers; see **[Subscriptions](../handlers/subscriptions.md)** for the full composition.
 * `server.streamable_http_app()` returns the same Starlette app `MCPServer`'s does; deploy it the way **[Running your server](../run/index.md)** deploys any other ASGI app. There is no `server.run(transport=...)` down here: `server.run(read_stream, write_stream, server.create_initialization_options())` drives one connection over a pair of streams, and that one line is the whole story.
 ## Recap
 * The low-level `Server` takes its handlers as `on_*` **constructor parameters**; every handler is `async (ctx, params) -> result`.
 * You write the `input_schema` dict and you build the `CallToolResult`. Nothing is derived, wrapped, or validated for you.
 * An exception in a handler is a `-32603` protocol error. A tool error the model can read is a `CallToolResult` with `is_error=True` that **you** return.
 * `_meta` on the result is addressed to the client application, not the model.
 * `Server[T]` is generic in what its lifespan yields; `ctx.lifespan_context` is a typed `T`.
 * `add_request_handler(method, params_type, handler)` serves any method. `initialize` is reserved.
 * The capabilities a `Server` advertises are derived from which handlers you registered.
 `Client(server)` treated both servers identically because they *are* the same protocol, which is the whole point. The next layer down isn't a class at all: it's **[Middleware](middleware.md)**.
@@ -0,0 +1,108 @@
 # Middleware
 A **middleware** is one async function that wraps every message your server receives.
 You write it as `async (ctx, call_next)` and append it to `server.middleware`. That is the whole API.
 !!! warning
    `Server.middleware` is marked **provisional** in the source. The signature and semantics are
    expected to change before v2 is final. Use it to *observe*: timing, logging, tracing.
    Do not make it the foundation your server stands on.
 This is a **low-level `Server`** feature. `MCPServer` does not expose a middleware list.
 If `Server(name, on_call_tool=...)` is new to you, read **[The low-level Server](low-level-server.md)** first.
 ## A timing middleware
 One server, one tool, one middleware that logs how long each message took:
 ```python title="server.py" hl_lines="40-46 50"
 --8<-- "docs_src/middleware/tutorial001.py"
 ```
 * `ctx` is the same `ServerRequestContext` your handlers receive. `ctx.method` is the raw
  method string; `ctx.params` are the raw params, **before** any validation.
 * `call_next(ctx)` runs the rest of the chain: validation, the handler lookup, your handler.
  Return what it returned and the response is untouched.
 * The `try`/`finally` is deliberate: a handler that raises is still timed, because the failure
  reaches your middleware as the exception out of `call_next`.
 * `server.middleware.append(...)` registers it. The list runs outermost-first, so
  `middleware[0]` is the one closest to the wire.
 ### Try it
 Connect a client, list the tools, call one. Your log has **three** lines:
 ```text
 server/discover took 18.3 ms
 tools/list took 0.1 ms
 tools/call took 0.1 ms
 ```
 You made two calls and got three lines. The first is `server/discover`: the request the
 client sent to set the connection up, before you asked for anything.
 That is the point. Middleware wraps **every** inbound message:
 * The connection setup: `server/discover`, or `initialize` and `notifications/initialized`
  on a legacy session.
 * Every request and every notification. For a notification, `ctx.request_id is None`,
  `call_next(ctx)` returns `None`, and whatever you return is discarded.
 * Even a method the server has no handler for: `call_next` raises the
  `MCPError(-32601, "Method not found")` *through* your middleware on its way to the client.
 ## What you can do inside one
 In increasing order of how much you should hesitate:
 * **Observe.** Time it, count it, log it. The example above.
 * **Refuse.** Raise an `MCPError` *instead of* calling `call_next(ctx)` and that one message is
  answered with a JSON-RPC error. The connection stays up; the next message goes through.
 * **Rewrite.** `ctx` is a dataclass: `await call_next(dataclasses.replace(ctx, params=...))`
  hands the rest of the chain different params than the client sent. Never do this to
  `initialize`: the result the client gets back is built from your rewritten params, but the
  server commits its connection state from the original wire params. The two sides can finish
  the handshake disagreeing about what they negotiated.
 !!! check
    `initialize` is one of the things middleware wraps, and it is the *only* hook you get
    for it. Try to take it over with `add_request_handler` and the SDK refuses:
    ```text
    ValueError: 'initialize' is handled by the server runner and cannot be overridden;
    use Server.middleware to observe or wrap initialization
    ```
 !!! warning
    `initialize` is handled inline: the server reads no further inbound messages until your
    middleware chain returns. Awaiting a server-to-client request (`ctx.session.send_request(...)`,
    an elicitation) while handling `initialize` therefore **deadlocks the connection**: the
    response you are waiting for can never be read. Fire-and-forget notifications are fine.
 ## The one middleware that ships on by default
 The SDK ships exactly one middleware, and it is already on your server's list: the one that
 emits an OpenTelemetry span for every message. You don't append it, and most of the time you
 don't think about it. It is a no-op until you install an exporter, and it has its own page:
 **[OpenTelemetry](../run/opentelemetry.md)**.
 !!! info
    If you have written ASGI middleware, you already know this shape. Starlette's
    `(scope, receive, send)` became `(ctx, call_next)`, and it runs *after* the transport, on
    the decoded message instead of the raw HTTP request. The two compose: Starlette middleware
    on `streamable_http_app()` sees HTTP; this sees MCP.
 ## Recap
 * A middleware is `async (ctx, call_next) -> result`, appended to `server.middleware` on the
  low-level `Server`.
 * It wraps **every** inbound message (`server/discover`, `initialize`, requests, notifications,
  unknown methods) and runs outermost-first.
 * `ctx.request_id is None` is how you tell a notification from a request.
 * Raise instead of calling `call_next` to refuse one message; the connection survives.
 * The SDK's own OpenTelemetry tracing is a middleware too, already on the list. See
  **[OpenTelemetry](../run/opentelemetry.md)**.
 * The whole surface is provisional. Observe with it; don't build on it.
 That is everything that wraps a request. **[Authorization](../run/authorization.md)** is what decides whether the request
 gets to run at all.
@@ -0,0 +1,80 @@
 # Pagination
 Most servers never need this.
 `MCPServer` answers every `list_*` request with everything it has, in one page, `next_cursor=None`. For a few dozen tools, resources or prompts that is the right answer and there is nothing to configure.
 Pagination is for the server whose resource list is really a database: thousands of rows it refuses to serialize in one response. The protocol's answer is a **cursor**: the server returns a page plus an opaque token, and the client sends that token back to get the next page.
 `@mcp.resource()` has no hook for any of that. To page, you write the list handler yourself, on the **[low-level Server](low-level-server.md)**.
 ## A server that pages
 ```python title="server.py" hl_lines="13 16-17"
 --8<-- "docs_src/pagination/tutorial001.py"
 ```
 * On a low-level `Server`, handlers are constructor arguments, not decorators. `on_list_resources` answers every `resources/list` request; that's the whole hookup.
 * Every paged handler is typed `params: PaginatedRequestParams | None`, and the example accepts both. Over a connection, though, the SDK never hands you `None` (a request with no `params` member reaches the handler as the model with its defaults), so the signal that matters is `params.cursor is None`: **start from the top**.
 * You decide what a cursor *is*. Here it's an offset rendered as a string. A timestamp, a primary key, a base64 blob: anything you can mint on the way out and recognise on the way back in.
 * `next_cursor=None` is how you say "that was the last page". There is no count, no total, no `has_more`. `None` is the entire signal.
 !!! tip
    A `PAGE_SIZE` of 10 makes the example readable. Pick yours per endpoint: a list of
    one-line resources can afford a page of 500; a list of fat prompt templates cannot.
    The client has no say in it, and that is by design.
 ### Try it
 `Client(server)` connects to a low-level `Server` in memory exactly as it connects to an `MCPServer`.
 Call `list_resources()` with no arguments. You get ten resources, `book-1` through `book-10`, and `next_cursor` is the string `"10"`.
 Hand it back with `list_resources(cursor="10")` and the first resource is `book-11`, the new `next_cursor` is `"20"`.
 The tenth page comes back with `next_cursor` set to `None`. Done.
 ## The client loop
 Every `list_*` method on `Client` (`list_tools`, `list_resources`, `list_resource_templates`, `list_prompts`) takes a `cursor=` keyword. Draining a paged list is one `while True`:
 ```python title="client.py" hl_lines="27-33"
 --8<-- "docs_src/pagination/tutorial002.py"
 ```
 * `cursor` starts as `None`, so the first request carries no cursor.
 * Extend **before** you look at `next_cursor`: the last page has resources too.
 * `next_cursor is None` is the exit. Anything else goes straight back into `cursor=`, untouched.
 Run its `main()` and it prints `100 resources`: ten pages of ten, stitched together by a loop that never knew there were ten pages.
 This is the same loop **[The Client](../client/index.md)** shows for every `list_*` verb, and it costs nothing against a server that doesn't page: `next_cursor` is `None` on the first response and the loop runs once.
 ## The three rules
 **Cursors are opaque.** A client must never parse, build, or guess one. The only legal source of a cursor is the previous page's `next_cursor`, verbatim.
 **The server picks the page size.** There is no `limit=` in the protocol. If you need a different page size, you change the server.
 **A client that ignores paging still works.** It calls `list_resources()` once, gets the first ten, and never notices the `next_cursor` it threw away. Nothing breaks; it sees less.
 !!! check
    Opaque means opaque. Invent a cursor (`list_resources(cursor="page-2")`) and there is
    nothing the protocol can do for you. This server tries `int("page-2")`, the handler raises,
    and what comes back to the client is:
    ```text
    MCPError(-32603, 'Internal server error', None)
    ```
    A cursor you didn't get from the server is a bug, not a feature request.
 ## Recap
 * `MCPServer` returns everything in one page. Pagination is opt-in, and you opt in on the low-level `Server`.
 * `on_list_resources` (and `on_list_tools`, `on_list_prompts`, `on_list_resource_templates`) receives `PaginatedRequestParams | None`; `params.cursor` is `None` for the first page.
 * You return a page plus `next_cursor`: any string you'll recognise later, or `None` when there is nothing left.
 * The client loop: pass `cursor=`, accumulate, repeat until `next_cursor is None`.
 * Cursors are opaque, the server owns the page size, and a non-paging client still gets page one.
 The rest of the hand-written `Server` API (`on_call_tool`, `input_schema` dicts, `_meta`) is **[The low-level Server](low-level-server.md)**.
@@ -0,0 +1,117 @@
 # Caching hints
 Every result a server returns for `tools/list`, `prompts/list`, `resources/list`, `resources/templates/list`, `resources/read` and `server/discover` carries two fields on the 2026-07-28 protocol: `ttlMs`, how many milliseconds a client may treat the result as fresh, and `cacheScope`, whether a cached result may be shared across users (`"public"`) or belongs to one authorization context (`"private"`).
 The server doesn't cache anything. The fields are a *declaration*: "this tool list is the same for everyone and won't change for a minute." A client (or a gateway in front of you) may then skip the round trip. Honoring the hints is the client's choice; emitting them is the server's job, and the SDK does it for you.
 Out of the box every result says `ttlMs: 0, cacheScope: "private"`: immediately stale, never shared. That is always safe and always conformant. If your lists really are stable and identical for all callers, say so at construction:
 ```python title="server.py" hl_lines="5-8"
 --8<-- "docs_src/caching/tutorial001.py"
 ```
 * The map is keyed by **method name**, and the six cacheable methods are the only legal keys. The parameter is typed `Mapping[CacheableMethod, CacheHint]`, so your editor autocompletes the keys and flags a typo before you run; anything that slips past the type checker raises at construction.
 * A method you don't mention keeps the defaults. The map is a set of overrides, not a manifest.
 * `CacheHint(ttl_ms=5_000)` left `scope` unset, so it stays `"private"`: five seconds of freshness, per caller. Scope and TTL are independent decisions.
 * `"server/discover"` is a legal key too, since the discovery result is cacheable like any list.
 !!! warning
    `cacheScope: "public"` means *anyone* may be served your cached response. A shared
    gateway will happily hand one user's result to another, even when the request was
    authenticated. Mark a result `"public"` only when it is identical for every caller, and
    never use `cacheScope` as access control: it is a label, not a lock.
 ## Per-handler override
 On the low-level `Server`, handlers build their results by hand, and `ttl_ms` / `cache_scope` are just fields on the result models. A handler that sets them explicitly always wins over the constructor map, field by field:
 ```python title="server.py" hl_lines="11 17"
 --8<-- "docs_src/caching/tutorial002.py"
 ```
 The handler said `ttl_ms=1_000` and nothing about scope. On the wire: `ttlMs: 1000` (the handler's, not the map's `60_000`) and `cacheScope: "public"` (the map's, because the handler left it unset). Explicit beats configured, and configured beats default. This holds per field, so a handler can pin one field and leave the other to the server-wide policy.
 This is also the escape hatch for dynamics the constructor can't know: a handler that filters `resources/read` per user can return `cache_scope="private"` for one URI from an otherwise-public server.
 One caveat on paginated lists: the protocol requires the **same `cacheScope` on every page** of one list. The constructor map satisfies that by construction, since it's keyed by method, not by page. But a handler that overrides the scope itself owns that consistency: override it on *every* page, never only when a cursor is present, or page one and page two will disagree.
 ## What the client sees
 On a 2026-07-28 session, `Client` honors the hints for you: it has a built-in response cache, on by default. A result that arrives carrying a `ttlMs` is stored, and an identical call within that TTL is served from the cache with no round trip. A result that carries *no* hint is not cached: hint-less results get `CacheConfig.default_ttl_ms`, which defaults to `0` (immediately stale), so a server that declares nothing sees exactly the call-for-call traffic it always did.
 ```python title="client.py" hl_lines="34 36 39"
 --8<-- "docs_src/caching/tutorial003.py"
 ```
 Four calls, three fetches. The second call found a fresh entry and never reached the server; advancing the (injected) clock past the TTL made the third fetch again; the fourth said `cache_mode="refresh"`. That kwarg exists on the five caching verbs (`list_tools`, `list_prompts`, `list_resources`, `list_resource_templates`, `read_resource`):
 * `"use"` (the default) serves a fresh entry if there is one, and stores the fetch if not.
 * `"refresh"` never serves: it fetches and stores the result, replacing whatever was cached.
 * `"bypass"` makes the round trip without touching the cache at all: no read, no write.
 One rule sits above `"use"`: **calls carrying `meta` always reach the server.** A request with `meta` set (a progress token, tracing fields) expects a wire request, so under `cache_mode="use"` it is treated as `"refresh"`: the cache read is skipped, and the fetched result still replaces the cached entry. `"bypass"` and an explicit `"refresh"` behave as they always do.
 To turn caching off entirely, construct with `Client(server, cache=False)`: every call is a round trip again, and `cache_mode`, while still accepted, does nothing.
 Scope is honored automatically too: `"private"` entries are keyed to the cache's *partition* (below), while `"public"` ones may opt into wider sharing. And **notifications beat TTL** for the exact entries they name: a `list_changed` notification evicts the matching cached listing, and `resources/updated` evicts the cached read stored under exactly its URI, however fresh they were. On a 2026-07-28 connection those notifications arrive on a `subscriptions/listen` stream you open with `client.listen(...)`, and eviction completes before your watcher sees the event; **[Subscriptions](subscriptions.md)** is that page.
 One caveat on `resources/updated`: eviction is exact-URI only. The store contract has no enumerate or scan operation (same as the reference TypeScript implementation), so a notification carrying a *sub*-resource URI does not evict a cached read of its parent. If your server signals sub-resources this way, refetch the parent with `cache_mode="refresh"`.
 ### Configuring it: `CacheConfig`
 ```python
 from mcp.client import CacheConfig
 client = Client("https://api.example.com/mcp", cache=CacheConfig(default_ttl_ms=5_000))
 ```
 * `store`: where entries live. The default is a fresh in-memory store per client; pass your own `ResponseCacheStore` implementation (Redis-backed, say) to share a cache across clients or processes. The contract types (`ResponseCacheStore`, `CacheKey`, `CacheEntry`, and the default `InMemoryResponseCacheStore`) are importable from `mcp.client`. A lookup may issue up to two sequential store `get`s (the private arm, then the public one), so size a remote store's latency expectations accordingly. A custom store **requires** an explicit `partition`.
 * `partition`: the authorization-context label that keeps one principal's `"private"` entries from being served to another within a shared store.
 * `target_id`: explicit server identity, for custom transports and in-process servers (below).
 * `default_ttl_ms`: TTL applied to results that carry no `ttlMs` hint. The default `0` leaves hint-less results uncached.
 * `share_public`: serve server-asserted-`"public"` entries across partitions (below). Off by default.
 * `clock`: the wall-clock source, in epoch seconds. Inject one, as the example above does, and expiry tests need no sleeping.
 !!! warning "Partition = verified principal"
    Derive `partition` from a **verified credential**, such as a validated token's subject. Never derive it from request-supplied data, and never from the server URL (server identity is a separate key axis). The SDK is a library with no authentication of its own: the trust anchor is whoever constructs the `CacheConfig`, which is the deployment, not the tenant. A multi-tenant gateway mints one `CacheConfig` per authenticated principal.
    The partition is also fixed for the `Client`'s lifetime. If the connection's authorization context changes mid-session (a re-authentication as a different principal, say), the cache does not follow; construct a new `Client` for the new principal.
 Cache keys also carry the **server's identity**: the URL string you dialed, with any `user:pass@` userinfo stripped and otherwise byte-exact. No case folding, no query reordering, no trailing-slash cleanup. Under-normalizing only costs sharing, while over-normalizing could merge two tenants (`?tenant=a` vs `?tenant=b`), so superficially different URLs simply don't share entries. When there is no URL (an in-process server, or a `Transport` instance), the client gets a random per-instance identity instead; set `CacheConfig.target_id` to name the server (with a custom store this is required, and construction says so). The identity is sha256-hashed before it enters key material, so a URL carrying secrets in its query string never appears in store keys. Don't log the pre-hash form yourself, either.
 !!! warning "`share_public` trusts the server, fleet-wide"
    By default even `"public"` entries stay within their partition. `share_public=True` serves entries the server marked `cacheScope: "public"` to **every** partition using the store, trusting the server's classification on behalf of all of them. A server that stamps `"public"` on per-tenant data (by bug or by malice) then leaks one tenant's response to the others. The flag is deliberately constructor-level only: the per-call `cache_mode` can narrow caching, but nothing per-call can widen sharing.
 ### What the cache never does
 * **Session-tier calls bypass it.** `client.session.list_tools()` and friends always make the round trip; the cache lives on the `Client` verbs.
 * **`server/discover` stays out of it.** The discover result is delivered once, at connect, and never enters the response cache, even when it carries a `ttlMs`. If you persist one yourself to skip the reconnect probe ([`prior_discover`](../protocol-versions.md#reconnecting-with-prior_discover)), its freshness is your bookkeeping: `DiscoverResult` carries `ttl_ms` and `cache_scope`, already parsed, for exactly that purpose.
 * **Continuation pages are never cached.** Only cursor-less calls participate. A continuation page rejected for an expired cursor does *evict* the cached listing, because the listing changed under it.
 * **Multi-round-trip reads are never cached.** A `read_resource` seeded with `input_responses`/`request_state`, or one that resolves through input rounds, never enters the cache (a spec MUST).
 * **Notification eviction needs notifications.** Eviction is only as good as the transport's delivery, and the modern in-process path (`Client(server)` with the default `mode="auto"`) does not deliver standalone notifications today.
 * **Eviction is eventual, not instantaneous.** Wire-path notifications are dispatched from spawned tasks, so a call racing a notification's arrival may be served the pre-eviction entry once more; the window is bounded by dispatch latency, and the eviction still lands.
 * **No stale-if-error.** An expired entry is never served because the refetch failed; the error propagates.
 * **No early re-fetch.** A stored entry is served until its TTL expires and the next call after that pays the round trip; nothing refreshes in the background.
 * **No coalescing.** Two concurrent identical calls are two fetches.
 * **No TTL beyond 24 hours.** A larger `ttlMs`, whether server-sent or configured, is clamped down on store (`mcp.client.caching.MAX_TTL_MS`), bounding how long any entry, however generously hinted, can be served.
 * On a **shared store**, clients race each other. Each client drops its own write when an eviction overtook the fetch in flight, but a *co-tenant* client can still write back an entry that an eviction it never saw had removed; and that race bookkeeping is itself bounded: past 4096 tracked keys the oldest key's guard is dropped first. Both windows are accepted, and closed by the TTL cap above.
 * **No serving across protocol eras.** Entries are scoped to the negotiated protocol version: on a shared persistent store, a session never serves an entry written under a different negotiated version (the same listing genuinely differs by era, since the SDK strips the 2026 fields for older sessions). Eviction likewise touches only the current era's entries; another era's entries simply age out by TTL.
 ### Reading the hints yourself
 The hints are also plain fields on every cacheable result (`result.ttl_ms` and `result.cache_scope`, already parsed), in case you want to layer your own bookkeeping on top of (or instead of) the built-in cache.
 Against an **older server** (pre-2026 protocol), the fields are simply absent from the wire, and the models show their conservative defaults: `ttl_ms == 0` and `cache_scope == "private"`, stale and unshared, the right assumption for a server that declared nothing. The cache treats a legacy session the same way: hints are never consulted there (whatever keys appear on the wire), only `default_ttl_ms` applies, and its default of `0` caches nothing, so a pre-2026 connection behaves exactly as it did before the cache existed. If you need to distinguish "the server said 0" from "the server said nothing", check `"ttl_ms" in result.model_fields_set`: it's only set when the field actually arrived.
 ## Older clients
 Clients on pre-2026 protocol versions never see either field; the SDK strips them at serialization for those connections. Configure your hints once; there is nothing version-specific to write.
 ## Recap
 * Six methods carry `ttlMs`/`cacheScope`; the SDK defaults them to `0`/`"private"`, stale and unshared, always safe.
 * `cache_hints={method: CacheHint(...)}` at construction (both `MCPServer` and `Server`) sets server-wide values per method.
 * A handler that sets the fields on its result overrides the map, per field.
 * `"public"` is a promise that the result is identical for every caller. It is not access control.
 * `Client` honors the hints automatically: its response cache is on by default, serves fresh entries instead of refetching, and caches nothing for servers (or sessions) that provide no hints.
 * Per call, `cache_mode="refresh"` refetches and `"bypass"` skips the cache; `cache=False` at construction turns it off entirely.
@@ -0,0 +1,149 @@
 # Client callbacks
 Nearly every request in MCP goes one way: client to server.
 A server can also ask the **client** for things: to put a question to the user, to sample the user's model, to list the user's workspace folders. You answer those requests by passing **callbacks** to `Client(...)`.
 ## A server that asks
 Here is a server whose tool can't finish on its own:
 ```python title="server.py" hl_lines="16"
 --8<-- "docs_src/client_callbacks/tutorial001.py"
 ```
 * `ctx.elicit(...)` sends an `elicitation/create` request **to the client** and waits.
 * The tool doesn't return until somebody (a person in a form, or your code) supplies a `name`.
 That is the server half, and the **[Elicitation](../handlers/elicitation.md)** page owns it. This page is the other end of the wire.
 ## The elicitation callback
 ```python title="client.py" hl_lines="7-11 17-18"
 --8<-- "docs_src/client_callbacks/tutorial002.py"
 ```
 * An elicitation callback is `async (context, params) -> ElicitResult`.
 * `params.message` is the question. `params.requested_schema` is the JSON Schema of the answer the server wants. A real client renders a form from it; this one auto-fills.
 * You return `ElicitResult(action="accept", content={...})`, or `action="decline"`, or `action="cancel"`. The only other option is `ErrorData(...)`, which refuses the request and fails the whole call.
 * `context` is a `ClientRequestContext`: the live `session`, the server's `request_id`, and any `meta` it attached.
 !!! tip
    `params` is a union of the two elicitation modes. Here `params.mode` is `"form"`; a `"url"` request
    carries `params.url` instead of a schema. One callback handles both; branch on `params.mode`.
    **[Elicitation](../handlers/elicitation.md)** shows the full pattern.
 ### Try it
 Call `issue_card` and watch both ends.
 Your callback receives the server's question, already parsed:
 ```python
 params.mode              # 'form'
 params.message           # 'What name should go on the card?'
 params.requested_schema  # {'properties': {'name': {'title': 'Name', 'type': 'string'}},
                         #  'required': ['name'], 'title': 'CardHolder', 'type': 'object'}
 ```
 It answers, `ctx.elicit(...)` resumes inside the tool, and the tool finishes:
 ```python
 result.content  # [TextContent(type='text', text='Card issued to Ada Lovelace.')]
 ```
 One `tools/call` from you, one `elicitation/create` back from the server, answered by your function, all inside a single tool call.
 !!! info
    `mode="legacy"` on line 17 is doing real work. By default `Client(...)` negotiates the modern
    protocol path, and that path has no back-channel for server-to-client requests: `ctx.elicit`
    fails before your callback ever runs. The transport doesn't decide that; the negotiated
    protocol does, in-memory and over a URL alike. Pin `mode="legacy"` whenever your client has
    to answer one; every test behind this page does. **[Protocol versions](../protocol-versions.md)** has the whole story.
    On a 2026-07-28 session the callback isn't dead, it's fed differently: when a tool returns an
    `InputRequiredResult` carrying an `ElicitRequest`, `Client` dispatches that entry to the same
    `elicitation_callback` and retries the call for you. That flow is **[Multi-round-trip requests](../handlers/multi-round-trip.md)**.
 ## A callback is a capability
 You never told the server that your client can answer elicitation requests. The SDK did.
 When a client connects it declares its `capabilities`, the mirror image of the server's. You don't write that object. **Registering a callback is the declaration.**
 | you pass | the client declares |
 | --- | --- |
 | `elicitation_callback=` | `"elicitation": {"form": {}, "url": {}}` |
 | `sampling_callback=` | `"sampling": {}` |
 | `list_roots_callback=` | `"roots": {"listChanged": true}` |
 | none of them | `{}` |
 Sampling sub-capabilities are the one refinement: pass `sampling_capabilities=SamplingCapability(tools=SamplingToolsCapability())` alongside `sampling_callback` when your sampler handles the `tools` / `tool_choice` parameters. Servers must see `sampling.tools` declared before they can send them.
 `logging_callback` and `message_handler` are not in the table. They handle notifications, and notifications need no capability.
 The server reads the declaration back with `ctx.session.check_client_capability(...)`. Add a tool that does:
 ```python title="server.py" hl_lines="23-31"
 --8<-- "docs_src/client_callbacks/tutorial003.py"
 ```
 Connect with only `elicitation_callback` and call it:
 ```python
 result.structured_content  # {'result': ['elicitation']}
 ```
 Pass all three callbacks and you get `['elicitation', 'sampling', 'roots']`. Pass none and you get `[]`.
 !!! check
    Now do the wrong thing: connect **without** `elicitation_callback` and call `issue_card` anyway.
    The server's `elicitation/create` request still reaches your client, and the SDK answers it for
    you, with an error, because you never said you could handle it. That error sinks the whole call.
    `call_tool` doesn't return an `is_error` result; it raises:
    ```text
    MCPError: Elicitation not supported
    ```
    That is a protocol error (`-32600`, *invalid request*), not a tool error: there is nothing for
    the model to read and retry. It's why `client_features` is worth having: a well-behaved server
    checks before it asks.
 ## The deprecated pair
 `sampling_callback` answers `sampling/createMessage`: the server asking *your* model to complete something. `list_roots_callback` answers `roots/list`: the server asking which directories it may work in.
 Both work. Both follow the rule above. And both serve RPCs the **2026-07-28 spec removes**: a modern server doesn't call back into your client mid-request, it hands the request back to you as part of the tool result (**[Multi-round-trip requests](../handlers/multi-round-trip.md)**). The callbacks themselves are not dead. When an `InputRequiredResult` carries a `CreateMessageRequest` or a `ListRootsRequest`, `Client`'s auto-loop dispatches it to the same `sampling_callback` or `list_roots_callback` you registered here. The whole list is in **[Deprecated features](../deprecated.md)**.
 You still need the callbacks to talk to servers that haven't moved. The signatures:
 ```python title="client.py"
 --8<-- "docs_src/client_callbacks/tutorial004.py"
 ```
 * A sampling callback receives the full `CreateMessageRequestParams` (`messages`, `model_preferences`, `max_tokens`) and returns a `CreateMessageResult`. *You* run the model, however you like; the SDK only carries the request.
 * A roots callback takes no params at all and returns a `ListRootsResult`.
 * Either one may return `ErrorData(...)` instead, to refuse.
 Pass them to `Client(...)` exactly like `elicitation_callback`.
 ## The notification callbacks
 Two more. Neither declares anything.
 `logging_callback` receives every `notifications/message` a server sends, as `LoggingMessageNotificationParams` (`level`, `logger`, `data`). Protocol logging is itself deprecated by the 2026-07-28 spec (**[Logging](../handlers/logging.md)** has what to do instead), so this callback exists for the servers that still emit it.
 `message_handler` is the catch-all: every server notification reaches it (as well as its specific callback), and on a stream-backed transport so does every transport-level `Exception`. The one pattern worth knowing is `if isinstance(message, Exception): raise message`, so a broken connection fails loudly instead of vanishing.
 ## Recap
 * A server can send requests to the client. You answer them with callbacks passed to `Client(...)`.
 * The elicitation callback is the current one: `async (context, params) -> ElicitResult`, one function for both form and URL mode.
 * **Registering a callback is declaring the capability.** Without it, the SDK refuses the server's request on your behalf and the whole call fails with `MCPError`.
 * A server finds out before asking with `ctx.session.check_client_capability(...)`.
 * `sampling_callback` and `list_roots_callback` work the same way but serve deprecated features; modern servers use multi-round-trip requests instead.
 * `logging_callback` and `message_handler` receive notifications. They declare nothing.
 The first argument to `Client(...)` is a transport object. **[Client transports](transports.md)** covers every kind.
@@ -0,0 +1,146 @@
 # Identity assertion
 An ordinary OAuth provider (**[OAuth clients](oauth-clients.md)**) starts by asking the MCP server a question: *which authorization server do you trust?* It follows the answer wherever it points, and then either a person signs in or a pre-shared secret stands in for one.
 An enterprise wants neither decided per server. It already runs an identity provider (Okta, Microsoft Entra ID, your own); the user already signed in to it this morning; and it is the one place the security team wants to decide who may reach what. [SEP-990](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/990), the **Enterprise-Managed Authorization** extension, moves the decision there. The IdP signs a short-lived JWT, an **Identity Assertion JWT Authorization Grant**, the **ID-JAG**: a statement that *this user*, through *this client*, may reach *this MCP server*. The client trades it for an ordinary access token. No browser, no consent screen, no dynamic registration.
 This page is both ends of that trade. The MCP server itself never changes: it is still the resource server from **[Authorization](../run/authorization.md)**, checking whatever token shows up.
 ## Two token requests
 Two different authorities are in play, and naming them apart is most of understanding this page. The **enterprise IdP** is your organization's identity provider: it knows who the employee is, it is where policy lives, and it issues the ID-JAG. The SDK never talks to it. The **MCP authorization server** is the same party it was in **[Authorization](../run/authorization.md)**: the issuer named in the MCP server's metadata, the thing that mints the tokens that MCP server accepts. In an ordinary OAuth flow, those two roles are usually one box. Here they are two, and the whole grant is the second agreeing to trust the first.
 The client makes one token request to each.
 1. **To the enterprise IdP.** The client trades the user's sign-in (their OpenID Connect ID token) for the ID-JAG. This is an [RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693) token exchange, it is entirely your IdP's API, and **the SDK does not make it**. You do, inside one async callback. It is also where the policy decision happens: an IdP that says no never issues the ID-JAG, and there is nothing to present.
 2. **To the MCP authorization server.** The client presents the ID-JAG under the [RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523) `jwt-bearer` grant (`grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer`, the ID-JAG as `assertion`) and receives the access token. **This is the request the SDK makes**, and accepting it is the one thing this page adds to an authorization server.
 Everything below is the second request: the client that sends it and the authorization server that answers it.
 ## The client
 **`IdentityAssertionOAuthProvider`** lives in `mcp.client.auth.extensions.identity_assertion`. Like every provider in **[OAuth clients](oauth-clients.md)** it is an `httpx.Auth`: construct one, put it on `auth=`, hand the `httpx.AsyncClient` to the transport.
 ```python title="client.py" hl_lines="49-50 53-61"
 --8<-- "docs_src/identity_assertion/tutorial001.py"
 ```
 Read it from the bottom.
 * `main()` is the standard OAuth-client `main()` (**[OAuth clients](oauth-clients.md)**), unchanged line for line. That is the point: once the provider exists, nothing downstream knows which grant produced the token.
 * The provider takes what the other providers cannot discover: a `client_id` and `client_secret` somebody **pre-registered** with the authorization server, that authorization server's `issuer`, and `assertion_provider`, an async callback that returns a fresh ID-JAG on demand.
 * `storage` is the same `TokenStorage` protocol. Only the two token methods are ever called; there is no dynamic registration here, so there is no `client_info` to remember.
 ### The assertion provider
 `fetch_id_jag(audience, resource)` is the only code you write. It is awaited once per token exchange, never at construction, and only *after* the authorization server's metadata has been fetched and validated, so a misconfigured issuer never leaks an assertion. Its two arguments are two of the claims the ID-JAG must be minted with: `audience` is the authorization server's issuer (the ID-JAG `aud`) and `resource` is the MCP server's canonical identifier (the ID-JAG `resource`). The third is one you already hold: the ID-JAG's `client_id` claim must name the `client_id` you gave the provider, or the authorization server refuses the exchange.
 `idp_issue_id_jag` above it is **not your code**. It stands in for the identity provider, signing the assertion in-process so the file is complete and you can read every claim an ID-JAG carries. A real `fetch_id_jag` makes the first token request of the previous section instead: an [RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693) token exchange against your IdP, defined by the Identity Assertion JWT Authorization Grant draft that [SEP-990](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/990) profiles. The signed-in user's ID token goes in as the `subject_token`, the `requested_token_type` is the ID-JAG's own URN (`urn:ietf:params:oauth:token-type:id-jag`), `audience` and `resource` pass straight through, and the response carries the ID-JAG. That exchange, under those names, is what to look for in your IdP's documentation.
 !!! tip
    A fresh ID-JAG is requested for every exchange, and that is the point: it is a single-use,
    minutes-lived grant, and the authorization server on this page refuses to accept the same one
    twice. Do not cache it. The access token it buys you is the thing that gets reused.
 ### The issuer is configuration
 Here is the inversion. `OAuthClientProvider` asks the resource server which authorization server to use and follows the answer wherever it points. This provider refuses to: `issuer` is required, the [RFC 8414](https://datatracker.ietf.org/doc/html/rfc8414) metadata is fetched from that issuer's own well-known path, the token endpoint must be on that issuer's origin, and the resource server is never asked anything.
 The extension does not demand this; it is a deliberately stricter choice. This client carries two things worth stealing, a pre-registered secret and an audience-bound assertion, and a client that let a compromised MCP server steer it to an attacker's authorization server would post both to it. Pinning the issuer at construction deletes that conversation.
 !!! warning
    The configured `issuer` is compared to the metadata document's `issuer` field by RFC 8414 §3.3
    simple string comparison: character for character, trailing slash included, no normalization.
    Do not guess it. Fetch `/.well-known/oauth-authorization-server` from your authorization server
    and copy the `issuer` value it returns. For the authorization server on this page that is
    `https://auth.example.com/`, with the slash, because its issuer was built from a pydantic URL
    object. A mismatch stops the flow at `OAuthFlowError: Authorization server metadata issuer
    mismatch` before a single credential or assertion is sent.
 ### A confidential client
 `client_secret` is required; the constructor raises `ValueError` without one. The IETF profile underneath [SEP-990](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/990) reserves this grant for confidential clients, SEP-990 requires the client to authenticate, and this SDK enforces both by insisting on a shared secret. `token_endpoint_auth_method` picks where it travels: `client_secret_post` (the default, in the form body) or `client_secret_basic` (an HTTP Basic header). The profile also permits `private_key_jwt`; this provider does not support it.
 !!! tip
    Read `client_secret` from the environment or a secret manager, never from source control.
 ### What the provider does for you
 The first request goes out unauthenticated, and the server's `401` starts the flow.
 1. **Discovery.** It fetches the authorization server metadata from the configured issuer's [RFC 8414](https://datatracker.ietf.org/doc/html/rfc8414) well-known path, checks the document's `issuer` matches, and checks the token endpoint is on the issuer's origin.
 2. **The assertion.** It awaits your `assertion_provider`.
 3. **Exchange.** It POSTs the `jwt-bearer` grant to the token endpoint, stores the `OAuthToken`, and replays your original request with `Authorization: Bearer ...`.
 A `403` whose `WWW-Authenticate` names `insufficient_scope` runs steps 2 and 3 again with the union of your `scope` and the challenged one. (`scope` is only ever a request; this page's authorization server grants what the ID-JAG says and nothing else.) There is no refresh token anywhere in this: when the access token expires, the next `401` mints a fresh ID-JAG and exchanges again, and *that* is the lever the IdP holds. Failures are the same two exceptions as the rest of **[OAuth clients](oauth-clients.md)**: `OAuthFlowError` for discovery and validation, its subclass `OAuthTokenError` when the token endpoint says no.
 ## The authorization server
 Most of the time you stop here. The MCP authorization server is somebody else's product, accepting ID-JAGs is its configuration to turn on, and the SDK's half of [SEP-990](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/990) is the client above.
 The SDK can also *be* the authorization server: `create_auth_routes` returns the authorization server's routes as a list any Starlette app can mount, which is how `examples/servers/simple-auth/` in the repository runs one. SEP-990 adds one flag and one method to that surface:
 ```python title="auth_server.py" hl_lines="48-50 105-107"
 --8<-- "docs_src/identity_assertion/tutorial002.py"
 ```
 * `identity_assertion_enabled=True` gates everything. Off, which is the default, `/token` answers this grant with `unsupported_grant_type` even if you implemented the hook, and the metadata does not mention it. On, the metadata gains the `jwt-bearer` grant type and lists `urn:ietf:params:oauth:grant-profile:id-jag` in `authorization_grant_profiles_supported`, the field the extension uses to advertise support. (This SDK's client never reads it: it is provisioned for one issuer and simply asks.)
 * **`exchange_identity_assertion`** is the hook. Before it runs, the SDK has authenticated the client, refused public clients, and refused clients whose registration does not list the grant. You get an `IdentityAssertionParams` (the raw `assertion`, the requested `scopes` and `resource`) and return a plain `OAuthToken`.
 * Dynamic client registration refuses this grant unconditionally, so `get_client` here serves a hand-provisioned client. An ID-JAG client cannot register itself into existence.
 * Half the class is refusals. `OAuthAuthorizationServerProvider` is the *whole* authorization server, so it also asks for the authorization-code flow; a server that signs users in as well implements those for real, and this one has exactly one door.
 !!! warning
    The SDK never decodes the assertion: only your deployment knows which IdP it trusts and which
    keys that IdP publishes, so everything inside `exchange_identity_assertion` is load-bearing.
    Verify the signature against the IdP's published keys (its JWKS; the shared secret here is the
    demo's), and `iss` and `exp`, per [RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523) §3. Require the JWT header's `typ` to be
    `oauth-id-jag+jwt`, the profile's guard against some other JWT being replayed as a grant.
    Require `aud` to be your own issuer. Require the ID-JAG's `client_id` claim to equal the client
    the handler authenticated, and its `resource` claim to name a resource you actually serve.
    Track `jti` until the assertion's `exp` so it is accepted once. And take the granted scopes
    and, above all, the issued token's `resource` from the validated ID-JAG, never from the
    request: `params.resource` is whatever the client typed. The full processing rules are in the
    [Enterprise-Managed Authorization specification](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization).
 Reject a bad assertion with `TokenError("invalid_grant", ...)`. The other error code in this flow is `invalid_target`: an ID-JAG that names a resource you do not serve is refused with it, which is what stops this server minting tokens for somebody else's. And the granted scopes come from the ID-JAG's `scope` claim (an assertion without one is refused too); yours might map the user's groups instead.
 And notice what the returned `OAuthToken` does not carry: a refresh token. The IdP decides how long this user keeps access by deciding whether to issue the next ID-JAG. A refresh token minted here would quietly hand that decision back.
 !!! info
    A server that still embeds its authorization server with `auth_server_provider=` reaches the same
    code through `AuthSettings(identity_assertion_enabled=True)`. **[Authorization](../run/authorization.md)** explains why new
    servers should not start there.
 !!! check
    Wire the two files on this page together and the whole grant is one `POST /token`:
    ```text
    grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
    assertion=eyJhbGciOiJIUzI1NiIsInR5cCI6Im9hdXRoLWlkLWphZytqd3QifQ...
    client_id=finance-agent
    resource=http://localhost:8001/mcp
    scope=notes:read
    client_secret=finance-agent-secret
    HTTP/1.1 200 OK
    {"access_token": "mcp_...", "token_type": "Bearer", "expires_in": 300, "scope": "notes:read"}
    ```
    No `/authorize`, no `/register`, no protected-resource-metadata fetch. The only requests on the
    wire are the one that drew the `401`, the well-known fetch, this exchange, and then ordinary
    MCP traffic with the bearer attached. And the `sub` your validator read out of the ID-JAG is
    exactly what `get_access_token().subject` reports inside a tool.
 ### Try it
 `examples/stories/identity_assertion/` in the SDK repository is this page running for real: the same `exchange_identity_assertion` validator, an MCP server gated on its tokens, a stand-in IdP, and the client, in one self-checking program. `uv run python -m stories.identity_assertion.client --http` runs the whole exchange and asserts that the user the IdP named is the user the tool sees.
 ## Recap
 * [SEP-990](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/990) lets the enterprise identity provider, not the end user, decide which MCP servers a client may reach. The IdP signs that decision into an **ID-JAG**.
 * Obtaining the ID-JAG is an [RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693) token exchange against *your IdP*, and the SDK does not make it. Presenting it to the MCP authorization server is the [RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523) `jwt-bearer` grant, and the SDK does both sides of that.
 * `IdentityAssertionOAuthProvider` is another `httpx.Auth`: a pre-registered confidential client, a pinned `issuer`, and one `assertion_provider(audience, resource)` callback. No browser, no registration, no refresh token.
 * The authorization server is never discovered from the resource server. Configure `issuer` to exactly the string its metadata document serves; the comparison is character for character.
 * Server side, `identity_assertion_enabled=True` plus `exchange_identity_assertion`. The SDK authenticates the client and gates the grant; validating the ID-JAG is entirely yours, and the issued token is bound to the ID-JAG's `resource`, not the request's.
 The one party this page never touched is the MCP server. What it does with the token you just minted, it was already doing in **[Authorization](../run/authorization.md)**.
@@ -0,0 +1,212 @@
 # The Client
 A **`Client`** is how a Python program talks to an MCP server.
 It is one object with one lifecycle: construct it, enter `async with`, call methods. Every protocol verb (list the tools, call one, read a resource, render a prompt) is an `async` method on it that returns a typed result.
 ## Your first client
 ```python title="client.py" hl_lines="14-18"
 --8<-- "docs_src/client/tutorial001.py"
 ```
 The server at the top is only there so you have something to connect to. The client is the five highlighted lines.
 * `Client(mcp)` is given the **server object itself**. That is the in-memory transport: no subprocess, no port, no HTTP. It is how every example on this page, and every test you write, connects.
 * `async with` is the **lifecycle**. Entering it connects and negotiates; leaving it disconnects. There is no `connect()` / `close()` pair, and a `Client` cannot be reused after the block ends.
 * Inside the block the connection facts are already there as plain properties.
 ### What you can pass to `Client`
 `Client` takes one positional argument and resolves the transport from its type:
 * An `MCPServer` (or low-level `Server`) instance: connected **in-process**.
 * A URL string (`Client("http://localhost:8000/mcp")`): Streamable HTTP, the production path.
 * A **transport**: anything you can `async with ... as (read, write)`, such as `stdio_client(...)` wrapping a subprocess.
 Everything else on this page is identical across all three. Headers, subprocesses, timeouts, and the `Transport` protocol get their own page: **[Client transports](transports.md)**.
 ### What's on a connected client
 Four read-only properties, populated the moment you enter the block:
 * `client.server_info`: the server's identity. `server_info.name` here is `"Bookshop"`, `server_info.version` is whatever the server reports.
 * `client.server_capabilities`: what the server can do (`tools`, `resources`, `prompts`, `completions`, ...). A capability the server doesn't have is `None`.
 * `client.protocol_version`: the protocol version the two sides agreed on. Here it is `"2026-07-28"`.
 * `client.instructions`: the server's `instructions=` string, or `None` if it didn't set one.
 You never picked a protocol version. By default the `Client` probes the server and falls back to the classic handshake on older ones, so one client works against any era of server. When you need to control that, **[Protocol versions](../protocol-versions.md)** has the whole story.
 !!! tip
    `client.session` is the underlying `ClientSession`, the low-level escape hatch.
    You won't need it for anything on this page.
 ## Listing tools
 ```python title="client.py" hl_lines="15-20"
 --8<-- "docs_src/client/tutorial002.py"
 ```
 `list_tools()` returns a `ListToolsResult`; the tools are in `.tools`. Each one is the complete definition a host would hand to a model:
 ```python
 tool.name          # 'search_books'
 tool.title         # 'Search the catalog'
 tool.description   # 'Search the catalog by title or author.'
 ```
 and `tool.input_schema` is the JSON Schema the server derived from the function's type hints:
 ```json
 {
  "type": "object",
  "properties": {
    "query": {"title": "Query", "type": "string"},
    "limit": {"default": 10, "title": "Limit", "type": "integer"}
  },
  "required": ["query"],
  "title": "search_booksArguments"
 }
 ```
 That schema is everything a UI needs to render an argument form, and everything a model needs to produce valid arguments.
 !!! tip
    `title` is optional, so a UI showing tools to a human has to pick: the `title` if there is one,
    the `name` if not. `from mcp.shared.metadata_utils import get_display_name` does exactly that,
    for tools, resources, resource templates and prompts.
 ## Calling a tool
 `call_tool(name, arguments)` runs the tool and gives you back a `CallToolResult`.
 ```python title="client.py" hl_lines="26-33"
 --8<-- "docs_src/client/tutorial003.py"
 ```
 The server's `lookup_book` returns a Pydantic `Book`. Here is what the client sees:
 ```python
 result.content             # [TextContent(type='text', text='{\n  "title": "Dune",\n  "author": "Frank Herbert",\n  "year": 1965\n}')]
 result.structured_content  # {'title': 'Dune', 'author': 'Frank Herbert', 'year': 1965}
 result.is_error            # False
 ```
 One return value, three things to read. Each has a different consumer.
 ### `content`: what the model reads
 `content` is a `list` of **content blocks**, and a content block is a union: `TextContent`, `ImageContent`, `AudioContent`, `ResourceLink`, or `EmbeddedResource`. A tool can return several, of different kinds.
 That is why `main` narrows with `isinstance(block, TextContent)` before touching `block.text`. Notice there is no `.text` outside the `isinstance`: the type checker won't allow it, because `ImageContent` has `.data`, not `.text`. The union is honest about what a tool is allowed to send you; your code should be too.
 ### `structured_content`: what your application reads
 `structured_content` is the tool's return value as JSON, matching the tool's declared `output_schema`. No string parsing, no guessing.
 When both are present they say the same thing twice on purpose: `content` is for a model, `structured_content` is for code. Where the structured half comes from, and how to control it, is the **[Structured Output](../servers/structured-output.md)** page.
 ### `is_error`: whether the tool failed
 A tool that raises does **not** raise in your client. It comes back as an ordinary result with `is_error=True`.
 !!! check
    Ask `lookup_book` for `"Solaris"` (a title that isn't in the catalog) and the function raises
    `ValueError`. The call still returns normally:
    ```python
    result.is_error            # True
    result.content             # [TextContent(type='text', text="Error executing tool lookup_book: No book titled 'Solaris' in the catalog.")]
    result.structured_content  # None
    ```
    The exception's message landed in `content`, where the **model** can read it and try again. That
    is deliberate: a tool error is part of the conversation, not a crash. Always look at `is_error`
    before you trust `structured_content`.
 !!! warning
    `is_error=True` covers more than your own `raise`. Ask for a tool the server doesn't even have
    (`call_tool("does_not_exist", {})`) and nothing raises. You get the same shape back,
    `is_error=True` with `Unknown tool: does_not_exist` in `content`. A `Client` method raises
    `MCPError` only when the server answers with a JSON-RPC **error** instead of a result, and
    **[Handling errors](../servers/handling-errors.md)** covers when a server produces which.
 ## Resources
 The resource verbs come in pairs: two ways to list, one way to read.
 ```python title="client.py" hl_lines="23-32"
 --8<-- "docs_src/client/tutorial004.py"
 ```
 * `list_resources()` returns the **concrete** resources, the ones with a fixed URI. Here: `['catalog://genres']`.
 * `list_resource_templates()` returns the **parameterised** ones. Here: `['catalog://genres/{genre}']`. They are two different lists because a template isn't readable until you fill it in.
 * `read_resource(uri)` takes a plain `str` URI and works on both: pass `"catalog://genres/poetry"` and the server matches it to the template.
 `read_resource` returns `contents`, a list of `TextResourceContents` or `BlobResourceContents`. Same idea as tool content: narrow with `isinstance`, then read `.text` (or `.blob`).
 A client can also be told when a resource changes. On 2025-era connections that is `subscribe_resource(uri)` / `unsubscribe_resource(uri)` - a method pair `MCPServer` doesn't implement, so on the 2026-07-28 wire (where those verbs no longer exist) the request answers `-32601`, *Method not found*. The 2026 replacement is a `subscriptions/listen` stream, which `MCPServer` *does* serve - `server_capabilities.resources.subscribe` is `True` there - and consuming it with `client.listen(...)` is this section's **[Subscriptions](subscriptions.md)** page.
 ## Prompts
 ```python title="client.py" hl_lines="15-20"
 --8<-- "docs_src/client/tutorial005.py"
 ```
 `list_prompts()` tells you what the server offers and what each prompt needs:
 ```python
 prompt.name        # 'recommend'
 prompt.title       # 'Recommend a book'
 prompt.arguments   # [PromptArgument(name='genre', required=True)]
 ```
 `get_prompt(name, arguments)` renders it. The arguments dict is `str -> str`: prompt arguments are always strings. The result is `messages`, a list of `PromptMessage`, each with a `role` and a `content` block:
 ```python
 message.role     # 'user'
 message.content  # TextContent(type='text', text='Recommend one poetry book from the catalog and say why.')
 ```
 A host hands those messages straight to the model. That is the whole feature.
 ## Completions
 A server with a completion handler can autocomplete prompt and resource-template arguments as the user types.
 ```python title="client.py" hl_lines="28-32"
 --8<-- "docs_src/client/tutorial006.py"
 ```
 * `ref` says *which* prompt or template you're filling in: a `PromptReference` or a `ResourceTemplateReference`.
 * `argument` is `{"name": ..., "value": ...}`: the argument and what the user has typed so far.
 The answer is in `result.completion.values`. Type `"p"` and the server comes back with `['poetry']`. The server side, and how a handler uses the *other* already-filled arguments to narrow its suggestions, is the **[Completions](../servers/completions.md)** page.
 ## Pagination
 Every `list_*` method takes a `cursor=` keyword and every result carries a `next_cursor`. When `next_cursor` is `None`, you have everything.
 ```python title="client.py" hl_lines="23-31"
 --8<-- "docs_src/client/tutorial007.py"
 ```
 This loop is correct against every server. `MCPServer` returns everything in one page, so `next_cursor` is `None` and the loop runs once, which is why most code never writes it. Servers that genuinely page, and the rules cursors obey, are in **[Pagination](../advanced/pagination.md)**.
 ## In tests
 `Client(mcp)` with no process and no port is already a test harness for your server.
 There is one constructor flag built for that: `Client(mcp, raise_exceptions=True)`. It only has an effect on in-memory connections, and **[Testing](../get-started/testing.md)** is the page that explains it and builds the whole pattern around it.
 ## Recap
 * `Client(x)` connects in-memory to a server object, over Streamable HTTP to a URL string, and over anything else via a transport.
 * `async with` is the whole lifecycle. Inside it, `server_info`, `server_capabilities`, `protocol_version` and `instructions` are already populated.
 * `list_tools()` gives you each tool's `name`, `title`, `description` and `input_schema`.
 * `call_tool()` returns `content` for the model, `structured_content` for your code, and `is_error`. A raising tool is a result, not an exception.
 * `content` is a union of block types; narrow with `isinstance` before reading.
 * `list_resources` / `list_resource_templates` / `read_resource`, `list_prompts` / `get_prompt`, and `complete` round out the verbs.
 * Every `list_*` takes `cursor=`; loop until `next_cursor` is `None`.
 The things a server can ask the *client* for, and how you answer them, are **[Client callbacks](callbacks.md)**.
@@ -0,0 +1,147 @@
 # OAuth clients
 Some MCP servers are protected. Send them a request without a token and they answer `401 Unauthorized`.
 **`OAuthClientProvider`** is how you get the token. It is not an MCP object at all. It is an `httpx.Auth`, the standard httpx hook for "do something to every request". You attach it to an `httpx.AsyncClient`, hand that client to the Streamable HTTP transport, and stop thinking about it.
 This page is the client side. Making your own server demand a token is **[Authorization](../run/authorization.md)**.
 ## The provider
 ```python title="client.py" hl_lines="44-54"
 --8<-- "docs_src/oauth_clients/tutorial001.py"
 ```
 You give it four things:
 * `server_url`: the MCP endpoint you are connecting to. The provider discovers everything else from it.
 * `client_metadata`: what you would type into an authorization server's "register an application" form.
 * `storage`: where tokens live between runs.
 * `redirect_handler` and `callback_handler`: the two moments a human is involved.
 Nothing else in the file mentions OAuth. `main()` never sees a token.
 ### Client metadata
 `OAuthClientMetadata` is the real [RFC 7591](https://datatracker.ietf.org/doc/html/rfc7591) registration document, as a Pydantic model.
 You set three fields. The defaults fill in the rest: `grant_types` is already `["authorization_code", "refresh_token"]` and `response_types` is already `["code"]`, which is exactly the flow this provider runs.
 !!! check
    Because it is a Pydantic model, it validates **before a single byte goes over the network**.
    Leave out `redirect_uris` and construction fails on the spot with a `ValidationError` that
    names the field:
    ```text
    redirect_uris
      Field required [type=missing, input_value={'client_name': 'Bookshop Agent'}, input_type=dict]
    ```
    No browser opened, no half-finished registration left behind on the authorization server.
 ### Token storage
 **`TokenStorage`** is a `Protocol` with four async methods. You don't inherit from anything; write the methods and any class is a token store:
 * `get_tokens` / `set_tokens` hold the `OAuthToken`: access token, refresh token, expiry, scope.
 * `get_client_info` / `set_client_info` hold the `OAuthClientInformationFull` the authorization server issued when the provider registered you, including your `client_id`.
 The in-memory version above works. It also forgets everything when the process exits, so the next run does the whole dance again. Persist it to a file or your platform's keyring and the next run is silent.
 !!! tip
    Store `client_info`, not only the tokens. The provider registers dynamically the first time it
    finds no stored `client_info`. Throw it away and you mint a fresh registration on every run.
 ### The two handlers
 The authorization code flow needs a human exactly once: someone has to sign in and click "allow".
 * **`redirect_handler`** is awaited with the fully-built authorization URL. The `client_id`, the `redirect_uri`, the `state` and the PKCE challenge are already in it. Your only job is to get a browser there. A desktop app calls `webbrowser.open`; this file prints it.
 * **`callback_handler`** is awaited next. It waits until the user lands back on your `redirect_uri` and returns that redirect's query parameters as an `AuthorizationCodeResult`.
 A real client runs a small local HTTP server on the redirect URI instead of calling `input()`. The shape is identical: get redirected, hand back `code`, `state`, and `iss`.
 !!! warning
    Pass `state` and `iss` through exactly as they arrived. The provider compares `state` to the one
    it generated and `iss` to the issuer it discovered, and refuses a mismatch. They are the CSRF
    and server-mix-up defences.
 ### Into the `Client`
 Look at `main()`. The provider goes on the **httpx client**, the httpx client goes into `streamable_http_client(url, http_client=...)`, and that transport goes into `Client`.
 `streamable_http_client` has no `auth=` keyword. Anything HTTP-level (auth, headers, timeouts, proxies) belongs on the `httpx.AsyncClient` you bring. That layering is **[Client transports](transports.md)**.
 ## What the provider does for you
 The first time `Client` sends a request, the server answers `401`. The provider takes over:
 1. **Discovery.** It reads the `WWW-Authenticate` header, fetches the server's Protected Resource Metadata from `/.well-known/oauth-protected-resource`, learns which authorization server protects this resource, and fetches *that* server's metadata.
 2. **Registration.** Nothing in storage? It registers you dynamically with your `OAuthClientMetadata` and stores the result.
 3. **Authorization.** It generates the PKCE pair and a `state`, builds the authorization URL, awaits your `redirect_handler`, then awaits your `callback_handler` for the code.
 4. **Exchange.** It trades the code for an `OAuthToken`, stores it, and replays your original request with `Authorization: Bearer ...`.
 After that it is quiet. Tokens come out of storage, an expired access token is refreshed with the refresh token, and only when none of that works does it run the flow again.
 You wrote none of it. Three keyword arguments remain (`timeout`, `client_metadata_url` and `validate_resource_url`), and this file needs none of them. `client_metadata_url` is the one worth knowing about; it gets its own section below.
 ### Try it
 Most examples in these docs you can check with an in-memory `Client(server)`. Not this: the whole point of the flow is an HTTP `401`, and there is no HTTP between an in-memory client and its server.
 The repository ships the live version. `examples/servers/simple-auth/` runs a standalone authorization server and a protected MCP server; `examples/clients/simple-auth-client/` is this page's client grown into a small CLI. Its README has the two commands: start the servers, run the client against them, and you watch the four steps go by.
 ## Client ID Metadata Documents
 The 2026-07-28 revision of the spec deprecates dynamic client registration in favor of **Client ID Metadata Documents** (CIMD). Instead of POSTing a fresh registration to every authorization server it meets, your client publishes one JSON document about itself at a stable HTTPS URL, and that URL *is* its `client_id`. The authorization server fetches the document; the provider never touches it.
 The SDK already speaks it: pass the URL as `client_metadata_url=` when you construct the provider. When the authorization server's metadata advertises `client_id_metadata_document_supported: true`, the provider skips the `/register` request entirely: the URL goes into the flow as the `client_id`, and there is no `client_secret`. When the server doesn't advertise it (most don't yet), or you never pass a URL, the provider falls back to dynamic registration **silently**, and everything above works exactly as described. Stored `client_info` still wins over both.
 The URL must be HTTPS with a non-root path; anything else is a `ValueError` at construction, before any network happens. The shipped `examples/clients/simple-auth-client/` takes it as the `MCP_CLIENT_METADATA_URL` environment variable.
 ## Machine to machine
 A nightly job, a CI step, another service. There is no browser and nobody to click "allow". That is the **client credentials** grant: you already hold a `client_id` and a `client_secret`, and the token endpoint is the whole flow.
 `ClientCredentialsOAuthProvider` is the same `httpx.Auth`, minus the human:
 ```python title="client.py" hl_lines="4 27-33"
 --8<-- "docs_src/oauth_clients/tutorial002.py"
 ```
 What changed:
 * No `OAuthClientMetadata`, no handlers. You pass `client_id` and `client_secret`; the provider builds a minimal `client_credentials` registration around them and skips dynamic registration entirely.
 * `scopes` is a space-separated string, the OAuth wire format.
 * Everything downstream is identical: the same `TokenStorage`, the same `httpx.AsyncClient(auth=...)`, the same `streamable_http_client`.
 By default the secret travels as HTTP Basic auth on the token request (`client_secret_basic`). Pass `token_endpoint_auth_method="client_secret_post"` to put it in the form body instead. Some authorization servers only accept one of the two.
 !!! tip
    Read `client_secret` from the environment or a secret manager, never from source control.
 !!! info
    One more provider lives in `mcp.client.auth.extensions.client_credentials`:
    **`PrivateKeyJWTOAuthProvider`**, for clients that authenticate with a JWT instead of a
    shared secret (`private_key_jwt`, the key-pair and workload-identity flavour). It follows
    the same pattern: construct one, put it on `auth=`. The same module ships
    `SignedJWTParameters` and `static_assertion_provider`, two helpers that build its assertion.
 There is one more no-human situation: the client belongs to an enterprise whose identity provider, not the user, decides which MCP servers it may reach. That is a different grant with its own trust model and its own page, **[Identity assertion](identity-assertion.md)**.
 ## When it fails
 When the OAuth flow goes wrong, the provider raises an `OAuthFlowError` from `mcp.client.auth`. It has two subclasses. `OAuthRegistrationError` means the authorization server refused to register you. `OAuthTokenError` means the token endpoint said no. One `except OAuthFlowError:` covers discovery, registration, authorization, and exchange.
 Not everything is a flow error. The network can still fail; those are ordinary `httpx` exceptions and pass through untouched.
 ## Recap
 * `OAuthClientProvider` is an `httpx.Auth`. Put it on an `httpx.AsyncClient`, pass that to `streamable_http_client(url, http_client=...)`, and `Client` never knows OAuth happened.
 * You supply four things: the server URL, an `OAuthClientMetadata`, a `TokenStorage`, and the redirect/callback handler pair.
 * `TokenStorage` is a `Protocol`: four async methods, no base class. Persist `client_info` as well as the tokens.
 * Discovery, registration (dynamic, or via a **Client ID Metadata Document**), PKCE, the `state` and `iss` checks, and token refresh are the provider's job, not yours.
 * `ClientCredentialsOAuthProvider` is the no-human version: `client_id` + `client_secret`, no handlers, no browser.
 * Every OAuth failure is an `OAuthFlowError`; `OAuthRegistrationError` and `OAuthTokenError` are its subclasses.
 The other half of this handshake, making your *server* demand the token, is **[Authorization](../run/authorization.md)**.
@@ -0,0 +1,82 @@
 # Session groups
 A `Client` connects to one server. Real applications often want several (a search server, a database server, an internal API) and end up juggling a connection and a tool list for each.
 **`ClientSessionGroup`** is one object that holds many connections and merges everything they expose into a single view.
 ## Two servers
 Start with two ordinary servers. They have nothing to do with each other, so both naturally called their tool `search`:
 ```python title="library_server.py" hl_lines="7"
 --8<-- "docs_src/session_groups/tutorial001.py"
 ```
 ```python title="web_server.py" hl_lines="7"
 --8<-- "docs_src/session_groups/tutorial002.py"
 ```
 ## One group
 Create a `ClientSessionGroup` and call **`connect_to_server`** once per server:
 ```python title="client.py" hl_lines="10-12"
 --8<-- "docs_src/session_groups/tutorial003.py"
 ```
 * `connect_to_server` takes transport parameters, not a server object: `StdioServerParameters` (from `mcp`) to launch a subprocess, or `StreamableHttpParameters` / `SseServerParameters` (from `mcp.client.session_group`) for a server already listening on a URL.
 * `group.tools` is a `dict[str, Tool]` of every connected server's tools. `group.resources` and `group.prompts` are the same shape.
 * `group.call_tool(name, arguments)` looks the name up, finds the session that owns it, and forwards the call. You never say which server.
 !!! check
    Put `client.py` next to the two servers and run it. The second `connect_to_server` refuses:
    ```text
    mcp.shared.exceptions.MCPError: {'search'} already exist in group tools.
    ```
    That is an `MCPError`, raised before anything from the second server is registered. A name must
    be unique across the **whole** group, and two servers you don't control will collide eventually.
 ## `component_name_hook`
 You fix this at the group, not at the servers. Pass a function of `(name, server_info)` and the group runs it on every name it registers:
 ```python title="client.py" hl_lines="8-9 16"
 --8<-- "docs_src/session_groups/tutorial004.py"
 ```
 Run it again. `print(sorted(group.tools))` now shows both:
 ```text
 ['Library.search', 'Web.search']
 ```
 * The **key** is yours. `by_server` built it from `server_info.name`, the name each `MCPServer(...)` was constructed with.
 * The `Tool` inside is untouched: `group.tools["Web.search"].name` is still `"search"`, and that is the name `call_tool` puts on the wire. The prefix never leaves your process.
 * It is not only tools. The library's `hours` resource is registered as `Library.hours`.
 !!! tip
    The hook runs on **every** name from **every** server, not only on conflicts: there is no
    prefix-on-collision mode. Pick one scheme and let it apply everywhere.
 ## Adding and removing servers
 `connect_to_server` returns the `ClientSession` it opened. Keep it if you ever want that server gone: `await group.disconnect_from_server(session)` removes its tools, resources, and prompts from the group.
 If you already hold a connected `ClientSession` (`Client.session` is one), hand it to `await group.connect_with_session(server_info, session)` instead of opening a new transport. It aggregates the same way. The group never closes a session it didn't open.
 ## The classic handshake
 `ClientSessionGroup` is built on `ClientSession`, not on `Client`. Each `connect_to_server` runs the classic `initialize` handshake. It never sends the `server/discover` probe described in **[Protocol versions](../protocol-versions.md)**. Every MCP server understands that handshake, so this costs you compatibility with nothing; it only means a group takes the older, slower path to a server that could do better.
 ## Recap
 * `ClientSessionGroup` holds many server connections and merges their tools, resources, and prompts into one `dict` each.
 * `connect_to_server(params)` per server. It takes transport parameters, never the server object or URL a `Client` takes.
 * `group.call_tool(name, arguments)` routes to the owning server for you.
 * Names must be unique across the whole group; two servers with a `search` tool cannot coexist on their own.
 * `component_name_hook=` rewrites every registered name. The dict key changes, the wire name does not.
 * `connect_with_session` adds a session you already hold; `disconnect_from_server` removes one.
 The handshake a group speaks (and the faster one a `Client` prefers) is the subject of **[Protocol versions](../protocol-versions.md)**.
@@ -0,0 +1,86 @@
 # Subscriptions
 A server's catalog is not fixed. Tools appear at runtime, and the content behind a resource URI changes. A client hears about it through `client.listen(...)`: one `subscriptions/listen` request whose response *is* the stream. It stays open and carries the change notifications the client asked for.
 This page is the client end: opening the stream, watching it beside your main flow, and handling its endings. Publishing changes, filtering, and serving the method are the server's side of the story, told in **[Subscriptions](../handlers/subscriptions.md)** under *Inside your handler*. The examples here talk to the sprint-board server built there.
 ## Watching the stream
 A subscription is one context manager. Entering it sends the request, with your keyword arguments as the subscription filter, and waits for the server's acknowledgment, so the stream is live by the time the block starts.
 ```python title="client.py" hl_lines="16 19 29"
 --8<-- "docs_src/subscriptions/tutorial003.py"
 ```
 Iteration yields four typed events: `ToolsListChanged`, `PromptsListChanged`, `ResourcesListChanged`, and `ResourceUpdated(uri=...)`.
 An event says *what* changed, never *how*. That is why `follow_board` calls `read_resource` and `list_tools`: the event is a cue to refetch. Read `event.uri` rather than assuming which resource moved: a filter can name several URIs, and a server may report a change on a sub-resource of one of them.
 Duplicate events waiting to be consumed collapse into one, and refetching still gets you the current state. Only identical events collapse: two `ResourceUpdated` for different URIs are two events.
 Two more properties of the handle:
 * `sub.honored` is the filter the server acknowledged: a `SubscriptionFilter` with the fields you passed, read as attributes (`sub.honored.prompts_list_changed`). `MCPServer` honors every kind you ask for, so it echoes your request back. A server that narrows the filter (see the [filter warning](../handlers/subscriptions.md#only-what-was-asked-for) on the server page) acknowledges less, and an honored kind may still never fire.
 * `sub.subscription_id` is the listen request's id, the one stamped on every frame of this stream. Several subscriptions can be open at once, each demultiplexed by its own id.
 ## Watching without blocking
 `follow_board` runs until the server closes the stream, which may be never, so on its own it owns your program. Real clients want the watcher *beside* the main flow: an agent calls tools while a watcher keeps a cache or a UI current.
 Open the subscription first, then start the watcher and get on with your work.
 === "asyncio"
    ```python title="app.py" hl_lines="18 20"
    --8<-- "docs_src/subscriptions/tutorial004_asyncio.py"
    ```
 === "trio"
    ```python title="app.py" hl_lines="18 21"
    --8<-- "docs_src/subscriptions/tutorial004_trio.py"
    ```
 === "anyio"
    ```python title="app.py" hl_lines="18 21"
    --8<-- "docs_src/subscriptions/tutorial004_anyio.py"
    ```
 !!! note
    `app.py` imports `BOARD` and `read_board` from the first example, which this repo stores as
    `tutorial003.py`. If you save the rendered files side by side as `client.py` and `app.py`,
    write `from client import BOARD, read_board` instead. The `watch.py` example further down
    imports `read_board` the same way.
 The order is the point. Nothing is replayed, so an event published before your stream existed is missed. Entering `client.listen(...)` waits for the acknowledgment, so every change from that moment on reaches your watcher, and the snapshot you take inside the block cannot miss one.
 Requests run freely beside an open stream, from the watcher task or any other, on the same client. Because *duplicate* unconsumed events coalesce, a busy main flow may produce one refetch rather than three. Events that differ do not coalesce: a filter naming many URIs queues one pending event per URI.
 To stop watching, leave the block: there is no `unsubscribe` call. Cancelling the task that owns the block does that for you, and the SDK cancels the listen request the way the transport expects: over streamable HTTP, by closing that request's stream. A watcher that runs for the life of your app never returns on its own, so cancel it, or its task group's scope, at shutdown.
 ## Streams end
 A stream ends in one of two ways, both ordinary control flow. A graceful server close ends the `async for`; an abrupt drop raises `SubscriptionLost`.
 The difference is diagnostic, not a difference in what to do next: the stream is gone, nothing was replayed, and a watcher that still cares re-listens and refetches.
 ```python title="watch.py" hl_lines="16 20"
 --8<-- "docs_src/subscriptions/tutorial005.py"
 ```
 Servers close streams gracefully for their own reasons, including shedding a subscriber whose backlog grew too large, so a clean end is not a signal to stop watching. Back off before re-listening.
 `SubscriptionLost` has one local cause too. The client holds at most 1024 unconsumed events, and a consumer that falls that far behind loses the subscription rather than grow without bound. Keep the body of the `async for` short and do slow work elsewhere.
 `keep_following` catches only `SubscriptionLost`. Entering `listen()` can also raise `MCPError` (the connection failed, or the server does not serve the method), `TimeoutError` (no acknowledgment arrived), and `ListenNotSupportedError` (a pre-2026 connection). Decide which of those your watcher should retry: the last never heals.
 ## Recap
 * Enter `async with client.listen(...)`; entering waits for the acknowledgment, so nothing published after it is missed.
 * Iterate with `async for event in sub`. Events are cues to refetch, never payloads.
 * Open the subscription, then run the watcher as a task, and tool calls keep flowing beside it.
 * A clean end stops the loop; a drop raises `SubscriptionLost`. Either way: re-listen, refetch, back off first.
 * Leaving the block is the unsubscribe.
 Publishing these events, narrowing the filter, and scaling past one process are the server's story: **[Subscriptions](../handlers/subscriptions.md)**. These same events also keep a client-side cache honest, and **[Caching](caching.md)** is the next page.
@@ -0,0 +1,115 @@
 # Client transports
 Every `Client` talks to its server over a **transport**: the thing that actually carries the messages.
 You never configure one separately. `Client` takes a single positional argument and works the transport out from its type.
 The *server* side of each (what `mcp.run()` does and what you deploy) is **[Running your server](../run/index.md)**.
 ## In memory
 Pass the server object itself:
 ```python title="client.py" hl_lines="14"
 --8<-- "docs_src/client_transports/tutorial001.py"
 ```
 No subprocess, no port, no bytes on a wire. The client and the server are two objects in the same process, and the call still goes through the real protocol layer: `search_books` is listed, validated and invoked exactly as it would be over HTTP.
 That makes it two things at once:
 * **A test harness.** Every example in this documentation is exercised this way, and the **[Testing](../get-started/testing.md)** page builds the whole pattern around it.
 * **An embedding API.** An application that constructs the server doesn't need a network hop to call its tools.
 ## Streamable HTTP
 Pass a URL string and you get **Streamable HTTP**, the transport you deploy behind:
 ```python title="client.py" hl_lines="5"
 --8<-- "docs_src/client_transports/tutorial002.py"
 ```
 That is the whole production client. `Client` wraps the URL in `streamable_http_client(...)` for you, on top of an `httpx.AsyncClient` configured the way MCP needs: `follow_redirects=True`, a 30-second timeout for connect/write/pool, and a 300-second read timeout because the server may hold a response stream open.
 !!! check
    A `Client` you have constructed is **not** connected. Construction only picks the transport;
    `async with` is what opens it. Reach for the connection before entering and the SDK tells you so:
    ```text
    RuntimeError: Client must be used within an async context manager
    ```
    Nothing was resolved, fetched or spawned when you wrote `Client("http://...")`. That line is free.
 ### Bring your own `httpx.AsyncClient`
 The moment you need an `Authorization` header, a cookie, a proxy, mTLS, or a different timeout, build the `httpx.AsyncClient` yourself and hand it to `streamable_http_client`:
 ```python title="client.py" hl_lines="8-14"
 --8<-- "docs_src/client_transports/tutorial003.py"
 ```
 Two things to notice:
 * You own the `httpx.AsyncClient`, so **you** enter and exit it. The SDK never closes a client it didn't create.
 * `streamable_http_client(url, http_client=...)` returns a transport, and `Client(transport)` accepts it like anything else.
 !!! warning
    `streamable_http_client` used to take `headers=` and `timeout=` directly. It does not any more:
    its only parameters are `url`, `http_client` and `terminate_on_close`. Reach for `headers=` out
    of habit and you get:
    ```text
    TypeError: streamable_http_client() got an unexpected keyword argument 'headers'
    ```
    Everything HTTP-shaped now lives on the one `httpx.AsyncClient` you pass in.
 !!! info
    If you know `httpx`, you already know how to do auth, proxies, event hooks, retries and connection
    limits here. The SDK adds nothing on top and takes nothing away. It is also where OAuth plugs in:
    `httpx.AsyncClient(auth=OAuthClientProvider(...))`. That whole flow is **[OAuth clients](oauth-clients.md)**.
 ## stdio
 A **stdio** server is a subprocess. The client launches it, writes JSON-RPC to its stdin and reads JSON-RPC from its stdout. It is how a desktop host runs a server on your machine: a host *is* this code plus a UI, and **[Connect to a real host](../get-started/real-host.md)** is the same relationship seen from the host's side, as a config file.
 Describe the process with `StdioServerParameters`, turn it into a transport with `stdio_client`, and hand *that* to `Client`:
 ```python title="client.py" hl_lines="4-8 12"
 --8<-- "docs_src/client_transports/tutorial004.py"
 ```
 `Client` does not accept the parameters object on its own. `StdioServerParameters` is configuration; `stdio_client(server)` is the transport that knows how to spawn a process from it. Always wrap.
 Leaving the `async with` block also shuts the subprocess down: close stdin, wait, kill if it lingers. You never clean it up yourself.
 !!! warning
    The child does **not** inherit your environment. It gets a minimal allow-list (`HOME`, `LOGNAME`,
    `PATH`, `SHELL`, `TERM` and `USER` on POSIX) so nothing sensitive leaks into a process you may
    not have written.
    A server that needs an API key won't find it there. Pass it explicitly with `env=`; those
    variables are merged on top of the allow-list. That is what `BOOKSHOP_API_KEY` is doing above.
 ## SSE
 `sse_client(url)`, from `mcp.client.sse`, is the HTTP transport that Streamable HTTP superseded. Wrap it the same way, `Client(sse_client("http://localhost:8000/sse"))`, to talk to a server that still speaks it, and don't build anything new on it.
 ## The `Transport` protocol
 To `Client`, all of the above are the same thing.
 A **transport** is any async context manager that yields a `(read, write)` pair of message streams: formally, the `Transport` protocol in `mcp.client`. `Client` resolves its argument by type: a server object connects in-process, a `str` becomes `streamable_http_client(url)`, and anything else is entered as a transport directly. That last rule is why `stdio_client(...)`, `streamable_http_client(...)` and `sse_client(...)` all drop into the same slot, and why you can write your own.
 ## Recap
 * `Client(mcp)` (the server object) connects in memory. Use it for tests and for embedding.
 * `Client("http://.../mcp")` (a URL) connects over Streamable HTTP, the production transport.
 * Headers, auth, proxies and timeouts belong on an `httpx.AsyncClient` you pass to `streamable_http_client(url, http_client=...)`. There is no `headers=` keyword.
 * stdio is `Client(stdio_client(StdioServerParameters(...)))`, never the parameters object alone.
 * The subprocess gets an allow-listed environment, not yours; `env=` adds to it.
 * A transport is anything you can `async with x as (read, write)`. `Client` hands anything that isn't a server object or a URL straight to that protocol.
 * Constructing a `Client` picks the transport. `async with` opens it.
 Once the transport is open the two sides have to agree on a protocol version. You normally never think about it; when you do, **[Protocol versions](../protocol-versions.md)** is the page.
@@ -0,0 +1,91 @@
 # Deprecated features
 The 2026-07-28 spec retires five things. The SDK still implements every one of them, and every one of them now carries a **deprecation warning**.
 The table below names each deprecated feature, why it is going away, and the replacement to build on.
 ## What is deprecated
 | Deprecated | Why | What you do instead |
 |---|---|---|
 | **Roots**: `ctx.session.list_roots()`, `client.send_roots_list_changed()`, the `list_roots_callback=` you pass to `Client(...)` | [SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577) retires the capability. | Take the paths as ordinary tool arguments or resource URIs, or embed a `ListRootsRequest` in an `InputRequiredResult` (see **[Multi-round-trip requests](handlers/multi-round-trip.md)**). |
 | **Server-initiated sampling**: `ctx.session.create_message()`, the `sampling_callback=` you pass to `Client(...)` | SEP-2577 retires the capability. | Return `InputRequiredResult` and let the client retry the call (see **[Multi-round-trip requests](handlers/multi-round-trip.md)**). |
 | **Protocol logging**: `ctx.log()`, `ctx.debug()`, `ctx.info()`, `ctx.warning()`, `ctx.error()`, `ctx.session.send_log_message()`, `client.set_logging_level()` | SEP-2577 retires the capability. Nothing in-protocol replaces it. | Ordinary `import logging` to stderr (see **[Logging](handlers/logging.md)**). |
 | **`ping`**: `client.send_ping()` | **Removed** from the protocol, not merely deprecated. There is no `ping` method in 2026-07-28. | Nothing. It only works against a `mode="legacy"` connection. |
 | **Client->server progress**: `client.send_progress_notification()` | 2026-07-28 makes progress server->client only. | Nothing to send. Your *server* reports progress with `ctx.report_progress()` (see **[Progress](handlers/progress.md)**). |
 Three things fall out of that table:
 * Roots, sampling, and logging go together. One proposal, **SEP-2577**, deprecates all three capabilities at once.
 * Sampling and roots share a deeper problem: they are places a **server** sends a **request** to the **client**. That whole direction is what 2026-07-28 replaces with **[Multi-round-trip requests](handlers/multi-round-trip.md)**. It is the standalone RPC methods (`sampling/createMessage`, `roots/list`, and push-style `elicitation/create`) that are gone; the `CreateMessageRequest` / `ListRootsRequest` / `ElicitRequest` payload types survive, embedded in `InputRequiredResult.input_requests`, and on the client they hit the same callbacks.
 * `ping` is the odd one out. The protocol does not deprecate it, it removes it. The SDK method still warns (its message says *removed*, not *deprecated*) and calling it on a modern connection answers with *"Method not found"*.
 ## Deprecated is advisory
 Nothing breaks today.
 Every method above keeps working against any session that negotiated **2025-11-25 or earlier**. Pin `mode="legacy"` on the client and you get exactly the pre-2026 behaviour. There are no wire changes and capability negotiation is unchanged.
 What changes is that you get a visible warning the first time each one runs:
 ```text
 MCPDeprecationWarning: The logging capability is deprecated as of 2026-07-28 (SEP-2577).
 ```
 `MCPDeprecationWarning` subclasses `UserWarning`, **not** `DeprecationWarning`. That is deliberate: Python's default filter only shows `DeprecationWarning` in code run directly as `__main__`, which is how libraries deprecate things and nobody notices for two years. This one shows up everywhere, with no `-W` flag.
 !!! warning
    "Advisory" stops at the wire. Sampling and roots are server-to-client *requests*, and a
    2026-07-28 session has no channel to carry one. Call `ctx.session.create_message()`
    inside a tool on a modern connection and the warning still fires, and then the send
    fails with an error:
    ```text
    Cannot send 'sampling/createMessage': this transport context has no back-channel
    for server-initiated requests.
    ```
    Two signals, in that order. The `MCPDeprecationWarning` fires the moment you call the
    method, on any connection. The error is what comes back when the SDK then tries to
    send. These two only work end-to-end on a `mode="legacy"` connection whose client
    registered the matching callback.
 ## Silencing the warning
 Don't, in new code.
 But a server you maintain that genuinely serves pre-2026 clients has every right to a quiet log. Filter the category before the first deprecated call runs:
 ```python
 import warnings
 from mcp import MCPDeprecationWarning
 warnings.filterwarnings("ignore", category=MCPDeprecationWarning)
 ```
 That is the whole API. There is no per-method switch, and you don't want one: the point of one category is that one line silences it and one line brings it back.
 !!! check
    Run the filter the other way and you get a free regression test. Add
    `"error::mcp.MCPDeprecationWarning"` to the `filterwarnings` setting in your pytest
    configuration and the deprecated call **raises** instead of warning. A tool named
    `old_log` that still calls `ctx.info()` stops passing and starts reporting:
    ```text
    Error executing tool old_log: The logging capability is deprecated as of 2026-07-28 (SEP-2577).
    ```
    One line of pytest configuration, and a deprecated call can never sneak back into your
    codebase without failing a test.
 ## Recap
 * The 2026-07-28 spec deprecates **roots**, server-initiated **sampling**, and protocol **logging** (all [SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577)), restricts **progress** to server-to-client, and removes **`ping`**.
 * The replacement column points you onward: **[Multi-round-trip requests](handlers/multi-round-trip.md)** for sampling and roots, **[Logging](handlers/logging.md)** for logging, **[Progress](handlers/progress.md)** for progress. `ping` needs nothing at all.
 * Deprecated is advisory: no wire changes, everything keeps working against pre-2026 sessions, and you get a visible `MCPDeprecationWarning` (a `UserWarning`, so it is on by default).
 * Sampling and roots additionally need a back-channel that a 2026-07-28 session does not have. On a modern connection they warn and then they raise.
 * `warnings.filterwarnings("ignore", category=MCPDeprecationWarning)` silences the whole category; `"error::mcp.MCPDeprecationWarning"` in pytest turns it into a test failure.
 * New code should not be built on any of these.
 Every other page in these docs teaches the current API.
@@ -0,0 +1,107 @@
 /* Sidebar hierarchy + density for Zensical's UI (Material-compatible md-*
   DOM, but different stock spacing: nav links are 8px-radius pills with
   7px 16px padding). All rules scoped to the desktop sidebar breakpoint
   (>= 76.25em) so the mobile drill-down drawer keeps stock styling. Colors
   use the md-* tokens, so the light and slate schemes both work without
   extra palette handling. */
@media screen and (min-width: 76.25em) {
  /* The sidebar is one coordinate system derived from the pill inset:
     every row — page links, group rows, section labels — is a direct
     .md-nav__link child of its item with the same 10px horizontal padding,
     so all text shares one column, and hover/active pills always paint
     10px of breathing room inside the scroll container (never clipped).
     The padding lives on the elements Zensical paints hover/active pills
     on (.md-nav__link[href] anchors and [for] labels — leaf links, bare
     section labels, and the inner anchor of an .md-nav__container
     wrapper); wrappers stay geometry-neutral, as stock. The 10px inset
     also stays >= the 0.4rem pill radius, so the corner curve never
     crowds the text. Vertical rhythm has a single knob: the nav list's
     flex gap (stock 0.2rem reads airy; 2px matches the density the site
     shipped with on Material, ~30px row pitch). */
  .md-sidebar--primary .md-nav__list {
    gap: 2px;
  }
  .md-sidebar--primary .md-nav__item > .md-nav__link:not(.md-nav__container),
  .md-sidebar--primary .md-nav__container > .md-nav__link {
    padding: 3px 10px;
    margin: 0;
  }
  .md-sidebar--primary .md-nav__item > .md-nav__container {
    padding: 0;
    margin: 0;
  }
  /* Section labels: typography only — geometry comes from the row rule
     above, so no specificity coordination is needed. */
  .md-sidebar--primary .md-nav__item--section {
    margin: 0.8em 0;
  }
  .md-sidebar--primary .md-nav__item--section > .md-nav__link {
    font-size: 0.62rem;
    font-weight: 700;
    text-transform: uppercase;
    letter-spacing: 0.1em;
    color: var(--md-default-fg-color--light);
  }
  /* Guide lines: 12px from the item box = 2px right of the label text
     (which sits at box + 10px pill inset); children indent past them. */
  .md-sidebar--primary .md-nav__item--section > .md-nav {
    margin-inline-start: 12px;
    border-inline-start: 0.05rem solid var(--md-default-fg-color--lightest);
  }
  .md-sidebar--primary .md-nav__item--nested:not(.md-nav__item--section) > .md-nav {
    margin-inline-start: 12px;
    border-inline-start: 0.05rem solid var(--md-default-fg-color--lightest);
  }
  /* The current page stands out from its siblings (on top of the stock
     pill highlight). 700 because only Inter 300/400/700 are loaded. */
  .md-sidebar--primary .md-nav__link--active {
    font-weight: 700;
  }
  /* The sidebar repeats the site name right above the homepage nav entry;
     drop the title row on desktop (the mobile drawer still needs it for its
     drill-down back-navigation, hence the media-query scope). */
  .md-sidebar--primary .md-nav--primary > .md-nav__title {
    display: none;
  }
 }
 /* Dark scheme: Zensical's slate canvas is near-black (hsla(225,15%,5%)),
   harsher than the Material slate this site shipped with; restore that
   blue-grey. Code blocks and other surfaces keep Zensical's own tokens. */
@media screen {
  [data-md-color-scheme="slate"] {
    --md-default-bg-color: #1e2129;
  }
 }
 /* Inline code inside admonitions: the chip token is an absolute dark
   surface designed for the page canvas, so on a tinted admonition panel it
   sits as an opaque slab (Zensical's own docs share this bug). Re-tint it
   tone-on-tone instead — translucent foreground, composited over whatever
   the panel color is — the same pattern Starlight and Docusaurus ship for
   code inside callouts. Prose chips keep the block-matching dark surface;
   block code inside admonitions keeps its own surface too. The first
   declaration is the fallback where color-mix is unsupported. */
 .md-typeset .admonition :not(pre) > code,
 .md-typeset details :not(pre) > code {
  background-color: var(--md-default-fg-color--lightest);
  background-color: color-mix(in srgb, currentcolor 11%, transparent);
  color: inherit;
 }
 /* Headings: the 300-weight light-gray defaults read washed out; use the
   full foreground color and a solid weight instead. 700, not 600: only
   Inter 300/400/700 are loaded (see the nav__link note above). */
 .md-typeset h1,
 .md-typeset h2 {
  font-weight: 700;
  color: var(--md-default-fg-color);
 }
 .md-typeset h3 {
  font-weight: 700;
 }
@@ -0,0 +1,11 @@
 <svg width="180" height="180" viewBox="0 0 180 180" fill="none" xmlns="http://www.w3.org/2000/svg">
 <rect width="180" height="180" rx="24" fill="black"/>
 <mask id="mask0_246_1229" style="mask-type:luminance" maskUnits="userSpaceOnUse" x="7" y="7" width="166" height="166">
 <path d="M173 7H7V173H173V7Z" fill="white"/>
 </mask>
 <g mask="url(#mask0_246_1229)">
 <path d="M23.5996 85.2532L86.2021 22.6507C94.8457 14.0071 108.86 14.0071 117.503 22.6507C126.147 31.2942 126.147 45.3083 117.503 53.9519L70.2254 101.23" stroke="white" stroke-width="11.0667" stroke-linecap="round"/>
 <path d="M70.8789 100.578L117.504 53.952C126.148 45.3083 140.163 45.3083 148.806 53.952L149.132 54.278C157.776 62.9216 157.776 76.9357 149.132 85.5792L92.5139 142.198C89.6327 145.079 89.6327 149.75 92.5139 152.631L104.14 164.257" stroke="white" stroke-width="11.0667" stroke-linecap="round"/>
 <path d="M101.853 38.3013L55.553 84.6011C46.9094 93.2447 46.9094 107.258 55.553 115.902C64.1966 124.546 78.2106 124.546 86.8543 115.902L133.154 69.6025" stroke="white" stroke-width="11.0667" stroke-linecap="round"/>
 </g>
 </svg>
@@ -0,0 +1,139 @@
 # First steps
 The **[landing page](../index.md)** moves fast: write a server, run it, call a tool.
 This page takes it slowly, with all three things a server can expose, and a name for everything along the way.
 ## Host, client, and server
 Three words you'll see on every page from here on:
 * A **host** is the LLM application: Claude, an IDE, an agent runtime. It's the thing the user is talking to.
 * A **client** lives inside the host and speaks MCP. The host runs one client per server it's connected to.
 * A **server** is what you build with this SDK. It exposes things to clients. It never talks to the model directly.
 You write the server. Hosts are someone else's product. The SDK also gives you a `Client`. You'll use it to test your servers, and it shows up later on this page.
 ## The three primitives
 A server exposes exactly three kinds of thing. What separates them is **who decides to use them**:
 | Primitive     | Controlled by   | What it is                                          | Example                            |
 |---------------|-----------------|-----------------------------------------------------|------------------------------------|
 | **Tools**     | The model       | A function the model calls to take an action        | An API call, a database write      |
 | **Resources** | The application | Data the host loads into the model's context        | A file's contents, an API response |
 | **Prompts**   | The user        | A reusable message template the user invokes by name | A slash command, a menu entry      |
 "Controlled by" is the whole point of the split. A tool runs because the **model** decided to call it. A resource is attached because the **application** decided the model needed it. A prompt runs because the **user** picked it.
 !!! info
    If you've built a web API you already have most of the intuition: a **resource** is a `GET`
    (it loads data and changes nothing) and a **tool** is a `POST` (it does work and may have
    side effects). A **prompt** has no HTTP analogue; it's closer to a saved query the user runs
    by name.
 ## One server, all three
 ```python title="server.py" hl_lines="6 12 18"
 --8<-- "docs_src/first_steps/tutorial001.py"
 ```
 Three plain functions, three decorators. Each decorator is the entire registration:
 * `@mcp.tool()` makes `add` a **tool**.
 * `@mcp.resource("greeting://{name}")` makes `greeting` a **resource template**: the `{name}` in the URI is the function's parameter.
 * `@mcp.prompt()` makes `summarize` a **prompt**. The string it returns becomes a user message.
 Everything else (the name, the description, the argument schema) the SDK reads from the function itself: its name, its docstring, its type hints. You never declared any of it separately.
 !!! tip
    The two halves of the SDK have two import paths: `from mcp import Client` and
    `from mcp.server import MCPServer`. There is no `from mcp import MCPServer`.
 ### Try it
 Run it with the MCP Inspector:
 ```console
 uv run mcp dev server.py
 ```
 Open the URL it prints. The Inspector has one tab per primitive; walk through them in order.
 **Tools.** One entry: `add`, described as *Add two numbers.* The form has a required integer field for `a` and another for `b`. Fill them in, call it, and the result is `3`. The Inspector built that form from `a: int, b: int`. So does every other client.
 **Resources.** The *Resources* list is empty. `greeting` is under **Resource Templates**, because `greeting://{name}` has a parameter: there is no single resource to list until someone supplies a `name`. Give it `World` and read it:
 ```text
 Hello, World!
 ```
 **Prompts.** One entry: `summarize`, with a single required `text` argument. Get it with some text and you receive one message with `role: user` and your rendered string as the content. That's all a prompt is: a function that builds messages.
 The Inspector ran your server over **stdio**, one of the transports an MCP server can speak. You don't pick one yet; **[Running your server](../run/index.md)** is the page for that.
 ## Capabilities
 You saw three tabs in the Inspector. How did it know there were three?
 When a client connects, the server declares its **capabilities**: which families of requests it will answer. The client uses that declaration to decide what to even ask for. You never wrote it; `MCPServer` declares it for you.
 Look at it yourself. The SDK's `Client` accepts the server object directly and connects to it **in memory** (no subprocess, no port):
 ```python
 import asyncio
 from mcp import Client
 from server import mcp
 async def main() -> None:
    async with Client(mcp) as client:
        print(client.server_capabilities.model_dump(exclude_none=True))
 asyncio.run(main())
 ```
 ```text
 {'prompts': {'list_changed': True}, 'resources': {'subscribe': True, 'list_changed': True}, 'tools': {'list_changed': True}}
 ```
 That dictionary is your server's declared **capabilities**. It's the first thing every connecting client learns:
 | Capability  | The client may now call                                    |
 |-------------|------------------------------------------------------------|
 | `tools`     | `tools/list`, `tools/call`                                  |
 | `resources` | `resources/list`, `resources/templates/list`, `resources/read` |
 | `prompts`   | `prompts/list`, `prompts/get`                               |
 `MCPServer` serves all three primitives, so all three are always declared.
 Notice what isn't there. `completions` (argument autocomplete for resource templates and prompts) needs a handler you write, this server doesn't have one, so the capability is absent and a well-behaved client won't ask. That's the rule for everything optional: register the thing and the capability appears; **[Completions](../servers/completions.md)** proves it.
 !!! info
    `Client(mcp)` is the same in-memory client every example in these docs is tested with, and
    it's how you'll test yours. It gets a whole page: **[Testing](testing.md)**.
 ## What you did not write
 Look back over this page. You wrote three small Python functions. You did **not** write:
 * A JSON Schema. `a: int, b: int` *is* the schema for `add`.
 * A request handler. `tools/list`, `resources/read`, `prompts/get`: all served for you.
 * A capability declaration. `MCPServer` made it for you.
 * A line of protocol. The version negotiation, the JSON-RPC framing, the capability exchange: all of it happened inside `mcp dev` and `Client(mcp)`, and you never saw it.
 That ratio is the whole point of the SDK.
 ## Recap
 * A **host** is the LLM app, a **client** is its MCP-speaking half, a **server** is what you build.
 * Tools are **model**-controlled, resources are **application**-controlled, prompts are **user**-controlled.
 * One decorator per primitive: `@mcp.tool()`, `@mcp.resource(uri)`, `@mcp.prompt()`. Name, description, and schema come from the function.
 * A URI with a `{param}` makes a resource **template**, listed separately from concrete resources.
 * The server's **capabilities** are declared for you, and a client only asks for what a server declares.
 * `Client(mcp)` connects to the server object in memory: your test harness from day one.
 Next up is **[Connect to a real host](real-host.md)**: this server inside Claude Desktop or an IDE, for real. Then **[Testing](testing.md)**: one page, one in-memory client, and you're never guessing whether it works. After that, each primitive gets its own page, starting with the one the model drives: **[Tools](../servers/tools.md)**.
@@ -0,0 +1,52 @@
 # Get started
 New to MCP, or new to this SDK? Start here. These pages take you from nothing to a
 working, tested server: [install the SDK](installation.md), build your
 [first server](first-steps.md), [connect it to a real host](real-host.md), and
 [test it](testing.md) with an in-memory client.
 ## Run the code
 All the code blocks can be copied and used directly: they are complete, working files.
 To follow along, paste a block into a `server.py` and open it in the MCP Inspector:
 ```console
 uv run mcp dev server.py
 ```
 It is **HIGHLY encouraged** that you write (or copy) the code, edit it, and run it locally. Using it in your own editor is what really shows you the point: how little you write, the autocompletion, the type checks catching mistakes before you run anything.
 ## You will not be guessing
 Every example in these docs is a complete file under [`docs_src/`](https://github.com/modelcontextprotocol/python-sdk/tree/main/docs_src) in the SDK's own repository, and every one of them is exercised by the SDK's test suite through an **in-memory client**:
 ```python
 import pytest
 from mcp import Client
 from server import mcp
@pytest.mark.anyio
 async def test_add() -> None:
    async with Client(mcp) as client:
        result = await client.call_tool("add", {"a": 1, "b": 2})
        assert result.structured_content == {"result": 3}
 ```
 No subprocess, no port, no transport. `Client(mcp)` connects to the server object directly.
 If a change to the SDK breaks an example on one of these pages, CI goes red before the page does. The code you read here is the code that runs.
 You'll use this yourself in [Testing](testing.md); it's how you test your own servers, too.
 ## Where to go next
 Once you have a server running, the rest of these docs are a reference, not a course.
 Every page stands on its own, so jump straight to what you need:
 * What a server exposes (tools, resources, prompts) is **[Servers](../servers/index.md)**.
 * What's available inside the functions you register is **[Inside your handler](../handlers/index.md)**.
 * Getting it in front of clients (stdio, HTTP, your existing FastAPI app) is **[Running your server](../run/index.md)**.
 * Building the other side, an application that *uses* MCP servers, is **[Clients](../client/index.md)**.
@@ -0,0 +1,49 @@
 # Installation
 The Python SDK is on PyPI as [`mcp`](https://pypi.org/project/mcp/). It requires **Python 3.10+**.
 These docs describe **v2**, which is in beta, so the version pin is not optional yet:
 === "uv"
    ```bash
    uv add "mcp[cli]==2.0.0b1"
    ```
 === "pip"
    ```bash
    pip install "mcp[cli]==2.0.0b1"
    ```
 !!! warning "Why the pin"
    Installers never select a pre-release unless you name one, so an unpinned `uv add "mcp[cli]"`
    gives you the latest **v1.x** release, which these docs do not describe. Check the
    [release history](https://pypi.org/project/mcp/#history) for the newest beta before you copy
    the line above.
    The same applies to one-off commands: `uv run --with "mcp==2.0.0b1" ...`, not `uv run --with mcp ...`.
    If your *package* depends on `mcp`, add a `<2` upper bound (for example `mcp>=1.27,<2`) before
    the stable v2 lands so the major version bump doesn't surprise you.
 ## What gets installed
 You don't need to know any of this to use the SDK, but if you're wondering what each dependency is for:
 * `mcp-types`: every protocol type (requests, results, content blocks) as its own package, versioned in lockstep with the SDK. Every `from mcp_types import ...` in these docs is this package.
 * [`anyio`](https://anyio.readthedocs.io/): the async runtime. The whole SDK is written against anyio, so it runs on either `asyncio` or `trio`.
 * [`pydantic`](https://docs.pydantic.dev/): what every `mcp_types` model is built on, plus all schema generation and validation.
 * [`pydantic-settings`](https://docs.pydantic.dev/latest/concepts/pydantic_settings/): server configuration via `MCP_*` environment variables and `.env` files.
 * [`httpx`](https://www.python-httpx.org/) and [`httpx-sse`](https://pypi.org/project/httpx-sse/): the HTTP client behind the Streamable HTTP and SSE *client* transports.
 * [`starlette`](https://www.starlette.io/), [`uvicorn`](https://www.uvicorn.org/), [`sse-starlette`](https://pypi.org/project/sse-starlette/), and [`python-multipart`](https://pypi.org/project/python-multipart/): the HTTP *server* transports.
 * [`jsonschema`](https://pypi.org/project/jsonschema/): validates a tool's structured output against its declared output schema.
 * [`pyjwt[crypto]`](https://pyjwt.readthedocs.io/): OAuth token handling for authorization.
 * [`opentelemetry-api`](https://opentelemetry-python.readthedocs.io/): just the lightweight API, so the SDK's tracing middleware costs nothing unless you install an OpenTelemetry SDK and exporter yourself.
 * [`typing-extensions`](https://typing-extensions.readthedocs.io/) and [`typing-inspection`](https://pypi.org/project/typing-inspection/): modern typing features on Python 3.10.
 * [`pywin32`](https://pypi.org/project/pywin32/): Windows only, used for `stdio` subprocess management.
 ## Optional extras
 * `mcp[cli]` adds [`typer`](https://typer.tiangolo.com/) and [`python-dotenv`](https://pypi.org/project/python-dotenv/) for the `mcp` command-line tool (`mcp dev`, `mcp run`, `mcp install`). You'll want this during development; you may not need it in a deployed server.
 * `mcp[rich]` adds [`rich`](https://rich.readthedocs.io/) for nicer server logs.
@@ -0,0 +1,182 @@
 # Connect to a real host
 A **host** is the application your server ends up inside: Claude Desktop, Claude Code, an IDE. The host is what the user talks to. Inside it, an MCP **client** launches your server as a child process and speaks to it over that process's stdin and stdout.
 Which means connecting to a host is one act: you tell it **the command that starts your server**. Everything on this page (two CLI commands, three JSON files) is a different place to put that same command.
 ## One server, every host
 ```python title="server.py" hl_lines="3 33-34"
 --8<-- "docs_src/real_host/tutorial001.py"
 ```
 Two tools and a resource, one file. Three things about that file matter to every host below:
 * `mcp.run()` with no arguments starts a **stdio** server: it blocks, reads protocol messages on stdin, and writes them on stdout. That is the transport every host on this page speaks. The host starts your file as a child process and owns those two pipes, which is why connecting is only ever "here is the command". You never pick a port, and nothing listens on one.
 * `run()` is under `if __name__ == "__main__":`. Everything below **imports** this file rather than executing it, so an unguarded `run()` would start a server the moment anything loaded the module.
 * The server object is a module-level global named `mcp`. That's the name `mcp run` looks for (`server` and `app` also work). Call it something else and you name it explicitly: `mcp run server.py:bookshop`.
 That is the last line of Python on this page. From here down it is all host configuration.
 ## The launch command
 Every host below gets the same command:
 ```bash
 uv run --with "mcp[cli]==2.0.0b1" mcp run /absolute/path/to/server.py
 ```
 One command for all of them because `uv run --with` resolves the pinned SDK into a fresh environment on the spot: it works from any directory, needs no project and no virtual environment to activate, and always gets the exact `mcp` version these docs describe. That matters here more than anywhere else, because a host launches your server from *its* working directory with a near-empty environment, not from your shell.
 It is also the command `mcp install` writes into Claude Desktop's config for you (below), so what you type by hand and what the tool generates agree.
 !!! warning "The version pin is not optional"
    v2 of this SDK is in beta, and installers never select a pre-release unless you name one. An
    unpinned `--with "mcp[cli]"` gives you the latest **v1.x**, which these docs do not describe.
    Use the exact pin from **[Installation](installation.md)**.
 !!! tip "If a host can't find `uv`"
    A host spawns your server with a minimal `PATH`, and `uv` may not be on it. Replace the bare
    `uv` with the absolute path from `which uv` (macOS/Linux) or `where uv` (Windows). That is
    exactly what `mcp install` writes.
 !!! note "This page is the local story"
    Everything here runs your server on the machine the host is on: the host launches your
    file, over stdio. That is exactly right for a personal or single-machine tool. To give a
    server to people who do *not* have your file, you hand out a **URL**, not a command: the
    same `mcp` object served over Streamable HTTP. **[Running your server](../run/index.md)**
    is that decision in one table, and **[Deploy & scale](../run/deploy.md)** is the road from
    there to a real hostname.
    And a host is nothing more than an application with an MCP client inside it, so your own
    Python can play the host's part: **[Client transports](../client/transports.md)** launches
    this same file as a subprocess with `stdio_client(...)`, and **[Testing](testing.md)**
    connects to it in memory with no process at all.
 ## Claude Desktop
 The one host the SDK can configure for you:
 ```bash
 uv run mcp install server.py
 ```
 That's it. `mcp install` imports the file to read the server's name, finds Claude Desktop's config file, and writes the launch command into it. Along the way it converts your path to an absolute one, so you don't have to.
 There is nothing to be mystified by. This is the entry it writes:
 ```json
 {
  "mcpServers": {
    "Bookshop": {
      "command": "/absolute/path/to/uv",
      "args": [
        "run",
        "--frozen",
        "--with",
        "mcp[cli]==2.0.0b1",
        "mcp",
        "run",
        "/absolute/path/to/server.py"
      ]
    }
  }
 }
 ```
 That's the launch command from the section above with two additions: the absolute path to `uv`, and `--frozen` so `uv` never rewrites a lockfile it happens to be near. It lands in `claude_desktop_config.json`, which lives at:
 * **macOS**: `~/Library/Application Support/Claude/claude_desktop_config.json`
 * **Windows**: `%APPDATA%\Claude\claude_desktop_config.json`
 You can write that file by hand. `mcp install` exists so you don't make the two classic mistakes (a relative path, a missing version pin) while doing it.
 Fully quit Claude Desktop (not just its window) and reopen it.
 !!! warning
    `mcp install` fails with `Claude app not found` if Claude Desktop's config *directory* doesn't
    exist yet. Install Claude Desktop and run it once: that's what creates the directory.
 !!! tip
    Claude Desktop starts your server in its own process, so your shell's environment variables are
    not there. `uv run mcp install server.py -v API_KEY=abc123` (or `-f .env`) records them in the
    entry's `env` field. `--name` overrides the entry name; it defaults to the server's `name`.
 ## Claude Code
 There is no file to edit. Register the server with the `claude` CLI; everything after `--` is the launch command.
 ```bash
 claude mcp add bookshop -- uv run --with "mcp[cli]==2.0.0b1" mcp run /absolute/path/to/server.py
 ```
 Run `/mcp` inside a Claude Code session to confirm `bookshop` is connected and its tools are listed.
 ## Cursor
 Create `.cursor/mcp.json` in your project root.
 ```json
 {
  "mcpServers": {
    "bookshop": {
      "command": "uv",
      "args": ["run", "--with", "mcp[cli]==2.0.0b1", "mcp", "run", "/absolute/path/to/server.py"]
    }
  }
 }
 ```
 The same `command` plus `args`, under the same `mcpServers` key Claude Desktop uses. The server appears in Cursor's MCP settings with both tools listed.
 ## VS Code
 Create `.vscode/mcp.json` in your project root.
 ```json
 {
  "servers": {
    "bookshop": {
      "type": "stdio",
      "command": "uv",
      "args": ["run", "--with", "mcp[cli]==2.0.0b1", "mcp", "run", "/absolute/path/to/server.py"]
    }
  }
 }
 ```
 Two differences from Cursor's file, and they are the only two: the wrapper key is `servers`, not `mcpServers`, and each entry declares its `type`. Confirm the trust prompt, then **MCP: List Servers** in the Command Palette shows `bookshop` running.
 !!! note
    You need VS Code 1.99 or later with the **GitHub Copilot** extension signed in (Copilot Free is
    enough), and Copilot Chat must be in **Agent** mode, because no other mode calls tools.
 ## It doesn't show up
 Before you touch any host config, run the launch command yourself:
 ```bash
 uv run --with "mcp[cli]==2.0.0b1" mcp run /absolute/path/to/server.py
 ```
 Nothing prints, and it doesn't return. That silence is correct: a stdio server is waiting for a host to speak first on stdin (`Ctrl-C` to stop it). A traceback or an immediate exit is the real bug, and now you can read it instead of guessing at it through a host.
 Once that command sits and waits, what's left is almost always one of three things:
 * **A relative path.** The host launches your server from *its* working directory, not the one you registered from. `server.py` where `/absolute/path/to/server.py` is needed is the single most common failure. If the host can't find `uv` either, that path has to be absolute too.
 * **The host is still running its old config.** Hosts read their config at launch. Claude Desktop in particular has to be *fully quit* (not just its window closed) and reopened before an edit to `claude_desktop_config.json` takes effect.
 * **Something reached stdout.** On stdio, stdout *is* the protocol. One stray `print()` and the host reads a corrupt message and drops the connection. Log with the `logging` module, which writes to stderr. **[Logging](../handlers/logging.md)** has the whole story.
 Claude Desktop keeps a log per server: `mcp-server-<NAME>.log` is your server's stderr, next to `mcp.log` for connections, under `~/Library/Logs/Claude` on macOS and `%APPDATA%\Claude\logs` on Windows.
 For anything past those three, **[Troubleshooting](../troubleshooting.md)** is the page.
 ## Recap
 * A **host** (Claude Desktop, an IDE) runs an MCP client that launches your server as a child process over stdio. Connecting means giving it one launch command.
 * That command is `uv run --with "mcp[cli]==2.0.0b1" mcp run /absolute/path/to/server.py`: version-pinned, no venv to activate, works from any directory. The pin is mandatory while v2 is in beta.
 * **Claude Desktop** is the one host `mcp install` configures for you. It writes that same command (plus the absolute path to `uv`) into `claude_desktop_config.json`, so you never have to.
 * **Claude Code** is `claude mcp add bookshop -- <launch command>`. **Cursor** is `.cursor/mcp.json` under `mcpServers`. **VS Code** is `.vscode/mcp.json` under `servers`, each entry with a `type`.
 * Absolute paths everywhere, restart the host after editing its config, and never let anything but the SDK write to stdout.
 Every host on this page connected to the same file, with the same command. What that file can *expose* is the rest of these docs: **[Tools](../servers/tools.md)**, **[Resources](../servers/resources.md)**, and every transport besides stdio in **[Running your server](../run/index.md)**.
@@ -0,0 +1,107 @@
 # Testing
 The Python SDK ships a `Client` class with an **in-memory transport**: pass it your server object and it connects to it directly.
 No subprocess. No port. No transport at all. It's the same idea as FastAPI's `TestClient`.
 ## Basic usage
 Let's assume you have a simple server with a single tool:
 ```python title="server.py"
 --8<-- "docs_src/testing/tutorial001.py"
 ```
 To run the test below you'll need two extra (development) dependencies:
 === "uv"
    ```bash
    uv add --dev pytest inline-snapshot
    ```
 === "pip"
    ```bash
    pip install pytest inline-snapshot
    ```
 !!! info
    These docs assume you already know [`pytest`](https://docs.pytest.org/en/stable/).
    [`inline-snapshot`](https://15r10nk.github.io/inline-snapshot/latest/) is what the test below
    uses to assert on the whole result object in one line. It records the output of a test as the
    `snapshot(...)` literal you see. If you'd rather not use it, drop the import and assert on the
    fields you care about (`result.content[0].text == "3"`) like in any other test.
 Now the test:
 ```python title="test_server.py"
 import pytest
 from inline_snapshot import snapshot
 from mcp import Client
 from mcp_types import CallToolResult, TextContent
 from server import mcp
@pytest.fixture
 def anyio_backend():  # (1)!
    return "asyncio"
@pytest.fixture
 async def client():  # (2)!
    async with Client(mcp, raise_exceptions=True) as c:
        yield c
@pytest.mark.anyio
 async def test_call_add_tool(client: Client):
    result = await client.call_tool("add", {"a": 1, "b": 2})
    assert result == snapshot(
        CallToolResult(
            content=[TextContent(type="text", text="3")],
            structured_content={"result": 3},
        )
    )
 ```
 1. If you are using `trio`, return `"trio"` instead. See the [anyio documentation](https://anyio.readthedocs.io/en/stable/testing.html#specifying-the-backends-to-run-on) for the details.
 2. The fixture yields a connected client. Every test that takes `client` gets a fresh in-memory connection to the same server.
 There you go! You can now extend your tests to cover more scenarios.
 ## Why `raise_exceptions=True`?
 Two different things can go wrong, and this flag only touches one of them.
 An exception inside one of **your tools** is not a protocol failure. It becomes a normal result with
 `is_error=True`, and the model reads the message. `raise_exceptions` doesn't change that: with or
 without it, `call_tool` returns the same `is_error=True` result. There's a whole page on it:
 **[Handling errors](../servers/handling-errors.md)**.
 A failure **outside** a tool body is different. On the connection `Client(mcp)` gives you, the
 server sanitises it into a generic `"Internal server error"` before the client sees it. You should
 never leak the details of an unexpected crash to a remote caller. In a test that is exactly what
 you *don't* want, and it is what `raise_exceptions=True` changes: your test sees the real message
 instead of the sanitised one.
 Leave it on in tests. It has no meaning in production code.
 ## In-process by default
 !!! note
    `Client(mcp)` connects in-process and is **era-neutral** by default: it probes the server and
    picks the appropriate protocol path. Pin `mode="legacy"` if your test exercises legacy-specific
    semantics (sampling or elicitation push, `message_handler`), and drop `raise_exceptions=True`
    there: a legacy connection never sanitises in the first place, and the flag re-raises the
    failure inside the server task instead of in your test.
 That one line is also why these docs can promise you that their examples work: every
 example file is exercised by the SDK's own test suite, almost all of them through exactly this
 client. You're using the same tool the SDK uses on itself.
 You have a working, tested server. Putting it inside a real application (Claude Desktop, an
 IDE) is **[Connect to a real host](real-host.md)**; every other way to serve it is
 **[Running your server](../run/index.md)**.
@@ -0,0 +1,129 @@
 # The Context
 A tool's arguments come from the model. Everything else (the request you are serving, the server you live in, a way to talk back to the client) comes from one object: the **`Context`**.
 You don't construct it and you don't configure it. You ask for it.
 ## Ask for it
 Add a parameter annotated with `Context` to any tool:
 ```python title="server.py" hl_lines="2 8"
 --8<-- "docs_src/context/tutorial001.py"
 ```
 * The SDK builds a fresh `Context` for every request and passes it in.
 * The parameter **name doesn't matter**. `ctx`, `context`, `c`: the SDK finds it by its annotation.
 * Resources and prompts can declare one too, the same way.
 * `ctx.request_id` is the id of the request your function is serving right now.
 !!! info
    If you've used FastAPI, you've seen this move: declare a parameter with the framework's own type
    (`Request` there, `Context` here) and the framework supplies it. Nothing to register, nothing to
    configure: the type annotation is the whole mechanism.
 ### Invisible to the model
 This is the part to internalise. Here is the input schema `tools/list` reports for `search_books`:
 ```json
 {
  "type": "object",
  "properties": {
    "query": {"title": "Query", "type": "string"}
  },
  "required": ["query"],
  "title": "search_booksArguments"
 }
 ```
 One property. `ctx` is not an argument: it never appears in the schema, the model is never told about it, and no client can fill it in. It's a contract between you and the SDK, invisible on the wire.
 ### Try it
 Run the server with the MCP Inspector:
 ```console
 uv run mcp dev server.py
 ```
 The form for `search_books` has a single `query` field. Call it with `dune`:
 ```text
 [request 3] Found 3 books matching 'dune'.
 ```
 The number is whichever request this happened to be. Call the tool again and it changes: every request gets its own `Context`.
 ## What it gives you
 The injected object is small. Besides `request_id`:
 * `await ctx.read_resource(uri)`: read one of the server's **own** resources from inside a tool. The next section.
 * `await ctx.report_progress(progress, total, message)`: stream progress back to the caller during a long call. The whole story is in **[Progress](progress.md)**.
 * `await ctx.elicit(message, schema)` and `await ctx.elicit_url(...)`: pause the tool and ask the user a question. That's **[Elicitation](elicitation.md)**.
 * `ctx.session`: the server's side of the conversation with this client. Notifications you send to the client live here; the last section uses it.
 * `ctx.headers`: the request headers the transport carried, or `None` on stdio. Read a custom header with `(ctx.headers or {}).get("x-...")`. Headers are client-supplied input - fine for a locale or a feature flag, never an identity.
 * `ctx.request_context`: the raw per-request record. The field you'll reach for is `lifespan_context`, the object your startup code yielded (see **[Lifespan](lifespan.md)**).
 Logging is deliberately not on that list. A server logs with Python's `logging` module, like any other Python program. **[Logging](logging.md)** is the short page on why.
 !!! tip
    Injection only happens for the function you registered. A helper that your tool calls doesn't get
    its own `Context`; pass `ctx` down as an ordinary argument. There is no ambient
    "current context" to fetch from somewhere else.
 ## Read your own resources
 A server's resources aren't only for clients. A tool can read them too:
 ```python title="server.py" hl_lines="16"
 --8<-- "docs_src/context/tutorial002.py"
 ```
 `ctx.read_resource` resolves the URI through the same registry that serves `resources/read`, so a tool gets what a client would get: an iterable of `ReadResourceContents`, one per content block. For this URI there is one:
 ```python
 contents.content    # 'fiction, non-fiction, poetry'
 contents.mime_type  # 'text/plain'
 ```
 * `content` is exactly what `genres()` returned. One source of truth: the client browses the resource, your tools consume it, nobody copies the string.
 * `describe_catalog`'s only parameter is the `Context`, so its input schema has **no properties at all**. The model calls it with `{}`.
 ## Tell the client the list changed
 What a server offers is not fixed at import time. Register a tool at runtime, then tell the client:
 ```python title="server.py" hl_lines="15-16"
 --8<-- "docs_src/context/tutorial003.py"
 ```
 * `mcp.add_tool(recommend_book)` registers a plain function as a tool: name, description and schema derived exactly as `@mcp.tool()` would have.
 * `await ctx.session.send_tool_list_changed()` sends `notifications/tools/list_changed`. A client that receives it calls `tools/list` again and sees `recommend_book`.
 The siblings are `send_resource_list_changed()`, `send_prompt_list_changed()`, and `send_resource_updated(uri)` for a change to one specific resource.
 On a 2026-07-28 connection, clients receive change notifications only on a `subscriptions/listen` stream they opened, so the `send_*` methods above do not reach those streams. The `Context` publish methods deliver to every subscribed stream at once: `await ctx.notify_tools_changed()`, `await ctx.notify_prompts_changed()`, `await ctx.notify_resources_changed()`, and `await ctx.notify_resource_updated(uri)`. The whole story, including scaling out across replicas, is in **[Subscriptions](subscriptions.md)**.
 !!! check
    Before anyone runs `enable_recommendations`, the tool you are promising does not exist. Call it
    anyway and the result is an error the model can read:
    ```text
    Unknown tool: recommend_book
    ```
    Run `enable_recommendations`, and the very same call succeeds. The tool list is genuinely
    dynamic: `tools/list` reflects whatever is registered *right now*.
 ## Recap
 * Annotate a parameter with `Context` (in a tool, a resource, or a prompt) and the SDK injects it. The name is yours.
 * It is invisible to the model: the input schema only ever contains your real arguments.
 * `ctx.request_id` identifies the request; `ctx.request_context.lifespan_context` is what your startup yielded.
 * `await ctx.read_resource(uri)` lets a tool read the server's own resources.
 * `ctx.session` is the channel back to the client: `send_tool_list_changed()` and its siblings tell it to re-fetch a list you changed.
 * Progress reporting and elicitation also start at `Context`; each has its own page.
 Parameters the model never sees, filled by your own functions, are **[Dependencies](dependencies.md)**.
@@ -0,0 +1,158 @@
 # Dependencies
 A tool's arguments come from the model. Some values never should: a price looked up from your records, a confirmation only a person can give, anything the model could get wrong by inventing it.
 **Dependencies** are parameters filled by your own functions. You annotate the parameter, name the function, and the SDK calls it before your tool runs.
 ## Declare one
 Wrap the parameter's type in `Annotated[...]` and add `Resolve(fn)`:
 ```python title="server.py" hl_lines="18-19 23"
 --8<-- "docs_src/dependencies/tutorial001.py"
 ```
 * `check_stock` is a **resolver**: a plain function the SDK runs before `reserve_book`, whose return value becomes the `stock` argument.
 * Its `title` parameter is the tool's own `title` argument, matched **by name**. The resolver sees exactly the validated value the tool body will see.
 * The tool body starts from a `Stock` that already exists. No lookup code in the tool, no "what if it's missing" preamble.
 !!! info
    If you've used FastAPI, this is `Depends`. Same move, same reason: the function declares what
    it needs, the framework supplies it, and the wiring lives in the type annotation.
 ### Invisible to the model
 Here is the input schema `tools/list` reports for `reserve_book`:
 ```json
 {
  "type": "object",
  "properties": {
    "title": {"title": "Title", "type": "string"}
  },
  "required": ["title"],
  "title": "reserve_bookArguments"
 }
 ```
 One property. Like the `Context` in **[The Context](context.md)**, a resolved parameter is a contract between you and the SDK: `stock` is not in the schema, the model is never told about it, and a client that sends a `stock` value anyway is ignored. The resolver's value is the only one your tool can receive.
 That last part is the point. A parameter the model cannot supply is a parameter the model cannot get wrong.
 ### Try it
 Run the server with the MCP Inspector:
 ```console
 uv run mcp dev server.py
 ```
 The form for `reserve_book` has a single `title` field. `stock` is nowhere on it. Call it with `Dune`:
 ```text
 Reserved 'Dune' (6 copies left).
 ```
 The tool body never looked anything up: `check_stock` ran first, and the `Stock` it returned arrived as an argument. Try `Neuromancer` and the same resolver hands the tool a zero.
 !!! tip
    You could just call `check_stock(title)` in the tool body. Declare it as a dependency when the
    value deserves more than a helper call: every tool that needs stock declares the same parameter,
    and the SDK runs the resolver at most once per call, no matter how many declare it. The next
    sections add the rest: resolvers that depend on each other, and resolvers that ask the user.
 ## Dependencies of dependencies
 A resolver can declare its own dependencies, with the same annotation:
 ```python title="server.py" hl_lines="22 29-30"
 --8<-- "docs_src/dependencies/tutorial002.py"
 ```
 * `estimate_delivery` depends on `check_stock`. The SDK runs the graph in order: stock first, then the estimate, then the tool.
 * Both `stock` and `delivery` ultimately need `check_stock`, but it runs **once per call**. One inventory lookup, two consumers.
 * There is nothing to register. The graph *is* the annotations.
 !!! check
    Don't take once-per-call on faith. Put a `print` in `check_stock` and call `order_book` from the
    Inspector: one line per call. Two consumers, one lookup.
 The SDK analyses the graph when the tool is registered, not when it is called. A parameter it can't classify - not a `Context`, not a `Resolve(...)`, not a tool argument's name - and a cycle of resolvers both raise `InvalidSignature` at startup. Your server fails before a client ever connects, with the offending parameter or resolver named in the error.
 A resolver's parameters resolve exactly like a tool's: another `Resolve(...)`, the tool's own arguments by name, or the `Context` - `ctx.headers`, the lifespan object, all of it.
 !!! warning
    On HTTP transports the `Context` includes `ctx.headers`. Headers are **client-supplied input**,
    like any tool argument: fine for a locale or a feature flag, never an identity. Who the caller
    is comes from your authorization layer (**[Authorization](../run/authorization.md)**), not from a header anyone can set.
 !!! tip
    *Once per call* means exactly that: the next `tools/call` runs `check_stock` again. A resource
    that should outlive a request - a database pool, an HTTP client - belongs in **[Lifespan](lifespan.md)**, and
    a resolver can reach it through `ctx.request_context.lifespan_context`.
 ## Ask when you must
 A resolver doesn't have to know the answer. It can return `Elicit(message, Model)` and the SDK asks the user - the **[Elicitation](elicitation.md)** machinery, run for you:
 ```python title="server.py" hl_lines="26-32 39"
 --8<-- "docs_src/dependencies/tutorial003.py"
 ```
 * In stock: `confirm_backorder` returns a `Backorder` directly. **No question, no round-trip.** The user is only interrupted when their answer matters.
 * Out of stock: the SDK sends the elicitation, validates the answer against `Backorder`, and injects it. Your resolver never touches the protocol.
 * The tool reads `backorder.confirm` like any other argument. Answering **no** is still an answer: the elicitation is accepted with `confirm=False`, the tool runs, and no order is placed. Asking became a precondition, not plumbing in the tool body.
 And if the user won't answer at all - declines the question, or cancels it?
 !!! check
    Run `order_book` for `Neuromancer` and decline the question. With the annotation written as
    `Annotated[Backorder, Resolve(...)]` the tool body never runs; the call fails with an error
    result the model can read:
    ```text
    Error executing tool order_book: Resolver for parameter 'backorder' could not resolve: elicitation was decline
    ```
 That's the right default for a precondition: no answer, no order. When declining is an outcome your tool wants to handle - skip the backorder but still suggest another title - annotate `ElicitationResult[Backorder]` instead and the tool receives the full accept/decline/cancel outcome to branch on. **[Elicitation](elicitation.md)** shows that form, and everything else about asking: the schema rules, the three answers, the client's side of the conversation.
 !!! info
    The framework picks the question's transport from the negotiated protocol version; the code
    above is identical on both. On **2026-07-28** and later the question rides inside a
    multi-round-trip `tools/call` - the server returns it, the client's `elicitation_callback`
    answers it, and the `Client` retries the call for you (**[Multi-round-trip requests](multi-round-trip.md)**). On
    **2025-11-25** and earlier it is a synchronous elicitation request mid-call. Each question is
    asked exactly once per call - a guarantee about the question, not the resolver. In the
    multi-round-trip form any resolver may run again whenever the call resumes after a question,
    so code before a `return Elicit(...)` runs on each of those rounds; the recorded answer then
    satisfies the repeated question without prompting the user again. A recorded answer is only
    ever consulted when the resolver asks; a resolver that answers *without* asking, like
    `check_stock`, always supplies its own computed value. Because each answer is matched back to
    its question, an eliciting resolver must derive its question deterministically from the
    tool's arguments and earlier answers. A per-call generated value (a `default_factory` id, a
    timestamp) is re-derived on each round and must not appear in a question the answer is meant
    to bind to. A question built from such volatile data makes every recorded answer look stale,
    so the server re-asks it on every round until the client's round limit ends the call.
 ## Ask the client, not the user
 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"
 --8<-- "docs_src/dependencies/tutorial004.py"
 ```
 * The framework routes these exactly like `Elicit`: inside the multi-round-trip `tools/call` on **2026-07-28**, over the standalone server->client request on **2025-11-25**. An undeclared capability refuses the call with a `-32021` protocol error (`sampling`, `roots`, form-mode `elicitation`; `sampling.tools` when the request carries `tools` or `tool_choice`).
 * Everything the info box above says about questions applies unchanged: a `Sample` request is matched to its recorded result by its exact rendering, so build it deterministically from the tool's arguments and earlier answers; the client then pays for the LLM call once per tool call, not once per round. The recorded result rides `request_state` for the rest of the call, so a very large completion makes every remaining round-trip heavier.
 * The standalone sampling and roots *features* are deprecated at 2026-07-28 (SEP-2577). New servers that need the client's model ask through this carrier; servers that don't should integrate with an LLM provider directly. `include_context` values other than `"none"` are themselves deprecated; avoid them.
 ## Recap
 * `Annotated[T, Resolve(fn)]` on a tool parameter: the SDK runs `fn` and injects its return value.
 * A resolved parameter is invisible to the model and cannot be supplied by a client. Values the model must not invent - prices, identities, permissions - belong here.
 * A resolver's parameters are resolved the same way: the `Context`, another `Resolve(...)`, or a tool argument by name. The graph runs each resolver at most once per round, however many consumers it has; each question is asked exactly once, and any resolver may run again when a call resumes after a question.
 * Bad graphs fail at registration with `InvalidSignature`, not mid-call.
 * Return `Elicit(message, Model)` to ask the user, only when you have to. Unwrapped annotations abort on decline; `ElicitationResult[T]` lets the tool branch.
 * Return `Sample(...)` or `ListRoots()` to ask the client for an LLM completion or the roots list; the plain result is injected.
 The state your server builds once at startup, and how a handler reaches it, is the **[Lifespan](lifespan.md)** page.
@@ -0,0 +1,185 @@
 # Elicitation
 A tool that is halfway through its job and missing one answer doesn't have to fail.
 **Elicitation** lets it ask. In the middle of a tool call the user gets a question, and their answer comes back into the same function call.
 There are two modes:
 * **Form mode**: you need a value (a confirmation, a date, a quantity). You describe the fields, the client renders the form.
 * **URL mode**: you need the user to go somewhere else (an OAuth consent screen, a payment page). Nothing they do there passes through the protocol.
 And there are two ways to ask. The one to reach for is a **resolver**: you hang the question on a parameter, and the SDK asks - on any connection, whatever protocol era the client speaks. The direct way, `await ctx.elicit(...)`, is a request from the *server* to the *client*, a channel that only exists for a client on a legacy connection (spec version 2025-11-25 or earlier). Both are on this page; start with the resolver.
 ## Ask with a resolver
 A question that gates the whole tool - *are you sure? which of the three matching accounts?* - can be lifted out of the tool body into a **resolver**, and the framework asks it for you.
 A parameter annotated `Annotated[T, Resolve(fn)]` is filled by running `fn` before the tool body. The resolver returns the value directly when it already knows it, or returns `Elicit(...)` to have the framework ask:
 ```python title="server.py" hl_lines="24-30 35-36"
 --8<-- "docs_src/elicitation/tutorial004.py"
 ```
 * `confirm_delete` reads the tool's own `path` argument by name, lists the folder, and **only elicits when it must** - an empty folder resolves to `Confirm(ok=True)` with no round-trip to the client.
 * `delete_folder` annotates `ElicitationResult[Confirm]`, so the framework injects the whole outcome and the tool `match`es every case: accept-and-confirm, accept-but-keep (`ok=False`), decline, cancel.
 * The `confirm` parameter never appears in the tool's input schema - the client supplies `path`, the resolver supplies `confirm`.
 Annotate the unwrapped model (`Annotated[Confirm, Resolve(confirm_delete)]`) instead when the tool doesn't need to branch: it receives the model on accept and the call aborts with an error on decline or cancel.
 A resolver works on **every** connection. For a client on a legacy connection the SDK sends it the question directly; on a **2026-07-28** connection the SDK *returns* the question from the call, and the client's next attempt carries the answer. Your resolver never knows the difference; what happens underneath is **[Multi-round-trip requests](multi-round-trip.md)**.
 Asking is only one thing a resolver can do. The general mechanism - dependencies that compute without asking, dependencies of dependencies, what the model can and cannot supply - is the **[Dependencies](dependencies.md)** page.
 ## Ask from inside the tool
 A tool can also stop in the middle of its own body and ask.
 !!! warning
    `ctx.elicit()` and `ctx.elicit_url()` are requests from the *server* to the *client* - a
    channel that only exists for a client on a legacy connection (spec version **2025-11-25**
    or earlier). On a **2026-07-28** connection there are no server-initiated requests, so
    these calls fail. A resolver works on both. **[Protocol versions](../protocol-versions.md)**
    has the whole story.
 `await ctx.elicit()` takes a message and a Pydantic model:
 ```python title="server.py" hl_lines="9-11 20-23 25"
 --8<-- "docs_src/elicitation/tutorial001.py"
 ```
 * The **`Context`** parameter is what gives you `ctx.elicit`; any tool can take one. That object has its own page: **[The Context](context.md)**.
 * `AlternativeDate` is the **schema** of the answer you want.
 * The tool is `async def`. It has to be: it stops in the middle and waits for a person.
 * On any other date the tool returns straight away. It only asks when it has to.
 * The date the user accepts goes back through `book_table` itself. An answer is input like any other: an alternative that is also fully booked gets asked about again, not confirmed blind.
 ### What the client receives
 The client gets your message and, next to it, a JSON Schema generated from the model:
 ```json
 {
  "properties": {
    "accept_alternative": {
      "description": "Try another date?",
      "title": "Accept Alternative",
      "type": "boolean"
    },
    "date": {
      "default": "2025-12-26",
      "description": "Alternative date (YYYY-MM-DD)",
      "title": "Date",
      "type": "string"
    }
  },
  "required": ["accept_alternative"],
  "title": "AlternativeDate",
  "type": "object"
 }
 ```
 That schema is the form. `Field(description=...)` is the label; a default pre-fills the input and makes the field optional. It's the same Pydantic-to-JSON-Schema machinery **[Tools](../servers/tools.md)** describes for a tool's arguments.
 !!! warning
    An elicitation schema is not as expressive as a tool's input schema. Flat, primitive fields
    only: `str`, `int`, `float`, `bool`, or a `Literal` of strings (it becomes an `enum`).
    Put a model inside the model and `ctx.elicit` raises before anything is sent to the client:
    ```text
    TypeError: Elicitation schema field 'address' rendered as {'$ref': '#/$defs/Address'}, which is not a valid PrimitiveSchemaDefinition
    ```
    You are interrupting a person mid-task. If the answer needs nesting, it should have been an
    argument to the tool.
 ### The three answers
 `result.action` tells you what the user did, and there are exactly three possibilities:
 * `"accept"`: they submitted the form. `result.data` is an `AlternativeDate` instance, already validated.
 * `"decline"`: they said no.
 * `"cancel"`: they dismissed the question without choosing.
 `result.data` only exists on `"accept"`, which is why the example checks `result.action` first. Your type checker enforces the order: after `result.action == "accept"`, `result.data` is an `AlternativeDate`; before it, there is no `.data` at all.
 A refusal is not an error. The tool decides what declining means (here, no booking) and answers the model normally.
 !!! tip
    The answer is validated against your model before your code sees it. A client that sends
    `"maybe"` for a `bool` doesn't corrupt your booking: the call fails with a
    schema-mismatch error, your `if` never runs.
 ## Send the user to a URL
 Some things must not go through the model or the client: credentials, card numbers, OAuth consent. For those you don't ask for data; you ask the user to go somewhere:
 ```python title="server.py" hl_lines="10-14 23"
 --8<-- "docs_src/elicitation/tutorial002.py"
 ```
 * `ctx.elicit_url()` takes the message, the **URL** to visit, and an `elicitation_id` you choose: any string that identifies this elicitation within your server.
 * The result has an action and nothing else. `"accept"` means the user agreed to open the URL, **not** that they finished what's on the other side.
 * The payment happens out of band, between the user's browser and your payment provider. No content ever comes back through MCP.
 Look at the second tool. When your server learns the out-of-band flow finished (a webhook, a poll; here it's modelled as a second tool), `ctx.session.send_elicit_complete(...)` sends `notifications/elicitation/complete` with the same `elicitation_id`. That is how the client knows it can stop showing *"waiting for payment..."*. Without it, the client can only guess.
 ## The client side
 Servers ask. Clients answer by passing an **`elicitation_callback`** to `Client(...)`:
 ```python title="client.py" hl_lines="7-8 19"
 --8<-- "docs_src/elicitation/tutorial003.py"
 ```
 * One callback handles both modes. `params` is a union of `ElicitRequestFormParams` and `ElicitRequestURLParams`; `isinstance` is the branch.
 * For a URL, you show `params.url` to the user and return the action they chose. Never any `content`.
 * For a form, a real application renders `params.requested_schema` and returns the user's input as `content`. This one always says yes with a canned answer, which is exactly the callback you want in a test.
 * Passing the callback is also the **capability declaration**: it's how the server learns this client can be asked. The other things a client can answer for a server live in **[Client callbacks](../client/callbacks.md)**.
 !!! info
    Elicitation is a request from the *server* to the *client*, and those only exist on a
    classic-handshake session, which is why this client passes `mode="legacy"`.
    On a **2026-07-28** connection a tool asks by *returning* the question from the call
    instead; that flow is **[Multi-round-trip requests](multi-round-trip.md)**.
 ### Try it
 Start the `ctx.elicit` form-mode `server.py` (the `book_table` one) on Streamable HTTP (**[Running your server](../run/index.md)** has the one-liner), then run the client's `main()` and ask `book_table` for Christmas day.
 The callback prints the question it was sent:
 ```text
 No tables for 2 on 2025-12-25. Would you like to try another date?
 ```
 It answers with `{"accept_alternative": True, "date": "2025-12-27"}`, and the tool, which has been waiting inside `await ctx.elicit(...)` this whole time, finishes the booking:
 ```text
 Booked a table for 2 on 2025-12-27.
 ```
 Now swap in the URL-mode `server.py` and point the same `main()` at `pay_deposit`: the same callback takes the other branch, prints the payment link, and the tool comes back with *"Complete the payment in your browser."* One round trip, mid-call, in both directions.
 !!! check
    Now remove `elicitation_callback=` from the `Client` and call `book_table` for Christmas day
    again. The whole call fails with a protocol error:
    ```text
    Elicitation not supported
    ```
    A client that registered no callback never declared the `elicitation` capability, so there is
    nobody to ask. Your tool didn't get a `"decline"`; it got an exception. Design for it: every
    elicitation needs a sensible answer to "what if I can't ask?".
 ## Recap
 * A parameter annotated `Annotated[T, Resolve(fn)]` is filled by a resolver, which returns `Elicit(...)` when it has to ask. It works on every connection.
 * The schema is a flat Pydantic model: primitive fields only, validated on the way back.
 * `result.action` is `"accept"`, `"decline"` or `"cancel"`; `result.data` exists only on accept.
 * `await ctx.elicit(message, schema=Model)` asks from inside the tool body, and `await ctx.elicit_url(message, url, elicitation_id)` is for everything that must not pass through the model (`ctx.session.send_elicit_complete(elicitation_id)` says the out-of-band part is done). Both are server-to-client requests: they need the client on a legacy connection.
 * The client answers with one `elicitation_callback`, branching on the params type; registering it is what declares the capability.
 * On a 2026-07-28 connection the server returns the question instead of pushing it; the same callback is fed by **[Multi-round-trip requests](multi-round-trip.md)**.
 Everything underneath that return (the retry loop, protecting `requestState`, driving it yourself) is **[Multi-round-trip requests](multi-round-trip.md)**.
@@ -0,0 +1,31 @@
 # Inside your handler
 A handler's arguments come from the client. Everything *else* it can read, and
 everything it can do while it runs, is here.
 What it can read:
 * **[The Context](context.md)** is the one extra parameter any handler can
  ask for: the live request, its headers, its session, and the progress and
  change-notification verbs.
 * **[Dependencies](dependencies.md)** are parameters the model never sees,
  filled in by your own functions with `Resolve`.
 * **[Lifespan](lifespan.md)** covers state your server builds once at
  startup, and how a handler reaches it through the `Context`.
 What it can do while it runs:
 * Ask the user for more input with **[Elicitation](elicitation.md)**, and
  **[Multi-round-trip requests](multi-round-trip.md)**, the 2026-07-28
  pattern that carries it.
 * Ask the client for an LLM completion or its workspace folders with
  **[Sampling and roots](sampling-and-roots.md)**, deprecated but still
  served.
 * Report **[Progress](progress.md)** on something slow.
 * Write logs (to standard error, for whoever operates the server) with
  **[Logging](logging.md)**.
 * Tell subscribed clients that something changed with
  **[Subscriptions](subscriptions.md)**.
 If you haven't registered a handler yet, start with
 **[Tools](../servers/tools.md)**. Every page here assumes you have one.
@@ -0,0 +1,102 @@
 # Lifespan
 Most real servers hold something for their whole life: a database pool, an HTTP client, a loaded model.
 You don't want to build it on every call, and you do want to close it cleanly. That's what the **lifespan** is for.
 ## A typed lifespan
 A lifespan is an `@asynccontextmanager` that receives the server and `yield`s **one object**. Whatever you yield is available to every handler for as long as the server runs.
 ```python title="server.py" hl_lines="25-31 34 38 40"
 --8<-- "docs_src/lifespan/tutorial001.py"
 ```
 Read it bottom-up:
 * `app_lifespan` connects the `Database` **before** the `yield` and disconnects it **after**, in a `finally`. That's startup and shutdown.
 * It yields an `AppContext`, a plain dataclass holding the things you set up. One field today, ten tomorrow.
 * `MCPServer("Bookshop", lifespan=app_lifespan)` is the whole wiring.
 * Inside the tool, the yielded object is `ctx.request_context.lifespan_context`.
 The lifespan runs **once**. It is entered when the server starts (before the first request) and exited when the server stops. Every request in between shares the same `AppContext`.
 !!! info
    If you've written a FastAPI `lifespan`, you already know this. Same decorator, same `yield`, same `finally`.
 ### What the model sees
 Nothing new. `ctx` is a **Context** parameter, so the SDK injects it and it never reaches the input schema:
 ```json
 {
  "type": "object",
  "properties": {
    "genre": {"title": "Genre", "type": "string"}
  },
  "required": ["genre"],
  "title": "count_booksArguments"
 }
 ```
 `genre` is the only argument the model can pass. The lifespan is your server's business.
 `@mcp.resource()` and `@mcp.prompt()` functions can take a `ctx` parameter too, written as a bare `Context` for a reason the next section gets to. Everything `ctx` carries is in **[The Context](context.md)**.
 ### It really is typed
 Look at the annotation again: `ctx: Context[AppContext]`.
 That one type parameter is why `ctx.request_context.lifespan_context` **is** an `AppContext` to your type checker. `.db` autocompletes; `.dbb` is an error before you ever run the server.
 Write a bare `Context` instead and `lifespan_context` is typed as `dict[str, Any]`: the type checker has no way to know what your lifespan yielded. The object is still there at runtime; you've lost the help.
 !!! warning
    `Context[AppContext]` is a **tool-only** spelling. Put it on an `@mcp.resource()` or
    `@mcp.prompt()` function and every call to that handler fails. The client gets an error back,
    and the server log shows why:
    ```text
    Context is not available outside of a request
    ```
    In resources and prompts, write the bare `ctx: Context`. The object your lifespan yielded is
    still `ctx.request_context.lifespan_context` at runtime; you give up the type parameter, not
    the object.
 !!! tip
    There is always a lifespan. If you don't pass one, the SDK's default yields an empty `dict`,
    so `ctx.request_context.lifespan_context` is `{}`, never `None`. That default is also why a
    bare `Context` types it as `dict[str, Any]`.
 ## Watch it happen
 "Startup runs before the first request" is the kind of sentence you should not have to take on faith.
 Strip the server down to the lifecycle: give `Database` a `connected` flag, flip it in `connect()` and `disconnect()`, and add a tool that reports it.
 ```python title="server.py" hl_lines="11 14 17 25 44"
 --8<-- "docs_src/lifespan/tutorial002.py"
 ```
 `database` lives at module level for one reason: so you can look at it from *outside* the server.
 !!! check
    Three moments, three values:
    * Before the server starts, `database.connected` is `False`. Importing the module connected nothing.
    * While it's running, call `database_status` and the result is `"connected"`.
    * Stop the server and the `finally` block runs: `database.connected` is `False` again.
    The work happened exactly where you put it: around the `yield`, not at import time and not per request.
 ## Recap
 * `lifespan=` takes an `@asynccontextmanager` that receives the server and `yield`s one object.
 * Code before the `yield` is startup. The `finally` after it is shutdown.
 * It runs once, around the whole life of the server, not per request.
 * Whatever you `yield` is `ctx.request_context.lifespan_context` in every tool, resource, and prompt.
 * `ctx: Context[AppContext]` makes that access fully typed in tools. Resources and prompts take the bare `Context`.
 * No `lifespan=` means an empty `dict`, never `None`.
 A handler that stops mid-call to ask the user for something only they know is **[Elicitation](elicitation.md)**.
@@ -0,0 +1,78 @@
 # Logging
 Log from a tool the way you log from any other Python function: with the standard library.
 MCP has a protocol-level **logging capability**: a server could push its log messages to the client as notifications, through methods on the `Context` object. The 2026-07-28 revision of the spec **deprecates that capability and does not replace it**, so these docs don't teach it. The full list of what's deprecated and what to do instead is in **[Deprecated features](../deprecated.md)**.
 What you do instead is what you do in every other Python program: the standard library.
 ## A tool that logs
 ```python title="server.py" hl_lines="1 5 13"
 --8<-- "docs_src/logging/tutorial001.py"
 ```
 * `logging.getLogger(__name__)` gives you a logger named after your module. Create it once, at the top.
 * Inside the tool you call `logger.info(...)` like in any other function. Nothing to inject, nothing to `await`, nothing MCP-specific.
 !!! check
    Call the tool and look at the whole result:
    ```python
    result.content             # [TextContent(text="Found 3 books matching 'dune'.")]
    result.structured_content  # {'result': "Found 3 books matching 'dune'."}
    ```
    The log line is nowhere in it. Logging is for **you**, the person operating the server. The model
    never sees it. If the model should read something, `return` it.
 ## Where it goes
 For a **stdio** server this question matters more than usual. The host launched your server as a subprocess and is reading MCP messages from its **stdout**. Standard error is yours.
 The standard library already does the right thing: log output goes to `sys.stderr` by default. Your `logger.info(...)` lines land in the terminal (or wherever the host collects the subprocess's stderr), and the protocol stream stays clean.
 !!! tip
    Never `print()` in a stdio server. `print` writes to **stdout**, and stdout *is* the wire: one stray
    line and the client is trying to parse it as JSON-RPC.
    `logger.debug("got here")` is the same one line of effort and goes to the right place.
 ## The level
 You don't have to call `logging.basicConfig()` yourself. Constructing an `MCPServer` already did, with a handler pointed at standard error, at the level you pass as `log_level=`, so `MCPServer("Bookshop", log_level="DEBUG")` is all it takes to see your `logger.debug(...)` lines.
 The default is `"INFO"`.
 `logging.basicConfig()` never replaces handlers that already exist. If you configure logging yourself before creating the server, your configuration wins.
 ## Try it
 Run the server with the MCP Inspector:
 ```console
 uv run mcp dev server.py
 ```
 Call `search_books` from the **Tools** tab. The Inspector shows you the result: only the return value. The line
 ```text
 Searching for 'dune'
 ```
 went to standard error: the terminal, not the wire.
 !!! info
    If what you actually want is *tracing* (every request, how long it took, whether it failed), you
    don't want log lines, you want spans. Your server already emits them: the SDK traces every
    message with OpenTelemetry out of the box. See **[OpenTelemetry](../run/opentelemetry.md)**.
 ## Recap
 * The MCP protocol's logging capability is deprecated by the 2026-07-28 spec and not replaced. Don't build on it.
 * `logger = logging.getLogger(__name__)` at module level, `logger.info(...)` in the tool. That's the whole pattern.
 * Log output never reaches the model. Only the value you `return` does.
 * Standard error is yours; stdout belongs to the protocol. Never `print()` in a stdio server.
 * `MCPServer(..., log_level="DEBUG")` sets the level, and a logging configuration you made first is left alone.
 Telling connected clients that something on your server changed (the tool list, a resource) is **[Subscriptions](subscriptions.md)**.
@@ -0,0 +1,186 @@
 # Multi-round-trip requests
 Sometimes a tool can't finish in one round trip. It needs something only the user has: a choice, a confirmation, a credential.
 Before 2026-07-28 the server got it by calling **back**: opening its own request to the client (an elicitation, a sampling call) in the middle of handling the original one. The 2026-07-28 spec retires that back-channel.
 Instead, the server **returns**.
 ## Return, don't call back
 The server answers `tools/call` with an **`InputRequiredResult`** instead of a `CallToolResult`. Two of its fields do the work:
 * **`input_requests`**: what the server still needs, as a dict keyed by names the server chose. Each value is an `ElicitRequest`, a `CreateMessageRequest`, or a `ListRootsRequest`.
 * **`request_state`**: an opaque token. The client echoes it back verbatim on the retry. Your server is the only thing that reads it.
 The client fulfils each request, then calls the **same tool again**, carrying its answers in `input_responses` and the token in `request_state`. The server now has what it was missing and returns a normal `CallToolResult`.
 That's the whole protocol. Every leg is an ordinary request from the client to the server. Nothing ever flows the other way.
 ## The server side
 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"
 --8<-- "docs_src/mrtr/tutorial001.py"
 ```
 * `on_call_tool` is typed `-> CallToolResult | InputRequiredResult`. Returning the second one is the entire server-side API.
 * On the first call `params.input_responses` is `None`, so the guard fires and the handler asks instead of answering.
 * On the retry, the `ElicitResult` the client sent is sitting under the **same key** (`"region"`) that the server used in `input_requests`.
 Everything else in that file (the explicit `input_schema`, the hand-built `CallToolResult`) is the ordinary low-level `Server`, covered in **[The low-level Server](../advanced/low-level-server.md)**. This page only adds the second return type.
 ## Beyond tools
 `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"
 --8<-- "docs_src/mrtr/tutorial004.py"
 ```
 * The first round returns the `InputRequiredResult`. On the retry, `ctx.input_responses` holds the answers under the same keys and the function returns its ordinary result — prompt messages here, resource content for a template resource.
 * A `request_state` you set is sealed before it crosses the wire and verified on the echo, like everything else on the server; **[Protecting `requestState`](#protecting-requeststate)** below covers what the seal gives you and when you need to configure keys.
 * An `@mcp.tool()` function can return the result directly the same way, when the dependency form doesn't fit.
 * Static `@mcp.resource()` functions don't participate: they take no `Context`, so they could never read the retry. Only template resources can ask.
 * The era rules below apply unchanged: returning an `InputRequiredResult` on a pre-2026 session is the same `-32603` the warning describes.
 ## The client side
 `Client` runs the loop for you.
 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"
 --8<-- "docs_src/mrtr/tutorial003.py"
 ```
 * That `elicitation_callback` is the same one a pre-2026 server's back-channel `elicitation/create` would have hit. The same is true of `sampling_callback` for `sampling/createMessage` and `list_roots_callback` for `roots/list`: at 2026-07-28 the standalone server->client RPCs are gone, but the identical `ElicitRequest` / `CreateMessageRequest` / `ListRootsRequest` payloads ride inside `input_requests` and dispatch to the same three callbacks. One set of callbacks serves both eras.
 * `call_tool` returns a plain `CallToolResult`. The intermediate rounds are invisible to the caller.
 * `get_prompt` and `read_resource` drive the same loop.
 !!! check
    Leave the callback off and the loop fails on the first round: the SDK's stand-in callback
    answers every elicitation with an error, and `call_tool` raises `MCPError` with the message
    *"Elicitation not supported"*.
 The loop is bounded. `Client(..., input_required_max_rounds=10)` is the default cap; a server that keeps returning `InputRequiredResult` past it makes `call_tool` raise. If a round carries only `request_state` and no `input_requests`, `Client` sleeps briefly (50ms doubling to a 250ms ceiling) before retrying, so a server that is just saying *"not done yet"* isn't busy-polled.
 ### Driving the loop yourself
 The auto-loop is enough for a single-process client. Own the loop instead when:
 * Your client is **distributed**: the process that renders the question to the user is not the process that called `call_tool`, so a different worker issues the retry. `request_state` is the persistable token you carry across that boundary, through your own storage, and `input_responses` is what the other side sends back with it.
 * You want to **inspect** each round: log or audit every `input_requests` entry, refuse certain request kinds, or apply your own backoff between legs.
 * You want a **wall-clock** bound rather than a round-count bound: wrap your own loop in `anyio.fail_after(...)` instead of relying on `input_required_max_rounds`.
 Drop to the underlying session, where `allow_input_required=True` hands you the union directly:
 ```python title="client.py" hl_lines="13 14 20"
 --8<-- "docs_src/mrtr/tutorial002.py"
 ```
 * `client.session.call_tool(..., allow_input_required=True)` widens the return type to `CallToolResult | InputRequiredResult`. The `isinstance` is what narrows it back.
 * `request_state` is now in your hands. Write it down between legs and the conversation can resume from a fresh process.
 * For every entry in `input_requests` you put an `InputResponse` under the **same key** in `input_responses`. `fulfil` is where your UI goes; this one hard-codes the answer.
 * Same tool name, same `arguments`, every leg. The retry is the original call carried out again, not a new method.
 ## Protecting `requestState`
 Everything above treats `request_state` as an echo, and on the wire that is all it is. But the client holds it between legs (writing it down across processes is exactly what the previous section blessed), so what comes back is **client-supplied input**: it can be modified, expired, or lifted from a different call entirely. The spec requires servers to integrity-protect this state and reject the round when verification fails, whenever the state can influence authorization, resource access, or business logic.
 `MCPServer` protects it by default. Every server seals outgoing `requestState` and verifies every echo — resolver state and hand-built state alike — under a key generated at process start. You configure nothing, write plaintext, and read plaintext; the wire only ever carries an opaque encrypted token.
 The default key lives and dies with the process, which is the one thing you must know before deploying beyond a single process:
 ```python
 from mcp.server.mcpserver import MCPServer, RequestStateSecurity
 # Multi-instance or restart-surviving: one or more shared secret keys (>= 32 bytes each).
 mcp = MCPServer("fleet", request_state_security=RequestStateSecurity(keys=[key]))
 ```
 * **The default (no configuration)** suits a single process: stdio, or exactly one HTTP worker. A retry that lands on a different worker, a different instance behind a load balancer, or the same server after a restart is sealed under a key that process doesn't have — the client gets the frozen rejection below and must start the flow over.
 * **`keys=[...]`** is required whenever a retry can reach a **different instance** (multi-worker `uvicorn`, load-balanced HTTP) or must survive restarts: every instance verifies what any sibling minted. Same machinery, your secret instead of a generated one.
 * For your own crypto, such as a KMS or an existing token service, pass `RequestStateSecurity(codec=...)` instead of `keys`; **[Bring your own crypto](#bring-your-own-crypto)** below covers the contract.
 ### What the seal carries
 Default or configured, `requestState` on the wire is an encrypted, authenticated token. Your code never sees it: handlers and resolvers write plaintext and read plaintext (`ctx.request_state`); the SDK seals on the way out and verifies on the way in. Beyond integrity, each token is bound to:
 * **A time window.** Every round re-seals with a fresh expiry, so `RequestStateSecurity(ttl=...)` (default 600 seconds) bounds per-round think time, not the whole flow.
 * **The authenticated principal.** When the request carries an OAuth access token the SDK validated, the state is bound to the token's client, issuer, and subject: state minted for one user fails under another, even when both users share one OAuth client. A verifier that supplies no subject degrades the binding to the client identity alone, which under URL-based client IDs is shared by every user of that client software. When auth is terminated outside the SDK (a fronting proxy), or the transport is unauthenticated, there is no principal to bind and this check is inert, unless `RequestStateSecurity(bind_principal=...)` supplies one from your own identity signal. Whichever components your token verifier supplies, it must supply them consistently: a verifier that includes the subject on some requests and omits it on others changes the principal mid-flow, and in-flight rounds are rejected.
 * **The originating request.** The method, the tool or prompt name (or resource URI), and a digest of the arguments. A token replayed against a different tool, different arguments, or a different method fails.
 * **The exact question asked.** Every resolver answer is pinned to the rendered question the client was shown, both on the round it first arrives and when a recorded answer is reused later. Redeploy with a reworded message or a changed schema and the server re-asks instead of consuming a stale answer. The same pinning cuts the other way: derive messages from the tool's arguments, not from per-call data. A message built from a timestamp or a live rate renders differently every round, so every recorded answer looks stale and the server re-asks until the client's round limit ends the call.
 All of that is the SDK's job, not yours, and not the codec's if you bring your own.
 ### Rotating keys
 `keys[0]` seals new state; every key in the list verifies. Zero-downtime rotation is three phases, each fully rolled out before the next:
 ```python
 RequestStateSecurity(keys=[OLD, NEW])  # 1: every instance learns to verify NEW; OLD still mints
 RequestStateSecurity(keys=[NEW, OLD])  # 2: NEW mints; in-flight OLD state keeps verifying
 RequestStateSecurity(keys=[NEW])       # 3: one ttl after phase 2 is fully out, retire OLD
 ```
 Never promote the minter first: minting under a key some instance can't yet verify drops in-flight rounds mid-rollout.
 Keys are scoped to one service. The sealed envelope also carries the server's name as an audience claim, so a token minted by a different service that happens to share a secret is rejected anyway. The claim is only as distinctive as the name, so a server given an explicit policy must have a real name or set `RequestStateSecurity(audience=...)` — an unnamed one raises at construction. `audience=` also serves deliberate multi-service topologies where one service must accept state another minted. (The no-configuration default is exempt: its key never leaves the process, so the audience claim has nothing to add.)
 ### Bring your own crypto
 `RequestStateSecurity(codec=...)` takes anything with `seal(bytes) -> str` and `unseal(str) -> bytes` that raises `InvalidRequestState` for any token it did not mint. The classic shape is envelope encryption against a KMS, where you unwrap a data key once at startup and keep the per-token crypto local:
 ```python title="server.py" hl_lines="12 26-27 34-35 38"
 --8<-- "docs_src/mrtr/tutorial005.py"
 ```
 TTL, principal binding, and request binding are **not** the codec's job: the SDK stamps them into the payload before `seal` and re-verifies them after `unseal`, for every codec. A codec's only obligations are integrity (tampered means raise) and, ideally, confidentiality.
 ### When verification fails
 Every inbound failure, whether tampered, expired, replayed against a different request or principal, or sealed under a key this server doesn't know, gets the same answer:
 ```json
 {"code": -32602, "message": "Invalid or expired requestState"}
 ```
 One frozen message for every cause, so the wire never reveals which check failed; the real reason goes to the server log. Every inbound `requestState` on `tools/call`, `prompts/get`, and `resources/read` is checked, including one arriving for a handler that never mints state. The most common rejection in practice isn't an attacker — it's the default process-local key meeting a retry from before a restart or from another instance; the client restarts the flow, and `keys=[...]` is the fix when that matters.
 ### Hand-built state
 A `request_state` you set yourself (returning `InputRequiredResult` from a tool, prompt, or resource-template function) is sealed and verified by the same machinery as resolver state, with zero code changes: write plaintext, read plaintext, and every binding above applies.
 The one thing the SDK cannot pin for you, even when configured, is question identity: it doesn't know which of *your* questions an answer in your state belongs to. If you store answers keyed by question, include your own question identifier in the state and check it on the retry.
 The low-level `Server` is the no-batteries tier: unlike `MCPServer`, nothing is sealed until you append the boundary yourself, and your `request_state` crosses the wire exactly as written until you do. The one-line opt-in is shown in **[The low-level Server](../advanced/low-level-server.md#the-other-handlers)**.
 ## A 2026-07-28 result
 `InputRequiredResult` only exists at protocol version **2026-07-28**. The in-memory `Client(server)` negotiates it for you; over the wire, `mode="auto"` discovers it. After connecting, `client.protocol_version` tells you what you got.
 !!! warning
    A pre-2026 session has nowhere to put an `InputRequiredResult`. Return one from your handler on a
    `mode="legacy"` connection and the runner cannot serialize it into the negotiated version; the
    client gets back a `-32603` *"Handler returned an invalid result"* error. A server that serves
    both eras must check `ctx.protocol_version` before reaching for it.
 !!! info
    **URL-mode elicitation** rides this exact mechanism on a 2026 connection. The entry in
    `input_requests` is an `ElicitRequest` whose params are `ElicitRequestURLParams`; the user
    finishes the out-of-band flow and your client retries the call. Same loop, no new API. The
    high-level server half is in **[Elicitation](elicitation.md)**.
 ## Recap
 * At 2026-07-28 a server that needs input mid-call **returns** an `InputRequiredResult`. It never opens a request to the client.
 * `input_requests` is what it needs. `request_state` is an opaque resume token only the server reads.
 * `Client` runs the retry loop for you: register `elicitation_callback` / `sampling_callback` / `list_roots_callback` and `call_tool` returns a plain `CallToolResult`. `input_required_max_rounds` (default 10) bounds it.
 * To inspect or persist rounds, use `client.session.call_tool(..., allow_input_required=True)` and own the `while isinstance(result, InputRequiredResult)` loop yourself.
 * On `@mcp.tool()`, a dependency that asks the user produces this result for you (**[Dependencies](dependencies.md)**); the **low-level** `Server` is the manual form.
 * Prompts and resources participate too: an `@mcp.prompt()` or template `@mcp.resource()` function returns the `InputRequiredResult` itself and reads `ctx.input_responses` on the retry.
 * `requestState` comes back as client-supplied input, so `MCPServer` seals it by default — resolver state and hand-built state alike — under a process-local key; multi-instance deployments pass `RequestStateSecurity(keys=[...])` (or a custom codec) so every instance can verify what a sibling minted. The seal binds every token to a time window, the originating request, and the authenticated principal when the request carries auth the SDK validated or `bind_principal=` supplies your own identity signal (**[Protecting `requestState`](#protecting-requeststate)**).
 This is the mechanism that replaces server-initiated sampling and the rest of the push-style back-channel; see **[Deprecated features](../deprecated.md)**.
@@ -0,0 +1,117 @@
 # Progress
 A tool that takes thirty seconds and says nothing for thirty seconds looks broken.
 **Progress notifications** fix that. The tool reports how far along it is; the client decides what to draw with it: a bar, a spinner, a log line.
 ## Report it from the tool
 Take a **`Context`** parameter and call `report_progress`:
 ```python title="server.py" hl_lines="8 11"
 --8<-- "docs_src/progress/tutorial001.py"
 ```
 Three arguments, and you decide what they mean:
 * `progress`: how far you are. The spec requires it to **increase** with every report; never repeat a value or go backwards.
 * `total`: how much there is in total, if you know. Optional.
 * `message`: one human-readable line about *this* step. Optional.
 `ctx` is injected because of its type hint and the model never sees it: `import_catalog`'s input schema has a single property, `urls`. **[The Context](context.md)** page is all about that object; progress is one of the things it gives you.
 ## Listen for it from the client
 The client opts in **per call**, by passing `progress_callback=` to `call_tool`:
 ```python title="client.py" hl_lines="7 16"
 import anyio
 from mcp import Client
 from server import mcp
 async def show(progress: float, total: float | None, message: str | None) -> None:
    print(f"{message} ({progress}/{total})")
 async def main() -> None:
    async with Client(mcp) as client:
        result = await client.call_tool(
            "import_catalog",
            {"urls": ["https://example.com/a.json", "https://example.com/b.json"]},
            progress_callback=show,
        )
    print(result.structured_content)
 anyio.run(main)
 ```
 The callback is an `async` function taking exactly what the server reported: `progress`, `total`, `message`.
 !!! info
    `Client(mcp)` connects straight to the server object, in memory, the same client the **[Testing](../get-started/testing.md)**
    page is built on. `progress_callback` is the same parameter whatever transport the `Client`
    uses; the *timing* you are about to see is the in-memory connection's. It runs your callback
    inline, so every report lands before `call_tool` returns. Over a real transport the
    notifications race the result, and a slow callback can still be running after `call_tool` has
    returned.
 ### Try it
 Put `client.py` next to `server.py` and run it:
 ```console
 python client.py
 ```
 ```text
 Imported https://example.com/a.json (1/2)
 Imported https://example.com/b.json (2/2)
 {'result': 'Imported 2 records.'}
 ```
 Every `await ctx.report_progress(...)` on the server became one call to `show` on the client, in order, and both lines printed **before** `call_tool` returned. Progress is not bundled into the result; it streams while the tool is still working.
 !!! warning
    `progress_callback` belongs to the **call**, not the `Client`. There is no constructor argument
    for it, because different calls want different callbacks: one drives a download bar, the next
    one a log line.
 !!! check
    Now delete `progress_callback=show` and run it again:
    ```text
    {'result': 'Imported 2 records.'}
    ```
    No error, no warning, same result. `report_progress` is a **no-op when the caller didn't ask
    for progress**, so you report unconditionally and never have to wonder whether anyone is
    listening.
 ## When you don't know the total
 `total` is for when you know the denominator. Often you don't: you're draining a feed, walking a cursor, downloading something with no length header.
 Leave it out:
 ```python title="server.py" hl_lines="20"
 --8<-- "docs_src/progress/tutorial002.py"
 ```
 The callback receives `total=None`. A client can still show *activity* ("3 imported so far...") but it can't show a percentage. Don't invent a total to get a prettier bar.
 !!! tip
    `progress` doesn't have to count anything in particular. Bytes, rows, pages: pick the unit the
    user would recognise, and only promise a `total` you can keep.
 ## Recap
 * `await ctx.report_progress(progress, total=None, message=None)` from any tool that takes a `Context`.
 * The client passes `progress_callback=` to `call_tool`: per call, never on the `Client`.
 * The callback is `async (progress, total, message) -> None` and fires while the tool is still running.
 * No callback on the call means `report_progress` does nothing. Report unconditionally.
 * Omit `total` when you don't know it; the callback gets `None`.
 Progress is what a running tool shows the *user*. The lines it logs for *you*, the person operating the server, are a different channel: **[Logging](logging.md)**.
@@ -0,0 +1,46 @@
 # Sampling and roots
 A handler can ask the connected client for two more things: a completion from the client's own model (**sampling**), and the client's workspace folders (**roots**).
 Both still work, on every protocol version the SDK speaks. But read the warning before you design around them:
 !!! warning "Deprecated by the 2026-07-28 specification"
    Sampling and roots are deprecated as of `2026-07-28` ([SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/2577)). They remain fully functional and stay in the specification for at least twelve months before becoming eligible for removal, but new implementations should not build on them. The suggested migrations: integrate directly with your LLM provider's API instead of sampling, and pass directories via tool parameters, resource URIs, or server configuration instead of roots. The SDK-wide list is in **[Deprecated features](../deprecated.md)**.
 ## Sampling: borrow the client's model
 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"
 --8<-- "docs_src/sampling_and_roots/tutorial001.py"
 ```
 * `Sample(messages, max_tokens=...)` mirrors the `sampling/createMessage` parameters. The injected value is the client's `CreateMessageResult`; pass `tools` or `tool_choice` and it becomes a `CreateMessageResultWithTools` instead.
 * The client must have declared the `sampling` capability (`sampling.tools` if you pass `tools` or `tool_choice`). If it didn't, the call fails with a `-32021` protocol error instead of sending a request the client cannot handle. A pre-2026 session with no back-channel fails with its usual no-back-channel error, since there is nothing to send on.
 * At `2026-07-28` the request is delivered inside the multi-round-trip flow (**[Multi-round-trip requests](multi-round-trip.md)**); on `2025-11-25` it is a standalone request to the client. The code is the same either way, but mind the multi-round-trip rule: the request must render identically across retry rounds, so build it only from the tool's arguments and other stable data.
 * Leave `include_context` alone: values other than `"none"` are themselves deprecated (SEP-2596) and need a capability almost no client declares.
 ## Roots: where should this go?
 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"
 --8<-- "docs_src/sampling_and_roots/tutorial002.py"
 ```
 * The injected `ListRootsResult` carries a list of `Root`s: a `file://` URI and an optional display name.
 * The gate is the same as for sampling: without a declared `roots` capability the call fails with `-32021` instead of sending the request.
 On the other side of the wire, the client answers both requests with the callbacks it already has: `sampling_callback` and `list_roots_callback`, covered in **[Client callbacks](../client/callbacks.md)**.
 ## On 2025-era connections
 `ctx.session.create_message(...)` and `ctx.session.list_roots()` still exist for code that drives the session directly. They only work where a back-channel exists (2025-era, non-stateless connections), and calling them raises a deprecation warning. The resolver markers above are the supported form: they pick the delivery from the negotiated version and don't warn.
 ## Recap
 * Return `Sample(...)` or `ListRoots()` from a resolver; the tool receives the `CreateMessageResult` or `ListRootsResult` like any other dependency.
 * The client must declare the matching capability, or the call fails with `-32021` instead of a request being sent.
 * Both features are deprecated at `2026-07-28`: fully functional for now, wrong for new designs. Prefer provider APIs over sampling and explicit parameters over roots.
 Reporting how far along a slow tool is: **[Progress](progress.md)**.
@@ -0,0 +1,146 @@
 # Subscriptions
 A server's catalog is not fixed. Tools appear at runtime, and the content behind a resource URI changes.
 **Subscriptions** are how a client hears about it. The client sends one `subscriptions/listen` request, and the response to that request *is* the stream: it stays open and carries the change notifications the client asked for.
 ## Publish it from the tool
 Your side of it is one line: publish the change.
 ```python title="server.py" hl_lines="20 32"
 --8<-- "docs_src/subscriptions/tutorial001.py"
 ```
 * `await ctx.notify_resource_updated("board://sprint")` reaches every open stream that subscribed to that URI. Nobody else.
 * `await ctx.notify_tools_changed()` reaches every stream that asked for tool-list changes. A client that receives it calls `tools/list` again, and now sees `sprint_report`.
 * The siblings are `notify_prompts_changed()` and `notify_resources_changed()`.
 * No subscribers, no work. Publishing to an idle server is a no-op, so you never check whether anyone is listening. You state what changed.
 `MCPServer` serves `subscriptions/listen` for you. The wire obligations (the acknowledgment as the first frame, per-stream filtering, the subscription id on every frame) are the SDK's job.
 !!! check
    On the wire, a stream whose filter named `board://sprint` looks like this after `complete_task` runs:
    ```json
    {"method": "notifications/subscriptions/acknowledged",
     "params": {"notifications": {"resourceSubscriptions": ["board://sprint"]}, "_meta": {"io.modelcontextprotocol/subscriptionId": "listen-1"}}}
    {"method": "notifications/resources/updated",
     "params": {"uri": "board://sprint", "_meta": {"io.modelcontextprotocol/subscriptionId": "listen-1"}}}
    ```
    Note what the update does *not* carry: the board. Every frame carries the listen request's JSON-RPC id under `_meta`, and that id is the subscription id. The client mints it: the Python `Client` uses strings like `"listen-1"`; other clients may use integers.
 ## Only what was asked for
 The filter is a contract. A stream that requested tool-list changes and one resource URI receives those two kinds and nothing else. Publish a prompt change and that stream stays silent.
 `MCPServer` matches resource URIs as exact strings, so a stream that named `board://sprint` hears nothing about `board://sprint/tasks/1`. The spec lets a server report a change on a sub-resource of a subscribed URI; `MCPServer` never does, but clients are built to expect it.
 Two things the stream is *not*:
 * **It is not a replay log.** A dropped stream is gone, and events published while nobody was connected are not queued. Clients re-listen and refetch.
 * **It is not the 2025 path.** Clients that called `resources/subscribe` are served by `ctx.session.send_resource_updated(uri)`. The `notify_*` methods reach `subscriptions/listen` streams only.
 !!! warning
    Don't publish sensitive per-user URIs through `notify_resource_updated` on a multi-tenant
    server. Any client may name any URI in its filter, and `MCPServer` honors it. The exposure
    is narrow but real: a subscriber learns that a URI it can guess changed, and when. It never
    learns content, and it cannot probe what exists, because an unknown URI is honored too and
    simply never fires. To narrow the filter per client today, serve the method with your own
    handler on the low-level `Server` and acknowledge a smaller filter than the client asked
    for; the acknowledgment is how the client learns what it actually got.
 !!! warning "Streamable HTTP only, for now"
    `subscriptions/listen` needs a transport that can stream a request's response, which today
    means streamable HTTP. Over stdio a 2026-07-28 connection rejects the method with
    METHOD_NOT_FOUND, even though `server/discover` advertises the subscription capabilities
    there. Serving it over stdio is planned; the open-stream semantics for that transport are
    not built yet.
 ## The client end
 Here is a client on the other side of that stream, following the board:
 ```python title="client.py" hl_lines="16"
 --8<-- "docs_src/subscriptions/tutorial003.py"
 ```
 Entering `client.listen(...)` sends the request and waits for your acknowledgment, so the stream is live when the block starts, and each typed event is a cue to refetch, never a payload. That is the whole contract in one screen. Everything else about the client end lives on its own page: watching beside a main flow, stream endings, and re-listening. See **[Subscriptions](../client/subscriptions.md)** under *Clients*.
 ## Scaling past one process
 Publishes travel from your handler to the open streams over a `SubscriptionBus`. The default is in-memory: one process, every stream in it. That is the right answer until you run replicas behind a load balancer, because then a client's stream is pinned to one replica, and a publish on another replica has to reach it.
 That seam is yours to implement: two methods over your pub/sub backend.
 ```python
 from collections.abc import Callable
 from redis.asyncio import Redis
 from mcp.server.mcpserver import MCPServer
 from mcp.server.subscriptions import ServerEvent  # SubscriptionBus is a Protocol: no base class
 class RedisSubscriptionBus:
    def __init__(self, redis: Redis) -> None:
        self._redis = redis
        self._listeners: dict[object, Callable[[ServerEvent], None]] = {}
    async def publish(self, event: ServerEvent) -> None:
        await self._redis.publish("mcp-events", encode(event))  # to every replica
    def subscribe(self, listener: Callable[[ServerEvent], None]) -> Callable[[], None]:
        token = object()
        self._listeners[token] = listener
        def unsubscribe() -> None:
            self._listeners.pop(token, None)
        return unsubscribe
 mcp = MCPServer("Sprint Board", subscriptions=RedisSubscriptionBus(redis))
 ```
 `encode` is yours, and so is the reader task on each replica that decodes arriving messages and calls every registered listener. Listeners are synchronous, must not raise, and run on the server's event loop.
 The bus carries typed `ServerEvent` values, four small dataclasses, never JSON-RPC. Stamping, filtering, and stream lifecycles stay in the SDK, so a bus implementation cannot break the protocol. It can only move events between processes.
 To publish from outside a request, construct the bus yourself so you hold the reference. `MCPServer` builds one internally when you pass nothing, and does not expose it.
 ```python
 from mcp.server.subscriptions import InMemorySubscriptionBus, ToolsListChanged
 bus = InMemorySubscriptionBus()
 mcp = MCPServer("Sprint Board", subscriptions=bus)
 async def tools_reloaded() -> None:
    await bus.publish(ToolsListChanged())  # from a lifespan task, a webhook, anywhere
 ```
 ## The low-level composition
 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"
 --8<-- "docs_src/subscriptions/tutorial002.py"
 ```
 * You own the bus, so you publish to it directly: `await bus.publish(ResourceUpdated(uri=...))`. Put it wherever your handlers can reach it: module scope here, the lifespan in a bigger app.
 * `ListenHandler(bus)` is the same handler `MCPServer` registers, and `on_subscriptions_listen=` is an ordinary handler slot. Put your own callable in that slot for different semantics, and the spec obligations move to you: acknowledge first, stamp every frame with the subscription id, deliver nothing outside the filter.
 * `ListenHandler.close()` ends every open stream gracefully. Each one receives the listen request's result as its final frame, which is the spec's way of saying the server ended the subscription deliberately. It returns before those streams finish flushing, so give them a moment before you tear the transport down. Without it, streams end when the client disconnects.
 ## Recap
 * A client opts in with one `subscriptions/listen` request, and the response is the stream. Serving it is built in.
 * You publish with `ctx.notify_*`, and the SDK does the stamping, filtering, and lifecycle work.
 * Events are cues, not payloads. Both ends refetch.
 * The client end is `async with client.listen(...)`: **[Subscriptions](../client/subscriptions.md)** under *Clients* is that story.
 * On the low-level `Server` you assemble the same parts yourself: a bus, `ListenHandler(bus)`, the `on_subscriptions_listen` slot.
 * Scaling out means implementing `SubscriptionBus`, two methods, and passing it as `MCPServer(subscriptions=...)`.
 Running the server that serves all this, behind one replica or twenty, is **[Deploy & scale](../run/deploy.md)**.
@@ -0,0 +1,102 @@
 # MCP Python SDK
 !!! info "You are viewing the in-development v2 documentation"
    For the current stable release, see the [v1.x documentation](https://py.sdk.modelcontextprotocol.io/).
    New to v2, or coming from v1? **[What's new in v2](whats-new.md)** is the five-minute tour of what changed.
    Trying v2? [Tell us what you find](https://github.com/modelcontextprotocol/python-sdk/issues/new?template=v2-feedback.yaml) — it is the most useful thing you can do for the SDK right now.
 The **Model Context Protocol (MCP)** lets applications provide context to LLMs in a standardized way, separating the concern of *providing* context from the LLM interaction itself.
 This is the official Python SDK for it. With it you can:
 * **Build MCP servers** that expose tools, resources, and prompts to any MCP host.
 * **Build MCP clients** that connect to any MCP server.
 * Speak every standard transport: stdio, Streamable HTTP, and SSE.
 ## Requirements
 Python 3.10+.
 ## Installation
 === "uv"
    ```bash
    uv add "mcp[cli]==2.0.0b1"
    ```
 === "pip"
    ```bash
    pip install "mcp[cli]==2.0.0b1"
    ```
 The `[cli]` extra gives you the `mcp` command; you'll want it for development.
 !!! warning "Pin the version while v2 is in beta"
    Installers never select a pre-release unless you name one, so an unpinned `uv add "mcp[cli]"`
    gives you the latest **v1.x** release, which this documentation does not describe. Check
    [PyPI](https://pypi.org/project/mcp/#history) for the newest beta before you copy the line
    above. See [Installation](get-started/installation.md) for the details.
 ## Example
 ### Create it
 Create a file `server.py`:
 ```python title="server.py"
 --8<-- "docs_src/index/tutorial001.py"
 ```
 That's a complete MCP server.
 It exposes one **tool**, `add`, and one templated **resource**, `greeting://{name}`.
 ### Run it
 ```console
 uv run mcp dev server.py
 ```
 This starts your server and opens the [MCP Inspector](https://github.com/modelcontextprotocol/inspector), an interactive UI for poking at it. Open the URL it prints.
 !!! note
    The Inspector is a Node.js app, so `mcp dev` needs `npx` on your `PATH`.
 ### Try it
 In the Inspector, go to **Tools** and call `add` with `a=1`, `b=2`.
 You get `3` back. ✨
 The Inspector built that form (a required integer field for `a`, another for `b`) from your type hints. So will Claude, and every other MCP host.
 Now go to **Resources** and read `greeting://World`:
 ```text
 Hello, World!
 ```
 ### Recap
 Look again at what you did **not** write:
 * No JSON Schema. `a: int, b: int` *is* the schema.
 * No request parsing, no serialization, no validation code.
 * No protocol handling at all.
 You wrote two Python functions with type hints and a docstring. The SDK does the rest.
 ## Where to go next
 * **[Get started](get-started/index.md)** takes you from install to a working, tested server.
 * Building an application that *uses* MCP servers? Start with **[Clients](client/index.md)**.
 * Already have a FastAPI or Starlette app? **[Add to an existing app](run/asgi.md)** mounts an MCP server inside it.
 * Hunting an exact error message? **[Troubleshooting](troubleshooting.md)** is keyed by the verbatim text.
 * Wondering what changed in v2? **[What's new in v2](whats-new.md)** is the five-minute tour.
 * Migrating from v1? Start with the **[Migration Guide](migration.md)**.
 * Hunting for an exact signature? The **[API Reference](api/mcp/index.md)** is generated from the source.
 * Reading with an LLM? This documentation is also published in the [llms.txt](https://llmstxt.org/) format:
  [llms.txt](https://py.sdk.modelcontextprotocol.io/v2/llms.txt) is an index of the pages, and
  [llms-full.txt](https://py.sdk.modelcontextprotocol.io/v2/llms-full.txt) contains every page in a single file.
@@ -0,0 +1,127 @@
 # Protocol versions
 MCP has two eras.
 Servers released before 2026-07-28 open every connection with the **`initialize` handshake**: the client proposes a version, the server counters, the client acknowledges, all before the first useful request. Servers at **2026-07-28** drop the handshake. The client sends one **`server/discover`** probe and the server answers it with everything in a single result.
 You almost never have to care, because `Client` negotiates for you. This page is about the one constructor argument that controls it, `mode=`, and the three times you change it.
 ## `mode="auto"`
 ```python title="client.py" hl_lines="14-15"
 --8<-- "docs_src/protocol_versions/tutorial001.py"
 ```
 You didn't pass `mode`, so you got the default: `"auto"`. Entering `async with` sends a single `server/discover` probe at the newest version this SDK speaks. Then:
 * A **modern server** answers it. The client adopts the result. One round trip, done.
 * An **older server** has never heard of `server/discover` and returns an error. The client falls back to the classic `initialize` handshake and takes whatever that negotiates.
 Either way you come out connected, and `client.protocol_version` tells you which it was:
 ```text
 2026-07-28
 ```
 That is the whole feature. One `Client`, any era of server, no branching in your code.
 !!! info
    `MCPServer` answers `server/discover` on every transport — in-memory, stdio, streamable
    HTTP — so against your own server `auto` always lands on `2026-07-28`. The fallback only
    ever fires against a real pre-2026 server, which is exactly when you want it to.
 ## `mode="legacy"`
 ```python title="client.py" hl_lines="14"
 --8<-- "docs_src/protocol_versions/tutorial002.py"
 ```
 `mode="legacy"` never probes. It runs the `initialize` handshake, the same connection a pre-2026 client opens.
 ```text
 2025-11-25
 ```
 Same server. It speaks `2026-07-28` perfectly well; you told the client not to ask.
 You want this for the **push-style** features.
 A server-initiated request is the server calling *you*: `ctx.elicit(...)` putting a form in front of your user, sampling asking your model for a completion mid-tool-call. That channel only exists on a handshake-era session.
 At 2026-07-28 it is gone. The server *returns* its questions and you retry the call with the answers (**[Multi-round-trip requests](handlers/multi-round-trip.md)**).
 `mode="auto"` only gives you a handshake when the server is too old for anything else. `mode="legacy"` guarantees one. Reach for it whenever you hand `Client(...)` a `sampling_callback`, an `elicitation_callback` you want driven as a request, or a `message_handler`. **[Client callbacks](client/callbacks.md)** goes through each.
 ## Pinning a version
 `mode` also accepts a modern protocol version string. Today that set is exactly `["2026-07-28"]`.
 ```python title="client.py" hl_lines="14"
 --8<-- "docs_src/protocol_versions/tutorial003.py"
 ```
 A pin sends **nothing**. No probe, no handshake. The client adopts `2026-07-28` locally and the connection is live the instant `async with` returns.
 A pin is a promise *you* make: you already know the server speaks that version. The client doesn't check.
 !!! check
    A pin is not a discovery. Print `client.server_info` and the price is right there:
    ```text
    name='' title=None version='' description=None website_url=None icons=None
    ```
    The client never asked the server who it is, so `server_info` is a blank. `client.server_capabilities`
    is the same story: every capability is `None`. Tool calls still work (the protocol needs none of it);
    code that reads `server_capabilities` to decide what to offer does not.
    The next section is the fix.
 Only modern versions are pinnable. A handshake-era string is rejected at construction, before any I/O, and the error tells you what to write instead:
 ```text
 ValueError: mode must be 'legacy', 'auto', or one of ['2026-07-28']; got '2025-06-18' ('2025-06-18' is a handshake-era version; use mode='legacy')
 ```
 ## Reconnecting with `prior_discover`
 The probe is cheap, but it is still a round trip you pay on every reconnect, and the answer almost never changes.
 So keep it. After an `auto` connection, `client.session.discover_result` holds the exact `DiscoverResult` the server sent: its `supported_versions`, its `capabilities`, its `server_info`, its `instructions`. Hand it back as `prior_discover=` the next time:
 ```python title="client.py" hl_lines="15 17"
 --8<-- "docs_src/protocol_versions/tutorial004.py"
 ```
 ```text
 2026-07-28
 Bookshop
 ```
 The second connection made **zero** negotiation round trips and still knows exactly who it is talking to. That is the pinned mode done properly: `mode=` names the version, `prior_discover=` supplies the identity. ✨
 `DiscoverResult` is a Pydantic model. `saved.model_dump_json()` goes into a file or a cache; `DiscoverResult.model_validate_json(...)` brings it back in the next process.
 !!! tip
    `prior_discover=` only does anything when `mode` is a version pin. Under `"auto"` the client
    probes the server anyway, and under `"legacy"` it is ignored.
 ## The four modes
 | You write | Negotiation traffic | You get |
 | --- | --- | --- |
 | `Client(target)` | one `server/discover` probe; the `initialize` handshake if it fails | the newest version both sides speak, whichever era |
 | `Client(target, mode="legacy")` | the `initialize` handshake | a handshake-era version; server-initiated requests work |
 | `Client(target, mode="2026-07-28")` | none | that version, pinned, with a blank `server_info` |
 | `Client(target, mode="2026-07-28", prior_discover=saved)` | none | that version, pinned, *and* the identity you saved last time |
 ## Recap
 * MCP has a handshake era (up to `2025-11-25`, the `initialize` handshake) and a modern era (`2026-07-28`, `server/discover`). `Client` bridges them.
 * `mode="auto"` is the default: probe, fall back. Leave it alone unless one of the other three rows describes you.
 * `client.protocol_version` is always the answer to "what did I get?".
 * `mode="legacy"` forces the handshake. It is what you need for server-initiated requests: sampling, push elicitation, `message_handler`.
 * A version pin (`mode="2026-07-28"`) sends no negotiation traffic at all, at the cost of a blank `server_info`.
 * `prior_discover=` pays that cost back: save `client.session.discover_result`, reconnect with it, get both.
 A modern connection has no push channel, so how does a 2026 server ask you a question mid-call? It returns it: **[Multi-round-trip requests](handlers/multi-round-trip.md)**.
@@ -0,0 +1,140 @@
 # Add to an existing app
 `mcp.run("streamable-http")` starts a web server for you. Sometimes you don't want that: your MCP server is one piece of a larger web application, or you already have an ASGI deployment.
 For that, `mcp.streamable_http_app()` returns a **Starlette application**.
 A Starlette app is an ASGI app, so anything that hosts ASGI (uvicorn, Hypercorn, another Starlette, FastAPI) can host your MCP server.
 ## The app
 ```python title="server.py" hl_lines="12"
 --8<-- "docs_src/asgi/tutorial001.py"
 ```
 `app` is an ordinary ASGI application. Hand it to any ASGI server:
 ```console
 uvicorn server:app
 ```
 The MCP endpoint is at `/mcp`, so a client connects to `http://127.0.0.1:8000/mcp`.
 The app already carries two things:
 * One route, `/mcp`: the Streamable HTTP endpoint.
 * A **lifespan** that starts `mcp.session_manager`, the object that owns every live session's background work.
 Run the app on its own (`uvicorn server:app`) and you never think about either.
 !!! tip
    `streamable_http_app()` takes the same keyword arguments as `mcp.run("streamable-http", ...)`,
    minus `port`: the port belongs to whatever serves the app. `host` is still accepted but binds
    nothing here; **[Deploy & scale](deploy.md)** explains what it actually controls.
    **[Running your server](index.md)** covers the options themselves.
 `mcp.sse_app()` does the same for the superseded SSE transport.
 ## Localhost only, until you say otherwise
 Out of the box the app answers **only** requests addressed to localhost. `streamable_http_app()`
 cannot know which hostname it will be served behind, so it arms DNS-rebinding protection with the
 safest possible allowlist; on your machine that is exactly right. Deployed behind a real hostname,
 it means **every request is rejected with `421 Misdirected Request`** until you pass
 `transport_security=` an allowlist of what you actually serve. Nothing you built is even
 consulted first. That allowlist, and everything else between a working app and a real hostname,
 is **[Deploy & scale](deploy.md)**.
 ## Mounting it
 The moment the MCP server is *part* of a bigger application, you put the app inside a `Mount`. And the moment you do that, the lifespan becomes your problem:
 ```python title="server.py" hl_lines="18-21 25-26"
 --8<-- "docs_src/asgi/tutorial002.py"
 ```
 * `Mount("/", ...)` plus the default `/mcp` path keeps the endpoint at `/mcp`. Starlette tries routes in order and `Mount("/")` matches **every** path, so your own routes go *before* it in the list. Anything after it is unreachable.
 * The `lifespan` function enters `mcp.session_manager.run()` for the lifetime of the **host** app. This is the line everyone forgets.
 * `mcp.session_manager` only exists *after* `streamable_http_app()` has been called. That is why the routes are built at module level and the manager is only touched inside the lifespan.
 Starlette's `Host` route works the same way: swap `Mount("/", ...)` for `Host("mcp.example.com", ...)` to route by hostname instead of by path. The lifespan rule does not change, and neither does the transport-security one. A `Host("mcp.example.com", ...)` route only ever receives requests addressed to that hostname, but the transport's own Host allowlist (**[Deploy & scale](deploy.md)**) still runs first. Without `"mcp.example.com"` in it, that route answers every one of them with a `421`.
 !!! warning "The host app owns the lifespan"
    `streamable_http_app()` wires `session_manager.run()` into the lifespan of the Starlette it
    returns, but **a mounted sub-application's lifespan never runs**. Mount the app and that
    built-in lifespan is dead code. Whichever app sits at the top of your ASGI stack must enter
    `mcp.session_manager.run()` in its own lifespan.
 !!! check
    Delete the `lifespan=lifespan` line and start the server. It starts. The route resolves.
    Then the first request to `/mcp` fails with:
    ```text
    RuntimeError: Task group is not initialized. Make sure to use run().
    ```
    Nothing starts the session manager except its `run()`.
 ## Two servers, one app
 Each `MCPServer` is its own app with its own session manager. Mount as many as you like; enter every manager from the one host lifespan:
 ```python title="server.py" hl_lines="27-30 35-36"
 --8<-- "docs_src/asgi/tutorial003.py"
 ```
 * `AsyncExitStack` enters both managers; they start together and shut down in reverse order.
 * The endpoints are `/notes/mcp` and `/tasks/mcp`: the mount prefix plus the default path.
 ## Changing the path
 That trailing `/mcp` is `streamable_http_path`. Set it to `"/"` and the mount prefix becomes the whole public path:
 ```python title="server.py" hl_lines="25"
 --8<-- "docs_src/asgi/tutorial004.py"
 ```
 Now clients connect to `/notes`, not `/notes/mcp`.
 ## CORS for browser clients
 A browser-based client needs two permissions from you: to **send** its MCP request headers, and to **read** the one MCP sends back. Both are CORS configuration on the host app, and the transport-security allowlist above has to agree with it:
 ```python title="server.py" hl_lines="27-30 33 35-49"
 --8<-- "docs_src/asgi/tutorial005.py"
 ```
 * `allow_headers` is the half everyone forgets. A browser **preflights** every MCP request, because `Content-Type: application/json` and the `Mcp-*` request headers are not on the CORS safelist, and a header the preflight doesn't grant is a request the browser never sends. (`allow_headers=["*"]` also works: Starlette answers a preflight with whatever it asked for.)
 * `expose_headers=["Mcp-Session-Id"]` is the read half. Streamable HTTP returns the session ID in that response header, and browsers hide response headers from JavaScript unless CORS exposes them by name. Without it the client can never make its second request.
 * `allow_origins` is your decision, not MCP's. Be precise, and mirror it in `allowed_origins=` above: the browser enforces CORS, but the server checks `Origin` itself, and an origin the transport doesn't trust gets a `403` even after a clean preflight.
 * `allow_methods` lists the three methods Streamable HTTP uses: `POST` to send messages, `GET` to open the server-to-client stream, `DELETE` to end the session.
 ## Custom routes
 `@mcp.custom_route()` registers a plain HTTP endpoint on the same app, for the things every deployed service needs that have nothing to do with MCP: a health check, an OAuth callback.
 ```python title="server.py" hl_lines="15-17"
 --8<-- "docs_src/asgi/tutorial006.py"
 ```
 * The handler is plain Starlette: an `async` function from `Request` to `Response`.
 * `streamable_http_app()` picks up every custom route. `app.routes` is now `/mcp` and `/health`.
 * `GET /health` answers `{"status": "ok"}` with no MCP in sight.
 !!! warning
    Custom routes are **never authenticated**, even when the rest of the server is. That is
    deliberate: health checks and OAuth callbacks have to be reachable before any token exists.
    Don't put anything private behind one.
 ## Recap
 * `mcp.streamable_http_app()` returns a Starlette app with one route, `/mcp`. Any ASGI server can run it.
 * Out of the box the app answers only requests addressed to localhost, and behind a real hostname it rejects everything with a `421` until you pass `transport_security=` an allowlist. **[Deploy & scale](deploy.md)** owns that, and the rest of the road to production.
 * `Mount` (or `Host`) puts it inside a bigger Starlette or FastAPI app.
 * **Mounting disables the built-in lifespan.** The host app's lifespan must enter `mcp.session_manager.run()`, or the first request fails.
 * Several servers in one app means several mounts and one lifespan that enters every session manager.
 * `streamable_http_path="/"` moves the endpoint to the mount prefix itself.
 * Browser clients need CORS: `allow_headers` for the `Mcp-*` request headers, `expose_headers=["Mcp-Session-Id"]` for the response.
 * `@mcp.custom_route()` adds plain, unauthenticated HTTP endpoints next to `/mcp`.
 Once the server is reachable at a real URL, **[The Client](../client/index.md)** connects to it with that URL instead of a server object.
@@ -0,0 +1,125 @@
 # Authorization
 Over Streamable HTTP your MCP server is an ordinary web service, and you protect it the way you protect any web service: with OAuth 2.1 bearer tokens.
 In OAuth terms, your server is a **resource server**. It never signs anyone in and it never issues a token. It does one thing: look at the `Authorization` header on each request and decide whether the token in it is good.
 This page is the server side. A client that discovers your authorization server and fetches the token is **[OAuth clients](../client/oauth-clients.md)**.
 ## The three parties
 * The **authorization server** signs people in and issues access tokens. You don't write this. It's your identity provider (Auth0, Keycloak, Entra, your own).
 * The **resource server** is your MCP server. It verifies the token on every request.
 * The **client** discovers which authorization server you trust, gets a token from it, and sends it back to you as `Authorization: Bearer <token>`.
 That's the whole triangle. Everything on this page is the middle bullet.
 ## A token verifier
 The SDK has no opinion about what a valid token looks like. You tell it, by implementing **`TokenVerifier`**:
 ```python title="server.py" hl_lines="12-14 19-24"
 --8<-- "docs_src/authorization/tutorial001.py"
 ```
 * `TokenVerifier` is a protocol with one async method. `verify_token` gets the raw token from the `Authorization` header and returns an **`AccessToken`** if it's valid, `None` if it isn't. There is nothing else to implement.
 * This one looks the token up in a table. A real one verifies a JWT signature or calls the authorization server's token-introspection endpoint. That code is yours; the SDK only calls it.
 * `token_verifier=` and `auth=` always travel together. Pass one without the other and `MCPServer(...)` raises a `ValueError` before it ever serves a request.
 `AuthSettings` is the public face of your resource server:
 * `issuer_url`: the authorization server that issues your tokens.
 * `resource_server_url`: the public URL of this MCP endpoint. It names *which* resource a token is for, and it's where the discovery document lives.
 * `required_scopes`: every token must carry all of them.
 !!! tip
    `examples/servers/simple-auth/` in the SDK repository has an `IntrospectionTokenVerifier` that calls
    a real authorization server's [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662) endpoint. It's the shape most production verifiers take.
 ## What you get over HTTP
 Authorization lives in HTTP headers, so it exists only on the HTTP transports. Run it on the one you deploy: `mcp.run(transport="streamable-http")` puts it on `http://127.0.0.1:8000/mcp`, and **[Running your server](index.md)** has the rest. The app now has two routes:
 ```text
 /mcp
 /.well-known/oauth-protected-resource/mcp
 ```
 You registered one tool. The second route is the SDK's.
 ### Discovery
 `GET` that well-known path and you get **[RFC 9728](https://datatracker.ietf.org/doc/html/rfc9728) Protected Resource Metadata**, built straight from your `AuthSettings`:
 ```json
 {
  "resource": "http://127.0.0.1:8000/mcp",
  "authorization_servers": ["https://auth.example.com/"],
  "scopes_supported": ["notes:read"],
  "bearer_methods_supported": ["header"]
 }
 ```
 This document is how a client that has never heard of your server finds its way in: it reads `authorization_servers` and goes there for a token. You wrote none of it.
 !!! check
    Call `/mcp` with no token (or with one your verifier returned `None` for) and the request is
    stopped at the door:
    ```text
    HTTP/1.1 401 Unauthorized
    WWW-Authenticate: Bearer error="invalid_token", error_description="Authentication required", resource_metadata="http://127.0.0.1:8000/.well-known/oauth-protected-resource/mcp"
    {"error": "invalid_token", "error_description": "Authentication required"}
    ```
    Nothing was parsed and no tool ran. And that `resource_metadata` pointer in `WWW-Authenticate` is
    what makes discovery automatic: 401 -> metadata document -> authorization server -> token -> retry.
 !!! warning
    None of this protects `stdio`. A pipe has no `Authorization` header, so `token_verifier` is never
    consulted there. A `stdio` server's security boundary is the process that launched it. The same
    goes for the in-memory `Client(mcp)` you use in tests: it connects straight to the server object
    and skips the HTTP layer, authorization included.
 ## The caller's identity
 Inside any handler, **`get_access_token()`** is the `AccessToken` your verifier returned for the current request:
 ```python title="server.py" hl_lines="4 32-35"
 --8<-- "docs_src/authorization/tutorial002.py"
 ```
 * It works in tools, resources, and prompts, and there is nothing to pass around: the auth middleware stores it in a context variable per request.
 * You get back the **same object your verifier built**: `client_id`, `scopes`, `subject`, `expires_at`, and any extra `claims` you attached. That's the hook for per-tool rules: read the scopes and refuse.
 * Outside an authenticated HTTP request it returns `None`. In-memory and over `stdio` it is always `None`.
 Call `whoami` with `Authorization: Bearer alice-token` and the model reads:
 ```text
 alice (scopes: notes:read)
 ```
 ## The half the SDK doesn't do
 The SDK gives you the resource-server half: verify, advertise, refuse. It does not give you a login page, a consent screen, or a token.
 To watch all three parties move, run `examples/servers/simple-auth/` from the SDK repository (a small authorization server and a resource server set up exactly like this page) and then point `examples/clients/simple-auth-client/` at it for the full discovery-and-token dance.
 !!! info
    There is a second constructor argument, `auth_server_provider=`, that embeds a full authorization
    server inside your MCP server. It predates the AS/RS separation that the MCP authorization spec
    is built around. New servers should not reach for it.
 An authorization server can also accept an enterprise identity provider's signed assertion in place of a user clicking through a consent screen, and the SDK supports both sides of that exchange. The grant, and the client that presents it, is **[Identity assertion](../client/identity-assertion.md)**.
 ## Recap
 * Over Streamable HTTP your server is an OAuth 2.1 **resource server**: it verifies tokens, it never issues them.
 * `TokenVerifier` is the whole integration surface: one async method, token in, `AccessToken | None` out.
 * `token_verifier=` and `auth=AuthSettings(issuer_url=..., resource_server_url=..., required_scopes=[...])` always travel together.
 * The SDK publishes [RFC 9728](https://datatracker.ietf.org/doc/html/rfc9728) Protected Resource Metadata at `/.well-known/oauth-protected-resource/...` and answers unauthenticated requests with a 401 whose `WWW-Authenticate` header points at it. That is the entire discovery story.
 * `get_access_token()` in any handler is who's calling.
 * Authorization is an HTTP concern. `stdio` and the in-memory client never see it.
 The client half (discovering your authorization server and fetching the token for you) is **[OAuth clients](../client/oauth-clients.md)**. And a client that *asserts* an identity instead of asking a user for one is **[Identity assertion](../client/identity-assertion.md)**.
@@ -0,0 +1,174 @@
 # Deploy & scale
 Your server works. Now it needs a real hostname, and more than one worker behind it.
 Almost none of that is MCP's business. You bring the ASGI server, the process manager, the load balancer. What this page has is the short list of things that *are* MCP's business: one setting that gates every deployment, and the two places where "more than one worker" changes what the SDK does.
 ## Before anything else: the Host allowlist
 `streamable_http_app()` cannot know which hostname it will be served behind, so it assumes the safest answer: localhost. With no `transport_security=`, the app switches on **DNS-rebinding protection** and accepts a request only if its `Host` header is `127.0.0.1:<port>`, `localhost:<port>`, or `[::1]:<port>`. The `Origin` header, when there is one, has to be the `http://` form of the same. On your machine that is exactly right: it stops a malicious web page from driving your local server through a DNS name it rebound to `127.0.0.1`.
 Deployed behind a real hostname, that same default rejects **every request** until you say otherwise. The check runs before anything MCP-shaped does, so nothing you built is even consulted:
 ```text
 421 Misdirected Request    Invalid Host header      the Host is not in the allowlist
 403 Forbidden              Invalid Origin header    the Origin is not in the allowlist
 ```
 `transport_security=` is the fix. Allowlist what you actually serve:
 ```python title="server.py" hl_lines="2 13-17"
 --8<-- "docs_src/deploy/tutorial001.py"
 ```
 * `allowed_hosts` entries are exact strings: `"mcp.example.com"` matches a bare `Host` header and `"mcp.example.com:*"` matches any port. List both.
 * `allowed_origins` only matters for browsers, because nothing else sends `Origin`. It is the server-side twin of the CORS configuration in **[Add to an existing app](asgi.md)**.
 * Behind a reverse proxy that already controls the `Host` header, switching the check off is the honest configuration: `TransportSecuritySettings(enable_dns_rebinding_protection=False)`.
 * Passing a non-localhost `host=` (for example `host="mcp.example.com"`) does **not** allowlist that hostname. It only stops the localhost default from arming the protection, which leaves every Host and Origin accepted. Say what you mean with `transport_security=` instead.
 !!! check
    Delete the `transport_security=security` argument and deploy the app anyway. It starts, `/mcp`
    routes, and every request (including from a plain `curl`) comes back:
    ```text
    HTTP/1.1 421 Misdirected Request
    Invalid Host header
    ```
    You will not find those words on the client side. A `421` is a plain-text HTTP response, not a
    JSON-RPC error, so the MCP client raises a generic transport error; the hostname it
    didn't like appears only in the **server's** log, as a single warning. A freshly
    deployed server that refuses every connection is a Host allowlist until proven otherwise.
    **[Troubleshooting](../troubleshooting.md)** starts here too.
 ## Workers, and who has to be sticky
 Once the hostname answers, put more than one worker behind it. There is no SDK knob for that; you scale a Starlette app the way you scale any ASGI app, by handing the object to something that knows how to fork:
 ```console
 uvicorn server:app --workers 4
 ```
 Four processes, one socket. And now the question every deployment has to answer: **does a request have to reach the worker that saw the last one?**
 For a client speaking the **2026-07-28** protocol, no. A modern request is one self-contained POST: no `initialize` handshake before it, no `Mcp-Session-Id` on the response, nothing for a second request to come back *to*. Route it to any worker.
 That is not a mode you switch on. `stateless_http=True` looks like it should be, but the transport routes on the `MCP-Protocol-Version` request header, hands a modern request to the modern handler, and **returns**. The line that reads `stateless_http` comes *after* that return. It isn't that the flag is ignored on the 2026-07-28 path; it is never reached. `stateless_http` is a knob for the **legacy** leg only, and the modern path is sessionless by construction.
 For a legacy client on spec version 2025-11-25 or earlier, the answer depends on that flag:
 | Client's protocol version | Session | What the load balancer must do |
 | --- | --- | --- |
 | **2026-07-28** | None. `Mcp-Session-Id` is never set. | Nothing. Any worker serves any request. |
 | **2025-11-25 and earlier** (the default) | `Mcp-Session-Id`, held in one worker's memory. | **Sticky sessions.** A follow-up that reaches a different worker gets a `404` *"Session not found"*. |
 | **2025-11-25 and earlier**, with `stateless_http=True` | None. | Nothing. The cost is the server-to-client back-channel (sampling, push elicitation, `roots/list`) and resumability. |
 Sticky sessions and what the legacy leg costs are their own page, **[Serving legacy clients](legacy-clients.md)**; the two eras themselves are **[Protocol versions](../protocol-versions.md)**. What matters here is the shape of the answer: *on 2026-07-28 you are already stateless, with nothing to configure.*
 The rest of this page is the two things that being stateless does **not** buy you.
 ## `requestState` across workers
 A **[multi-round-trip](../handlers/multi-round-trip.md)** tool needs something the client has to go get (a confirmation, a choice, a credential), so it returns a question instead of an answer and finishes on the retry. Between the two rounds the client holds an opaque `request_state` token the server minted. On the retry the server has to open that token again.
 *Sealed under what key?* By default, one the server generated with `os.urandom(32)` at construction time. Under `--workers 4` that is four constructions, in four processes: four different keys, never written anywhere, never shared, gone on restart.
 Here is a tool that asks before it acts, on a server that configures nothing:
 ```python title="server.py" hl_lines="15 21"
 --8<-- "docs_src/deploy/tutorial002.py"
 ```
 The first round reaches worker A. Worker A seals `refund:120` under **its** key and returns the token. The client puts the question in front of a person, gets a yes, and retries. The retry is a brand-new HTTP request.
 !!! check
    Let that retry reach worker B. B tries to unseal a token it did not mint, cannot, and refuses the
    whole round. `refund` is never called; the client gets a JSON-RPC error:
    ```json
    {
      "code": -32602,
      "message": "Invalid or expired requestState",
      "data": {"reason": "invalid_request_state"}
    }
    ```
    That message is **frozen**. Expired, tampered with, replayed against different arguments, or (by
    far the most common cause in a real deployment) sealed by a sibling worker: the client is told
    the same thing every time, so the wire never reveals which check failed. The real reason is one
    `WARNING` in the server's log:
    ```text
    requestState rejected on tools/call: unknown key
    ```
    A multi-round-trip tool that worked with one worker and started failing *some of the time* at
    two is this. Both rounds still have to reach the same process, so it fails exactly as often as
    your load balancer separates them.
 The two rounds are two independent HTTP requests, and several ordinary things separate them: a proxy that balances per request, a connection that dropped in between, a deploy or a restart, a client that persisted `request_state` and is resuming from a different process entirely (**[Driving the loop yourself](../handlers/multi-round-trip.md#driving-the-loop-yourself)**). Any of them is "a different worker".
 The fix is one argument. It has **two** halves.
 ```python title="server.py" hl_lines="3 13 15"
 --8<-- "docs_src/deploy/tutorial003.py"
 ```
 * **`keys=[...]`** is the half everyone finds. Give every instance the same secret (at least 32 bytes of it), and every instance can unseal what any sibling minted. `keys[0]` seals and every key in the list unseals, which is the rotation ring; **[Rotating keys](../handlers/multi-round-trip.md#rotating-keys)** is how you turn it without downtime.
 * **The server's name** is the half almost nobody finds, and the reason cross-instance retries still fail after you share the key. Every sealed token carries the server's `name` as an **audience claim**, checked strictly on the way back in. Two instances built from the same code have the same name and never notice it. Name them apart (`MCPServer(f"billing-{POD}")` reads like good observability hygiene), and every cross-instance retry is refused exactly as above, shared key or not. The log says `audience` instead of `unknown key`; the client cannot tell the difference.
 Mint the secret once and hand the same value to every instance. This is the command the SDK's own error message tells you to run if you pass it fewer than 32 bytes:
 ```console
 python -c "import secrets; print(secrets.token_hex(32))"
 ```
 !!! warning "Same keys, *and* the same name"
    A multi-instance deployment must share both. If per-instance names are load-bearing for you,
    give the fleet one explicit audience instead: `RequestStateSecurity(keys=[...], audience="billing")`.
    Every instance then mints and accepts under `"billing"` no matter what it is called.
 Everything else about the seal is **[Protecting `requestState`](../handlers/multi-round-trip.md#protecting-requeststate)**: what it binds, the per-round `ttl` (600 seconds by default), bringing your own codec, why the unconfigured default is exactly right on `stdio`. This page's whole contribution is a two-item checklist: *same keys, same name.*
 !!! info
    You are on this path even if you have never typed `InputRequiredResult`. A tool whose parameters
    use `Resolve(...)` (**[Dependencies](../handlers/dependencies.md)**) is a multi-round-trip tool,
    and the SDK mints and seals its `request_state` for it. Same default key, same failure across
    workers, same fix.
 ## Change notifications across replicas
 A client's `subscriptions/listen` stream is one long-lived response, so it is pinned to one replica for its whole life. A `ctx.notify_resource_updated(...)` published on a **different** replica has to reach it.
 The seam between the two is the `SubscriptionBus`. Whatever bus you give a server is the one every publish goes into and every open stream listens on, so hand the same bus to every replica:
 ```python title="server.py" hl_lines="2 7 9"
 --8<-- "docs_src/deploy/tutorial004.py"
 ```
 Nothing about the fan-out cares which server object a stream is attached to. Two servers holding one `InMemorySubscriptionBus` already behave this way: open a listen stream on one, `edit_note` on the other, and the stream hears about it. That in-memory bus only spans server objects inside one process, which makes it the model, not the deployment:
 * Across real processes, **the SDK ships no bus that can help you.** `SubscriptionBus` is a two-method `Protocol` (`publish` and `subscribe`) that you implement over your own pub/sub backend (Redis, NATS, whatever you already run) and pass as `MCPServer(subscriptions=...)`. **[Subscriptions](../handlers/subscriptions.md#scaling-past-one-process)** has the sketch and the contract.
 * The bus carries four small typed events, never JSON-RPC. Acknowledgment, filtering, and stream lifecycle stay in the SDK, so your bus cannot break the protocol; it can only move events between processes.
 * Streams are **not** resumable and events are **not** replayed. Losing a replica drops its streams; the clients re-listen and re-fetch. There is no event store to share and nothing else to configure. This is the one place where scaling out is genuinely just more of the same.
 ## What the SDK does not give you
 An `MCPServer` is a protocol implementation, not an application server. The deployment knobs you go looking for next are missing on purpose:
 * **No `workers=`.** `mcp.run("streamable-http")` starts exactly one uvicorn process, and that is all it will ever start. Multi-process is `streamable_http_app()` handed to whatever you already deploy ASGI with: `uvicorn --workers`, gunicorn, your platform's process manager. This page is deliberately not a tutorial for any of them; their documentation is better than a copy of it here would be.
 * **No health-check route.** `@mcp.custom_route("/health", methods=["GET"])` is the whole answer, and it is never authenticated even when the rest of the server is. That is right for a liveness probe, wrong for anything private. **[Add to an existing app](asgi.md#custom-routes)** shows one.
 * **No production settings object.** There is nowhere on `MCPServer` to write down timeouts, TLS, graceful shutdown, or connection limits, because none of those are its job. They belong to your ASGI server, and you configure them there. **[Running your server](index.md)** covers the handful of settings the constructor *does* take.
 * **No shipped `EventStore`, and on 2026-07-28 no use for one.** Resumability is a feature of the legacy stateful leg; a modern exchange is one POST, one response, and nothing to resume.
 ## Recap
 * Out of the box the app answers only requests addressed to localhost. `transport_security=TransportSecuritySettings(allowed_hosts=[...], allowed_origins=[...])` is the go-live gate: until you pass it, every request behind a real hostname is a `421` and the reason is only in the server's log.
 * On 2026-07-28 there is no session and nothing for a load balancer to be sticky on. `stateless_http=True` is a legacy-only knob because a modern request is routed and answered before that flag is ever read.
 * The default `requestState` key is `os.urandom(32)`, minted per process. A multi-round-trip retry that reaches a different worker fails with `-32602` *"Invalid or expired requestState"*.
 * The fix is `RequestStateSecurity(keys=[...])` **and** the same server name on every instance. The name is the token's default audience claim. Same keys, same name.
 * Change notifications cross replicas through one shared `SubscriptionBus`. The SDK's only implementation is in-process; the two-method `Protocol` over your own pub/sub is yours to write.
 * There is no `workers=`, no health route, no production settings object. Bring your own ASGI server.
 The other thing a real hostname needs in front of it is a token: **[Authorization](authorization.md)**.
@@ -0,0 +1,148 @@
 # Running your server
 `mcp.run()` starts the server.
 The only decision you make is the **transport**: how the bytes between your server and its client actually move.
 ## Pick a transport
 | Transport | What it is | When |
 |---|---|---|
 | `stdio` | The host launches your file as a subprocess and speaks over its stdin and stdout. | Local servers. The default. |
 | `streamable-http` | A real HTTP server listening on a port. | Anything you deploy. |
 | `sse` | The older HTTP transport. | You don't. |
 !!! warning
    SSE was superseded by Streamable HTTP in the 2025-03-26 protocol revision.
    `mcp.run(transport="sse")` still works, with its own `sse_path=` and `message_path=`
    options, but it exists for clients that haven't moved. Don't build anything new on it.
 ## `mcp.run()`
 ```python title="server.py" hl_lines="12-13"
 --8<-- "docs_src/run/tutorial001.py"
 ```
 * `run()` is synchronous. It blocks for the life of the server.
 * With no argument, the transport is `stdio`.
 * It sits under `if __name__ == "__main__":` because everything that loads your server (`mcp dev`, `mcp run`, `mcp install`, your tests) **imports** this file. The guard keeps an import from turning into a running server.
 ### stdio
 There is nothing to configure. The host starts your file as a child process, writes requests to its stdin, and reads responses from its stdout.
 Run it yourself and you see the consequence:
 ```console
 python server.py
 ```
 Nothing prints, and it doesn't return. It is waiting on stdin for a host to speak first.
 That also means stdout **is the wire**. A stray `print()` corrupts the stream; the `logging` module writes to stderr and is the right tool. That story is in **[Logging](../handlers/logging.md)**.
 ### Try it
 ```console
 uv run mcp dev server.py
 ```
 The Inspector does exactly what a real host does: it launches `server.py` as a subprocess and connects to it over stdio.
 You never gave it a port. There isn't one.
 ## Streamable HTTP
 To put the same server on a port instead, name the transport (and its options) in `run()`:
 ```python title="server.py" hl_lines="13"
 --8<-- "docs_src/run/tutorial002.py"
 ```
 That one line builds a Starlette app and serves it with uvicorn. Clients connect to `http://127.0.0.1:3001/mcp`.
 Each transport has its own keyword arguments, all on `run()`:
 * `host` / `port`: where to listen. Defaults `127.0.0.1` and `8000`.
 * `streamable_http_path`: where the MCP endpoint lives. Default `/mcp`.
 * `json_response=True`: answer with plain JSON instead of an SSE stream.
 * `stateless_http=True`: a fresh transport per request, no session tracking.
 * `event_store`, `retry_interval`, `transport_security`: resumability and DNS-rebinding protection. They can wait, until you deploy somewhere other than localhost; **[Deploy & scale](deploy.md)** covers `transport_security`.
 !!! warning
    Transport options go to `run()`, **not** to `MCPServer(...)`. The constructor describes what
    your server *is*: name, version, instructions. `run()` describes how it is served. Get it
    backwards and Python answers before MCP is even involved:
    ```text
    TypeError: MCPServer.__init__() got an unexpected keyword argument 'port'
    ```
 `run()` is the short road. The moment you need more (your server mounted inside an existing app, two servers in one process, CORS for browser clients), you build the ASGI app yourself and hand it to any ASGI host. That is **[Add to an existing app](asgi.md)**.
 ## Server settings
 A couple of things about running are not about the transport. They are constructor arguments:
 ```python title="server.py" hl_lines="3"
 --8<-- "docs_src/run/tutorial003.py"
 ```
 * `log_level`: handed to `logging.basicConfig()` the moment `MCPServer(...)` is constructed. That configures the **root** logger, so it sets the level for your own loggers too, not just the SDK's. Default `"INFO"`.
 * `debug`: forwarded to the Starlette app that the HTTP transports build. Default `False`.
 Both land on `mcp.settings`, which you can read back at runtime.
 ## The `mcp` command
 The `[cli]` extra installs a small command-line tool around all of this.
 `mcp dev` runs your server under the **MCP Inspector**:
 ```console
 uv run mcp dev server.py
 uv run mcp dev server.py --with pandas --with numpy
 uv run mcp dev server.py --with-editable .
 ```
 `--with` adds packages to the environment it builds; `--with-editable` installs your own package into it. It needs `npx` on your `PATH`: the Inspector is a Node.js app.
 `mcp run` imports the file, finds the server object (a module-level `mcp`, `server`, or `app`), and calls `run()` on it:
 ```console
 uv run mcp run server.py
 uv run mcp run server.py:bookshop
 ```
 The `:` suffix names the object when it isn't called `mcp`, `server`, or `app`.
 Your `if __name__ == "__main__":` block never executes here: `mcp run` calls `run()` itself, and the only option it forwards is `--transport`.
 `mcp install` registers the server with **Claude Desktop**, so the app launches it for you:
 ```console
 uv run mcp install server.py --name "Bookshop"
 uv run mcp install server.py -v API_KEY=abc123 -f .env
 ```
 `-v KEY=VALUE` and `-f .env` record environment variables in that entry. Claude Desktop starts your server in its own process. Your shell's environment is not there.
 Claude Desktop is the only host `mcp install` knows. Every other host (Claude Code, Cursor, VS Code) takes the same launch command in its own config file, and **[Connect to a real host](../get-started/real-host.md)** has each one.
 `mcp version` prints the installed SDK version.
 !!! tip
    `mcp dev` and `mcp run` only understand `MCPServer`. If you build with the low-level `Server`,
    you run it yourself. See **[The low-level Server](../advanced/low-level-server.md)**.
 ## Recap
 * A **transport** is how bytes reach your server: `stdio` for a local subprocess, `streamable-http` for a port. SSE is superseded.
 * `mcp.run()` picks the transport. With no argument it is `stdio`, and it blocks.
 * Every transport option (`host`, `port`, `streamable_http_path`, ...) is an argument to `run()`, never to `MCPServer(...)`.
 * Keep `run()` under `if __name__ == "__main__":`. Everything that loads your server imports the file first.
 * `log_level=` and `debug=` are constructor arguments; they land on `mcp.settings`.
 * `mcp dev` for the Inspector, `mcp run` to execute a file, `mcp install` for Claude Desktop, `mcp version` for the version.
 * The transport never changes what your server *is*: all three files on this page expose the identical tool.
 When `run()` itself is the limit (your server inside an app that already exists), it is **[Add to an existing app](asgi.md)**. A real hostname and more than one worker is **[Deploy & scale](deploy.md)**. And if some of your clients are still on spec version 2025-11-25 or earlier, **[Serving legacy clients](legacy-clients.md)** is the good news.
@@ -0,0 +1,120 @@
 # Serving legacy clients
 MCP has two protocol eras: the `initialize`-handshake era, up to spec version `2025-11-25`, and the modern era, `2026-07-28`. **[Protocol versions](../protocol-versions.md)** is the page on the split itself.
 This page is about the server side of that split, and the answer fits in one sentence: **the `streamable_http_app()` you already deploy serves both.**
 The SDK routes every request by its `MCP-Protocol-Version` header. A request naming `2026-07-28` goes to the modern handler. A request naming a handshake-era version, or carrying no header at all (which is how a pre-2026 client's `initialize` arrives), goes to the transport those clients expect: `initialize` handshake, sessions and all. It happens per request, before your code, on the one app.
 So a legacy client is not something you build *for*. It is something that connects *to* the server you already wrote. You configure nothing.
 !!! note
    Nothing, literally. There is no `legacy=` option, no version allowlist, no way to reject or
    disable an era: not on `streamable_http_app()`, not on `run()`, not on the session manager.
    Both eras are always on. The nearest thing to a per-era switch in that signature is
    `stateless_http`, and it is most of this page.
 ## One handler, both eras
 Here is a tool that has to ask the user something, and both eras of client calling it:
 ```python title="server.py" hl_lines="24 37-38"
 --8<-- "docs_src/legacy_clients/tutorial001.py"
 ```
 `reserve` needs one thing the model didn't supply: how many copies. `Annotated[..., Resolve(ask_quantity)]` is how a tool declares that (**[Dependencies](../handlers/dependencies.md)** is that whole story). Nothing in `reserve` names a version, checks a capability, or branches.
 The two clients are open **at the same time**, on the same `mcp` object. `mode="legacy"` runs the `initialize` handshake: the exact connection a pre-2026 client opens. The other one takes the default and lands on `2026-07-28`.
 ```text
 2025-11-25 {'result': "Reserved 2 of 'Dune'."}
 2026-07-28 {'result': "Reserved 2 of 'Dune'."}
 ```
 Same server, same handler, same answer. That is the whole feature.
 It is worth pausing on *how*, because the two clients were asked the same question over two completely different wires. The `2026-07-28` connection has no channel for the server to send a request on, so `Resolve` returned the question inside the tool result and the client retried the call with the answer (**[Multi-round-trip requests](../handlers/multi-round-trip.md)**). The `2025-11-25` connection has no such thing; there, `Resolve` sent a live `elicitation/create` request mid-call and waited. You wrote neither. `Resolve` reads the connection's negotiated version and picks; your tool body sees an `AcceptedElicitation` either way.
 !!! tip
    That era-portability is *why* `Resolve` is the API to build on. Its older sibling `ctx.elicit()`
    (**[Elicitation](../handlers/elicitation.md)**) only ever sends `elicitation/create`, so it only
    ever works on a legacy connection. On a `2026-07-28` one the call fails. If a tool still uses
    it, the fix is the one you see above, not a version check.
 ## What a legacy session costs you
 The routing is free. The session is not.
 A `2026-07-28` connection is **sessionless**: every request stands alone, and the modern handler never issues an `Mcp-Session-Id`. A legacy connection is the opposite. The moment a pre-2026 client sends `initialize`, the SDK mints an `Mcp-Session-Id`, returns it in a response header, and keeps a live record behind it for the client's later requests to find: the negotiated version, the open streams, a background task driving the session.
 That record is a **plain in-process `dict`**. There is no distributed session store and no way to plug one in.
 On one worker that is invisible. On two, it is the whole problem: a request that carries an `Mcp-Session-Id` and lands on a worker that didn't mint it finds nothing in that dict, and the answer is a `404` (`Session not found`), not the tool result. So the moment you run more than one worker, **legacy clients need sticky routing**: every request in a session has to reach the process that started it. Modern clients never do; they have no session to be sticky to. **[Deploy & scale](deploy.md)** covers stickiness and everything else about running more than one of these.
 !!! warning
    `event_store=` looks like the fix and is not. It is **resumability** (replaying missed SSE
    events to a client reconnecting to the *same* session), not a session store. It never makes a
    session reachable from another process.
 ## The one knob: `stateless_http`
 If stickiness is a cost you refuse to pay, there is exactly one thing you can change.
 ```python title="server.py" hl_lines="28"
 --8<-- "docs_src/legacy_clients/tutorial002.py"
 ```
 That is the server from the top of the page plus one keyword. `stateless_http=True` makes the legacy leg build a throwaway, per-request session instead: no `Mcp-Session-Id` issued, nothing remembered between requests, so any worker can serve any request and the load balancer can do whatever it likes.
 Two things about it matter more than what it does.
 **It only touches the legacy leg.** Requests are routed on the version header *before* `stateless_http` is read, so the modern path never sees it. A `2026-07-28` connection is already sessionless and is exactly the same under either value.
 **It costs both server-to-client channels on that leg.** A session that lives for one `POST` has no stream for the server to push a request down and no standalone stream for it to push notifications down. Every server-initiated request raises `NoBackChannelError`: `ctx.elicit()`, the retired sampling and roots calls (**[Deprecated features](../deprecated.md)**), and, yes, `Resolve` asking a *legacy* client its question. Notifications don't even get an error; they are silently dropped.
 !!! check
    Do the wrong thing. `reserve` is the exact tool that just served both clients. Deploy it with
    `stateless_http=True`, connect the same two clients over HTTP, and call it from each.
    The modern client still gets `Reserved 2 of 'Dune'.` The modern leg didn't change.
    The legacy client's call does not come back as an `is_error` result the model could read.
    The whole request fails, as a top-level protocol error:
    ```text
    mcp.shared.exceptions.MCPError: Cannot send 'elicitation/create': this transport context has no back-channel for server-initiated requests.
    ```
    `Resolve` did not save you. On a `2025-11-25` connection it *has* to send `elicitation/create`,
    and the channel it needs is exactly the thing `stateless_http=True` gave away. Era-portable
    code is not back-channel-free code.
 So it is a real trade, and it only exists on the legacy leg: **sessionful and sticky, or stateless and one-directional.** If your tools never call back into the client, `stateless_http=True` is free and you should take it. If they do, keep the sessions and keep the routing sticky.
 ## Where your code actually forks
 Almost nowhere.
 Tools, resources, prompts, structured output, progress, errors: none of them care which era called. The `initialize` handshake, the `Mcp-Session-Id`, the standalone stream, the `DELETE` that ends a session: the SDK owns all of it, and a handler never sees any of it. Interactive input is *the* place the eras genuinely differ on the wire, and `Resolve` exists so that it is not your problem: you just watched one tool serve both.
 There is exactly one thing left, and it is **change notifications**, because the two eras listen on different pipes:
 * A `2026-07-28` client opens a `subscriptions/listen` stream and reads the subscriptions bus. `ctx.notify_resource_updated()` (and `notify_tools_changed()`, `notify_prompts_changed()`, `notify_resources_changed()`) publish there, and *only* there. **[Subscriptions](../handlers/subscriptions.md)** is that page.
 * A legacy client reads the standalone stream its session keeps open. `ctx.session.send_resource_updated()` (and `send_tool_list_changed()` and friends) write to the *connection* that carried the request: for a legacy session, that is its standalone stream. For a modern HTTP request there is no such channel, and the notification is quietly dropped.
 Over HTTP, neither call reaches the other era's clients. To tell everyone, call both:
 ```python title="server.py" hl_lines="19-20"
 --8<-- "docs_src/legacy_clients/tutorial003.py"
 ```
 Two lines, no `if`, no version check, and you are done. That is the entire list of things a handler does differently because a legacy client exists.
 ## Recap
 * One `streamable_http_app()` serves both protocol eras. The SDK routes each request by its `MCP-Protocol-Version` header; there is nothing to configure and no era knob to look for.
 * A legacy client costs you a session: an in-process `Mcp-Session-Id` record with no distributed store behind it. More than one worker means **sticky routing**, or the wrong worker answers `404 Session not found`. **[Deploy & scale](deploy.md)** has the multi-worker story.
 * `stateless_http=True` is the one knob, and it is **legacy-leg-only**. It buys free load balancing for legacy clients at the price of both server-to-client channels on that leg: server-initiated requests raise `NoBackChannelError` (a top-level error at the client, not an `is_error` result), and notifications are dropped.
 * A `2026-07-28` connection is sessionless either way. `stateless_http` never touches it.
 * Your handler code forks on era in exactly one place: change notifications. `ctx.notify_*` reaches `subscriptions/listen` clients; `ctx.session.send_*` reaches legacy sessions. Call both.
 * Everything else (including asking the user for input, via `Resolve`) is era-portable by construction. Write the modern thing once.
@@ -0,0 +1,107 @@
 # OpenTelemetry
 Your server is already traced. You don't have to add anything.
 Every server you create emits an [OpenTelemetry](https://opentelemetry.io/) span for every
 message it handles. You didn't write that, and you don't import it. It is there the moment you
 call `MCPServer(...)`.
 ```python title="server.py"
 --8<-- "docs_src/opentelemetry/tutorial001.py"
 ```
 That is a complete, traced server. Call `search_books` and a span is created for it. The same is
 true for the low-level `Server`: the tracing lives on both.
 ## What you get
 Every inbound message becomes a `SERVER` span named after the method and its target. So a
 `tools/call` for `search_books` is the span `tools/call search_books`, and a bare `tools/list`
 is just `tools/list`.
 Each span carries a few attributes:
 * `mcp.method.name` and `mcp.protocol.version`, on every span.
 * `jsonrpc.request.id`, on a request (a notification has none).
 * A handler that raises sets the span status to error. So does a tool result with `is_error=True`.
 And because tracing a tool call is such a common thing to want, `tools/call` spans speak
 OpenTelemetry's [GenAI semantic conventions](https://opentelemetry.io/docs/specs/semconv/gen-ai/):
 * `gen_ai.operation.name`, set to `"execute_tool"`.
 * `gen_ai.tool.name`, set to the tool being called.
 A `prompts/get` span gets `gen_ai.prompt.name` in the same spirit. The list methods carry no
 `gen_ai.*` keys, because there is nothing to name.
 !!! tip
    Those GenAI attributes are the reason a tracing UI groups your tool calls the way it groups
    any other agent's. You get that grouping for free, with no extra code.
 ## It costs nothing until you want it
 Here is the part that makes "on by default" a comfortable default.
 The SDK depends only on `opentelemetry-api`, the lightweight half of OpenTelemetry. With no SDK
 and no exporter installed, creating a span is a no-op. So the spans your server is emitting right
 now cost you almost nothing, and nobody is collecting them.
 The day you want to *see* them, you install the other half and point it somewhere:
 ```console
 uv add opentelemetry-sdk opentelemetry-exporter-otlp
 ```
 Configure an exporter the usual OpenTelemetry way, and every span the SDK has been quietly
 creating lights up. Your server code does not change. Not one line.
 !!! info
    [Pydantic Logfire](https://logfire.pydantic.dev/) is one such backend, and it does the
    configuration for you: `pip install logfire`, `logfire.configure()`, and your MCP spans show
    up in the live view. It is built on OpenTelemetry, so anything below applies to it too.
 ## Traces that cross the wire
 A trace is most useful when it follows a request from the client into the server, in one
 connected picture.
 When the client and the server both run the SDK, that connection is automatic. The client injects
 the [W3C trace context](https://www.w3.org/TR/trace-context/) into the request, and the server
 reads it back out, so the server span nests under the client span in the same trace. This is
 [SEP-414](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/414), and you get it without
 asking.
 If the inbound message carries no trace context, for example a request from a client that is not
 the SDK, the server span simply parents to whatever span is already current on the server, rather
 than starting a brand-new orphan trace.
 ## Turning it off
 Tracing is a middleware, the first one on your server's list. If you really want a server that
 emits no spans, take it off:
 ```python
 from mcp.server._otel import OpenTelemetryMiddleware
 mcp._lowlevel_server.middleware[:] = [
    m for m in mcp._lowlevel_server.middleware if not isinstance(m, OpenTelemetryMiddleware)
 ]
 ```
 !!! warning
    That import has a leading underscore, and that is on purpose. The class is provisional, the
    same way [`Server.middleware`](../advanced/middleware.md) is provisional, so the import path is something
    you should expect to change. You almost never need this: with no exporter installed the spans
    are free, so the usual answer is to leave them on and not install an exporter.
 ## Recap
 * Every `MCPServer` and every low-level `Server` emits one `SERVER` span per inbound message, out
  of the box. You write nothing.
 * Spans carry `mcp.method.name` and `mcp.protocol.version`; `tools/call` and `prompts/get` also
  carry GenAI attributes so your tool calls group like any other agent's.
 * It costs nothing until you install an OpenTelemetry SDK and an exporter, and then it lights up
  with no change to your server.
 * Client-to-server trace context propagates automatically when both sides run the SDK.
 The thing that decides whether a request runs at all is **[Authorization](authorization.md)**.
@@ -0,0 +1,125 @@
 # Completions
 A client building a UI on top of your server wants to autocomplete argument values as the user types: language names, repository names, file paths.
 **Completions** are how your server supplies those suggestions.
 ## Something worth completing
 Completions apply to exactly two things: the arguments of a **prompt** and the parameters of a **resource template**. So start with a server that has one of each:
 ```python title="server.py" hl_lines="6 12"
 --8<-- "docs_src/completions/tutorial001.py"
 ```
 Nothing here is about completions yet.
 * `review_code` takes a `language`. A user shouldn't have to guess which spellings you accept.
 * `github_repo` takes an `owner` and a `repo`. Free-text boxes for both make a bad form.
 ## The completion handler
 Add **one** function decorated with `@mcp.completion()`:
 ```python title="server.py" hl_lines="22-30"
 --8<-- "docs_src/completions/tutorial002.py"
 ```
 * There is one handler per server. Every completion request lands here, and you branch on what's being completed.
 * It must be `async def`: the SDK awaits it.
 * It receives three arguments:
  * `ref`: *which* prompt or resource template, as a `PromptReference` or a `ResourceTemplateReference`. `isinstance` is how you tell them apart.
  * `argument`: `argument.name` is the argument being completed, `argument.value` is what the user has typed so far.
  * `context`: the arguments already resolved. Ignore it for now.
 * You return a `Completion(values=[...])`, or `None` when you have nothing to offer.
 !!! tip
    `argument.value` is the prefix the user has typed. The SDK does **not** filter for you: whatever
    you put in `values` is what the UI shows. The `startswith` is yours to write.
 ### Try it
 Drive it with the in-memory `Client` from **[Testing](../get-started/testing.md)**. Call
 `client.complete()` with `ref=PromptReference(name="review_code")` and
 `argument={"name": "language", "value": "py"}`:
 ```python
 result.completion.values  # ['python']
 ```
 * `ref` is the same reference type your handler receives.
 * `argument` is a plain dict with exactly two keys, `name` and `value`.
 Send an empty `value` and you get the whole list back. `lang.startswith("")` is true for every language:
 ```python
 result.completion.values  # ['go', 'javascript', 'python', 'rust', 'typescript']
 ```
 Ask about `code` (an argument your handler doesn't recognise) and it returns `None`, which the SDK turns into an empty list:
 ```python
 result.completion.values  # []
 ```
 `None` means *"no suggestions"*, never an error. A UI falls back to a plain text box.
 ## A capability you never declared
 Registering the handler is the declaration. Connect a client and look:
 ```python
 client.server_capabilities.completions  # CompletionsCapability()
 ```
 You didn't list `completions` anywhere. The SDK saw the handler and declared the capability for you. Every *optional* capability works this way: the handler is the declaration. (The three primitives are not optional: `MCPServer` always declares those, handlers or not.)
 !!! check
    Go back to the first `server.py` (the one with no handler) and ask it anyway. The call fails
    with a JSON-RPC error:
    ```text
    Method not found
    ```
    And `client.server_capabilities.completions` is `None`. That's the point of the capability: a
    well-behaved client checks it and never sends the request you can't answer.
 ## Dependent arguments
 `github://repos/{owner}/{repo}` has two parameters, and the useful values for `repo` depend on which `owner` was picked first.
 That's what `context` is for. It carries the arguments the user has **already resolved**:
 ```python title="server.py" hl_lines="9-12 35-39"
 --8<-- "docs_src/completions/tutorial003.py"
 ```
 * The new branch fires for the template's `repo` parameter.
 * `context.arguments` is a `dict[str, str] | None` of the values picked so far (here, `owner`).
 * No `owner` yet means no sensible suggestions, so the handler returns `None`.
 The client sends those resolved values with `context_arguments=`. This time `ref` is a
 `ResourceTemplateReference(uri="github://repos/{owner}/{repo}")`. Ask for `repo` with an
 empty `value` and pass `context_arguments={"owner": "modelcontextprotocol"}`:
 ```python
 result.completion.values  # ['python-sdk', 'typescript-sdk', 'inspector']
 ```
 Drop `context_arguments=` and the same call returns `[]`. The handler can't know which repos to offer until it knows the owner.
 !!! info
    `Completion` also takes `total=` and `has_more=`. Set them when `values` is a slice of a longer
    list, so a UI can show *"and 200 more"*. Most handlers never need them.
 ## Recap
 * Completions are suggestions for **prompt arguments** and **resource template parameters**. Nothing else.
 * `@mcp.completion()` registers the one handler. It's `async def (ref, argument, context) -> Completion | None`.
 * Branch on `isinstance(ref, ...)` and on `argument.name`. Filter by `argument.value` yourself.
 * `None` becomes an empty list. It is never an error.
 * `context.arguments` holds the already-resolved values; the client supplies them as `context_arguments=`.
 * The `completions` capability appears the moment you register the handler. Without it, the request is `Method not found`.
 Suggestions help while the user is still *filling in* a prompt or template; to ask them a question in the *middle* of a tool call, you want **[Elicitation](../handlers/elicitation.md)**. Everything a tool can return besides text is **[Images, audio & icons](media.md)**.
@@ -0,0 +1,134 @@
 # Handling errors
 A tool can fail in two ways, and the SDK treats them very differently.
 Raise an ordinary exception and the **model** sees it. Raise `MCPError` and the **protocol** sees it.
 This page is about choosing.
 ## An error the model can fix
 Take a tool that looks something up, and let the lookup miss:
 ```python title="server.py" hl_lines="11-12"
 --8<-- "docs_src/handling_errors/tutorial001.py"
 ```
 There is nothing MCP about those two lines. `get_author` raises a plain `ValueError`, the way any Python function would.
 Call it with a title that isn't in the catalog and look at the result:
 ```python
 result.is_error            # True
 result.content             # [TextContent(text="Error executing tool get_author: No book titled 'Nothing' in the catalog.")]
 result.structured_content  # None
 ```
 * The request **succeeded**. There is a result; nothing was raised at the caller.
 * `is_error` is `True`, and your exception's message (prefixed with the tool name) is in `content`, exactly where the model reads.
 * `structured_content` is `None`. A failed call has no return value to structure.
 This is a **tool error**, and it is the default for *any* exception your tool raises. It is also almost always what you want.
 The model is the one calling your tool. It picked the arguments. So a tool error is a turn in the conversation: the model reads *"No book titled 'Nothing' in the catalog."*, realises it guessed the title wrong, and calls again with a better one. You wrote one `raise` and got a self-correcting agent.
 !!! tip
    Never `return` an error message from a tool. A returned string has `is_error=False`, so to the
    model (and to every client UI) it looks like the tool worked and that string was the answer.
    `raise`. The flag is the signal.
 ## An error the model cannot fix
 Now swap `ValueError` for `MCPError`.
 ```python title="server.py" hl_lines="1 3 15"
 --8<-- "docs_src/handling_errors/tutorial002.py"
 ```
 `MCPError` is the SDK's **protocol error**. It is the one exception the tool wrapper does *not* catch: it propagates, and the whole `tools/call` request fails with a JSON-RPC error instead of a result.
 ```json
 {
  "code": -32602,
  "message": "No book titled 'Nothing' in the catalog."
 }
 ```
 * There is **no result**. No `content`, no `is_error`: nothing for the model to read.
 * The **host** application gets the error instead, the same way it would if the tool didn't exist at all.
 * `code`, `message`, and `data` arrive intact. `INVALID_PARAMS` is `-32602`; `mcp_types` exports it and the other JSON-RPC error codes (`INVALID_REQUEST`, `INTERNAL_ERROR`, ...) as constants so you never type a magic number.
 !!! check
    Same lookup, same miss, but now the call *raises* on the client side instead of returning:
    ```text
    mcp.shared.exceptions.MCPError: No book titled 'Nothing' in the catalog.
    ```
    The first version handed the model a sentence it could react to. This one hands it nothing.
    For `get_author` that is strictly worse, which is the point of the next section.
 ## Which one to raise
 The two paths answer two different questions.
 * **Raise any exception** for a failure of *execution*: the thing your tool tried to do didn't work. The model chose the call, so the model should see the consequence and get a chance to recover. A misspelled title, an upstream API that timed out, a row that doesn't exist: all tool errors.
 * **Raise `MCPError`** when the *request itself* should be rejected: the client is missing a capability your tool depends on, the server isn't in a state to serve anyone, the caller skipped a required step. No retry from the model fixes any of those, so there is nothing to gain from handing it the message.
 One question decides it: **could a smarter model have avoided this?** Yes -> ordinary exception. No -> `MCPError`.
 By that test, the second version of `get_author` made the wrong choice: a better title fixes it, so the model deserved to see the message. It's there to show you the mechanism, not to recommend it.
 !!! info
    `MCPError` lives at `from mcp import MCPError` and takes `code`, `message`, and an optional
    `data` payload. Whatever you put in them is what the client receives: the SDK forwards a raised
    `MCPError` verbatim instead of sanitising it.
 ## A resource that doesn't exist
 Resources draw the same line, and ship one named exception for the common case.
 ```python title="server.py" hl_lines="2 13"
 --8<-- "docs_src/handling_errors/tutorial003.py"
 ```
 `books://{title}` is a **template**. It matches *any* title, so "the URI is well-formed" and "the book exists" are two different questions, and only your function can answer the second one.
 When it can't, raise `ResourceNotFoundError`. The SDK turns it into the protocol error the spec assigns to a missing resource: `-32602` with the requested URI in `data`, so the client knows *which* read failed.
 ```json
 {
  "code": -32602,
  "message": "No book titled 'Nothing' in the catalog.",
  "data": {"uri": "books://Nothing"}
 }
 ```
 Notice there is no `is_error=True` half-result here. A resource read either returns contents or fails: resources have only the protocol path. Templates and everything else about resources live in **[Resources](resources.md)**.
 ## Errors you never raise
 A bad argument never reaches your function.
 Send `get_author` a `title` that isn't a string and the SDK rejects it against the input schema **before** calling you, as the same kind of `is_error=True` tool error the model can read and correct. **[Tools](tools.md)** shows the same rejection with a `Field(le=50)` constraint.
 It means a whole class of `raise` statements you don't write: don't re-validate your own type hints.
 !!! info
    Everything on this page is what a **client** sees, and the in-memory `Client` you'll write
    tests with sees exactly the same thing. Even `raise_exceptions=True` doesn't turn a tool error
    back into a traceback: by the time that flag could act, your exception is already the
    `is_error=True` result. Assert on the result. **[Testing](../get-started/testing.md)** covers the pattern.
 ## Recap
 * Raise **any exception** in a tool -> the call returns `is_error=True` with your message in `content`. The model reads it and can retry. This is the default.
 * Raise **`MCPError`** -> the call itself fails with a JSON-RPC error. The model sees nothing; the host deals with it. `code`, `message`, and `data` survive intact.
 * The deciding question: *could a smarter model have avoided this?* Yes -> exception. No -> `MCPError`.
 * `ResourceNotFoundError` from a resource handler -> the protocol's `-32602`, with the URI in `data`.
 * Bad arguments are rejected against the schema before your function runs; you don't `raise` for those.
 * `from mcp import MCPError`; the error-code constants come from `mcp_types`.
 Errors handled. That is everything a server *exposes*. What every handler can read, and do back to the client while it runs, is the next section: **[Inside your handler](../handlers/index.md)**.
 The exact text of the SDK errors you are most likely to meet, what each means, and the one-move fix for each is **[Troubleshooting](../troubleshooting.md)**.
@@ -0,0 +1,30 @@
 # Servers
 An `MCPServer` exposes three primitives to a connected client. They differ by who
 decides to use them:
 * A **[tool](tools.md)** is an action the *model* picks and calls. This is
  the page most people want first, and
  **[Structured Output](structured-output.md)** is its reference companion:
  everything about the shape of what a tool returns.
 * A **[resource](resources.md)** is read-only data the *application*
  chooses to read. **[URI templates](uri-templates.md)** is its reference
  companion: the full addressing syntax and the path-safety rules.
 * A **[prompt](prompts.md)** is a message template a *person* invokes by
  name, from a menu or a slash command.
 Around the three primitives, the rest of what a server declares:
 * **[Completions](completions.md)** is server-side autocomplete for prompt
  and resource-template arguments.
 * **[Images, audio & icons](media.md)** covers everything a tool can
  return besides text, and the icons a client shows next to your server.
 * **[Handling errors](handling-errors.md)** explains the difference between an
  error the model can recover from and one it must never see.
 Every page here stands on its own; jump straight to the one you need. If you haven't
 built a server yet, start with **[First steps](../get-started/first-steps.md)** instead.
 What happens *inside* the functions you register (the `Context`, dependency injection,
 asking the user for more input mid-call) is the next section,
 **[Inside your handler](../handlers/index.md)**.
@@ -0,0 +1,108 @@
 # Media
 Text is not the only thing a tool can return.
 The SDK ships two helpers for binary results (**`Image`** and **`Audio`**) and an **`Icon`** type for giving your server, tools, resources, and prompts a face in the client's UI.
 ## Returning an image
 Annotate the return type as `Image` and return one:
 ```python title="server.py" hl_lines="14 16"
 --8<-- "docs_src/media/tutorial001.py"
 ```
 * `Image` takes exactly one of `data` (raw bytes) or `path` (a file to read).
 * `format="png"` becomes the MIME type the client sees: `image/png`.
 * The bytes here are a one-pixel placeholder so the file runs on its own. In a real server they come from Pillow, matplotlib, a headless browser, or anything else that hands you `bytes`.
 `Image` is an SDK convenience, not a protocol type. On the wire your return value becomes an **`ImageContent`** block (your bytes base64-encoded, plus the MIME type):
 ```python
 result.content             # [ImageContent(type="image", data="iVBORw0KGgoAAAANSUhEUg...", mime_type="image/png")]
 result.structured_content  # None
 ```
 Two things to notice:
 * `data` is base64. You returned raw `bytes`; the SDK did the encoding.
 * `structured_content` is `None`. An `Image` is content for the model to look at, not data for the application to parse: there is no output schema. (Contrast **[Structured Output](structured-output.md)**, where the return annotation *is* the schema.)
 !!! info
    `ImageContent` and `AudioContent` live in `mcp_types`, right next to the `TextContent`
    that a plain `str` result becomes (**[Tools](tools.md)**). A tool result is a list of content blocks; `Image` and `Audio` are
    the shortest way to produce the two binary kinds.
 ### Try it
 ```console
 uv run mcp dev server.py
 ```
 Open the **Tools** tab and call `logo`. The result is not a string: it is an `image` content block, and the Inspector renders it as a picture. You returned `bytes`; everything between that and the pixels on screen was the SDK.
 ## Returning audio
 `Audio` is the same shape:
 ```python title="server.py" hl_lines="21-24"
 --8<-- "docs_src/media/tutorial002.py"
 ```
 The result is an **`AudioContent`** block:
 ```python
 result.content             # [AudioContent(type="audio", data="UklGRjQAAABXQVZFZm1...", mime_type="audio/wav")]
 result.structured_content  # None
 ```
 Same deal: raw bytes in, base64 and a MIME type out, no output schema.
 ## Bytes or a file
 Both helpers also accept `path=` instead of `data=`. The file is read when the result is built, and the MIME type is guessed from the suffix:
 * `Image`: `.png`, `.jpg`, `.jpeg`, `.gif`, `.webp`.
 * `Audio`: `.wav`, `.mp3`, `.ogg`, `.flac`, `.aac`, `.m4a`.
 A suffix it doesn't recognise falls back to `application/octet-stream`.
 !!! check
    With `data=` there is no filename, so there is nothing to guess from. Forget `format=` and
    the SDK falls back to a default: `image/png` for images, `audio/wav` for audio. Build an
    `Audio` from MP3 bytes that way and the client is told `mime_type="audio/wav"`, then
    faithfully fails to decode it. When you pass `data=`, pass `format=`.
 ## Icons
 An `Icon` is metadata, not content. It doesn't carry the image; it points at one with a URI, and a client may fetch it and show it next to your server's name, a tool, a resource, or a prompt.
 ```python title="server.py" hl_lines="5-6 8 11 17"
 --8<-- "docs_src/media/tutorial003.py"
 ```
 * `src` is a URI the client can resolve: `https:`, or a `data:` URI if you want the icon embedded with no extra fetch.
 * `mime_type` and `sizes` (`"48x48"`, or `"any"` for a scalable format) let the client pick the right one when you offer several.
 * `theme="light"` or `theme="dark"` marks an icon for one colour scheme.
 The same `icons=[...]` keyword is accepted by `MCPServer(...)`, `@mcp.tool()`, `@mcp.resource()`, and `@mcp.prompt()`.
 ### Where a client sees them
 Icons travel with whatever they decorate. The server's arrive when the client connects, on `client.server_info`:
 ```python
 client.server_info.icons  # [Icon(src="https://example.com/brand-kit.png", mime_type="image/png", sizes=["48x48"])]
 ```
 A tool's icons are on the `Tool` object from `tools/list`, a resource's on the `Resource` from `resources/list`, a prompt's on the `Prompt` from `prompts/list`. The field is always called `icons`.
 ## Recap
 * Return an `Image` or `Audio` from a tool and the client receives an `ImageContent` / `AudioContent` block: your bytes base64-encoded, with a MIME type.
 * Build one from in-memory `data=` plus an explicit `format=`, or from a `path=` and let the suffix decide.
 * Media results carry no `structured_content` and no output schema.
 * An `Icon` is a pointer: a `src` URI plus optional `mime_type`, `sizes`, and `theme`.
 * `icons=[...]` works on the server, on tools, on resources, and on prompts, and clients find them on the matching objects.
 That is everything a tool can put *into* a result. What happens when a tool *fails* (and who should find out) is **[Handling errors](handling-errors.md)**.
@@ -0,0 +1,150 @@
 # Prompts
 A **prompt** is a message template the user picks.
 Tools are for the model. A prompt is the opposite: the user chooses one from a menu in their client (a slash command, a button), fills in its arguments, and the rendered messages go into the conversation as if they had typed them.
 You declare one by putting `@mcp.prompt()` on a function that returns the text.
 ## Your first prompt
 ```python title="server.py" hl_lines="6-9"
 --8<-- "docs_src/prompts/tutorial001.py"
 ```
 The SDK reads the same three things it reads from a tool:
 * The **name** is the function name: `review_code`.
 * The **description** the client shows is the docstring: `Review a piece of code.`
 * The **arguments** come from the parameters. `code` has no default, so it's required.
 That is what a client gets back from `prompts/list`:
 ```json
 {
  "name": "review_code",
  "description": "Review a piece of code.",
  "arguments": [
    {"name": "code", "required": true}
  ]
 }
 ```
 There is no JSON Schema here. Prompt arguments are a flat list of **named string values**: a form a person fills in, not a payload a model constructs.
 ### Rendering it
 The client renders the template with `prompts/get`, passing the arguments. Your function runs and the `str` you return becomes **one user message**:
 ```json
 {
  "description": "Review a piece of code.",
  "messages": [
    {
      "role": "user",
      "content": {
        "type": "text",
        "text": "Please review this code:\n\ndef add(a, b): return a + b"
      }
    }
  ],
  "resultType": "complete"
 }
 ```
 That is the entire life of a prompt: listed by name, rendered on demand, dropped into the chat.
 !!! check
    `required` is enforced before your function runs. Render `review_code` without `code` and the
    request itself fails with a JSON-RPC error (code `-32603`):
    ```text
    mcp.shared.exceptions.MCPError: Internal server error
    ```
    There is no tool-style error result to hand back to a model, because no model is in the loop:
    the call raises. The reason (`Missing required arguments: {'code'}`) lands in your server's log.
 ### Try it
 Run the server with the MCP Inspector:
 ```console
 uv run mcp dev server.py
 ```
 Open the **Prompts** tab and select `review_code`. The Inspector draws a form with one required `code` field. Fill it in, render it, and you get back exactly the user message above.
 ## More than one message
 A code review is one message. A debugging session is a conversation, and a prompt can seed the whole thing.
 Return a list of messages instead of a `str`:
 ```python title="server.py" hl_lines="2 13-20"
 --8<-- "docs_src/prompts/tutorial002.py"
 ```
 * `UserMessage` and `AssistantMessage` come from `mcp.server.mcpserver.prompts.base`. Hand them a `str` and they wrap it in `TextContent` for you. The role is the class name.
 * `Message` is their common base. Use it as the return annotation.
 Rendering `debug_error` now produces three messages, in order:
 ```json
 {
  "description": "Start a debugging conversation.",
  "messages": [
    {"role": "user", "content": {"type": "text", "text": "I'm seeing this error:"}},
    {"role": "user", "content": {"type": "text", "text": "TypeError: 'int' object is not iterable"}},
    {
      "role": "assistant",
      "content": {"type": "text", "text": "I'll help debug that. What have you tried so far?"}
    }
  ],
  "resultType": "complete"
 }
 ```
 Notice the last one. Pre-filling an `assistant` turn is how you steer the model's *next* reply without making the user type the steering themselves.
 ## Titles and argument descriptions
 `review_code` is a function name, not a label. Give the client something better to put on the button, and describe each argument so the form explains itself:
 ```python title="server.py" hl_lines="10-13"
 --8<-- "docs_src/prompts/tutorial003.py"
 ```
 * `title="Code review"` is the human-readable name, exactly like a tool's `title`.
 * `Annotated[str, Field(description=...)]` is the same pattern **[Tools](tools.md)** uses to describe a tool's parameters. Here the description lands on the argument instead of in a schema.
 * `language` has a default, so it stops being required.
 The `prompts/list` entry now carries everything a client needs to draw a good form:
 ```json
 {
  "name": "review_code",
  "title": "Code review",
  "description": "Review a piece of code.",
  "arguments": [
    {"name": "code", "description": "The code to review.", "required": true},
    {"name": "language", "description": "The language the code is written in.", "required": false}
  ]
 }
 ```
 !!! info
    If you have read **[Tools](tools.md)**, you already know everything on this page. Same decorator, same
    docstring-as-description, same `Annotated`/`Field`. The only things that change are who
    triggers it (the user) and where the result goes (into the conversation).
 ## Recap
 * `@mcp.prompt()` on a function makes it a prompt. Name from the function, description from the docstring.
 * Prompts are **user-controlled**: the client lists them, the user picks one and fills in the arguments.
 * Arguments are a flat list of named strings (no schema). A parameter with a default is optional.
 * Return a `str` and it becomes one user message. Return a list of `UserMessage` / `AssistantMessage` to seed a multi-turn conversation.
 * `title=` and `Field(description=...)` are what a client puts in its UI.
 * A missing required argument fails the whole request. There is no per-prompt error result.
 Server-side autocomplete for a prompt's (or a resource template's) arguments is **[Completions](completions.md)**.
@@ -0,0 +1,141 @@
 # Resources
 A **resource** is data you expose for the application to read.
 That's the split. A tool is something the **model** decides to call. A resource is something the **application** decides to load (a config file, a record, a document) and put in front of the model as context.
 You declare one by putting `@mcp.resource(uri)` on a plain Python function.
 ## Your first resource
 ```python title="server.py" hl_lines="6-8"
 --8<-- "docs_src/resources/tutorial001.py"
 ```
 It's the same shape as a tool, plus one thing: the **URI**. Resources are addressed, not named. A client asks for `config://app`, never for `get_config`.
 The SDK still reads the rest from the function:
 * The **name** is the function name: `get_config`.
 * The **description** the client sees is the docstring.
 * The **content** is whatever you return.
 During `resources/list` the client gets this:
 ```json
 {
  "name": "get_config",
  "uri": "config://app",
  "description": "The active shop configuration.",
  "mimeType": "text/plain"
 }
 ```
 And when it reads `config://app`, your function runs and the return value comes back as text:
 ```python
 result.contents  # [TextResourceContents(uri="config://app", mime_type="text/plain", text="theme=dark\nlanguage=en")]
 ```
 !!! tip
    Listing is cheap. Your function is **not** called during `resources/list`, only during
    `resources/read`, and only for the URI that was asked for. Expose a thousand resources
    and you pay for the ones somebody opens.
 ### Try it
 Run the server with the MCP Inspector:
 ```console
 uv run mcp dev server.py
 ```
 Open the URL it prints and go to the **Resources** tab. `config://app` is in the list with its description. Click it and the Inspector reads it: there are your two lines of config.
 ## Resource templates
 One URI per record doesn't scale. Put a **placeholder** in the URI and a matching parameter on the function:
 ```python title="server.py" hl_lines="12-13"
 --8<-- "docs_src/resources/tutorial002.py"
 ```
 `{user_id}` in the URI, `user_id: str` on the function. That is the entire contract.
 This is now a **resource template**, and it moves house: it leaves `resources/list` and shows up in `resources/templates/list` instead, as a pattern rather than an address:
 ```json
 {
  "name": "get_user_profile",
  "uriTemplate": "users://{user_id}/profile",
  "description": "A customer's profile.",
  "mimeType": "text/plain"
 }
 ```
 The client fills in the placeholder and reads a concrete URI: `users://42/profile`, `users://ada/profile`. One function answers all of them, with the matched value passed in as `user_id`:
 ```python
 result.contents  # [TextResourceContents(uri="users://42/profile", text="User 42: 12 orders since 2021.")]
 ```
 Notice the `uri` in the result. It is the **concrete** URI the client asked for, not the template.
 !!! check
    The placeholders and the parameters have to agree. Rename the function parameter to
    `user` while the URI still says `{user_id}` and the decorator refuses **at import time**,
    before any client gets near it:
    ```text
    ValueError: Mismatch between URI parameters {'user_id'} and function parameters {'user'}
    ```
    A mismatch can only ever be a bug, so the SDK makes it impossible to start the server with one.
 The placeholder syntax is [RFC 6570](https://datatracker.ietf.org/doc/html/rfc6570): `{+path}` for multi-segment values, `{?q,lang}` for optional query parameters, and more. The SDK also applies path-safety checks to extracted values by default. See **[URI templates and path safety](uri-templates.md)** for the full reference.
 `get_user_profile` can also take a parameter annotated `Context`. The SDK injects it without ever treating it as a URI parameter, and **[The Context](../handlers/context.md)** page covers what it gives you.
 ## What you return
 You're not limited to `str`. Give each resource a `mime_type` and return whatever fits:
 ```python title="server.py" hl_lines="8-9 14-15 20-21"
 --8<-- "docs_src/resources/tutorial003.py"
 ```
 * `readme` returns a `str`, so it's sent as-is. This is the common case.
 * `catalog_stats` returns a `dict`, so the SDK serialises it to **JSON text** for you:
    ```json
    {
      "books": 1204,
      "authors": 391
    }
    ```
 * `placeholder_cover` returns `bytes`, so the client gets a `BlobResourceContents` instead of a `TextResourceContents`, with your bytes base64-encoded in its `blob` field.
 The same rule applies to anything else JSON-serialisable: a list, a Pydantic model, a dataclass. If it isn't a `str` and isn't `bytes`, it becomes JSON.
 `mime_type` is yours to declare, and it defaults to `text/plain`. The SDK never inspects what you return to guess it, so a `dict` resource you don't label is still advertised as plain text.
 !!! tip
    `name=`, `title=` and `description=` are also accepted by `@mcp.resource()` when you don't
    want to derive them from the function. And when there's no function to write at all,
    `mcp.server.mcpserver.resources` has ready-made `Resource` classes (`TextResource`,
    `BinaryResource`, `FileResource`, `HttpResource`, `DirectoryResource`) that you register
    with `mcp.add_resource(...)`.
 A client can also **subscribe** to a resource and be notified when it changes; that's the client's half of the story and it lives in **[The Client](../client/index.md)**.
 ## Recap
 * `@mcp.resource(uri)` on a function makes it a resource. The URI is the address, the return value is the content, the docstring is the description.
 * A `{placeholder}` in the URI makes it a **template**: it's listed under `resources/templates/list` and one function serves every URI that matches.
 * Placeholder names must equal the function's parameter names. Get it wrong and you find out at import time, not in production.
 * Your function runs when the resource is **read**, not when it's listed.
 * `str` becomes text, `bytes` becomes a base64 blob, anything else becomes JSON text. `mime_type=` is how you label it.
 * Tools are for the model to act. Resources are for the application to read.
 The third primitive, the one a person picks from a menu, is **[Prompts](prompts.md)**.
@@ -0,0 +1,245 @@
 # Structured Output
 A tool that returns a plain `str` produces the result twice: as text in `content`, and as `{"result": "..."}` in `structured_content`.
 This page is about that second channel: where it comes from, every shape it can take, and how the SDK keeps it honest.
 The short version: **the return type annotation is the output schema**. You already wrote it.
 ## The output schema
 ```python title="server.py" hl_lines="9"
 --8<-- "docs_src/structured_output/tutorial001.py"
 ```
 The line that matters is the signature: `-> int`.
 Because of it, the tool the SDK sends during `tools/list` carries an `output_schema` next to the input schema it builds from your parameters (**[Tools](tools.md)** covers that one):
 ```json
 {
  "properties": {
    "result": {"title": "Result", "type": "integer"}
  },
  "required": ["result"],
  "title": "get_temperatureOutput",
  "type": "object"
 }
 ```
 A bare `int` isn't a JSON object, so the SDK **wraps** it in `{"result": ...}`. Call the tool and both channels are filled:
 ```python
 result.content             # [TextContent(text="17")]
 result.structured_content  # {"result": 17}
 ```
 Every scalar gets the same wrapper: `str`, `int`, `float`, `bool`, `bytes`, `None`.
 ## Two channels
 Why send the same value twice?
 * `content` is for the **model**. A language model reads text; this is the only part of the result it sees.
 * `structured_content` is for the **application** the model runs inside: code that wants `17`, not a sentence containing "17".
 * `output_schema` is the contract between them, published before the tool is ever called.
 You return one Python value. The SDK fills in all three.
 ## Return a model
 Declare the shape as a Pydantic `BaseModel` and return an instance:
 ```python title="server.py" hl_lines="8-11 15"
 --8<-- "docs_src/structured_output/tutorial002.py"
 ```
 `WeatherData` **is** the schema now. No wrapper, no `result` key:
 ```json
 {
  "properties": {
    "temperature": {"description": "Degrees Celsius.", "title": "Temperature", "type": "number"},
    "humidity": {"description": "Relative humidity, 0 to 1.", "title": "Humidity", "type": "number"},
    "conditions": {"title": "Conditions", "type": "string"}
  },
  "required": ["temperature", "humidity", "conditions"],
  "title": "WeatherData",
  "type": "object"
 }
 ```
 `structured_content` is the object, field for field:
 ```python
 result.structured_content  # {"temperature": 16.2, "humidity": 0.83, "conditions": "Overcast"}
 ```
 And the model is not left out. The SDK serializes the same object to JSON text for `content`:
 ```json
 {
  "temperature": 16.2,
  "humidity": 0.83,
  "conditions": "Overcast"
 }
 ```
 Notice the `Field(description=...)` on `temperature` and `humidity` landed in the schema. The same `Field` that described your **inputs** describes your outputs.
 !!! info
    If you've used FastAPI's `response_model`, you already know this: a Pydantic model as the declared
    response, serialized and documented for you. The only difference is that here the return annotation
    is the whole declaration.
 ## A `TypedDict`
 Not every shape deserves a class. A `TypedDict` produces the same schema:
 ```python title="server.py" hl_lines="8"
 --8<-- "docs_src/structured_output/tutorial003.py"
 ```
 A `TypedDict` is a plain `dict` at runtime, so that is what you build and return. The schema, the validation, and `structured_content` are identical to the `BaseModel` version (minus the descriptions, which `TypedDict` has no place for).
 ## A dataclass
 Dataclasses work too, and so does any ordinary class whose attributes have type hints. The SDK builds a Pydantic model out of the annotations behind the scenes.
 ```python title="server.py" hl_lines="8-9"
 --8<-- "docs_src/structured_output/tutorial004.py"
 ```
 Three spellings, one schema. Use whichever your codebase already has.
 ## Lists
 A `list[...]` isn't a JSON object either, so it gets the `{"result": ...}` wrapper, with your item type as a `$defs` reference inside it:
 ```python title="server.py" hl_lines="15"
 --8<-- "docs_src/structured_output/tutorial005.py"
 ```
 ```json
 {
  "$defs": {
    "WeatherData": {
      "properties": {
        "temperature": {"title": "Temperature", "type": "number"},
        "humidity": {"title": "Humidity", "type": "number"},
        "conditions": {"title": "Conditions", "type": "string"}
      },
      "required": ["temperature", "humidity", "conditions"],
      "title": "WeatherData",
      "type": "object"
    }
  },
  "properties": {
    "result": {"items": {"$ref": "#/$defs/WeatherData"}, "title": "Result", "type": "array"}
  },
  "required": ["result"],
  "title": "get_forecastOutput",
  "type": "object"
 }
 ```
 Ask for a two-day forecast and `structured_content` is `{"result": [{...}, {...}]}`. `content` becomes **two** `TextContent` blocks, one per item: a list is flattened for the model rather than dumped as one string.
 `tuple[...]`, unions, and `Optional[...]` are wrapped the same way.
 ## Dictionaries
 `dict[str, ...]` is the one generic that already *is* a JSON object, so it isn't wrapped:
 ```python title="server.py" hl_lines="9"
 --8<-- "docs_src/structured_output/tutorial006.py"
 ```
 ```json
 {
  "additionalProperties": {"type": "number"},
  "title": "get_temperaturesDictOutput",
  "type": "object"
 }
 ```
 ```python
 result.structured_content  # {"London": 16.2, "Reykjavik": 4.4}
 ```
 The keys must be `str`. A `dict[int, float]` can't be a JSON object, so it falls back to the `{"result": ...}` wrapper.
 ## Validation
 `output_schema` is not documentation. Whatever your function returns is **validated against it** before it leaves the server.
 You don't notice while you build the value by hand: Pydantic already made sure your `WeatherData` was a `WeatherData`. You notice the day the data comes from somewhere you don't control:
 ```python title="server.py" hl_lines="9 21"
 --8<-- "docs_src/structured_output/tutorial007.py"
 ```
 The annotation promises `WeatherData`. The upstream response stopped sending `humidity`.
 !!! check
    Call `get_weather` and it does not quietly hand the client a half-empty object. The call fails,
    and the first lines of the error name the field:
    ```text
    Error executing tool get_weather: 1 validation error for WeatherData
    humidity
      Field required [type=missing, input_value={'temperature': 16.2, 'conditions': 'Overcast'}, input_type=dict]
    ```
    That text comes back as the tool result with `is_error=True`, so the model knows the call failed
    instead of confidently reading weather that isn't there.
 Returning a plain `dict` from a `-> WeatherData` tool is fine, by the way. That's exactly what `json.loads` produced. Validation is on the value, not on the Python type.
 ## Opting out
 Sometimes the return annotation is for your type checker, not for the protocol. Pass `structured_output=False` and the tool is text-only:
 ```python title="server.py" hl_lines="6"
 --8<-- "docs_src/structured_output/tutorial008.py"
 ```
 No `output_schema`, no wrapping, no validation. `structured_content` is `None` and `content` is the string you returned.
 The opposite, `structured_output=True`, turns the automatic detection into a requirement: a tool whose return type can't produce a schema raises at import time instead of falling back to text.
 ## A class without type hints
 There is one way to end up unstructured without asking for it: return a class that has **no annotations on its body**.
 ```python title="server.py" hl_lines="6-9"
 --8<-- "docs_src/structured_output/tutorial009.py"
 ```
 `Station` sets `name` and `online` inside `__init__`, but the *class* declares nothing. The SDK reads class annotations, finds none, and gives up.
 !!! warning
    It gives up **silently**. `output_schema` is `None`, `structured_content` is `None`, and the text
    the model reads is the object's `repr`:
    ```text
    "<server.Station object at 0x7f539d75b230>"
    ```
    No error, no warning, a useless tool. Move the annotations onto the class body, or pass
    `structured_output=True`, which turns this into a hard error the moment the module imports:
    `Function get_station: return type <class 'server.Station'> is not serializable for structured output`.
 !!! tip
    Need full control (building the `CallToolResult` yourself, or attaching `_meta` that the
    application can see but the model can't)? That's **[The low-level Server](../advanced/low-level-server.md)**.
 ## Recap
 * The **return type annotation** is the output schema. It's published in `tools/list` as `output_schema`.
 * Scalars, lists, tuples and unions are wrapped in `{"result": ...}`. Models, `TypedDict`s, dataclasses, annotated classes and `dict[str, ...]` are objects already and stay as they are.
 * Every result carries `content` (text, for the model) **and** `structured_content` (data, for the application).
 * What you return is validated against the schema. A mismatch is a tool error, not a corrupt result.
 * `structured_output=False` opts a tool out. A class without type hints opts out silently; watch for it.
 You now own everything a tool can say back. Next, the second primitive: **[Resources](resources.md)**.
@@ -0,0 +1,172 @@
 # Tools
 A **tool** is a function the model can call.
 You declare one by putting `@mcp.tool()` on a plain Python function. That's the whole API.
 ## Your first tool
 ```python title="server.py" hl_lines="6-8"
 --8<-- "docs_src/tools/tutorial001.py"
 ```
 Look at what you wrote. There are no schemas, no JSON, no protocol, just a function. The SDK reads three things from it:
 * The **name** of the tool is the name of the function: `search_books`.
 * The **description** the model sees is the docstring: `Search the catalog by title or author.`
 * The **arguments** the model is allowed to pass come from the type hints: `query: str` and `limit: int`.
 ### The input schema
 From those type hints the SDK generates a JSON Schema and sends it to the client during `tools/list`:
 ```json
 {
  "type": "object",
  "properties": {
    "query": {"title": "Query", "type": "string"},
    "limit": {"title": "Limit", "type": "integer"}
  },
  "required": ["query", "limit"],
  "title": "search_booksArguments"
 }
 ```
 Both arguments are in `required` because neither has a default. You'll fix that in a moment. (The `title` keys are Pydantic artifacts; the properties, their types, and `required` are the contract.)
 !!! tip
    Type hints aren't documentation here. They are **the contract**. If a client sends `"limit": "ten"`,
    the SDK rejects it before your function ever runs.
 ### What the model gets back
 Call the tool with `{"query": "dune", "limit": 5}` and the result has two parts:
 ```python
 result.content             # [TextContent(text="Found 3 books matching 'dune' (showing up to 5).")]
 result.structured_content  # {'result': "Found 3 books matching 'dune' (showing up to 5)."}
 ```
 `content` is the text the **model** reads. `structured_content` is typed data for the **client application**. It's there because you declared the return type as `-> str`.
 Don't worry about `structured_content` yet. Return real Python objects from your tools and the right thing happens; the **[Structured Output](structured-output.md)** page is all about it.
 ### Try it
 Run the server with the MCP Inspector:
 ```console
 uv run mcp dev server.py
 ```
 Open the URL it prints, go to the **Tools** tab, and call `search_books`.
 The Inspector renders a form with a required `query` text field and a required `limit` number field. It built that form from your type hints. So will every other MCP client.
 ## Optional arguments
 Give a parameter a default value and it stops being required. That's it. It's just Python.
 ```python title="server.py" hl_lines="7"
 --8<-- "docs_src/tools/tutorial002.py"
 ```
 The schema follows:
 ```json
 {
  "type": "object",
  "properties": {
    "query": {"title": "Query", "type": "string"},
    "limit": {"default": 10, "title": "Limit", "type": "integer"}
  },
  "required": ["query"],
  "title": "search_booksArguments"
 }
 ```
 `limit` left `required` and gained `"default": 10`. A client that omits it gets `10`, exactly as Python would.
 ## Richer schemas with `Field`
 Type hints get you a long way, but sometimes you want to *describe* an argument, or constrain it.
 Wrap the type in `Annotated` and add a Pydantic `Field`:
 ```python title="server.py" hl_lines="12-14"
 --8<-- "docs_src/tools/tutorial003.py"
 ```
 Three new things, all on the parameters:
 * `Field(description=...)`: a per-argument description the model reads alongside the docstring.
 * `Field(ge=1, le=50)`: numeric bounds. They land in the schema as `"minimum": 1, "maximum": 50`.
 * `Literal["fiction", "non-fiction", "poetry"]`: an enum. The model can only pick one of those.
 !!! check
    Constraints are not decoration. Call the tool with `limit=999` and the SDK answers with a
    tool error **before your function runs**:
    ```text
    Input should be less than or equal to 50
    ```
    That error goes back to the model as the tool result, and the model reads it and retries with
    a valid value. You wrote `le=50` once and got self-correcting agents for free.
 !!! info
    If you've used FastAPI or Pydantic, you already know all of this. It's the same `Field`,
    the same `Annotated`, the same validation. There is nothing MCP-specific to learn here.
 ## A model as a parameter
 When a tool takes more than a couple of arguments, group them into a Pydantic model:
 ```python title="server.py" hl_lines="8-11 15"
 --8<-- "docs_src/tools/tutorial004.py"
 ```
 The `Book` schema is nested inside the tool's input schema (as a `$defs` reference), the model fills it in as a JSON object, and your function receives a **real `Book` instance**, already validated, with `.title`, `.author` and `.year` attributes.
 You can mix and match: plain parameters next to model parameters, nested models, lists of models. It's Pydantic all the way down.
 ## `async def`
 If a tool does I/O (calls an API, reads a file, queries a database), declare it `async def` and `await` inside it. The SDK awaits it.
 A plain `def` tool works too: the SDK runs it in a thread so it never blocks the server.
 There is nothing else to configure.
 ## Names, titles, and annotations
 Everything the SDK infers, you can override in the decorator:
 ```python title="server.py" hl_lines="8-11"
 --8<-- "docs_src/tools/tutorial005.py"
 ```
 * `title` is a human-readable name for UIs. Clients show *"Search the catalog"* instead of `search_books`.
 * `annotations` are behavioural **hints** for the client:
  * `read_only_hint=True`: this tool doesn't change anything.
  * `open_world_hint=False`: it works on a closed set of things (this catalog), not the open web.
  * The other two, `destructive_hint` and `idempotent_hint`, describe a tool that *writes*: may it
    delete something, and is calling it twice the same as calling it once? The spec defines both
    only for non-read-only tools, so they would say nothing on `search_books`.
 A well-behaved client uses them to decide things like *"do I need to ask the user before running this?"*. They are hints, not security. Never rely on a client honouring them.
 !!! tip
    `name=` and `description=` are also accepted by `@mcp.tool()` if you don't want to derive them
    from the function name and docstring. Most of the time you do.
 ## Recap
 * `@mcp.tool()` on a function makes it a tool. Name from the function, description from the docstring.
 * Type hints **are** the input schema. Defaults make arguments optional.
 * `Annotated[..., Field(...)]` adds descriptions and constraints; `Literal` adds enums.
 * A Pydantic model parameter is how you take a structured "body".
 * Bad arguments are rejected for you, with an error the model can read and recover from.
 * `async def` for I/O, plain `def` for everything else.
 **[Structured Output](structured-output.md)** is what happens to the value you `return`.
@@ -0,0 +1,269 @@
 # URI templates and path safety
 This is the reference for the URI-template syntax that
 [`@mcp.resource`](resources.md) accepts, and for the
 path-safety policy the SDK applies to extracted values. For an
 introduction to what resources are and when to use them, start with
 **[Resources](resources.md)**; this page assumes you're already comfortable declaring a
 resource and want the full operator set, the security knobs, or the
 low-level wiring.
 The template syntax is [RFC 6570](https://datatracker.ietf.org/doc/html/rfc6570).
 The SDK supports a subset chosen for matching incoming `resources/read`
 URIs, plus a security layer that rejects values that would resolve
 outside the directory you intend to serve. For the protocol-level
 details (message formats, lifecycle, pagination) see the
 [MCP resources specification](https://modelcontextprotocol.io/specification/latest/server/resources).
 ## The full operator set
 The plain placeholder, `{user_id}`, is the one **[Resources](resources.md)** introduces. There are four more
 operator forms; here they are on one server so you can see them next to
 each other:
 ```python title="server.py" hl_lines="16-17 22-23 28-29 34-35 40-41"
 --8<-- "docs_src/uri_templates/tutorial001.py"
 ```
 Each highlighted decorator is a different way of carving up the URI.
 The sections below walk them top to bottom.
 ### Simple expansion: `{name}`
 `books://{isbn}` is the plain, everyday form. The placeholder maps to
 the `isbn` parameter, so a client reading `books://978-0441172719` calls
 `get_book("978-0441172719")`.
 A plain `{name}` stops at the first `/`. `books://978/extra` does not
 match because the slash after `978` ends the capture and `/extra` is
 left over.
 ### Type conversion
 Extracted values arrive as strings, but you can declare a more specific
 type and the SDK will convert. `orders://{order_id}` lands in a function
 whose parameter is `order_id: int`, so reading `orders://12345` calls
 `get_order(12345)`, not `get_order("12345")`. The handler does
 arithmetic on it (`order_id + 1`) without a cast.
 ### Multi-segment paths: `{+name}`
 To capture a value that contains slashes, use `{+name}`. With
 `manuals://{+path}`:
 * `manuals://returns.md` gives `path = "returns.md"`
 * `manuals://printing/setup.md` gives `path = "printing/setup.md"`
 Reach for `{+name}` whenever the value is hierarchical: filesystem
 paths, nested object keys, URL paths you're proxying.
 ### Query parameters: `{?a,b,c}`
 `reviews://{isbn}{?limit,sort}` puts `limit` and `sort` after the `?`.
 The path identifies *which* book; the query tunes *how* you read it.
 Query params are matched leniently: order doesn't matter, extras are
 ignored, and omitted params fall through to your function defaults. So
 `reviews://978-0441172719` uses `limit=10, sort="newest"`, and
 `reviews://978-0441172719?sort=top` overrides only `sort`.
 ### Path segments as a list: `{/name*}`
 If you want each path segment as a separate list item rather than one
 string with slashes, use `{/name*}`. With `shelves://browse{/path*}`, a
 client reading `shelves://browse/fiction/sci-fi` calls
 `browse_shelf(["fiction", "sci-fi"])`.
 ### Template reference
 The most common patterns:
 | Pattern      | Example input         | You get                 |
 |--------------|-----------------------|-------------------------|
 | `{name}`     | `alice`               | `"alice"`               |
 | `{name}`     | `docs/intro.md`       | *no match* (stops at `/`) |
 | `{+path}`    | `docs/intro.md`       | `"docs/intro.md"`       |
 | `{.ext}`     | `.json`               | `"json"`                |
 | `{/segment}` | `/v2`                 | `"v2"`                  |
 | `{?key}`     | `?key=value`          | `"value"`               |
 | `{?a,b}`     | `?a=1&b=2`            | `"1"`, `"2"`            |
 | `{/path*}`   | `/a/b/c`              | `["a", "b", "c"]`       |
 ### What the parser rejects
 A few template shapes are caught up front rather than failing on the
 first request. `@mcp.resource` parses the template when the decorator
 runs, so none of these ever reach a running server.
 `UriTemplate.parse()` raises `InvalidUriTemplate` for:
 * **Two variables with nothing between them.** `manuals://{+path}{ext}`
  is rejected: matching can't tell where `path` ends and `ext` begins.
  Put a literal between them (`manuals://{+path}/{ext}`), or use an
  operator that supplies its own delimiter. `manuals://{+path}{.ext}`
  is accepted because `{.ext}` contributes the `.` itself.
 * **More than one multi-segment variable.** At most one of `{+var}`,
  `{#var}`, or an exploded variable (`{/var*}`, `{.var*}`, `{;var*}`)
  per template. Two are inherently ambiguous: there is no principled
  way to decide which one absorbs an extra segment.
 * **The usual syntax errors**: an unclosed brace, a variable name used
  twice, or an RFC 6570 feature the SDK doesn't support, such as the
  `{var:3}` prefix modifier or the `{?vars*}` query explode.
 On top of that, `@mcp.resource` raises `ValueError` when a handler
 parameter is bound to a query variable in the template's trailing
 `{?...}`/`{&...}` run but has no Python default. Those variables are
 matched leniently (a client may leave any of them out), so a parameter
 without a default would only surface as an opaque internal error on the
 first request that omits it. `reviews://{isbn}{?limit,sort}` in the
 server above is the well-formed version: `limit` and `sort` both carry
 defaults.
 ## Security
 Template parameters come from the client. If they flow into filesystem
 or database operations unchecked, values like `../../etc/passwd` can
 resolve outside the directory you intended to serve.
 ### What the SDK checks by default
 Before your handler runs, the SDK rejects any parameter that:
 * would escape its starting directory via `..` components
 * looks like an absolute path (`/etc/passwd`, `C:\Windows`) or a
  Windows drive-relative one (`C:foo`). A drive-relative value and a
  namespaced identifier like `x:y` are indistinguishable as strings,
  so any single-letter-plus-colon value is rejected by default;
  exempt the parameter if it legitimately receives such values
 * contains a null byte (`\x00`)
 The `..` check is component-based, not a substring scan. Values like
 `v1.0..v2.0` or `HEAD~3..HEAD` pass because `..` is not a standalone
 path segment there.
 These checks apply to the decoded value, so they catch traversal
 regardless of how it was encoded in the URI (`../etc`, `..%2Fetc`,
 `%2E%2E/etc`, `..%5Cetc`, `%00` all get caught).
 !!! check
    Read `manuals://../etc/passwd` from the server above and the request
    is rejected outright: template matching stops at the first failure,
    so no later (potentially more permissive) template is tried as a
    fallback. The client sees the same `-32602` "Unknown resource" error
    it would for a URI that matches no template at all, and
    `read_manual` never runs.
 ### Filesystem handlers: use safe_join
 The built-in checks stop the common cases but can't know your sandbox
 boundary. For filesystem access, use `safe_join` to resolve the path
 and verify it stays inside your base directory:
 ```python title="server.py" hl_lines="4 14"
 --8<-- "docs_src/uri_templates/tutorial002.py"
 ```
 `safe_join` catches symlink escapes, `..` sequences, and absolute-path
 tricks that a simple string check would miss. If the resolved path
 escapes `DOCS_ROOT`, it raises `PathEscapeError`, which surfaces to the
 client as a `ResourceError`.
 ### When the defaults get in the way
 Sometimes the checks block legitimate values. A catalog-import tool
 might intentionally receive an absolute path, or a parameter might be a
 relative reference like `../sibling` that your handler interprets
 safely without touching the filesystem. Exempt that parameter, or relax
 the policy for the whole server:
 ```python title="server.py" hl_lines="9 16-19"
 --8<-- "docs_src/uri_templates/tutorial003.py"
 ```
 * `security=ResourceSecurity(exempt_params={"source"})` on the decorator
  skips the checks for that one parameter on that one resource. The
  rest of the server keeps the default policy.
 * `resource_security=` on the `MCPServer` constructor sets the default
  for every resource. Here `relaxed` turns off the `..` check entirely.
 The configurable checks:
 | Setting                 | Default | What it does                        |
 |-------------------------|---------|-------------------------------------|
 | `reject_path_traversal` | `True`  | Rejects `..` sequences that escape the starting directory |
 | `reject_absolute_paths` | `True`  | Rejects `/foo`, `C:\foo`, UNC paths, and drive-relative `C:foo` (also catches `x:y`) |
 | `reject_null_bytes`     | `True`  | Rejects values containing `\x00`    |
 | `exempt_params`         | empty   | Parameter names to skip checks for  |
 These checks are a heuristic pre-filter; for filesystem access,
 `safe_join` remains the containment boundary.
 !!! tip
    If your handler can't fulfil the request (the file doesn't exist,
    the id is unknown), raise an exception. The SDK turns it into an
    error response. See **[Handling errors](handling-errors.md)** for the difference between a
    protocol error and a tool error.
 ## Resources on the low-level Server
 If you're building on the low-level `Server` (see **[The low-level
 Server](../advanced/low-level-server.md)**), you register handlers for the `resources/list` and
 `resources/read` protocol methods directly. There's no decorator; you
 return the protocol types yourself.
 ### Static resources
 For fixed URIs, keep a registry and dispatch on exact match:
 ```python title="server.py" hl_lines="18 22 28"
 --8<-- "docs_src/uri_templates/tutorial004.py"
 ```
 The list handler tells clients what's available; the read handler
 serves the content. Check your registry first, fall through to
 templates (below) if you have any, then raise for anything else.
 ### Templates
 The template engine `MCPServer` uses lives in `mcp.shared.uri_template`
 and works on its own. You get the same parsing and matching; you wire
 up the routing and security policy yourself.
 ```python title="server.py" hl_lines="14-17 23-26 30 34 46"
 --8<-- "docs_src/uri_templates/tutorial005.py"
 ```
 Three things are happening in the highlighted lines:
 * **Parse once, match per request.** `UriTemplate.parse()` builds the
  template; `template.match(uri)` returns the extracted variables as a
  `dict`, or `None` if the URI doesn't fit. URL decoding happens inside
  `match()`; the decoded values are returned as-is without path-safety
  validation. Values come out as strings: convert them yourself
  (`int(matched["id"])`, `Path(matched["path"])`).
 * **Apply the safety checks yourself.** The `..` and absolute-path
  checks `MCPServer` runs by default live in `mcp.shared.path_security`.
  `read_manual_safely` calls them before touching `MANUALS`. If a
  parameter isn't a filesystem path (an ISBN, a search query), skip the
  checks for that value: you control the policy per handler rather than
  through a config object.
 * **List the templates from the same source.** Clients discover
  templates through `resources/templates/list`. `str(template)` gives
  back the original template string, so the listing and the matcher
  share one source of truth.
 ## Recap
 * `{name}` matches one segment; `{+name}` keeps the slashes; `{?a,b}`
  pulls from the query string; `{/name*}` splits segments into a list.
 * Two variables with nothing between them, or a second multi-segment
  variable, are rejected at parse time. A parameter bound to a trailing
  `{?...}`/`{&...}` query variable must declare a Python default.
 * Annotate the parameter (`order_id: int`) and the SDK converts.
 * The default security policy rejects `..`, absolute paths, and null
  bytes before your handler runs; override per resource with
  `security=ResourceSecurity(...)` or server-wide with
  `resource_security=`.
 * For filesystem access, `safe_join` is the containment boundary.
 * On the low-level `Server`, parse with `UriTemplate.parse()`, match
  with `.match()`, and apply `mcp.shared.path_security` yourself.
@@ -0,0 +1,412 @@
 # Troubleshooting
 Every heading on this page is the exact text of an error the SDK produces, followed by what it means and the one-move fix. Find the last line of your traceback (or your server log) here with your browser's find-in-page, and read only that entry.
 Several entries run against this one server. One tool and one templated resource, each raising for a city it doesn't know:
 ```python title="server.py"
 --8<-- "docs_src/troubleshooting/tutorial001.py"
 ```
 The errors this page quotes are real: the SDK's own test suite reproduces every one of them.
 ## `ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception)`
 This is not an MCP error. It is anyio noise, and your real error is the **last line** of the paste.
 `Client.__aenter__` starts a task group. anyio wraps anything that leaves a task group in an `ExceptionGroup`, so *every* exception that escapes an `async with Client(...)` block, whatever it is, arrives inside one:
 ```python
 async def main() -> None:
    async with Client(mcp) as client:
        await client.read_resource("weather://Atlantis")
 ```
 ```text
  + Exception Group Traceback (most recent call last):
  |   ...
  | ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception)
  +-+---------------- 1 ----------------
    | Exception Group Traceback (most recent call last):
    |   ...
    | ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception)
    +-+---------------- 1 ----------------
      | Traceback (most recent call last):
      |   ...
      | mcp.shared.exceptions.MCPError: No forecast for 'Atlantis'.
      +------------------------------------
 ```
 Two things to do with that:
 1. **Read the bottom.** `MCPError: No forecast for 'Atlantis'.` is the failure; find *its* text on this page.
 2. **Catch inside the block.** The `ExceptionGroup` only appears when the exception *leaves* the `async with`. Caught inside it, the same failure is the plain `MCPError`, no group anywhere:
 ```python
 async def main() -> None:
    async with Client(mcp) as client:
        try:
            await client.read_resource("weather://Atlantis")
        except MCPError as e:
            print(e)  # No forecast for 'Atlantis'.
 ```
 !!! tip
    A failure during *connection* (a wrong URL, a server that isn't running, the `421` further
    down this page) escapes from `async with` itself, so there is no "inside" to catch it in.
    For those, read the bottom of the group.
 ## `RuntimeError: Client must be used within an async context manager`
 `Client(...)` only builds the object. Nothing connects until `async with`, so every method refuses:
 ```python
 async def main() -> None:
    client = Client(mcp)
    tools = await client.list_tools()  # RuntimeError
 ```
 Enter it. `__aenter__` is the connection:
 ```python
 async def main() -> None:
    async with Client(mcp) as client:
        tools = await client.list_tools()
 ```
 `__aexit__` is the disconnection, which is why there is no `client.close()` to forget. **[Testing](get-started/testing.md)** is built on exactly this pattern.
 ## `Error executing tool <name>: <message>` and `Unknown tool: <name>`
 You are reading a **result**, not an exception. `call_tool` did not raise, and it never will for a failing tool.
 Call `forecast` for a city the server doesn't know, and the exception it raises comes back with the request marked as *succeeded*:
 ```python
 result.is_error  # True
 result.content   # [TextContent(text="Error executing tool forecast: No forecast for 'Atlantis'.")]
 result.structured_content  # None
 ```
 `Unknown tool: get_forecast` is the same shape for a name the server never registered, and a bad argument is rejected the same way, against the tool's input schema, before your function ever runs.
 The fix is in your client: **check `result.is_error`**. A `try/except` around `call_tool` catches none of these, because there is nothing to catch. This is deliberate, and it is the single most useful thing on this page to internalise: the *model* chose the call, so the model gets the message and a chance to try again. **[Handling errors](servers/handling-errors.md)** is the whole story, including the `MCPError` path that *does* raise.
 ## `TypeError: The @tool decorator was used incorrectly. Did you forget to call it? Use @tool() instead of @tool`
 You wrote `@mcp.tool` instead of `@mcp.tool()`. `tool()` is a decorator *factory*: without the parentheses, Python hands your function to its `name=` parameter.
 ```python
@mcp.tool  # <- missing ()
 def forecast(city: str) -> str:
    """Today's forecast for one city."""
    return f"{city}: Rain."
 ```
 ```text
 TypeError: The @tool decorator was used incorrectly. Did you forget to call it? Use @tool() instead of @tool
 ```
 Add the parentheses. `@mcp.resource(...)` and `@mcp.prompt()` say the same thing for the same slip.
 !!! note
    This raises when the module is **imported**, before any client connects. So a host that shows
    your server as *failed to start* (or *disconnected*), rather than as connected with zero
    tools, has this shape: run `python server.py` yourself and read the traceback. A type checker
    also catches it: a function is not a valid `name=`.
 ## `Tool already exists: <name>`
 Two registrations used the same tool name. The **first** one wins, the second is silently dropped, and this warning in the *server log* is the only signal:
 ```python title="server.py" hl_lines="6 12"
 --8<-- "docs_src/troubleshooting/tutorial002.py"
 ```
 ```text
 WARNING mcp.server.mcpserver.tools.tool_manager: Tool already exists: forecast
 ```
 `tools/list` reports one `forecast`, and it is `forecast_today`. Rename one of them. `MCPServer(..., warn_on_duplicate_tools=False)` silences the warning without changing the outcome, so leave it on. Resources and prompts have the same rule and the same log line (`Resource already exists:`, `Prompt already exists:`).
 ## My host lists zero tools
 There is no error string for this, which is exactly why it is hard to search. The SDK never drops a registered tool from `tools/list`, so work outward:
 * **Did the server start at all?** `@mcp.tool` without parentheses raises at import time, and a crashed server looks a lot like an empty one in some hosts. Run `python server.py` yourself.
 * **Is the tool on the `mcp` the host is running?** A second `MCPServer(...)` in another module is a different, empty server. Check which object the host's command actually imports.
 * **Did two tools share a name?** Then one of them is gone. Look for `Tool already exists:` in the server log.
 * **Is the host's list stale?** Adding a tool after startup only reaches clients that handle `notifications/tools/list_changed`. Restarting the host is the blunt fix.
 * **Did something write to `stdout`?** On a stdio transport, stdout *is* the protocol: one stray `print()` and the host drops the connection, which some hosts render as a server with nothing in it. Log with the `logging` module instead. The rest of the host-side checklist is on **[Connect to a real host](get-started/real-host.md)**.
 An "invalid" tool name is *not* on that list: a non-conforming name logs a warning but the tool is registered and listed anyway.
 ## `MCPError: Server returned an error response`
 The server refused the HTTP request outright, with a body that is not JSON-RPC, so the python `Client` has nothing better to show you than this stand-in.
 By far the most common cause is a freshly deployed Streamable HTTP server. `streamable_http_app()` (and `mcp.run("streamable-http")`) with no `transport_security=` defaults to **DNS-rebinding protection**: it accepts only requests whose `Host` header is localhost. That is the right default on your laptop and the wrong one behind a real hostname:
 ```python title="server.py" hl_lines="12"
 --8<-- "docs_src/troubleshooting/tutorial003.py"
 ```
 Deploy that, point a client at it, and the connection fails on the handshake:
 ```python
 async with Client("https://mcp.example.com/mcp") as client:
    ...
 ```
 ```text
 mcp.shared.exceptions.MCPError: Server returned an error response
 ```
 The words the server actually sent, `421` and `Invalid Host header`, never reach you: the 421 body has no `Content-Type: application/json`, so the client cannot parse it. They are in the **server's log**, which is where to look next:
 ```text
 WARNING mcp.server.transport_security: Invalid Host header: mcp.example.com
 ```
 The fix is `transport_security=`. Allowlist the hostname you actually serve:
 ```python title="server.py" hl_lines="14-17"
 --8<-- "docs_src/troubleshooting/tutorial004.py"
 ```
 !!! check
    That is the whole change. The identical client now connects, negotiates `2026-07-28`, and
    calls `forecast`.
 **[Deploy & scale](run/deploy.md)** covers what each field means, the reverse-proxy case, and everything else that changes at deploy time. And `421 Misdirected Request` / `Invalid Host header`, right below, is the same failure seen from the other side.
 ## `421 Misdirected Request` / `Invalid Host header`
 This is `Server returned an error response`, seen from anything that is *not* the python `Client`: curl, a browser's network tab, a reverse proxy's access log, or another SDK.
 ```bash
 curl -i https://mcp.example.com/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"curl","version":"1"}}}'
 ```
 ```text
 HTTP/1.1 421 Misdirected Request
 Invalid Host header
 ```
 `421 Misdirected Request` is HTTP's own reason phrase for the status; `Invalid Host header` is the SDK's response body; and the python `Client` renders the same event as `Server returned an error response`. All three are one refusal. The check runs against the **`Host` header the request carries**, not the address the server bound, so a reverse proxy that forwards the public hostname trips it exactly as a direct client does.
 The fix is the same `transport_security=TransportSecuritySettings(allowed_hosts=[...], allowed_origins=[...])` shown under `Server returned an error response`. Two of its edges are worth naming:
 * An `allowed_hosts` entry is an exact string. `"mcp.example.com"` matches a bare `Host` header and `"mcp.example.com:*"` matches any explicit port. List both.
 * A `403` with the body `Invalid Origin header` is the sibling check on the `Origin` header. It only fires for browsers (nothing else sends `Origin`), and `allowed_origins=` is its allowlist.
 **[Deploy & scale](run/deploy.md)** has the full treatment, including when switching the check off is the honest configuration.
 ## `RuntimeError: Task group is not initialized. Make sure to use run().`
 Your MCP app is mounted inside another ASGI app, and nothing started its **session manager**.
 `mcp.streamable_http_app()` returns a Starlette app whose own lifespan starts the manager, and `uvicorn server:app` runs that lifespan for you. But Starlette **never runs a mounted sub-application's lifespan**, so the moment the app goes inside a `Mount`, the manager never starts and the first request explodes:
 ```python title="server.py" hl_lines="16"
 --8<-- "docs_src/troubleshooting/tutorial005.py"
 ```
 The server starts. The route resolves. Then `uvicorn` prints this for every request:
 ```text
 ERROR:    Exception in ASGI application
 Traceback (most recent call last):
  ...
 RuntimeError: Task group is not initialized. Make sure to use run().
 ```
 The client sees a 500. The fix is a lifespan on the **host** app that enters `mcp.session_manager.run()`:
 ```python
@asynccontextmanager
 async def lifespan(app: Starlette) -> AsyncIterator[None]:
    async with mcp.session_manager.run():
        yield
 app = Starlette(routes=[Mount("/", app=mcp.streamable_http_app())], lifespan=lifespan)
 ```
 **[Add to an existing app](run/asgi.md)** is the page for this, including several servers in one app and FastAPI. Two neighbouring strings from the same class:
 * `StreamableHTTPSessionManager .run() can only be called once per instance. Create a new instance if you need to run again.` The manager is single-use; entering the same app's lifespan twice hits it.
 * `mcp.session_manager` only exists **after** `streamable_http_app()` has been called, so build the routes first and touch the manager only inside the lifespan.
 ## `MCPError: Session not found`
 The server does not recognise the `Mcp-Session-Id` your client sent, almost always because the server **restarted** (or you were routed to a different instance). Sessions live in that one process's memory.
 There is no server bug to find. The HTTP response is a `404` whose body *is* JSON-RPC, so, unlike the `421` above, the python `Client` shows you this one verbatim:
 ```json
 {"jsonrpc": "2.0", "id": null, "error": {"code": -32600, "message": "Session not found"}}
 ```
 The fix is to reconnect: leave the `async with Client(...)` block and enter a new one, which negotiates a fresh session. For a long-lived client, that means catching `MCPError` around your calls and reconnecting on this message rather than retrying inside a dead session.
 If it happens *without* a restart, you are running more than one worker without sticky sessions: each worker holds its own session table, so a request routed to the wrong one lands here. **[Deploy & scale](run/deploy.md)** and **[Serving legacy clients](run/legacy-clients.md)** own that story and its two fixes (sticky routing, or `stateless_http=True`).
 For the server operator, the matching log line is `Rejected request with unknown or expired session ID: <id>`. It is logged at `INFO`, so it is invisible at the usual `WARNING` threshold. Seeing it in bursts right after a deploy is normal; every connected client is reconnecting.
 ## `MCPError: Method not found`
 One side sent a JSON-RPC request the other has no handler for, and `e.error.data` names the method. The usual cause is an **era mismatch**: a method that exists in one protocol revision and not in the other, sent to a peer on the wrong one, such as a `2025`-era `resources/subscribe` arriving at a `2026-07-28` connection, or a `2026`-only `subscriptions/listen` sent by a client pinned to `mode="legacy"`. **[Protocol versions](protocol-versions.md)** is the map of which side speaks what, and the other honest cause (an optional capability you never registered a handler for) is on **[Completions](servers/completions.md)**.
 One thing does **not** produce this error, despite being a request the modern protocol removed: a tool calling `ctx.elicit()` on a `2026-07-28` connection. The server refuses to *send* that request at all, so what you get instead is `Cannot send 'elicitation/create': ...`, further down this page.
 ## `MCPError: Client did not declare the form elicitation capability required by resolver '<name>'`
 Your server wants to ask the user something, and this client never said it can be asked.
 An elicitation resolver refuses up front when the connected client did not declare form elicitation, and `e.error.data` names exactly what is missing:
 ```json
 {
  "code": -32021,
  "message": "Client did not declare the form elicitation capability required by resolver 'server:ask_to_confirm'",
  "data": {"requiredCapabilities": {"elicitation": {"form": {}}}}
 }
 ```
 Pass `elicitation_callback=` to `Client(...)`. Registering the callback *is* the capability declaration; there is no second switch:
 ```python
 async def main() -> None:
    async with Client(mcp, elicitation_callback=handle_elicitation) as client:
        result = await client.call_tool("book_table", {"date": "Friday"})
 ```
 **[Client callbacks](client/callbacks.md)** lists the others (`sampling_callback`, `list_roots_callback`), each of which is a declaration in the same way.
 !!! info
    `-32021` is `MISSING_REQUIRED_CLIENT_CAPABILITY`, one of three error codes the 2026-07-28
    spec adds. None of them is an exception class: they all arrive as `MCPError`, and
    `e.error.code` is where to look. `mcp_types` exports the constants. The other two are
    `-32020` `HEADER_MISMATCH` (an HTTP header disagrees with the request body it accompanies)
    and `-32022` `UNSUPPORTED_PROTOCOL_VERSION` (the request named a version this server does not
    speak). A conforming SDK client cannot produce either, so if you see one, look at whatever is
    rewriting requests between your client and your server.
 ## `MCPError: Elicitation not supported`
 The same gap as `Client did not declare the form elicitation capability ...`, spelled by the paths that don't check up front: the server needed an elicitation answered, and the connected client registered no `elicitation_callback`.
 You see this one from `ctx.elicit()` on a legacy connection, and on any connection at all from a returned multi-round-trip question (**[Multi-round-trip requests](handlers/multi-round-trip.md)**) that reaches a client with no callback to answer it. The fix is identical: pass `elicitation_callback=` to `Client(...)`. There is no version of "the user wasn't asked" that your tool receives as a `decline`; a client that cannot be asked is a failed call, so design your tools for it.
 ## `MCPError: Cannot send 'elicitation/create': this transport context has no back-channel for server-initiated requests.`
 Your handler tried to reach the client mid-request, on a connection where nothing can carry a request from the server. There are exactly two ways to be on one.
 **A `2026-07-28` connection: any transport, always.** The modern protocol has no server-initiated requests at all, so the server refuses before anything is sent. `ctx.elicit()` inside a tool is the classic way to meet this (on the very first in-memory test, since `Client(server)` negotiates `2026-07-28` without being asked), and passing `elicitation_callback=` changes nothing, because no request ever reaches the client for it to answer:
 ```python title="server.py" hl_lines="16"
 --8<-- "docs_src/troubleshooting/tutorial006.py"
 ```
 ```python
 async def main() -> None:
    async with Client(mcp) as client:
        await client.call_tool("book_table", {"date": "Friday"})
 ```
 ```text
 mcp.shared.exceptions.MCPError: Cannot send 'elicitation/create': this transport context has no back-channel for server-initiated requests.
 ```
 **A legacy connection on a `stateless_http=True` server.** Statelessness means every request is its own world: no session, no server-to-client stream, and so nowhere to send an `elicitation/create` (or `sampling/createMessage`, or `roots/list`) even for the era that has them:
 ```python title="server.py" hl_lines="16 23"
 --8<-- "docs_src/troubleshooting/tutorial008.py"
 ```
 The message names the method it could not send. `NoBackChannelError` is the class the server raises, but the wire carries only the base `MCPError`, so the sentence above is your traceback's last line, not the class name.
 The fix is the same for both: don't reach back mid-call. Move the question into a **resolver** (or return an `InputRequiredResult` yourself) and it becomes part of the *response*, which every connection can carry:
 ```python title="server.py" hl_lines="15-17 21"
 --8<-- "docs_src/troubleshooting/tutorial007.py"
 ```
 Same question, same `elicitation_callback` on the client. The difference is under the hood: a resolver lets the server *return* the question from the call instead of pushing it, so nothing ever flows server-to-client. **[Elicitation](handlers/elicitation.md)** covers resolvers; **[Multi-round-trip requests](handlers/multi-round-trip.md)** covers what happens on the wire.
 !!! check
    The tool with `ctx.elicit()` is not wrong, it is *pre-2026*. Connect with `mode="legacy"`
    (the classic `initialize` handshake, spec `2025-11-25` and earlier) to a server that is not
    `stateless_http=True`, and it works, because the server-to-client channel exists there.
    **[Protocol versions](protocol-versions.md)** is the page on what each version has.
 ## `MCPError: Invalid or expired requestState`
 The server could not verify the `requestState` token your client echoed back, so it refused the round.
 `requestState` is the opaque resume token a **[multi-round-trip](handlers/multi-round-trip.md)** call carries between legs. `MCPServer` seals it on the way out and verifies every echo, and it verifies *every* inbound `request_state` on `tools/call`, `prompts/get`, and `resources/read`, even for a handler that never mints one. So a token this process didn't seal is refused wherever it lands:
 ```python
 async def main() -> None:
    async with Client(mcp) as client:
        await client.call_tool("forecast", {"city": "London"}, request_state="round-1-from-worker-a")
 ```
 ```text
 mcp.shared.exceptions.MCPError: Invalid or expired requestState
 ```
 The message is deliberately frozen: the wire never reveals which check failed. The reason goes to the **server log**, and reading it is the whole diagnosis:
 ```text
 WARNING mcp.server.request_state: requestState rejected on tools/call: malformed
 ```
 The reasons you will actually see:
 * **`unknown key`** is the one that matters. The default sealing key is generated at process start, so a retry that lands on a **different worker**, a different instance behind a load balancer, or the same server **after a restart** was sealed under a key this process never had. That is not an attacker; it is the default meeting more than one process.
 * **`audience`**: the token was sealed by an instance with a *different server name*. The name is the seal's default audience claim, so a fleet must share the name (or set an explicit `RequestStateSecurity(audience=...)`) as well as the keys.
 * **`expired`**: the round took longer than the seal's `ttl`, which is 600 seconds and per round, not per call.
 * **`malformed`** / **`codec error`**: the token was altered in transit, or was never a sealed token at all.
 * **`request binding`**: the token came back with a different tool, different arguments, or a different method.
 The multi-process fix is one argument (the *same* `keys` on every instance) plus one thing that is not an argument at all: the same server *name* (or an explicit shared `audience=`).
 ```python
 mcp = MCPServer("Weather", request_state_security=RequestStateSecurity(keys=[key]))
 ```
 `keys[0]` seals; every key in the list verifies, which is what makes zero-downtime rotation possible. **[Multi-round-trip requests](handlers/multi-round-trip.md#protecting-requeststate)** explains what the seal protects and the rotation sequence, and **[Deploy & scale](run/deploy.md)** walks the whole two-worker failure and its two-part fix.
 !!! tip
    `keys=[...]` refuses a weak key immediately, with an unusually helpful message:
    ```text
    ValueError: request-state keys must be at least 32 bytes of secret randomness; keys[0] is 7 bytes. Generate one with: python -c "import secrets; print(secrets.token_hex(32))"
    ```
    Do what it says.
 ## Still stuck?
 * If a message the SDK produced is not on this page, that is a documentation bug worth reporting on its own.
 * Search the [issue tracker](https://github.com/modelcontextprotocol/python-sdk/issues); most error strings appearing there are already someone's write-up.
 * Found nothing? [Open an issue](https://github.com/modelcontextprotocol/python-sdk/issues/new?template=v2-feedback.yaml) with the full traceback, or ask in [#python-sdk-dev on the MCP Contributors Discord](https://discord.gg/6CSzBmMkjX).
 ## Recap
 * `ExceptionGroup: unhandled errors in a TaskGroup` is never the error. Read the **last line**; catching `MCPError` *inside* the `async with Client(...)` block skips the wrapping entirely.
 * `call_tool` does not raise for a failing tool. `Error executing tool ...` and `Unknown tool: ...` are results: check `result.is_error`.
 * `Client must be used within an async context manager` -> use `async with`. `Use @tool() instead of @tool` -> add the parentheses.
 * `Tool already exists:` in the server log is the only sign that two same-named tools collapsed into one.
 * One 421, three spellings: `Server returned an error response` (the python `Client`), `421 Misdirected Request` / `Invalid Host header` (everything else), `Invalid Host header: <host>` (the server log). Fix: `transport_security=TransportSecuritySettings(allowed_hosts=[...])`.
 * `Task group is not initialized` -> a mounted app whose host lifespan never entered `mcp.session_manager.run()`.
 * `Session not found` -> the server restarted; reconnect.
 * `Cannot send 'elicitation/create': ... no back-channel ...` -> `ctx.elicit()` needs a server-to-client channel: a `2026-07-28` connection never has one, and `stateless_http=True` takes away the legacy one. Use a resolver. Its neighbour `Method not found` is a request for a method the other side's protocol revision doesn't have.
 * `Client did not declare the form elicitation capability ...` and `Elicitation not supported` -> the client is missing `elicitation_callback=`.
 * `Invalid or expired requestState` never says why on the wire. The server log does; `unknown key` means share `RequestStateSecurity(keys=[...])` across workers.
@@ -0,0 +1,210 @@
 # What's new in v2
 Two things happened at once in v2. The **SDK was rebuilt**: a new engine under both the client and the server, a first-class `Client`, and a set of renames that a v1 codebase meets on its first import. And the **protocol moved**: v2 speaks the 2026-07-28 revision of MCP, which removes the connection handshake, the session, and every server-initiated request, without stranding the clients you already have.
 This page is the tour of both halves, one section per headline, each ending in the page that owns the topic. It is not the porting manual. That is the **[Migration Guide](migration.md)**: every breaking change, with before and after code.
 !!! note "v2 is a beta"
    `pip install mcp` still installs v1.x: you opt into v2 with an exact version pin, and the
    API can still move before the stable release, which lands alongside the spec release.
    **[Installation](get-started/installation.md)** has the copy-paste install line and the
    pinning rules. And if anything in v2 breaks, surprises, or slows you down,
    [tell us](https://github.com/modelcontextprotocol/python-sdk/issues/new?template=v2-feedback.yaml):
    while v2 is in beta, that is the most useful thing you can send us.
 ## The SDK: v1 to v2
 ### `FastMCP` is now `MCPServer`
 The high-level server class was renamed, and its module with it. This is the first thing every v1 server hits, because the old import path is gone rather than deprecated:
 ```python
 from mcp.server import MCPServer  # v1: from mcp.server.fastmcp import FastMCP
 mcp = MCPServer("Demo")  # v1: FastMCP("Demo")
 ```
 It is also, for a decorator-built server, most of the port. `@mcp.tool()`, `@mcp.resource()`, and `@mcp.prompt()` accept what they accepted in v1 (`@mcp.resource()` adds one optional `security=` keyword), and the input schema still comes from your type hints. Around the edges: everything under `mcp.server.fastmcp.*` now lives under `mcp.server.mcpserver.*`, `ctx.fastmcp` is `ctx.mcp_server`, `get_context()` is gone (declare a `ctx: Context` parameter instead), and the exception base `FastMCPError` is `MCPServerError`. The **[Migration Guide](migration.md#fastmcp-renamed-to-mcpserver)** has the import table.
 ### `Resolve`: the new way to ask the user for input
 Not everything a tool needs should come from the model. New in v2, a tool parameter annotated with `Resolve(fn)` is filled by a function you write instead, invisibly to the model, and that function can return `Elicit(...)` to put a question in front of the user. This is the preferred way to get anything from the client mid-call: the SDK carries the question over whichever mechanism the connection supports (a live elicitation request for a legacy client, a multi-round-trip on 2026-07-28), so one tool body serves both eras. **[Dependencies](handlers/dependencies.md)** is the page.
 !!! note
    The other two forms remain when you need them: `ctx.elicit()` still works for clients on
    legacy connections (**[Elicitation](handlers/elicitation.md)**), and a handler can return an
    `InputRequiredResult` itself and drive the rounds by hand, which is also how sampling and
    roots requests travel at 2026-07-28 (**[Multi-round-trip requests](handlers/multi-round-trip.md)**).
 ### A first-class `Client`
 v1 handed you three nested layers: a transport context manager yielding raw streams, a `ClientSession` wrapped around them, and a hand-called `await session.initialize()`. v2 has one object:
 ```python title="client.py" hl_lines="14-18"
 --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.
 **[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.
 ### The low-level `Server` was rebuilt, not renamed
 If you work at the JSON-RPC layer, this is the "everything is different" part of v2. Here is the same one-tool server both ways; click the markers for what moved.
 <!-- The v1 fence cannot be a tested docs_src file (nothing in CI can import the
 1.x SDK). Its ground truth: this exact code was run verbatim against a real
 mcp==1.28.1 install. If you edit it, re-validate it against 1.x. -->
 ```python title="v1"
 from typing import Any
 import mcp.types as types
 from mcp.server.lowlevel import Server
 server = Server("Bookshop")
@server.list_tools()  # (1)!
 async def list_tools() -> list[types.Tool]:
    return [  # (2)!
        types.Tool(
            name="search_books",
            description="Search the catalog by title or author.",
            inputSchema={  # (3)!
                "type": "object",
                "properties": {"query": {"type": "string"}},
                "required": ["query"],
            },
        )
    ]
@server.call_tool()
 async def call_tool(name: str, arguments: dict[str, Any]) -> list[types.ContentBlock]:  # (4)!
    if name != "search_books":
        raise ValueError(f"Unknown tool: {name}")  # (5)!
    ctx = server.request_context  # (6)!
    return [types.TextContent(type="text", text=f"Found 3 books matching {arguments['query']!r}.")]  # (7)!
 ```
 1. Handlers are registered with decorators (called, with parentheses), any time after the server exists.
 2. You return a bare `list[Tool]` and the SDK wraps it into a `ListToolsResult`.
 3. Fields are camelCase in Python, and the schema is **enforced**: the SDK jsonschema-validates `call_tool` arguments against it before your function runs, which is why `arguments["query"]` below is safe.
 4. One `call_tool` handler serves every tool, and it receives the tool name and the already-validated arguments, unpacked and never `None`.
 5. Raising is how a v1 tool signals failure: any exception is caught and returned as `CallToolResult(isError=True)` with `str(e)` as its text, so the calling model reads this message and can retry.
 6. The context comes from an ambient ContextVar, reached through the server object mid-request.
 7. Bare content blocks are wrapped into a `CallToolResult` for you.
 ```python title="v2"
 --8<-- "docs_src/whats_new/tutorial001.py"
 ```
 1. Fields are snake_case now, and the schema is **advertised but never applied**: nothing checks the arguments before your handler runs.
 2. Every handler has the same shape: `async (ctx, params) -> result`. The context is the first argument (`ctx.session`, `ctx.request_id`, `ctx.protocol_version` live on it); this is where `server.request_context` went.
 3. You build the full `ListToolsResult` yourself. Returning a bare list is a server-side `TypeError` now, not something the SDK wraps.
 4. Typed params in (`params.name`, `params.arguments`), a full result out. Nothing is unpacked, wrapped, or converted for you.
 5. Same check, different verb. A `ValueError` here would reach the model as an opaque `-32603` (see below), so a deliberate wire error is raised as `MCPError`: it passes through with its code and message intact, and `-32602` with this text is the spec's own answer for an unknown tool.
 6. `params.arguments` can be `None`; v1 defaulted it to `{}` before your code ever saw it. With no validation in front of the handler, this line is load-bearing.
 7. An unexpected exception raised here becomes a **sanitized** protocol error, `-32603` `"Internal server error"`: the model never sees the message. For a failure the model should read and react to, return `CallToolResult(is_error=True, ...)`.
 8. Handlers are constructor arguments, so the server's surface is complete the moment it exists; `add_request_handler()` is the post-construction escape hatch, and the door to custom methods.
 The example is the pattern. More generally: every handler has the same shape, with typed params in and a full result type out; the old jsonschema check of tool arguments is gone; an exception is a protocol error, never an `is_error=True` tool result; and the ambient `server.request_context` ContextVar is gone. Custom, vendor-namespaced methods are first class through `add_request_handler(method, params_type, handler)`, which validates inbound params against your model before your handler runs. And a `middleware` list (deliberately marked provisional) wraps every inbound message, replacing the private `_handle_*` methods people used to override.
 Underneath, the v1 `BaseSession` receive loop was replaced by a dispatcher engine that the client and the server now share, and it is what makes several things on this page true at once: one `Server` object serves both protocol eras, `Client(server)` dispatches in process with no JSON-RPC framing, and a timed-out client request now actually cancels the server-side handler.
 **[The low-level Server](advanced/low-level-server.md)** is the page; the **[Migration Guide](migration.md#lowlevel-server-decorator-based-handlers-replaced-with-constructor-on_-params)** walks every removed hook. If you never dropped below `MCPServer`, none of this touches you.
 ### The wire types moved to `mcp-types`, and every field is snake_case
 The protocol types now live in their own distribution, `mcp-types`, imported as `mcp_types`. It depends on nothing but pydantic and typing-extensions, so a gateway, a proxy, or a code generator can consume MCP's wire shapes without installing an HTTP stack. `mcp` depends on it at an exact version and re-exports the common names, so `from mcp import Tool` still works; `import mcp.types` does not.
 On those types, every Python attribute is now snake_case: `result.is_error`, `tool.input_schema`, `listing.next_cursor`. The JSON on the wire is camelCase, exactly as before; only the attribute spelling changed. Two stricter defaults ride along: unknown fields are ignored instead of round-tripped (put extras in `_meta`), and both sides validate traffic against the protocol version they negotiated. See the **[Migration Guide](migration.md#field-names-changed-from-camelcase-to-snake_case)** for the rename table.
 ### Transport configuration moved to `run()`
 `MCPServer(...)` is about what your server *is*: its name, its instructions, its lifespan, its auth. How it is *served* now belongs to `run()` and the app builders, which is where `host`, `port`, `stateless_http`, `json_response`, the endpoint paths, and `transport_security` went (`MCPServer("x", port=9000)` is a `TypeError`). The overloads are typed per transport, so your editor tells you which options `stdio` takes and which `streamable-http` takes. One removal worth knowing: `mount_path` is gone; mounting the ASGI app is the supported way to serve under a prefix.
 **[Running your server](run/index.md)** covers the options; **[Add to an existing app](run/asgi.md)** covers mounting.
 ### Behavior that changes without an import error
 The renames announce themselves. These do not:
 * **Sync functions run on a worker thread.** A `def` tool (or resource, prompt, or resolver) no longer blocks the event loop; the trade is that its body no longer runs *on* the event-loop thread, which matters to thread-affine code. `async def` handlers are untouched. **[Migration Guide](migration.md#sync-handler-functions-now-run-on-a-worker-thread)**.
 * **`MCPError` (v1's `McpError`) raised inside a tool is a protocol error now.** The model never sees it. Every other exception still becomes an `is_error=True` result the model can read and react to. **[Handling errors](servers/handling-errors.md)** is the split.
 * **Results are validated before they leave.** A hand-built `Tool` whose `input_schema` is `{}` now fails `tools/list` (the spec requires `"type": "object"`). Servers built on `@mcp.tool()` never see this; the SDK writes their schemas.
 * **Your client validates what it receives.** `list_tools()` and `call_tool()` check the server's answer against the negotiated protocol version, so a not-quite-valid server that v1's lenient parse tolerated now raises `pydantic.ValidationError`. If you connect to servers you do not control, expect to be the one who finds them; the **[Migration Guide](migration.md#client-validates-inbound-traffic-against-the-protocol-schema)** has the details.
 * **URI templates are real RFC 6570 now.** `{+path}`, `{?query}` and friends work, matching is exact instead of regex-loose, and path traversal in extracted values is rejected by default. Stricter templates fail at decoration time, not on the first request. **[URI templates](servers/uri-templates.md)**.
 * **The streamable HTTP lifespan runs once**, at startup, and its state is shared by every session and request. In v1 it ran once per session, and once per request under `stateless_http=True`. Pools and caches built in a lifespan get dramatically cheaper; anything that acquired a per-connection resource there belongs in the handler body now. **[Lifespan](handlers/lifespan.md)**.
 * **`mcp dev` and `mcp install` pin the environment they spawn** to your installed SDK version. Both commands run your server in a fresh `uv run --with ...` environment, which used to resolve `mcp` to the newest stable release rather than the version you are developing against. **[Migration Guide](migration.md#mcp-dev-and-mcp-install-pin-the-spawned-environment-to-your-sdk-version)**.
 ### Removed outright
 Each of these is a section in the **[Migration Guide](migration.md)**:
 * The **WebSocket transport**, both sides, and the `mcp[ws]` extra. It was never part of the MCP specification.
 * The **experimental Tasks** API (`mcp.*.experimental`). 2026-07-28 moves tasks out of the core protocol and into an official extension ([SEP-2663](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2663)), which this SDK does not implement yet.
 * `mcp.types`, `mcp.shared.version`, and `mcp.shared.progress` as import paths.
 * The deprecated `streamablehttp_client` spelling, and the `get_session_id` callback from `streamable_http_client` (which now yields exactly two streams).
 * `McpError`, renamed **`MCPError`** with a direct `(code, message, data)` constructor.
 * `MCPServer.get_context()`, `mount_path=`, and the lowlevel `Server`'s decorator methods, ContextVar, and handler dicts.
 ## The protocol: 2025-11-25 to 2026-07-28
 v2 implements the 2026-07-28 revision, and it serves **both** revisions at once: the same `streamable_http_app()` (and the same stdio server) answers a 2025-era client's `initialize` and a 2026-era client's requests with nothing to configure, no flag to flip, and no separate deployment. Serving the new revision does not strand a client on the old one. What follows is what the new revision itself changes.
 ### No handshake, no session
 A 2026-07-28 client does not open a connection, negotiate, and then talk. Every request carries its protocol version, client info, and client capabilities in `_meta`, and the one discovery call, `server/discover`, is a plain request like any other. `Client` does the right thing by default: it probes `server/discover` once and falls back to the `initialize` handshake if the server is older.
 Over Streamable HTTP there is no `Mcp-Session-Id` on the 2026 path, which is the operational headline: **nothing ties a modern request to a worker**, so any replica behind a plain round-robin load balancer can answer it. Two honest qualifiers. Your 2025-era clients (today, that is most clients) still open sessions and still need whatever stickiness they needed on v1; nothing changes for them. And the one thing a *multi-round-trip* retry has to carry across workers is its sealed `request_state`, whose default key is minted per process, so a scaled-out deployment passes `RequestStateSecurity(keys=[...])`. (`stateless_http=True` is unrelated: it only affects how 2025-era clients are served, and 2026 traffic never reads it; if you already set it in v1, nothing changes.)
 **[Protocol versions](protocol-versions.md)** is the client's side of this, **[Deploy & scale](run/deploy.md)** is the operator's checklist (the Host allowlist, the `request_state` key, notifications across replicas), and **[Serving legacy clients](run/legacy-clients.md)** is the both-eras-at-once story.
 ### The server cannot call the client: multi-round-trip requests
 Every server-initiated request is gone at 2026-07-28: push elicitation, sampling, `roots/list`. On a 2026 connection there is no channel for them, so `ctx.elicit()` and `ctx.session.create_message()` fail there with `NoBackChannelError` (they still work for legacy clients).
 The replacement turns the call around. A tool that needs something from the user *returns* the question (`InputRequiredResult`), the client answers it with the same callbacks it always had, and the call is retried with the answers attached. `Client` drives that loop for you. On the server you rarely build the result yourself, because a **[dependency](handlers/dependencies.md)** does it: annotate a parameter with `Resolve(ask_quantity)`, where `ask_quantity` is an ordinary function you write, and the SDK asks over whichever mechanism the connection supports, a live elicitation request on a legacy session or a multi-round-trip on 2026. One tool body, both eras:
 ```python title="dual_era.py" hl_lines="24 37-38"
 --8<-- "docs_src/legacy_clients/tutorial001.py"
 ```
 That file is the pitch in one place: one server, one `Resolve`-backed tool, and a legacy client plus a modern client both getting their answer, in memory. **[Multi-round-trip requests](handlers/multi-round-trip.md)** explains the mechanism (including `request_state`, which the SDK seals and verifies for you); **[Elicitation](handlers/elicitation.md)** covers the asking.
 !!! warning "This is the one place a ported v1 server changes behavior"
    Your own tests hit it first: `Client(mcp)` negotiates 2026-07-28 against your v2 server by
    default, so a tool that calls `ctx.elicit()` fails in a test that passed on v1. Move the
    question into a `Resolve(...)` parameter (era-portable), or pin the test client to
    `mode="legacy"` if you genuinely want the push behavior.
 ### Roots, sampling, and protocol logging are deprecated; `ping` is removed
 [SEP-2577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577) deprecates three whole *capabilities*, on every protocol version: roots, sampling, and MCP-level logging (`ctx.info()` and friends). That is a separate axis from the missing back-channel above; deprecated is advisory, everything keeps working against 2025-era sessions, and nothing changes on the wire. What you notice is `MCPDeprecationWarning`, which is a `UserWarning`, so it prints by default; expect your first `ctx.info(...)` after the upgrade to say so.
 `ping` is stricter: removed from the protocol, not deprecated. Two of the deprecated features' standalone methods are removed at 2026-07-28 the same way, `logging/setLevel` and the client's `notifications/roots/list_changed`, and progress notifications are now server-to-client only.
 **[Deprecated features](deprecated.md)** has the full table, the replacement for each, and the one-line filter if you need a quiet log while you serve legacy clients.
 ### Change notifications become one stream
 At 2026-07-28 the standalone HTTP GET stream and `resources/subscribe` are replaced by `subscriptions/listen`: the client opens one long-lived stream and names the notification kinds it wants. `MCPServer` serves it out of the box; you publish with `await ctx.notify_resource_updated(uri)` (and `notify_tools_changed()`, and so on), and multi-replica deployments plug in a shared `SubscriptionBus`. On the client (since `2.0.0b2`), `async with client.listen(...)` opens the stream: the filter goes in as keyword arguments, typed change events come back, and `sub.honored` is the subset the server agreed to deliver. One honest caveat: over stdio the server does not serve the stream yet.
 **[Subscriptions](handlers/subscriptions.md)** covers publishing and serving, **[its Clients twin](client/subscriptions.md)** the watching end, and **[Deploy & scale](run/deploy.md)** the bus.
 ### The rest, quickly
 * **Requests are routable without parsing bodies.** Modern HTTP requests carry `Mcp-Method` (and, for the three tool-ish calls, `Mcp-Name`); a tool input-schema property annotated with `x-mcp-header` is mirrored into an `Mcp-Param-*` header and cross-checked by the server ([SEP-2243](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2243)). Gateways and rate limiters can route on headers alone; the **[Migration Guide](migration.md#servers-validate-mcp-param-headers-against-the-request-body-sep-2243)** has the rules.
 * **Results carry cache hints.** List and read results declare `ttlMs` and `cacheScope` ([SEP-2549](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2549)); you set them per method with `cache_hints=`, and `Client` honors them with a built-in response cache. A server that sends no hints (every pre-2026 server) sees identical, uncached traffic. **[Caching hints](client/caching.md)**.
 * **Extensions are first class.** Servers and clients declare optional capability bundles under reverse-DNS identifiers ([SEP-2133](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2133)); the built-in `Apps` extension (MCP Apps) is the reference. **[Extensions](advanced/extensions.md)** and **[MCP Apps](advanced/apps.md)**.
 * **Error codes got standardized.** A missing resource is `-32602` with the URI in `error.data`, and the new spec-reserved codes appear as `-32020` (header mismatch), `-32021` (missing required capability), and `-32022` (unsupported protocol version). **[Troubleshooting](troubleshooting.md)** is keyed by the exact messages.
 * **Authorization got harder to hold wrong.** The client validates the `iss` returned with the authorization code ([RFC 9207](https://datatracker.ietf.org/doc/html/rfc9207); your `callback_handler` now returns an `AuthorizationCodeResult`), sends `application_type` when it registers, and never replays credentials against a different authorization server. New in the enterprise corner: the [SEP-990](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/990) identity-assertion flow. The **[Migration Guide](migration.md)** lists every OAuth change; **[OAuth for clients](client/oauth-clients.md)** and **[Identity assertion](client/identity-assertion.md)** are the pages.
 * **Every server is traceable.** OpenTelemetry ships on by default as middleware: every request gets a server span, at no cost until the process configures an exporter. When both ends run the SDK, the client also propagates W3C trace context in `_meta`, so the traces join up. **[OpenTelemetry](run/opentelemetry.md)**.
 ## Upgrading from v1?
 * The **[Migration Guide](migration.md)** is the complete, exact list of what to change; this page was the why.
 * **v1.x is not going anywhere.** It stays the stable line, with critical fixes and security patches, and nothing about the 2026-07-28 spec release breaks it. If you publish a library that depends on `mcp`, add an upper bound (for example `mcp>=1.27,<2`) so stable v2 does not surprise your users.
 * Something rough, confusing, or broken? **[File v2 feedback](https://github.com/modelcontextprotocol/python-sdk/issues/new?template=v2-feedback.yaml)**; it all gets read.
@@ -0,0 +1,7 @@
 """Complete, runnable source for every code example in `docs/`.
 Each `docs/<page>.md` includes its examples from `docs_src/<chapter>/tutorialNNN.py`
 via `--8<--`, and `tests/docs_src/test_<chapter>.py` imports the same module and
 exercises it through the in-memory `mcp.Client`. The file you read in the docs is
 the file CI runs.
 """
@@ -0,0 +1,3 @@
 <!doctype html>
 <title>Report</title>
 <p>Quarterly numbers render here.</p>
@@ -0,0 +1,39 @@
 from mcp import Client
 from mcp.client import advertise
 from mcp.server.apps import APP_MIME_TYPE, EXTENSION_ID, Apps, client_supports_apps
 from mcp.server.mcpserver import MCPServer
 from mcp.server.mcpserver.context import Context
 CLOCK_HTML = """\
 <!doctype html>
 <title>Clock</title>
 <h1 id="now">...</h1>
 <script>
  window.addEventListener("message", (event) => {
    const text = event.data?.result?.content?.[0]?.text;
    if (text) document.getElementById("now").textContent = text;
  });
 </script>
 """
 apps = Apps()
@apps.tool(resource_uri="ui://clock/app.html", description="The current time.")
 def get_time(ctx: Context) -> str:
    now = "2026-06-26T12:00:00Z"
    if not client_supports_apps(ctx):
        return f"The time is {now}."
    return now
 apps.add_html_resource("ui://clock/app.html", CLOCK_HTML, title="Clock")
 mcp = MCPServer("clock", extensions=[apps])
 async def main() -> None:
    async with Client(mcp, extensions=[advertise(EXTENSION_ID, {"mimeTypes": [APP_MIME_TYPE]})]) as client:
        result = await client.call_tool("get_time", {})
        print(result.content)
        # [TextContent(text='2026-06-26T12:00:00Z')]
@@ -0,0 +1,25 @@
 from mcp.server.apps import Apps, ResourceCsp, ResourcePermissions
 from mcp.server.mcpserver import MCPServer
 DASHBOARD_HTML = "<!doctype html><title>Dashboard</title><canvas id='chart'></canvas>"
 apps = Apps()
@apps.tool(resource_uri="ui://dashboard/app.html", visibility=["app"])
 def refresh_dashboard() -> str:
    """Refresh the dashboard data."""
    return "refreshed"
 apps.add_html_resource(
    "ui://dashboard/app.html",
    DASHBOARD_HTML,
    title="Dashboard",
    csp=ResourceCsp(connect_domains=["https://api.example.com"]),
    permissions=ResourcePermissions(clipboard_write={}),
    domain="dashboard.example.com",
    prefers_border=True,
 )
 mcp = MCPServer("dashboard", extensions=[apps])
@@ -0,0 +1,20 @@
 from pathlib import Path
 from mcp.server.apps import Apps
 from mcp.server.mcpserver import MCPServer
 from mcp.server.mcpserver.resources import FileResource
 REPORT_HTML = Path(__file__).parent / "report.html"
 apps = Apps()
@apps.tool(resource_uri="ui://report/app.html")
 def refresh_report() -> str:
    """Refresh the report data."""
    return "report refreshed"
 apps.add_resource(FileResource(uri="ui://report/app.html", name="report", path=REPORT_HTML))
 mcp = MCPServer("report", extensions=[apps])
@@ -0,0 +1,12 @@
 from mcp.server import MCPServer
 mcp = MCPServer("Notes")
@mcp.tool()
 def add_note(text: str) -> str:
    """Save a note."""
    return f"Saved: {text}"
 app = mcp.streamable_http_app()
@@ -0,0 +1,27 @@
 from collections.abc import AsyncIterator
 from contextlib import asynccontextmanager
 from starlette.applications import Starlette
 from starlette.routing import Mount
 from mcp.server import MCPServer
 mcp = MCPServer("Notes")
@mcp.tool()
 def add_note(text: str) -> str:
    """Save a note."""
    return f"Saved: {text}"
@asynccontextmanager
 async def lifespan(app: Starlette) -> AsyncIterator[None]:
    async with mcp.session_manager.run():
        yield
 app = Starlette(
    routes=[Mount("/", app=mcp.streamable_http_app())],
    lifespan=lifespan,
 )
@@ -0,0 +1,39 @@
 from collections.abc import AsyncIterator
 from contextlib import AsyncExitStack, asynccontextmanager
 from starlette.applications import Starlette
 from starlette.routing import Mount
 from mcp.server import MCPServer
 notes = MCPServer("Notes")
 tasks = MCPServer("Tasks")
@notes.tool()
 def add_note(text: str) -> str:
    """Save a note."""
    return f"Saved: {text}"
@tasks.tool()
 def add_task(title: str) -> str:
    """Create a task."""
    return f"Created: {title}"
@asynccontextmanager
 async def lifespan(app: Starlette) -> AsyncIterator[None]:
    async with AsyncExitStack() as stack:
        await stack.enter_async_context(notes.session_manager.run())
        await stack.enter_async_context(tasks.session_manager.run())
        yield
 app = Starlette(
    routes=[
        Mount("/notes", app=notes.streamable_http_app()),
        Mount("/tasks", app=tasks.streamable_http_app()),
    ],
    lifespan=lifespan,
 )
@@ -0,0 +1,27 @@
 from collections.abc import AsyncIterator
 from contextlib import asynccontextmanager
 from starlette.applications import Starlette
 from starlette.routing import Mount
 from mcp.server import MCPServer
 mcp = MCPServer("Notes")
@mcp.tool()
 def add_note(text: str) -> str:
    """Save a note."""
    return f"Saved: {text}"
@asynccontextmanager
 async def lifespan(app: Starlette) -> AsyncIterator[None]:
    async with mcp.session_manager.run():
        yield
 app = Starlette(
    routes=[Mount("/notes", app=mcp.streamable_http_app(streamable_http_path="/"))],
    lifespan=lifespan,
 )
@@ -0,0 +1,52 @@
 from collections.abc import AsyncIterator
 from contextlib import asynccontextmanager
 from starlette.applications import Starlette
 from starlette.middleware import Middleware
 from starlette.middleware.cors import CORSMiddleware
 from starlette.routing import Mount
 from mcp.server import MCPServer
 from mcp.server.transport_security import TransportSecuritySettings
 mcp = MCPServer("Notes")
@mcp.tool()
 def add_note(text: str) -> str:
    """Save a note."""
    return f"Saved: {text}"
@asynccontextmanager
 async def lifespan(app: Starlette) -> AsyncIterator[None]:
    async with mcp.session_manager.run():
        yield
 security = TransportSecuritySettings(
    allowed_hosts=["mcp.example.com", "mcp.example.com:*"],
    allowed_origins=["https://app.example.com"],
 )
 app = Starlette(
    routes=[Mount("/", app=mcp.streamable_http_app(transport_security=security))],
    middleware=[
        Middleware(
            CORSMiddleware,
            allow_origins=["https://app.example.com"],
            allow_methods=["GET", "POST", "DELETE"],
            allow_headers=[
                "Authorization",
                "Content-Type",
                "Last-Event-ID",
                "Mcp-Method",
                "Mcp-Name",
                "Mcp-Protocol-Version",
                "Mcp-Session-Id",
            ],
            expose_headers=["Mcp-Session-Id"],
        )
    ],
    lifespan=lifespan,
 )
--- a/Show More
+++ b/Show More
		`@@ -0,0 +1,2 @@`
							`# Generated`
							`uv.lock linguist-generated=true`
		`@@ -0,0 +1 @@`
							<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 180 180"><path fill="none" d="M23.5996 85.2532L86.2021 22.6507C94.8457 14.0071 108.86 14.0071 117.503 22.6507C126.147 31.2942 126.147 45.3083 117.503 53.9519L70.2254 101.23" stroke="currentColor" stroke-width="11.0667" stroke-linecap="round"/><path fill="none" d="M70.8789 100.578L117.504 53.952C126.148 45.3083 140.163 45.3083 148.806 53.952L149.132 54.278C157.776 62.9216 157.776 76.9357 149.132 85.5792L92.5139 142.198C89.6327 145.079 89.6327 149.75 92.5139 152.631L104.14 164.257" stroke="currentColor" stroke-width="11.0667" stroke-linecap="round"/><path fill="none" d="M101.853 38.3013L55.553 84.6011C46.9094 93.2447 46.9094 107.258 55.553 115.902C64.1966 124.546 78.2106 124.546 86.8543 115.902L133.154 69.6025" stroke="currentColor" stroke-width="11.0667" stroke-linecap="round"/></svg>