modelcontextprotocol / modelcontextprotocol/python-sdk

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

Ouverte Adaptée aux débutants
#3,145 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

enhancement needs decision P3 v1 v2
Langage dominant
Python
Étoiles
24.3k
Forks
4k
Merge moyen
1 j 1 h
PR mergées (30 j)
31

Description

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

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Commencez par ClientSession.validate_tool_result() et par le remplissage existant de _tool_output_schemas dans list_tools() et _absorb_tool_listing(). Ajoutez le point d’entrée public d’enregistrement décrit dans l’issue, puis vérifiez qu’un outil découvert dynamiquement peut être enregistré et que son structuredContent est validé sans déclencher l’avertissement indiquant qu’un outil est manquant.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
python
Domaine
api, backend
Type d'issue
Fonctionnalité
Difficulté
2/5
Temps estimé
1-3 heures
Activité
Calme
Clarté
Clairement spécifiée
Accessibilité débutants
72/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.