Anthropic, Simon Willison i zwrot ku bezstanowemu MCP

Anthropic wprowadził MCP w 2024 roku, lecz Simon Willison uznał później narzędzia terminalowe za bardziej elastyczne. Specyfikacja z 28 lipca 2026 roku częściowo odwróciła tę ocenę. Usuwa sesje protokołu i przekształca zdalne wywołania MCP w samodzielne żądania.

Ta zmiana ponownie wzbudziła zainteresowanie Willisona i zainspirowała dwa projekty: mcp-explorer oraz datasette-mcp. Co ważniejsze, uderza w architektoniczną słabość, przez którą zdalne serwery MCP były trudniejsze do wdrożenia niż zwykłe usługi HTTP.

Historia Anthropic i Simona Willisona nie jest więc kolejną aktualizacją protokołu. To sprawdzian, czy MCP może przestać konkurować z narzędziami wiersza poleceń i znaleźć bardziej uzasadnioną rolę. Skills pozostają atrakcyjne jako sposób uczenia agentów korzystania z istniejącego oprogramowania, podczas gdy bezstanowe MCP oferuje uporządkowane zdalne narzędzia, wykrywanie, autoryzację i współdzieloną infrastrukturę.

Bezstanowe MCP usuwa sesję z każdej ścieżki żądania

Nowa specyfikacja zmienia MCP z protokołu opartego na połączeniach w protokół oparty na żądaniach.

Model Context Protocol definiuje standardowy interfejs, za pośrednictwem którego agenci AI mogą wykrywać i wywoływać zewnętrzne narzędzia. Anthropic wprowadził go w listopadzie 2024 roku, a programiści szybko stworzyli serwery dla baz danych, przeglądarek, platform komunikacyjnych i aplikacji biznesowych.

Wcześniejsze wersje wymagały procesu inicjalizacji przed zwykłymi wywołaniami narzędzi. Klient i serwer wymieniały wersje protokołu, możliwości oraz informacje identyfikujące. Negocjacja ustanawiała kontekst, który kolejne wiadomości miały zachowywać.

Serwery HTTP mogły również wystawiać Mcp-Session-Id. Klienci zwracali następnie ten identyfikator w późniejszych żądaniach. Taki układ sprawiał, że sekwencja wywołań zachowywała się jak jedna ciągła rozmowa między konkretnym klientem a instancją serwera.

Projekt ten pociągał za sobą konsekwencje infrastrukturalne. Load balancer musiał kierować powiązane wywołania do właściwej instancji albo przechowywać dane sesji we współdzielonym magazynie. Operatorzy potrzebowali także zasad dotyczących wygasania, ponownego łączenia, odzyskiwania i czyszczenia.

Ostateczna wersja 2026-07-28 usuwa obowiązkowy handshake initialize. Usuwa również sesję na poziomie protokołu oraz powiązany z nią nagłówek. Każde żądanie zawiera teraz informacje potrzebne do jego niezależnej interpretacji.

Oficjalne wydanie MCP opisuje tę rewizję jako największą zmianę od uruchomienia protokołu. Do bezstanowego rdzenia dołączają rozszerzenia, zmieniona obsługa Tasks, zmiany w autoryzacji i formalny cykl życia funkcji.

Klient może teraz bezpośrednio wysłać wywołanie narzędzia. Żądanie zawiera wersję protokołu, metodę, nazwę narzędzia, informacje o kliencie i odpowiednie możliwości. Każda zgodna instancja serwera może je przetworzyć bez polegania na wcześniejszej wymianie.

Zmiana dodaje również server/discover, który pozwala klientom żądać możliwości serwera w razie potrzeby. Wykrywanie nie zmusza już każdego wywołującego do tworzenia i utrzymywania sesji protokołu.

To nie oznacza, że każda aplikacja musi porzucić stan. Usługa automatyzacji przeglądarki, koszyk zakupowy, transakcja bazodanowa czy przepływ pracy badawczej nadal mogą przechowywać informacje między wywołaniami.

Różnica polega na tym, gdzie te informacje się znajdują i jak są adresowane. Zamiast ukrywać je za sesją, serwer może zwrócić jawny identyfikator. Model przekazuje ten identyfikator podczas kolejnych wywołań.

