Refactor handler context to be transport- and handler-type-aware

Offen

#2,021 erstellt am 09.2.2026 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit: 5/5
Geschätzter Aufwand: Über eine Woche
Anfängerfreundlichkeit: 25/100

Issue-Typ: Refactoring
Klarheit: Muss geklärt werden
Aktivitätsstatus: Veraltet
Tech-Stack: python
Bereich: backend-api-design

Rechercherichtung

Beginne damit, RequestContext und ServerRequestContext durch die Handler-Einstiegspunkte zu verfolgen, und untersuche anschließend ServerMessageMetadata.request_context sowie die für Starlette Request und stdio erwähnten Transportfälle. Vergleiche, wie Request- und Notification-Handler Kontext erhalten und wie auf transportspezifische Werte zugegriffen wird. Als abgeschlossen gilt die Aufgabe, wenn die vorgesehenen Typgrenzen und das Transportverhalten definiert sind, ohne sich auf Any oder optionale Request-IDs zu stützen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

P1 v2

The current RequestContext / ServerRequestContext design has a few rough edges that warrant a dedicated refactor:

Request vs notification context — Request handlers have request_id and meta, notification handlers do not. Currently request_id is optional (RequestId | None) on a single shared type, which loses type safety. Ideally these would be distinct types so request handlers get a context where request_id is always present, and notification handlers get one where it does not exist.
Transport-specific context — The request_context field on ServerMessageMetadata is typed as Any because the server layer is transport-agnostic (e.g. it is a Starlette Request for HTTP transports, None for stdio). A better design would let transports provide their own typed context that handlers can access without casting.

These two concerns are related — both point toward making the context type more precise depending on how and where a handler is invoked.

_{AI Disclaimer}

Vorherrschende Sprache: Python
Sterne: 24.3k
Forks: 4k
Ø Merge: 1 T. 11 Std.
Gemergte PRs (30 T.): 30

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
Forken Sie das Repository und arbeiten Sie in einem Branch.
Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus modelcontextprotocol/python-sdk

OAuth client scope handling breaks on comma-separated scope strings Offen

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100

modelcontextprotocol/python-sdk#3566 · Erstellt am 23.9.2026
Streamable HTTP client logs a WARNING for valid 202 Accepted on session termination (DELETE) Offen

v1 v2

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 85/100

modelcontextprotocol/python-sdk#3546 · 5 Kommentare · Erstellt am 19.9.2026
Server ClientAuthenticator requires client_id in token body, rejecting valid client_secret_basic requests (RFC 6749 §2.3.1) Offen

v1 v2

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100

modelcontextprotocol/python-sdk#3545 · 1 Kommentar · Erstellt am 18.9.2026
Revocation requires client_secret to be present Offen

v1 v2

Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 91/100

modelcontextprotocol/python-sdk#3508 · 2 Kommentare · Erstellt am 15.9.2026
Does same-origin redirect enforcement break MCP servers behind a reverse proxy? Offen

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 64/100

modelcontextprotocol/python-sdk#3504 · Erstellt am 15.9.2026

Alle Issues in modelcontextprotocol/python-sdk