wersjonowanie specyfikacji MCP

Wersje specyfikacji MCP oznaczane datą (np. 2025-11-25, 2026-07-28) i uzgadniane podczas inicjalizacji połączenia. Kolejne rewizje wprowadzały zmiany niewsteczne, więc serwer napisany pod jedną wersję nie musi działać z klientem obsługującym inną. Od 2026-07-28 obowiązuje polityka deprecjacji z minimum dwunastomiesięcznym oknem.

W Polsce nazywane też:

wersje MCPzgodność wersjipolityka deprecjacji

Pytanie „czy ten serwer MCP zadziała z moim klientem” nie ma odpowiedzi bez wskazania wersji. Protokół zmienia się kilka razy w roku i nie wszystkie zmiany są wsteczne.

Jak oznaczane są wersje

Wersje specyfikacji noszą oznaczenia datowane, na przykład 2025-06-18, 2025-11-25 czy 2026-07-28. Wersja jest ustalana podczas inicjalizacji połączenia — klient i serwer uzgadniają, w jakim dialekcie rozmawiają.

Dlaczego to nie jest szczegół

Kolejne wersje wprowadzały zmiany istotne dla działania: elicitation i ustrukturyzowane wyjście narzędzi, usunięcie grupowania żądań, wymagany nagłówek wersji, klasyfikacja serwerów jako zasobów OAuth, a w ostatniej — bezstanowy rdzeń, framework rozszerzeń i deprecjacja części prymitywów.

Serwer napisany pod jedną wersję nie musi działać poprawnie z klientem obsługującym inną. Przy diagnozowaniu problemów z integracją wersja specyfikacji jest jedną z pierwszych rzeczy do sprawdzenia.

Polityka deprecjacji

Od specyfikacji 2026-07-28 obowiązuje formalna polityka deprecjacji z minimum dwunastomiesięcznym oknem. Element usunięty z zaleceń pozostaje w dokumencie przez ten czas, co pozwala planować migracje zamiast reagować na nie.

Praktyka

W dokumentacji własnego serwera warto podawać obsługiwaną wersję wprost, a przy każdej aktualizacji sprawdzać listę zmian — nie dlatego, że coś przestanie działać z dnia na dzień, ale dlatego, że zalecane podejście do danego problemu mogło się zmienić.