Python SDK pro MCP už nenásleduje přesměrování na jiný server

MCP Python SDK 2.2.0 vyšel 7. září. Poznámky k vydání začínají čtyřmi změnami chování, nikoli novými metodami pro nástroje. Nejvýraznější z nich omezuje, kam smí HTTP klient následovat přesměrování.

Stejný server ano, jiný už ne

Klient dál přijme relativní přesměrování a adresu se stejným protokolem, hostitelem i portem. Povolí také přechod z HTTP na HTTPS u stejného hostitele, pokud obě adresy používají výchozí port. Přesměrování na jinou doménu, subdoménu nebo port odmítne. Totéž platí pro návrat z HTTPS na nešifrované HTTP.

U požadavku POST se zachováním metody následuje jen kódy 307 a 308. Kódy 301, 302 a 303 by běžný HTTP klient mohl zopakovat jako GET bez těla, což se pro zprávu MCP nehodí. U GET může SDK následovat i ostatní přesměrování, pořád však pouze uvnitř stejného původu.

Předchozí chování záviselo na tom, kdo HTTP klienta vytvořil. Výchozí klient SDK následoval všechna přesměrování, zatímco vlastní klient vývojáře je bez volby follow_redirects=True nenásledoval. Změna číslo 3397 přesunula rozhodování do transportu MCP. Nastavení follow_redirects na předaném klientovi už tato pravidla nerozšíří.

Původní hlavičky už necestují za cizí adresou

Při volném následování mohl server odpovědět hlavičkou Location s cizí adresou. Klient by na ni podle popisu změny poslal znovu hlavičky, přihlášení i tělo určené původnímu koncovému bodu a odpověď by považoval za odpověď serveru MCP. Autoři k tomu nepřiřadili CVE a poznámky nemluví o známém zneužití. Jde o zpřísnění výchozího chování a současně o nekompatibilní změnu pro služby, které záměrně přesměrovávají jinam.

Doporučení OWASP k ochraně před SSRF radí automatické následování přesměrování v HTTP klientovi vypnout, protože se jím dají obejít kontroly vstupní adresy. Python SDK volí méně přísnou variantu: běžné přesuny uvnitř jednoho serveru zachová, odchod na jiný původ zastaví.

Odmítnuté přesměrování ukončí konkrétní volání chybou MCPError; rozběhnutá relace zůstane použitelná. Výjimkou je počáteční připojení přes starší SSE, které skončí chybou HTTP. Pokud je cílová adresa skutečně správný server, vydání radí zadat ji rovnou jako koncový bod místo spoléhání na přesměrování.

OAuth musí poznat svého vydavatele

Druhá sada změn se týká autorizačních metadat. Klient už i na starší cestě bez metadat chráněného prostředku kontroluje pole issuer. Když v dokumentu stojí jiný vydavatel než původ očekávaný klientem, přihlášení skončí chybou OAuthFlowError. Návrh s kontrolou vydavatele se odvolává na oddíl 3.3 RFC 8414, podle kterého se neshodující metadata nesmějí použít.

Výpadek při načítání metadat se také přestal tvářit jako jejich nepřítomnost. Odpověď 429 nebo chyba řady 5xx nyní autorizační tok zastaví; klient už po ní nespadne na starší výchozí adresy. Poskytovatelé s předem přidělenými údaji dostali volitelný parametr issuer. Ve verzi 3.0 má být povinný.

Serverová strana umí nově zapnout validate_token_resource. Ověřovatel tokenu pak musí uvést, že token vznikl právě pro adresu tohoto serveru; token pro jiný prostředek nebo bez této vazby dostane odpověď 401. Implementace kontroly prostředku ji ve 2.2.0 ponechává vypnutou kvůli rozdílným identifikátorům u poskytovatelů identity. Nenastavená volba ale vyvolá varování a verze 3.0 ji má zapnout jako výchozí.

Opuštěná relace zmizí po půl hodině

Verze 2.2.0 mění i životní cyklus stavových relací staršího přenosu Streamable HTTP. Relace bez rozpracovaného požadavku se po 1 800 sekundách ukončí a další požadavek na její identifikátor dostane stav 404. Otevřený proud GET nebo dlouhé volání nástroje časovač zastaví, takže aktivní práce uprostřed běhu neskončí.

Jeden proces drží ve výchozím stavu nejvýš 10 000 relací. Další inicializaci odmítne stavem 503 a žádnou starší relaci kvůli ní nevyhodí. Smazání klientem uvolní místo okamžitě. Bezstavové servery a spojení podle revize protokolu z 28. července 2026 tento limit nepotřebují, protože relace neuchovávají.

Podobný problém řešila v srpnu Spring AI 2.0.1, ale s jinými výchozími hodnotami: 100 000 relací a vypnuté ukončování po nečinnosti. Python SDK nastavilo desetinu tohoto počtu a časovač zapnulo. Obě knihovny dovolují limit i čas změnit nebo vypnout; konkrétní nasazení si proto musí hodnoty srovnat s počtem klientů a dostupnou pamětí.

Povýšení může odkrýt skryté přesměrování

Správce serveru za reverzní proxy by měl po aktualizaci ověřit konečnou adresu, návratové kódy a protokol. Přesměrování z /mcp na /mcp/ na témže serveru projde. Přechod na jiného hostitele nebo nestandardní port už ne, i když dříve fungoval.

Testy, které převádějí varování na chyby, mohou spadnout i bez síťového problému. Stačí nenastavený issuer u strojového OAuth nebo chybějící rozhodnutí o validate_token_resource. Vydání 2.2.0 ještě zachovává staré chování těchto dvou voleb, ale žádá výslovnou volbu před řadou 3.0. Přechod proto není pouhá výměna čísla balíčku.

Zdroje

• MCP Python SDK 2.2.0 – datum vydání a souhrn změn chování
• Omezení přesměrování – přesná pravidla, chybové stavy a testy
• Kontrola vydavatele OAuth a vazba tokenu na prostředek
• Životní cyklus relací – výchozí čas a nejvyšší počet relací
• OWASP SSRF Prevention Cheat Sheet – nezávislé doporučení k přesměrováním HTTP