modelcontextprotocol / modelcontextprotocol/python-sdk

Requests with "id": null silently misclassified as notifications

オープン
#2,057 コメント 10 件 リアクション 1 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

bug improves spec compliance P2
主要言語
Python
スター
24.3k
フォーク
4k
平均マージ
1日 1時間
マージ済み PR(30日)
31

説明

Initial Checks
Description

When a JSON-RPC request arrives with "id": null, the SDK should reject it. Both JSON-RPC 2.0 and the MCP spec restrict request IDs to strings or integers. Instead, the request is silently reclassified as a JSONRPCNotification and the caller gets a 202 with no response.

This happens because of how JSONRPCMessage union resolution interacts with extra='allow':

  1. RequestId correctly excludes None (Annotated[int, Field(strict=True)] | str).
  2. JSONRPCRequest validation rejects id: null, working as intended.
  3. Pydantic falls through to JSONRPCNotification, which absorbs "id": None as an extra field via extra='allow'.
  4. The streamable HTTP transport sees "not a request" and returns 202.

The net effect is the caller gets no error and no response, which is hard to debug. Found via authprobe scanning.

I suspect the v2 migration to TypeAdapter and dropping extra='allow' on top-level types would resolve this, but wanted to flag it for the current release line too.

Example Code
from mcp.types import JSONRPCMessage, JSONRPCRequest

msg = {"jsonrpc": "2.0", "method": "initialize", "id": None}

# JSONRPCRequest correctly rejects null id
try:
    JSONRPCRequest.model_validate(msg)
except Exception:
    print("JSONRPCRequest rejects null id")  # Expected

# JSONRPCMessage falls through to JSONRPCNotification
parsed = JSONRPCMessage.model_validate(msg)
print(type(parsed.root).__name__)   # JSONRPCNotification (unexpected)
print(parsed.root.model_extra)      # {'id': None}
Python & MCP Python SDK
Python 3.13
mcp 1.14.1 (also reproduced on 1.26.0, latest at time of filing)

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

まず JSONRPCMessage と JSONRPCRequest の検証から始め、次に streamable HTTP トランスポートが解析済みメッセージをどのように処理するかを追跡します。提示された null-id の例を再現し、それが JSONRPCNotification として分類されたり 202 で応答されたりするのではなく、無効なリクエストとして拒否されることを確認します。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
python
領域
api
issue の種類
バグ
難易度
3/5
見積もり時間
1〜2日
活発さ
停滞
明瞭さ
おおむね明確
初心者へのやさしさ
48/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。