Serwer przeglądarki może zwrócić browser_id po uruchomieniu instancji. Późniejsze narzędzia mogą przyjmować tę wartość podczas nawigowania, przechwytywania strony lub zamykania przeglądarki. Narzędzie bazodanowe może zastosować ten sam wzorzec do identyfikatora transakcji.

Przyjęta propozycja bezsesyjna opisuje te wartości jako jawne uchwyty stanu. Nie są one nowym typem danych MCP. To zwykłe wejścia i wyjścia narzędzi, które uwidaczniają stan aplikacji.

Ta widoczność ma znaczenie dla agentów. Orkiestrator może udostępnić jeden uchwyt podagentowi, jednocześnie izolując inny. Może również zapisać identyfikator do późniejszej pracy lub przekazać go innemu upoważnionemu procesowi.

Operacje listowania zyskują osobną korzyść. Gdy narzędzia i zasoby nie mogą już zmieniać się zgodnie z niejednoznaczną sesją, klienci mogą bezpieczniej buforować wyniki wykrywania. Ogranicza to powtarzane wywołania między krótkotrwałymi agentami.

Bezstanowe MCP lepiej pasuje również do znanych operacji HTTP. Zdalne serwery mogą korzystać ze standardowego równoważenia round-robin, zwykłego routingu przez bramę, uwierzytelniania dla każdego żądania i sprawdzonych systemów obserwowalności.

To połączenie ponownie przyciągnęło uwagę Willisona. Aktualizacja nie tylko skraca handshake. Usuwa architektoniczne zobowiązanie, które wcześniej przenikało każde wdrożenie i każdą implementację klienta.

Dlaczego zwrot Anthropic i Simona Willisona ma znaczenie

Ponowne zainteresowanie Willisona ma znaczenie, ponieważ jego wcześniejsza krytyka uchwyciła rzeczywiste odchodzenie użytkowników agentów programistycznych od MCP.

MCP przyciągał ogromną uwagę przez większą część 2025 roku. Jego propozycję wartości łatwo było zrozumieć: wdrożyć jeden interfejs serwera, a następnie udostępnić te same narzędzia kilku zgodnym klientom AI.

Jednocześnie agenci programistyczni się rozwijali. Zyskali niezawodny dostęp do terminala, lepsze wykorzystanie powłoki i większą zdolność analizowania dokumentacji. Wielu z nich potrafiło zainstalować bibliotekę lub wywołać konwencjonalne API za pomocą curl.

Stworzyło to bezpośrednie wyzwanie. Dobrze udokumentowany program wiersza poleceń już zapewnia kompozycyjny interfejs narzędziowy. Agent może łączyć polecenia, przekierowywać dane wyjściowe, pisać małe skrypty i analizować błędy bez adaptera protokołu.

Skills wzmocniły tę ścieżkę. Skill to pakiet instrukcji, skryptów i materiałów referencyjnych, który uczy agenta wykonywania zadania. Może objaśniać istniejące API, nie wymagając od jego właściciela prowadzenia serwera MCP.

Willison podsumował swój sceptycyzm w przeglądzie roku 2025. W przypadku agentów programistycznych preferował narzędzia wiersza poleceń i biblioteki zamiast MCP. Opcje te dawały modelowi większą swobodę, unikając jednocześnie kolejnej warstwy usługowej.

Krytyka nigdy nie polegała na twierdzeniu, że uporządkowane wywołania narzędzi nie mają wartości. Trudniejsze pytanie dotyczyło tego, czy MCP zapewnia wystarczającą dodatkową wartość, by uzasadnić sesje, zarządzanie transportem, pracę nad zgodnością klientów i narzut kontekstowy.

Bezstanowe MCP zmniejsza tę lukę. Niewielkie zdalne narzędzie może teraz zachowywać się bardziej jak konwencjonalny endpoint webowy, zachowując jednocześnie kontrakt czytelny maszynowo dla klientów agentowych.

