modelcontextprotocol / modelcontextprotocol/python-sdk

Add `ClientSession.register_tool_schema()` for dynamic tool discovery patterns

オープン 初心者向け
#3,145 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

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

説明

Description
Problem

ClientSession.validate_tool_result() validates tool results against cached output schemas in self._tool_output_schemas, which is populated exclusively by list_tools(). When a tool is invoked that wasn't returned by list_tools(), two things happen:

  1. A warning is logged: "Tool {name} not listed by server, cannot validate any structured content"
  2. If the tool returns structuredContent with an outputSchema, validation is skipped entirely — a correctness gap.

This affects MCP servers that use dynamic tool discovery, where list_tools() intentionally returns only a small subset of available tools (e.g., meta-tools like a search tool) and actual tools are discovered at runtime via semantic search or catalog queries.

Use case

AWS Bedrock AgentCore Gateway is an MCP-compatible server that can host hundreds or thousands of tools. Rather than returning all tools in list_tools() (which would overwhelm LLM context windows), it exposes a built-in tool called x_amz_bedrock_agentcore_search. Clients call this tool with a natural language query, and the gateway returns matching tool definitions — including names, descriptions, input schemas, and output schemas. The client then invokes these discovered tools by name via call_tool().

At that point, the SDK doesn't recognize these tools because they never appeared in a list_tools() response. This triggers the warning and skips output validation. The only workaround today is accessing the private _tool_output_schemas dict directly.

AWS Prescriptive Guidance documents this "search function" approach as one of three canonical tool discovery strategies for MCP (alongside static definition and dynamic discovery via list_tools()).

Proposed API

A single public method on ClientSession:

def register_tool_schema(
    self, name: str, output_schema: dict[str, Any] | None = None
) -> None:
    """Register a tool's output schema for result validation.

    Use this when tools are discovered dynamically (e.g., via a catalog
    search API) and won't appear in list_tools() responses.
    """
    self._tool_output_schemas[name] = output_schema

Usage:

# Client discovers tools via semantic search (not list_tools)
search_results = await session.call_tool("x_amz_bedrock_agentcore_search", {"query": "data analysis"})

# Register discovered tools for proper validation
for tool in parse_discovered_tools(search_results):
    session.register_tool_schema(tool.name, tool.output_schema)

# Now call_tool validates structuredContent correctly, no warning logged
result = await session.call_tool("data_analysis_v2", {"input": "..."})

This is purely additive — no changes to existing behavior, no new data structures. It writes to the same dict that _absorb_tool_listing() already populates.

References

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

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

はじめの一歩

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

調査の方向性

ClientSession.validate_tool_result() と、list_tools() および _absorb_tool_listing() における既存の _tool_output_schemas の設定処理から始めます。issue で説明されている公開登録エントリーポイントを追加し、その後、動的に検出されたツールを登録でき、その structuredContent が、ツールが見つからないという警告を発生させずに検証されることを確認します。

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

評価

技術スタック
python
領域
api, backend
issue の種類
機能追加
難易度
2/5
見積もり時間
1〜3時間
活発さ
静か
明瞭さ
明確に書かれている
初心者へのやさしさ
72/100

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

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