modelcontextprotocol / modelcontextprotocol/python-sdk

ClientSessionGroup raises KeyError when a server exposes no tools, resources or prompts

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

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

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

説明

Initial Checks
Release line

2.x (current stable), and it reproduces on the latest 1.x too.

Description

Connecting a ClientSessionGroup to a server that registers nothing fails with a raw KeyError. A server that registers even one tool, resource or prompt is fine.

_aggregate_components ends with this cleanup step, which only runs when all three list calls came back empty (session_group.py:420 on 2.1.0):

# Clean up exit stack for session if we couldn't retrieve anything
# from the server.
if not any((prompts_temp, resources_temp, tools_temp)):
    del self._session_exit_stacks[session]  # pragma: no cover

Two different things go wrong depending on how you got there.

Via connect_with_session(), the key was never inserted, so the del raises KeyError. That is the traceback below.

Via connect_to_server(), the key does exist, so the del succeeds. It removes the bookkeeping entry without closing the stack. The next lines then register the session in self._sessions anyway, so the group reports the session as connected while holding no way to close it. Calling disconnect_from_server() afterwards takes the session_known_for_stack is False branch and returns without closing anything, so the transport stays open until the whole group is torn down. I confirmed this by pre-registering a stack with a close callback and watching the callback never fire.

What I expected: connecting to a server that exposes nothing should either succeed with an empty component set, or fail with a clear error. If the group decides to drop the session, the exit stack should be closed rather than forgotten.

Two smaller things in the same condition, for whoever picks this up. The comment says "clean up exit stack" but the code only forgets it. And not any(...) treats "the server legitimately exposes nothing" and "all three list calls raised" as the same case, which may deserve separating.

Example Code
import anyio
import mcp_types as types
from mcp.client.client import Client
from mcp.client.session_group import ClientSessionGroup
from mcp.server.mcpserver import MCPServer

INFO = types.Implementation(name="empty", version="1.0")


async def main() -> None:
    # A server that registers no tools, no resources and no prompts.
    async with Client(MCPServer("empty")) as client:
        group = ClientSessionGroup()
        await group.connect_with_session(INFO, client.session)


anyio.run(main)

Output:

  File ".../mcp/client/session_group.py", line 420, in _aggregate_components
    del self._session_exit_stacks[session]  # pragma: no cover
        ~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^
KeyError: <mcp.client.session.ClientSession object at 0x77e8450e16a0>
Python & MCP Python SDK
Python 3.13.11, Linux.

mcp 2.1.0  (latest 2.x): fails at session_group.py:420
mcp 1.29.1 (latest 1.x): fails at session_group.py:409
Also reproduces on main at d8b63830.

Reported with AI assistance; I ran the reproduction above and read the output.

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

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

はじめの一歩

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

調査の方向性

mcp/client/session_group.py の _aggregate_components(420行目付近)から始め、issue にある空のサーバーの例を connect_with_session() と connect_to_server() の両方に通して実行します。既存のセッションのクリーンアップと disconnect_from_server() の経路を確認します。完了の条件は、空のサーバーで KeyError が発生しなくなり、破棄されたセッションスタックが適切にクローズされ、両方の接続経路をカバーすることです。

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

評価

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

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

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