Analiza bezstanowego MCP Willisona łączy tę zmianę z dwoma eksperymentami. Pierwszy to mcp-explorer, którego celem jest ułatwienie analizowania i rozumienia serwerów MCP. Drugi to datasette-mcp, który stosuje nowe podejście do Datasette.

Datasette to open-source'owy system Willisona do eksplorowania i publikowania uporządkowanych danych. Już udostępnia bazy danych za pośrednictwem interfejsów webowych i API. MCP oferuje kolejną warstwę zaprojektowaną specjalnie dla modeli językowych korzystających z narzędzi.

To zestawienie jest pouczające. Wdrożenie Datasette jest z natury zdalne, uporządkowane i współdzielone przez użytkowników. Nie pasuje tak naturalnie do lokalnego modelu wiersza poleceń jak narzędzie programistyczne zainstalowane obok agenta.

Serwer MCP może reklamować narzędzia bazodanowe za pomocą schematów rozumianych przez klientów. Agenci mogą sprawdzać dostępne operacje przed wysłaniem zapytań. Operatorzy serwera zachowują kontrolę nad uwierzytelnianiem, uprawnieniami, limitami i szczegółami implementacji.

To sprawia, że porównanie Anthropic i Simona jest bardziej zniuansowane niż MCP kontra Skills. Skill może nauczyć agenta, jak wysyłać zapytania do API. MCP może zapewnić wielu klientom współdzielony kontrakt do wykrywania i wywoływania tego API.

Oba podejścia mogą też działać razem. Skill może opisywać, kiedy korzystać z serwera MCP, wyjaśniać jego pojęcia domenowe lub dostarczać przepływ pracy obejmujący kilka narzędzi. MCP może obsługiwać granicę zdalnego wykonania.

Ten podział zmniejsza presję, by MCP stał się uniwersalną odpowiedzią na każde działanie agenta. Lokalne polecenia mogą pozostać lokalne. Biblioteki mogą obsługiwać elastyczne zadania programistyczne. Skills mogą pakować wiedzę operacyjną.

MCP zyskuje wyraźniejszą rolę tam, gdzie serwer kontroluje wykonanie, a wielu klientów potrzebuje tego samego wykrywalnego interfejsu. Dane przedsiębiorstw, hostowane wyszukiwanie, współdzielone usługi i uwierzytelnione systemy biznesowe pasują do tego wzorca.

Prostota protokołu zmienia więc pytanie dotyczące konkurencji. Programiści nie muszą już pytać, czy każde narzędzie zasługuje na wrapper MCP. Mogą zapytać, czy zdalna funkcjonalność korzysta na standaryzowanym wykrywaniu i wywoływaniu.

To mniejsza obietnica niż najszersze wczesne interpretacje MCP. Jest też bardziej wiarygodna. Standardy często stają się użyteczne, gdy ich granice stają się wyraźniejsze.

Bezstanowe żądania sprawiają, że MCP pasuje do zwykłej infrastruktury chmurowej

MCP 2.0 ma znaczenie, ponieważ usuwa wyspecjalizowaną koordynację z typowej ścieżki wdrożenia.

Przyjęta propozycja bezstanowego MCP wskazuje trzy problemy starego modelu inicjalizacji. Sesje komplikowały skalowanie, osłabiały odzyskiwanie po awariach i zwiększały nakład implementacyjny po obu stronach.

Rozważmy zdalne narzędzie wyszukiwania działające na trzech instancjach serwera. W projekcie zorientowanym na sesję późniejsze wywołania mogły wymagać tej samej instancji, która przetworzyła inicjalizację. Podstawowy load balancer round-robin nie może zagwarantować takiego wyniku.

Operatorzy mogą rozwiązać ten problem za pomocą sticky routing. Mogą również przechowywać dane sesji we współdzielonej usłudze. Oba podejścia wprowadzają stan operacyjny, dodatkowe tryby awarii i nowe wymagania dotyczące monitorowania.

Sticky sessions mogą nierównomiernie rozdzielać pracę. Współdzielone magazyny tworzą kolejną zależność. Ponowne uruchomienia serwera mogą unieważnić stan lokalny, a klienci muszą wykrywać awarie i powtarzać inicjalizację.

