modelcontextprotocol / modelcontextprotocol/python-sdk
pkg_version() in Server.create_initialization_options doesn't guard against importlib.metadata.version() returning None
Personne n'a encore pris cette issue.
- Langage dominant
- Python
- Étoiles
- 24.3k
- Forks
- 4k
- Merge moyen
- 1 j 1 h
- PR mergées (30 j)
- 31
Description
Summary
Server.create_initialization_options in mcp/server/lowlevel/server.py:183 falls through to pkg_version("mcp") when self.version is falsy. The fallback function catches exceptions and returns "unknown", but doesn't guard against the (rare but real) case where importlib.metadata.version() returns None instead of raising or returning a string.
When that happens, None flows through to InitializationOptions.server_version — which is typed as str on the pydantic model — and pydantic raises ValidationError. The server dies before the stdio handshake completes; the MCP client sees a bare "Connection closed" with no useful diagnostic.
Reproduction
Environment where I hit this: Python 3.12 embedded distribution installed via WiX MSI, with mcp>=1.26,<2 pip-installed into the embedded Python's site-packages via the standard python.exe -m pip install command.
Probe from the affected Python:
from importlib.metadata import version
print(repr(version("mcp"))) # prints: None
The mcp-1.30.0.dist-info/METADATA file on disk correctly declares Version: 1.30.0. Root cause of the None return appears to be a downstream bug in the embedded-Python distribution or its pip metadata setup — a separate concern I'm investigating on my side.
Impact
Any FastMCP server that (a) doesn't set an explicit version (FastMCP doesn't accept a version= kwarg anyway) and (b) runs on a Python where importlib.metadata.version("mcp") returns None instead of a string, crashes on stdio startup:
Exception Group Traceback (most recent call last):
File "…/mcp/server/fastmcp/server.py", line 775, in run_stdio_async
self._mcp_server.create_initialization_options(),
File "…/mcp/server/lowlevel/server.py", line 181, in create_initialization_options
return InitializationOptions(
File "…/pydantic/main.py", line 263, in __init__
validated_self = self.__pydantic_validator__.validate_python(data, self_instance=self)
pydantic_core._pydantic_core.ValidationError: 1 validation error for InitializationOptions
server_version
Input should be a valid string [type=string_type, input_value=None, input_type=NoneType]
Full traceback from an affected install:
2026-09-09 14:44:00,841 [INFO] __main__: Starting GRAccess MCP server (stdio transport)
+ Exception Group Traceback (most recent call last):
| File "<frozen runpy>", line 198, in _run_module_as_main
| File "…/mcp/server/fastmcp/server.py", line 312, in run
| anyio.run(self.run_stdio_async)
| File "…/mcp/server/fastmcp/server.py", line 771, in run_stdio_async
| async with stdio_server() as (read_stream, write_stream):
| File "…/mcp/server/lowlevel/server.py", line 181, in create_initialization_options
| return InitializationOptions(
| File "…/pydantic/main.py", line 263, in __init__
| validated_self = self.__pydantic_validator__.validate_python(data, self_instance=self)
| pydantic_core._pydantic_core.ValidationError: 1 validation error for InitializationOptions
| server_version
| Input should be a valid string [type=string_type, input_value=None, input_type=NoneType]
Suggested fix
Guard the return of pkg_version against None — matches the existing "returns 'unknown' on failure" contract implied by the type annotation and the # pragma: no cover fallback:
def pkg_version(package: str) -> str:
try:
from importlib.metadata import version
v = version(package)
if v is not None:
return v
except Exception: # pragma: no cover
pass
return "unknown" # pragma: no cover
Doesn't change happy-path behavior for well-formed metadata; catches the pathological None case that pydantic then rejects.
Workaround
Setting mcp._mcp_server.version explicitly on the underlying server after FastMCP(...) construction bypasses the fallback entirely. That's what I ended up shipping in my own server.
Version
mcp:1.30.0- Python:
3.12embedded distribution on Windows Server 2022
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez dans mcp/server/lowlevel/server.py, au niveau de Server.create_initialization_options et du fallback pkg_version qu’il appelle. Reproduisez le retour de None par importlib.metadata.version("mcp"), puis vérifiez que l’initialisation produit le fallback existant "unknown" au lieu d’un Pydantic ValidationError, et que les chaînes de version normales restent inchangées.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- python
- Domaine
- backend
- Type d'issue
- Bug
- Difficulté
- 2/5
- Temps estimé
- 1-3 heures
- Activité
- Active
- Clarté
- Clairement spécifiée
- Accessibilité débutants
- 78/100