fix(deps): update third party deps (major)

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
mcp	>=1.24.0, <2 → >=2, <3
websockets (changelog)	>=14.0,<16.0 → >=17,<17.1

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Release Notes

modelcontextprotocol/python-sdk (mcp)

v2.0.0

Compare Source

MCP Python SDK v2 Stable Release

This is v2.0.0, the stable v2 release of the MCP Python SDK. It supports the 2026-07-28 revision of the Model Context Protocol and serves every earlier revision from the same server. pip install mcp now installs 2.x.

pip install "mcp[cli]"

# or
uv add "mcp[cli]"

Documentation Rewrite

The documentation has the full tutorial and API reference. Coming from v1? What's new in v2 is the tour of what changed and why, and the migration guide lists every breaking change with before-and-after code.

V1 Maintenance mode

v1.x is in maintenance mode and will only receive security fixes from now on The 1.x line lives on the v1.x branch, continues to receive critical bug fixes and security patches, and is documented at https://py.sdk.modelcontextprotocol.io/v1/. If your project is not ready to migrate, keep a <2 upper bound on your requirement (for example mcp>=1.28,<2).

Highlights

One SDK, both protocol eras

v2 speaks the 2026-07-28 revision (stateless requests with no handshake, server/discover, subscriptions/listen, multi-round-trip requests) and still serves every 2025-era client from the same MCPServer, over Streamable HTTP and stdio, with nothing to configure. Client(target) negotiates the version automatically.

FastMCP is now MCPServer, and there is a first-class Client

The decorator API is unchanged; the low-level Server is rebuilt around a shared dispatcher engine, and one Client object replaces v1's transport-plus-ClientSession-plus-initialize() layering. It connects to a URL, a stdio subprocess, a custom transport, or straight to a server object in memory for tests.

Multi-round-trip requests and resolver dependency injection

At 2026-07-28 the server can no longer call the client, so tools return the question instead. A Resolve(fn) parameter is filled by your function invisibly to the model and can put a question to the user; one tool body serves both eras.

Extension APIs, OpenTelemetry, and a standalone types package

Servers and clients compose protocol extensions through pluggable extension APIs (MCP Apps built in); OpenTelemetry tracing ships on by default; every protocol type is its own package, mcp-types (imported as mcp_types), published in lock-step with mcp.

Hardened stdio and auth

stdio servers keep handler subprocesses and stray prints off the wire, and stdout is diverted to stderr while serving. OAuth adds RFC 9207 issuer validation, the SEP-990 identity-assertion flow, and the client-credentials extension.

Coming from a v2 pre-release

Since the last release candidate: the per-version wire packages are private (mcp_types._v*), mcp.types is a permanent alias for mcp_types, the auth registration request model is split from the registered-client record, cancelled requests are no longer answered, and log notifications are gated on the per-request log-level opt-in at 2026-07-28. Since the betas: Client(cache=False) is now cache=None with CacheConfig() the default; Context.client_id, RFC7523OAuthClientProvider, and OAuthClientProvider(timeout=) are removed; the client-credentials providers take scope=; message_handler receives notifications and exceptions only; FileResource(is_binary=) becomes encoding; MCP_* env vars are gone with pydantic-settings; Streamable HTTP servers reject bodies over 4 MiB with HTTP 413. The migration guide covers all of it.

Known gaps

The tasks extension (SEP-2663) is not part of this release. On the client, the DPoP proof binding (SEP-1932) and the workload-identity jwt-bearer grant are not implemented; both are additive and can land in 2.x.

Feedback

Something rough, confusing, or broken? Open an issue or find us in #python-sdk-dev on the MCP Contributors Discord.

Full Changelog: modelcontextprotocol/python-sdk@v2.0.0rc1...v2.0.0

v1.29.0

Compare Source

What's Changed

• [v1.x] Route Context.report_progress() to the originating request stream by @​maxisbey in #​2994
• [v1.x] docs: publish llms.txt and markdown renditions of the docs by @​maxisbey in #​3029
• [v1.x] docs: pin mkdocs<2 by @​maxisbey in #​3074
• [v1.x] Add Streamable HTTP request body limits by @​Kludex in #​3101
• [v1.x] fix: reject trailing newline in tool-name validation by @​maxisbey in #​3086
• [v1.x] ci: pick the docs toolchain per worktree in build-docs.sh by @​maxisbey in #​3082
• [v1.x] Move the v1.x docs to /v1/ and mark v1.x as the maintenance line by @​maxisbey in #​3177