W nowym modelu żądań każda sprawna instancja może przetworzyć zgodne wywołanie narzędzia. Brama może kierować ruch według metody i metadanych narzędzia, a nie historii połączenia.

Ta zmiana sprawia też, że wdrożenia serverless stają się bardziej prawdopodobne. Platformy, które uruchamiają i zatrzymują instancje zależnie od zapotrzebowania, działają najlepiej, gdy żądania nie zależą od pamięci pozostawionej przez wcześniejsze żądanie.

Serwer nadal potrzebuje trwałego magazynu dla rzeczywiście trwałego stanu aplikacji. Bezstanowe MCP nie eliminuje baz danych, magazynów obiektów, workerów przeglądarki ani kolejek zadań. Usuwa założenie, że stan protokołu musi im towarzyszyć.

Długotrwałe operacje znajdują się teraz w modelu opartym na rozszerzeniach. Serwer może zwrócić uchwyt zadania, a klient później sprawdzać, aktualizować lub anulować to zadanie za pomocą jawnych operacji.

Rozróżnienie jest istotne. Ukryty stan sesji wiąże przepływ pracy z relacją transportową. Uchwyt zadania przekształca ten przepływ w adresowalny zasób, którym mogą zarządzać inne upoważnione komponenty.

Multi Round-Trip Requests rozwiązują inny trudny przypadek. Niektóre narzędzia potrzebują więcej informacji od użytkownika lub klienta przed ukończeniem działania. Wcześniejsze implementacje wiązały tę wymianę z ustanowioną sesją.

Nowy projekt pozwala na żądanie inicjowane przez serwer tylko wtedy, gdy przetwarza on żądanie klienta. Dane korelacyjne przemieszczają się w cyklu żądania i odpowiedzi, bez tworzenia trwałej sesji protokołu.

Ogranicza to pewne zachowania. Serwer nie może niespodziewanie skontaktować się z klientem długo po wywołaniu inicjującym. Ten limit zmniejsza elastyczność, ale daje komunikatom dla użytkownika wyraźniejsze źródło i cykl życia.

Odkrywanie narzędzi również staje się łatwiejsze do trasowania i buforowania. Specyfikacja dodaje metadane metod i narzędzi do nagłówków HTTP. Bramy mogą sprawdzać te metadane bez analizowania treści każdego żądania.

Serwery mogą dołączać wartość czasu życia do odpowiedzi listujących. Klienci mogą wtedy ponownie wykorzystywać informacje o narzędziach w dozwolonym okresie, zamiast żądać tej samej listy dla każdego krótkotrwałego subagenta.

Propozycja bezsesyjna ostrzega, że wcześniejsze zachowanie mogło generować powtarzający się ruch związany z odkrywaniem, proporcjonalny do liczby subagentów pomnożonej przez liczbę serwerów. Bezstanowe listy dają orkiestratorom lepszą podstawę do uniknięcia tego kosztu.

Ma to znaczenie, gdy systemy agentowe stają się bardziej rozproszone. Jedno żądanie użytkownika może uruchomić planistę, kilku wyspecjalizowanych wykonawców i weryfikatora. Powtarzanie inicjalizacji i odkrywania dla każdej gałęzi zwiększa opóźnienia i ruch.

Zmieniony protokół przyjmuje również pełny JSON Schema 2020-12 dla definicji narzędzi. JSON Schema to standardowy słownik do opisywania danych strukturalnych, w tym wymaganych pól, typów i reguł walidacji.

Bogatsze schematy mogą opisywać bardziej precyzyjne dane wejściowe i wyjściowe. Daje to klientom lepsze informacje do walidowania wywołań i tworzenia interfejsów. Zmniejsza także zależność od luźno napisanych opisów narzędzi.

Rozszerzenia zapewniają kolejną formę rozdzielenia architektonicznego. MCP Apps mogą udostępniać interfejsy renderowane po stronie serwera, podczas gdy Tasks obsługują dłuższe operacje. Funkcje te mogą ewoluować bez wymuszania umieszczania każdej możliwości w rdzeniu protokołu.

