pyjwt[crypto] as an unconditional dependency blocks installation on platforms without a cryptography wheel (e.g. Windows on ARM)

[jtauschl]

Summary

pyjwt[crypto] is declared as an unconditional Requires-Dist in mcp's package metadata, even though the crypto extra (and the jwt import it enables) is only used by one file: mcp/client/auth/extensions/client_credentials.py, an OAuth client-credentials flow. Every consumer of this package — including a pure MCP server implementation that never acts as an OAuth client — is forced to install pyjwt[crypto], which pulls in cryptography as a hard dependency.

Why this matters

cryptography ships prebuilt wheels for most platforms, but not all — e.g. there is currently no PyPI wheel for win_arm64 (Windows on ARM). On a platform without a prebuilt wheel, pip/uv fall back to building cryptography from source via maturin/cargo/rustc, which additionally requires a working Rust toolchain and the MSVC linker (link.exe, part of Visual Studio Build Tools) to be present. A user with a plain Python install (no Visual Studio, no Rust) hits a hard installation failure:

error: linker `link.exe` not found
note: the msvc targets depend on the msvc linker but `link.exe` was not found
note: please ensure that Visual Studio 2017 or later, or Build Tools for
Visual Studio were installed with the Visual C++ option

This blocks installing mcp (and anything depending on it) entirely on that platform, for a feature (OAuth client-credentials auth) the user may never use — in our case, a Community-Edition-facing MCP server package that has no OAuth-client code path at all.

Suggested fix

mcp already uses the extras pattern for other optional functionality (cli, rich in the current metadata). Moving the OAuth client-credentials code's pyjwt[crypto] requirement behind its own extra (e.g. oauth or similar) would let server-only/non-OAuth-client consumers install mcp without pulling in cryptography at all, while OAuth-client users opt in explicitly with mcp[oauth].

Environment where this was found

• Windows on ARM64 (win_arm64), Python 3.14 (win_arm64 build)
• Both pip (venv fallback) and uv sync hit the identical build failure
• Confirmed cryptography has no win_arm64 wheel on PyPI as of writing; only win_amd64 prebuilt wheels exist for this release
• No Visual Studio / Build Tools installed (a normal state for an end user who is not a C/C++ developer)

Happy to provide the full build log if useful.

[jstar0]

There is one packaging interaction worth resolving before treating the proposed extra split as complete.

MCPServer imports RequestStateSecurity from mcp.server.request_state at module import time, and that module imports cryptography unconditionally. MCPServer also installs RequestStateSecurity.ephemeral() by default. Therefore:

• moving only pyjwt[crypto] behind an OAuth extra would make the server installation lose the dependency needed by the default request-state path; or
• adding cryptography as a separate base dependency would preserve imports but leave the Windows ARM build blocker unchanged.

Would the intended scope include making request-state crypto optional/lazy, or should this issue be narrowed to a client-only packaging split? I verified the import chain against current main before commenting.

AI-assisted analysis: I reviewed the current source and packaging metadata, then checked the dependency boundary manually.

[iam-kira]

Confirming @jstar0's import-chain analysis, with one detail that makes the
split sharper: cryptography isn't declared in pyproject.toml at all mcp.server.request_state imports it directly (module level, lines 22-25)
but only receives it transitively via pyjwt[crypto].

So moving pyjwt[crypto] behind an oauth extra wouldn't degrade the
default request-state path, it would break it outright with an ImportError
on any server-only install.

Also worth noting for scoping: client_credentials.py defaults to RS256,
so it genuinely needs the crypto extra rather than plain pyjwt there's
no narrow win available there.

That seems to leave only two coherent options: declare cryptography as a
base dependency and accept that win_arm64 stays blocked, or make the
request-state crypto lazy so cryptography can become optional. Happy to
implement whichever you prefer.