Full Changelog: modelcontextprotocol/python-sdk@v1.28.1...v1.29.0

python-websockets/websockets (websockets)

v17.0

Compare Source

See https://websockets.readthedocs.io/en/stable/project/changelog.html for details.

v16.1.1

Compare Source

See https://websockets.readthedocs.io/en/stable/project/changelog.html for details.

v16.1

Compare Source

See https://websockets.readthedocs.io/en/stable/project/changelog.html for details.

v16.0

Compare Source

See https://websockets.readthedocs.io/en/stable/project/changelog.html for details.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • "before 9am on monday"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[renovate]

⚠️ Artifact update problem

Renovate failed to update artifacts related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

• any of the package files in this branch needs updating, or
• the branch becomes conflicted, or
• you click the rebase/retry checkbox if found above, or
• you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: uv.lock

Command failed: uv lock --upgrade-package mcp
Using CPython 3.14.7 interpreter at: /opt/containerbase/tools/python/3.14.7/bin/python3
  × No solution found when resolving dependencies for split (markers:
  │ python_full_version == '3.14.*' and sys_platform == 'win32'):
  ╰─▶ Because openai[realtime]>=2.50.0,<=2.54.0 depends on websockets>=13,<16
      and openai[realtime]>=2.51.0,<=2.54.0 depends on websockets>=13,<16,
      we can conclude that openai[realtime]>=2.50.0,<=2.51.0 depends on
      websockets>=13,<16.
      And because openai[realtime]>=2.52.0,<=2.54.0 depends on
      websockets>=13,<16 and openai[realtime]>=2.52.1,<=2.54.0
      depends on websockets>=13,<16, we can conclude that
      openai[realtime]>=2.50.0,<=2.52.1 depends on websockets>=13,<16.
      And because openai[realtime]>=2.53.0,<=2.54.0 depends on
      websockets>=13,<16 and openai[realtime]==2.53.0 depends on
      websockets>=13,<16, we can conclude that openai!=3.0.0, all of:
          websockets<13
          websockets>=16
      , openai[realtime]>=2.50.0 are incompatible.
      And because livekit-plugins-openai depends on openai[realtime]>=2.50
      and livekit-agents depends on openai>=2,<3, we can conclude that
      livekit-plugins-openai, all of:
          websockets<13
          websockets>=16
      , livekit-agents[anam] are incompatible.
      And because livekit-plugins-gnani depends on websockets>=17,<17.1
      and your workspace requires livekit-agents[anam], we can conclude
      that your workspace's requirements, livekit-plugins-gnani,
      livekit-plugins-openai[vertex] are incompatible.
      And because your workspace requires livekit-plugins-gnani and
      livekit-plugins-openai[vertex], we can conclude that your workspace's
      requirements are unsatisfiable.

hint: The resolution failed for an environment that is not the current one, consider limiting the environments with `tool.uv.environments`.

File name: uv.lock

Command failed: uv lock --upgrade-package websockets
Using CPython 3.14.7 interpreter at: /opt/containerbase/tools/python/3.14.7/bin/python3
  × No solution found when resolving dependencies for split (markers:
  │ python_full_version == '3.14.*' and sys_platform == 'win32'):
  ╰─▶ Because openai[realtime]>=2.50.0,<=2.54.0 depends on websockets>=13,<16
      and openai[realtime]>=2.51.0,<=2.54.0 depends on websockets>=13,<16,
      we can conclude that openai[realtime]>=2.50.0,<=2.51.0 depends on
      websockets>=13,<16.
      And because openai[realtime]>=2.52.0,<=2.54.0 depends on
      websockets>=13,<16 and openai[realtime]>=2.52.1,<=2.54.0
      depends on websockets>=13,<16, we can conclude that
      openai[realtime]>=2.50.0,<=2.52.1 depends on websockets>=13,<16.
      And because openai[realtime]>=2.53.0,<=2.54.0 depends on
      websockets>=13,<16 and openai[realtime]==2.53.0 depends on
      websockets>=13,<16, we can conclude that openai!=3.0.0, all of:
          websockets<13
          websockets>=16
      , openai[realtime]>=2.50.0 are incompatible.
      And because livekit-plugins-openai depends on openai[realtime]>=2.50
      and livekit-agents depends on openai>=2,<3, we can conclude that
      livekit-plugins-openai, all of:
          websockets<13
          websockets>=16
      , livekit-agents[anam] are incompatible.
      And because livekit-plugins-gnani depends on websockets>=17,<17.1
      and your workspace requires livekit-agents[anam], we can conclude
      that your workspace's requirements, livekit-plugins-gnani,
      livekit-plugins-openai[vertex] are incompatible.
      And because your workspace requires livekit-plugins-gnani and
      livekit-plugins-openai[vertex], we can conclude that your workspace's
      requirements are unsatisfiable.