Formalny cykl życia zapewnia co najmniej 12 miesięcy między wycofaniem funkcji a najwcześniejszym możliwym jej usunięciem. Nie eliminuje to prac migracyjnych, ale po tym zdecydowanym zerwaniu daje implementatorom wyraźniejsze okno planowania.

Oficjalne wytyczne TypeScript pokazują, że migracja nadal wymaga świadomej pracy. Przewodnik migracji SDK wskazuje, że nowy format transmisji wymaga jawnego wdrożenia, zamiast po cichu zmieniać każdą istniejącą aplikację.

Ta ostrożność jest uzasadniona. Nowa specyfikacja nie może sama publikacją zapewnić interoperacyjności. Klienci, serwery, bramy i SDK muszą implementować te same szczegóły oraz testować je na rzeczywistych obciążeniach.

Mimo to mechanizm ten rozwiązuje konkretną słabość. Zastępuje charakterystyczną dla MCP obsługę sesji wzorcami, których zespoły chmurowe używają już w zwykłych usługach HTTP.

Jawny stan rodzi nowe pytania dotyczące bezpieczeństwa i niezawodności

Bezstanowy MCP usuwa bariery infrastrukturalne, ale przenosi większą odpowiedzialność na projektowanie narzędzi, autoryzację i pamięć agenta.

Jawne uchwyty czynią stan widocznym i przenośnym. Te korzyści poszerzają też miejsca, w których mogą pojawić się wrażliwe identyfikatory. Uchwyt może trafić do historii czatu, promptów, logów, śladów, zawartości schowka lub wiadomości subagentów.

Serwer nie może traktować znajomości identyfikatora jako wystarczającej autoryzacji. Powinien przy każdym wywołaniu walidować zarówno uchwyt, jak i uwierzytelnioną tożsamość.

Przypomina to projekt stosowany przez wiele usług dokumentowych i projektowych. Identyfikator zasobu wskazuje obiekt, a bieżący kontekst autoryzacji określa, czy wywołujący może go odczytać lub zmienić.

Usługi nieuwierzytelnione mają trudniejszy problem. W takim środowisku nieprzewidywalny uchwyt może działać jak token typu bearer. Każdy, kto go uzyska, może uzyskać dostęp do bazowego stanu, dopóki uchwyt nie wygaśnie.

Specyfikacja bezsesyjna zaleca w takich przypadkach identyfikatory o wysokiej entropii i ograniczonym czasie życia. To zalecenie pozostaje wskazówką implementacyjną, ponieważ MCP nie definiuje typu uchwytu na poziomie transmisji.

Tworzy to lukę egzekwowania zasad. Klienci nie mogą automatycznie rozpoznać, które zwracane ciągi reprezentują aktywny stan. browser_id wygląda jak każda inna wartość, chyba że nazwy i opisy narzędzi komunikują jego rolę.

Orkiestrator nie zawsze może więc wiedzieć, które identyfikatory muszą przetrwać kompresję kontekstu. Może też mieć trudności z określeniem, które wartości wymagają wyczyszczenia lub nigdy nie powinny trafić do innego subagenta.

Modele rutynowo przenoszą ścieżki plików, hashe commitów, adresy URL i identyfikatory transakcji. Nadal mogą jednak nieprawidłowo skopiować uchwyt, pominąć go lub utracić, gdy długa rozmowa zostanie podsumowana.

Stan sesji miał podobne słabości. Klienci stosowali niespójne czasy życia, a wielu z nich nie przywracało sesji po rozłączeniu. Usunięcie sesji uwidacznia te problemy, ale nie automatyzuje zarządzania stanem.

Czyszczenie zasobów stanowi kolejny nierozstrzygnięty szczegół. Zakończenie sesji kiedyś oferowało teoretyczny sygnał do zwalniania zasobów. W praktyce klienci często kończyli sesje zbyt często, zbyt rzadko albo po niepowiązanym odświeżeniu strony.

Jawne przepływy pracy potrzebują własnych zasad wygasania i niszczenia. Usługa przeglądarki może oferować close_browser, jednocześnie wymuszając limit bezczynności. Usługa zadań może przechowywać ukończone wyniki przez zdefiniowany okres.

Zgodność wsteczna zwiększa złożoność operacyjną podczas wdrażania. Istniejące serwery zależne od identyfikatorów sesji nie mogą po prostu zaakceptować nowej rewizji protokołu bez zmiany swojego modelu stanu.

Klienci i SDK mogą w razie potrzeby negocjować starszą rewizję. Pozwala to na stopniową migrację, ale tworzy też dwie ścieżki zachowania, które deweloperzy muszą testować.

Niektóre możliwości stają się mniej bezpośrednie w bezstanowym HTTP. Nieproszone powiadomienia i długotrwałe interakcje inicjowane przez serwer nie pasują tak naturalnie do niezależnych żądań. Rozszerzenia i mechanizmy nasłuchiwania muszą przejąć tę pracę.

Nie ma też gwarancji, że każda integracja MCP stanie się wydajna tylko dlatego, że sesje znikną. Źle zaprojektowane schematy mogą zużywać kontekst. Duże katalogi narzędzi mogą dezorientować modele. Niejasne opisy nadal mogą wywoływać nieprawidłowe wywołania.

Skills i narzędzia wiersza poleceń zachowują tu swoje zalety. Agent programistyczny często może sprawdzić wynik pomocy programu i napisać krótki skrypt bez ładowania dużego zdalnego katalogu narzędzi.

Lokalne narzędzia mogą również przechowywać wrażliwe dane na komputerze użytkownika. Zdalne wdrożenie MCP wprowadza kwestie uwierzytelniania, ekspozycji sieciowej, logowania i dostępności usługi, których lokalne wykonanie pozwala uniknąć.

MCP nie rozwiązuje też problemu prompt injection. Agent z dostępem do narzędzi może łączyć prywatne informacje, niezaufane dane wejściowe i zewnętrzną komunikację niezależnie od tego, czy transport jest stanowy.

Operatorzy serwerów muszą ograniczać uprawnienia i dane wyjściowe. Twórcy agentów muszą kontrolować, które narzędzia pojawiają się razem. Użytkownicy potrzebują jasnych granic zatwierdzania dla działań o istotnych konsekwencjach.

Ograniczenia te podważają najsilniejszą interpretację zwrotu Anthropic Simon. Odnowione zainteresowanie Willisonem potwierdza zmianę architektury, a nie każdą implementację MCP ani każdy proponowany serwer.

mcp-explorer i datasette-mcp są użytecznymi wczesnymi eksperymentami, ponieważ ujawniają praktyczne pytania. Czy klienci mogą konsekwentnie odkrywać narzędzia? Czy schematy są zrozumiałe? Czy uwierzytelnianie i uchwyty stanu przetrwają rzeczywiste przepływy pracy?

Najmocniejszy argument za bezstanowym MCP będzie wynikał z dowodów interoperacyjności. Niezależni klienci powinni łączyć się z niezależnymi serwerami bez niestandardowych poprawek, a operatorzy powinni wdrażać je przy użyciu zwykłej infrastruktury.

Dopóki takich dowodów nie przybędzie, MCP 2.0 pozostaje lepszym fundamentem, a nie ukończonym zwycięstwem. Protokół usunął jedno istotne źródło tarcia. To implementatorzy nadal decydują, czy powstałe systemy pozostaną bezpieczne i zrozumiałe.

Co deweloperzy powinni obserwować po MCP 2.0

Kolejnym testem jest wdrożenie w SDK, rzeczywistych serwerach i klientach, a nie kolejny wzrost liczby repozytoriów.

Pierwszym sygnałem jest zakres implementacji rewizji 2026-07-28. Oficjalne SDK potrzebują spójnej obsługi odkrywania, metadanych dla każdego żądania, jawnych możliwości, Tasks i zachowania autoryzacji.

Same etykiety wersji nie wystarczą. Deweloperzy powinni obserwować wyniki zgodności i testy międzyjęzykowe. Serwer Python, klient TypeScript i zarządzana brama powinny zgadzać się co do tych samych żądań i błędów.