hint: The resolution failed for an environment that is not the current one, consider limiting the environments with `tool.uv.environments`.

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 1 additional finding in Devin Review.

[devin-ai-integration]

🟡 Dependency lockfile no longer matches the declared package requirements

The declared version ranges were changed (mcp>=2, <3 at livekit-agents/pyproject.toml:64 and the websockets range in the gnani plugin) without regenerating the committed lockfile, so environment setup and CI checks that verify the lockfile is up to date will fail.
Impact: Contributors and CI can no longer install dependencies from the lockfile without an error.

Stale specifiers recorded in uv.lock

uv.lock:2249 still records { name = "mcp", marker = "extra == 'mcp'", specifier = ">=1.24.0,<2" } and uv.lock:2910 still records { name = "websockets", specifier = ">=14.0,<16.0" } for livekit-plugins-gnani, with the resolved versions being mcp 1.28.1 and websockets 15.0.1. Since [package.metadata].requires-dist no longer matches the pyproject files, uv sync (used by make install, see AGENTS.md) will need to re-resolve and any --locked/--frozen check fails.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 1 additional finding in Devin Review.

[devin-ai-integration]

🔴 Agents can no longer use MCP tool servers after the dependency jump

The MCP tool-server dependency is moved to a new major line (mcp>=2, <3 at livekit-agents/pyproject.toml:64) without updating the code that talks to it, so every agent that connects to an MCP tool server fails to start.
Impact: Any agent using MCP tools breaks immediately with a confusing "install the mcp package" error, even though the package is installed.

Incompatible v1 client APIs used against the mcp 2.x SDK

Inspecting the published mcp 2.0.0 wheel shows several v1 APIs used by livekit-agents/livekit/agents/llm/mcp.py are gone or changed:

• GetSessionIdCallback no longer exists anywhere in the package, so from mcp.client.streamable_http import GetSessionIdCallback, streamable_http_client (livekit-agents/livekit/agents/llm/mcp.py:27) raises ImportError, which the surrounding try/except ImportError (livekit-agents/livekit/agents/llm/mcp.py:29-33) converts into the misleading "The 'mcp' package is required ... pip install 'livekit-agents[mcp]'" message. This alone makes all MCP usage unusable.
• v2 depends on httpx2, not httpx: sse_client/streamable_http_client expect an httpx2.AsyncClient (and sse_client calls client.sse(url)), while _create_http_client (livekit-agents/livekit/agents/llm/mcp.py:388-405) builds an httpx.AsyncClient.
• ClientSession(read_timeout_seconds=...) is now float | None (no timedelta handling remains in the package; the value is passed straight to anyio.fail_after), but livekit-agents/livekit/agents/llm/mcp.py:158 still passes timedelta(seconds=...).
• mcp.server.fastmcp was removed, breaking examples/voice_agents/mcp/server.py:4.

Either keep the <2 bound or port llm/mcp.py (and the example server) to the v2 client API.

Prompt for agents

Bumping the optional dependency to mcp>=2,<3 in livekit-agents/pyproject.toml breaks livekit-agents/livekit/agents/llm/mcp.py, which is written against the mcp 1.x client API. Concretely, in mcp 2.0.0: GetSessionIdCallback no longer exists in mcp.client.streamable_http (the module-level import fails and is swallowed into a misleading 'install the mcp package' ImportError message); the transports now use the httpx2 package instead of httpx, so the locally built httpx.AsyncClient in MCPServerHTTP._create_http_client is not compatible with sse_client/streamable_http_client; ClientSession's read_timeout_seconds is now plain float seconds and is fed directly to anyio.fail_after, while the code passes a datetime.timedelta; and mcp.server.fastmcp (used by examples/voice_agents/mcp/server.py) was removed. Decide whether to keep the <2 constraint until the client code is migrated, or to port llm/mcp.py and the example server to the v2 client API.

---

Was this helpful? React with 👍 or 👎 to provide feedback.