Silna kompatybilność między SDK wzmocniłaby tezę, że MCP oferuje teraz stabilną granicę dla zdalnych narzędzi. Utrzymujące się niezgodności osłabiłyby ją, odsyłając deweloperów z powrotem do adapterów specyficznych dla klientów.

Drugim sygnałem jest sposób, w jaki serwery produkcyjne migrują przepływy pracy oparte na stanie. Automatyzacja przeglądarki, transakcje, koszyki zakupowe i długotrwałe zadania badawcze stanowią wymagające testy dla jawnych uchwytów.

Udane migracje powinny wykazać niezawodne czyszczenie, autoryzację dla każdego żądania, przekazywanie uchwytów i kompresję kontekstu. Powinny również dokumentować, co dzieje się, gdy agent utraci lub powtórzy identyfikator.

Jeśli te wzorce staną się wielokrotnego użytku, jawny stan będzie wyglądał na lepszą abstrakcję niż niejednoznaczne sesje. Jeśli każdy serwer wymyśli niekompatybilne reguły cyklu życia, protokół jedynie przeniesie złożoność, zamiast ją zmniejszyć.

Trzecim sygnałem jest relacja między MCP a Skills. Platformy agentowe powinny pokazywać, kiedy wybierają lokalne polecenie, wywołanie API prowadzone przez skill czy zdalny serwer MCP.

Jasne zasady wyboru wzmocniłyby węższą tezę. MCP obsługiwałby współdzielone zdalne możliwości, podczas gdy Skills pakowałyby instrukcje i lokalne przepływy pracy.

Utrzymujące się nakładanie się funkcji mogłoby tworzyć zduplikowane utrzymanie. Właściciele narzędzi mogliby potrzebować API, CLI, pakietu skill, serwera MCP i integracji specyficznej dla klienta dla tej samej możliwości.

Deweloperzy powinni opierać się traktowaniu tej duplikacji jako nieuniknionej. Skill może odwoływać się do serwera MCP, a serwer MCP może opakowywać istniejące API. Użyteczne pytanie brzmi: który interfejs jest właścicielem trwałego kontraktu.

W przypadku narzędzi danych eksperymenty Willison zapewniają konkretne miejsce do obserwacji. Datasette już udostępnia ustrukturyzowane informacje przez web API. datasette-mcp może sprawdzić, czy kontrakt skoncentrowany na agencie poprawia odkrywanie i bezpieczne wykonywanie zapytań.

Zespoły budujące przepływy pracy oparte na wiedzy stoją przed podobnym wyborem. Lokalne dokumenty i notatki często należą do prywatnej, przeszukiwalnej bazy wiedzy inżynierskiej. Współdzielone systemy biznesowe mogą lepiej pasować do uwierzytelnionych zdalnych narzędzi.

Kluczowe jest unikanie przyznawania jednemu agentowi nieograniczonego zbioru narzędzi tylko dlatego, że wspólny protokół ułatwia połączenie. Standaryzacja zmniejsza pracę integracyjną, ale nie zastępuje projektowania uprawnień.

Zwrot Anthropic Simon Willison jest wartościowy, ponieważ następuje po okresie autentycznego sceptycyzmu. MCP nie odzyskało uwagi dzięki brandingowi. Jego opiekunowie usunęli strukturalne obciążenie, na które krytycy mogli wskazywać w wdrożonych systemach.

Tak powinien ewoluować protokół. Powinien uwzględniać dowody wynikające z błędnych założeń, zawężać zakres odpowiedzialności i ułatwiać rozumowanie o typowych operacjach.

W ciągu najbliższych trzech miesięcy przeanalizuj klientów i serwery, których faktycznie używasz. Sprawdź, czy obsługują końcową rewizję, jak reprezentują stan aplikacji oraz czy ich autoryzacja jest stosowana do każdego uchwytu.

Następnie porównaj wynik z najprostszą alternatywą. Jeśli lokalne polecenie pozostaje bardziej przejrzyste, zachowaj je. Jeśli wiele agentów potrzebuje jednej zarządzanej zdalnej możliwości, przetestuj bezstanowy MCP i zapisuj miejsca, w których interoperacyjność nadal zawodzi.