Przeciążenie obowiązków MCP
Jedną z powszechnych krytyk jest obarczanie MCP zbyt dużą odpowiedzialnością. Autor argumentuje, że MCP powinien służyć przede wszystkim jako brama dla LLM (Large Language Models) do uzyskiwania dostępu i interakcji z zewnętrznymi zasobami. Postrzeganie go jedynie jako ‘drzwi’ lub ‘mostu’ pomaga wyjaśnić jego cel i ograniczenia.
Przypisywanie problemów, takich jak przypadkowe ujawnienie danych, podatności na prompt injection i niedociągnięcia w kontroli kosztów bezpośrednio MCP, jest błędem. Są to problemy, którymi deweloperzy powinni się zająć w granicach, które kontrolują. Deweloperzy muszą wdrażać limity szybkości i monitorować wykorzystanie, niezależnie od używanego protokołu. Porównanie tego do obwiniania drogi za przekroczenie prędkości jest trafne – infrastruktura nie jest odpowiedzialna za indywidualne zachowanie.
Ostatecznie wiele podniesionych obaw to szersze kwestie związane z delegowaniem zadań agentom AI. Deweloperzy muszą wziąć odpowiedzialność za zarządzanie tymi wyzwaniami w swoich konkretnych aplikacjach, zamiast oczekiwać, że sam API wszystko załatwi.
Obosieczny miecz LLM i prompt injection
Ostatnie dyskusje na temat MCP często przypominają ostrzeżenia o niebezpieczeństwach związanych z ostrymi nożami – mogą ciąć, jeśli są źle używane. Prompt injection, poważna obawa, jest konsekwencją natury samych LLM. Próby wyeliminowania ryzyka prompt injection grożą obniżeniem zdolności, które czynią LLM wartościowymi.
Pojęcie oddzielenia ‘kontroli od danych’, powszechne w tradycyjnych systemach, nie istnieje naturalnie w LLM. LLM zyskują swoją moc i ogólność właśnie dlatego, że brakuje im tego sztywnego oddzielenia. Ta inherentna cecha czyni je podatnymi na ataki prompt injection.
Chociaż zdalne MCP jako usługa mogą stwarzać zagrożenia, wina leży nie w samym protokole, ale w powierzaniu wrażliwych zadań niezaufanym stronom trzecim. Ta analogia rozciąga się na pomysł przyklejenia noża do nieprzewidywalnego Roomba – problemem nie jest sam nóż, ale decyzja o przymocowaniu go do nieprzewidywalnego urządzenia.
Upomnienia, aby ‘być ostrożnym’ lub sugestie dotyczące odzieży ochronnej, choć technicznie dokładne, pomijają sedno sprawy: nieroztropną decyzję o połączeniu ostrego narzędzia z niekontrolowanym systemem.
Wyzwania związane ze skalowalnością
Oprócz kwestii bezpieczeństwa, MCP stoi przed fundamentalnymi ograniczeniami skalowalności. Autor podkreśla negatywną korelację między niezawodnością LLM a ilością dostarczonego kontekstu instrukcyjnego. To podważa powszechne przekonanie, że dodanie większej ilości danych i integracji automatycznie rozwiąże problemy. Wraz ze wzrostem liczby narzędzi i integracji, wydajność agenta może się pogorszyć, jednocześnie zwiększając koszt każdego żądania.
Autor podkreśla, że MCP nie skaluje się poza pewien próg. Próba dodania nieograniczonej liczby narzędzi do kontekstu agenta nieuchronnie negatywnie wpłynie na jego możliwości. To ograniczenie jest inherentne w koncepcji MCP i wymaga więcej uwagi niż kwestie uwierzytelniania.
Użytkownicy mogą ostatecznie doświadczyć spadku wydajności, gdy włączą więcej serwerów MCP, co doprowadzi do zakłóceń między nimi. To stoi w jaskrawym kontraście z typowymi systemami zarządzania pakietami, gdzie brak interferencji jest fundamentalną właściwością.
Istotą problemu z MCP jest to, że jego rzeczywiste zachowanie odbiega od oczekiwań użytkowników. Należy pamiętać, że MCP nie jest rozwiązaniem typu plug-and-play, które bezproblemowo integruje nieograniczoną liczbę narzędzi bez konsekwencji.
Rozwiązywanie ograniczeń za pomocą interfejsu użytkownika i zarządzania narzędziami
Jednym z proponowanych rozwiązań ograniczeń MCP jest ulepszenie interfejsu użytkownika. Jeśli narzędzie zostanie uruchomione nieumyślnie, interfejs użytkownika powinien zapewnić łatwy sposób na jego wyłączenie lub zmodyfikowanie jego opisu, aby wyjaśnić jego zamierzone użycie.
Autor zauważa również, że wzrost kontekstu często prowadzi do poprawy wydajności i zdolności użytkowych w świecie rzeczywistym, co przeczy pojęciu ściśle negatywnej korelacji. Uznaje jednak, że w niektórych przypadkach użycia lub przy źle zaprojektowanych kontekstach może dojść do pogorszenia wydajności.
Aby rozwiązać problem przytłaczającego wyboru narzędzi, sugerowane jest podejście ‘dziel i rządź’. Obejmuje to dodanie narzędzia zaprojektowanego specjalnie do wybierania najbardziej odpowiednich narzędzi dla danego zadania. To ‘narzędzie do wyboru narzędzi’ mogłoby być kolejnym wywołaniem LLM, którego zadaniem byłoby zwrócenie podzbioru dostępnych narzędzi do ‘nadrzędnego’ agenta. To warstwowe podejście dodaje dodatkowe poziomy pośredniości w celu zarządzania złożonością.
Jednak samo posiadanie narzędzi w kontekście może znacząco zmienić wynik modelu. Chociaż narzędzia kontekstowo odpowiednie (osiągnięte dzięki technikom takim jak Retrieval-Augmented Generation lub RAG) są korzystne, ukrywanie wszystkich narzędzi za żądaniem ‘get_tools’ może być szkodliwe.
MCP jako warstwa transportu i autoryzacji
MCP pełni przede wszystkim funkcję transportu i formatu przewodowego z cyklem życia żądanie/odpowiedź, koncentrując się na autoryzacji na poziomie narzędzia. Artykuł argumentuje, że największym problemem z MCP jest brak możliwości funkcjonalnego komponowania narzędzi przez agentów AI.
Autor stawia hipotezę, że MCP może być w ogóle niepotrzebny, ponieważ LLM posiadają już zdolność interakcji z API udokumentowanymi przy użyciu specyfikacji OpenAPI. Brakującym elementem jest autoryzacja – możliwość kontrolowania, do których API może mieć dostęp AI. Zamiast MCP, autor sugeruje umożliwienie AI wykonywania żądań HTTP przy jednoczesnym stosowaniu autoryzacji do określonych punktów końcowych. To podejście jest zgodne z obecnym trendem owijania istniejących API cienkimi narzędziami MCP.
Szczególnie irytującym aspektem MCP jest brak obsługi przesyłania strumieniowego wyników wywołań narzędzi. Pojedyncza para żądanie/odpowiedź zmusza klientów do wielokrotnego wywoływania narzędzi w celu paginacji, utrudniając długotrwałe procesy. Wdrożenie możliwości przesyłania strumieniowego, być może przy użyciu gRPC, mogłoby znacząco poprawić wydajność MCP.
Łatwość ujawniania wrażliwych danych
Poważnym problemem związanym z MCP jest potencjalna łatwość ujawniania wrażliwych danych. Ponadto MCP nie czyni inherentnie agentów AI bardziej niezawodnymi; po prostu daje im dostęp do większej liczby narzędzi, co paradoksalnie może zmniejszyć niezawodność w niektórych sytuacjach.
Autor przyznaje, że nie oczekuje, że MCP rozwiąże wszystkie te problemy lub będzie za nie odpowiedzialny. Raczej MCP tworzy większą powierzchnię narażenia na te problemy, wymagając od twórców aplikacji i użytkowników czujności.
Analogie i urbanistyka
Autor używa analogii do urbanistyki, aby zilustrować problem. Porównanie MCP do sześciopasmowej drogi miejskiej z ograniczeniem prędkości do 25 mil na godzinę podkreśla rozbieżność między projektem a zamierzonym użyciem. Samo nakładanie grzywien lub dodawanie powierzchownych ‘poprawek’ nie rozwiązuje podstawowego problemu złego projektu.
Skuteczne planowanie urbanistyczne obejmuje projektowanie dróg, które naturalnie zachęcają do przestrzegania ograniczeń prędkości. Podobnie, MCP powinien być zaprojektowany tak, aby inherentnie łagodzić potencjalne ryzyko, zamiast polegać wyłącznie na zewnętrznych kontrolach.
Podejmowanie niechcianych działań przez LLM
Artykuł przechodzi do szerszej krytyki protokołów, które umożliwiają LLM wykonywanie działań na usługach. Autor identyfikuje podstawowy problem: LLM mogą podejmować działania, których użytkownicy nie zamierzają podejmować. Rozróżnia działania, które LLM mogą podejmować niezależnie, oraz te, które wymagają monitowania użytkownika.
Chociaż ostatecznym celem może być zarządzanie całymi firmami przez LLM, technologia nie jest jeszcze gotowa na taką autonomię. Obecnie użytkownicy mogą nawet nie chcieć, aby AI wysyłała e-maile bez wcześniejszej weryfikacji.
Autor odrzuca rozwiązanie polegające na monitowaniu użytkownika o potwierdzenie, powołując się na ryzyko, że użytkownicy wpadną w wzorzec automatycznego potwierdzania (‘tryb YOLO’), gdy większość narzędzi wydaje się nieszkodliwa. Jest to porównywalne do psychologicznego zjawiska, w którym ludzie wydają więcej kartami niż gotówką – problem zakorzeniony w ludzkim zachowaniu, a nie w technologii.
Podstawowe pytanie: dlaczego po prostu nie używać API?
Powracającym pytaniem w dyskusjach na temat MCP jest, dlaczego po prostu nie używać API bezpośrednio.
MCP umożliwia klientom LLM, których użytkownicy nie kontrolują bezpośrednio (np. Claude, ChatGPT, Cursor, VSCode), interakcję z API. Bez MCP programiści musieliby budować niestandardowych klientów za pomocą API LLM, co jest znacznie droższym przedsięwzięciem niż korzystanie z istniejących klientów z subskrypcją i uczenie ich, jak korzystać z określonych narzędzi.
Jeden z programistów dzieli się swoim doświadczeniem budowania serwera MCP do połączenia się z syntezatorem sprzętowym FM przez USB, umożliwiając projektowanie dźwięku oparte na sztucznej inteligencji.
Integracja klienta LLM i standaryzacja
Podstawowym problemem jest to, że nie wszyscy klienci LLM natywnie obsługują bezpośrednią interakcję z API, przy czym akcje niestandardowe ChatGPT są godnym uwagi wyjątkiem. Anthropic, Google i OpenAI zgodziły się przyjąć MCP jako wspólny protokół, aby usprawnić proces dla klientów opartych na LLM, takich jak Claude, ChatGPT i Cursor.
MCP upraszcza proces dla tych, którzy budują klientów LLM. Jeśli chcesz, aby LLM wchodził w interakcje z API, nie możesz po prostu podać klucza API i oczekiwać, że zadziała – musisz stworzyć Agenta.
MCP można postrzegać jako sposób na dokumentowanie API i opisywanie sposobu ich wywoływania, wraz ze standardowymi narzędziami do udostępniania tej dokumentacji i ułatwiania wywołań. Zapewnia wystarczającą abstrakcję, aby otoczyć API bez zbędnych komplikacji, ale ta prostota może również prowadzić do tego, że użytkownicy ‘strzelą sobie w stopę’.
Wydajność i możliwość ponownego wykorzystania MCP
Bez MCP programiści musieliby wielokrotnie wyjaśniać LLM, jak korzystać z narzędzia za każdym razem, gdy jest ono wywoływane. Wiąże się to z ryzykiem, że LLM nie użyje narzędzia poprawnie z powodu zapomnianych informacji lub niestandardowego zachowania API.
To ciągłe wyjaśnianie i duplikowanie marnuje tokeny w kontekście, zwiększając koszty i czas. MCP usprawnia ten proces, łącząc wszystkie niezbędne informacje, dzięki czemu korzystanie z narzędzi jest bardziej wydajne i ułatwia udostępnianie narzędzi.
Informując dostawcę LLM ‘oto narzędzie, którego możesz użyć’ wraz z dokumentacją API, użytkownicy mogą ponownie wykorzystać to narzędzie w wielu czatach bez powtarzających się przypomnień. Umożliwia to również klientom LLM na komputery stacjonarne łączenie się z programami działającymi lokalnie, rozwiązując problem procesów wykonywania specyficznych dla systemu operacyjnego.
MCP i dostęp do zasobów lokalnych
MCP ułatwia dostęp do zasobów lokalnych, takich jak pliki, zmienne środowiskowe i dostęp do sieci dla LLM. Jest przeznaczony do uruchamiania lokalnie, zapewniając LLM kontrolowany dostęp do tych zasobów.
Standardowy ‘kształt’ wywołania narzędzia LLM ściśle odzwierciedla ‘kształt’ wywołania narzędzia MCP, co czyni go prostym standardem łączenia narzędzi z agentami.
MCP działa jako pomost między schematem wywoływania funkcji udostępnianym modelowi AI a bazowymi API. Tłumaczy wywołania funkcji na narzędzia, umożliwiając bezproblemową komunikację.
Jeśli jesteś dostawcą narzędzi, MCP oferuje standardowy protokół dla front-endów agentów AI do łączenia się z twoim narzędziem. To odpowiada na pytanie, dlaczego standardowy protokół nie może być po prostu HTTP i OpenAPI.
MCP to meta-API, które włącza punkty końcowe i ich szczegóły operacyjne do specyfikacji, umożliwiając LLM bardziej efektywną interakcję z nimi.
MCP w konkretnych scenariuszach
MCP może rozwiązywać problemy, gdy użytkownicy zadają pytania lub nie są pewni, których API użyć. Może również przetwarzać żądania na podstawie poprzednich wiadomości.
Jeden z użytkowników dzieli się swoim doświadczeniem związanym z chęcią pobrania ‘X’ użytkownika i wysłania go do punktu końcowego. Uważają, że MCP jest przesadą dla tak prostego zadania, co wskazuje, że nie zawsze jest to konieczne w przypadku podstawowych interakcji z API.
MCP jest porównywane do struktury aplikacji internetowej FastAPI do tworzenia oprogramowania, które może komunikować się przez sieć, zaprojektowanej specjalnie do doświadczeń agentowych. Można to postrzegać jako ‘Rails-for-Skynet’, zapewniający standardową strukturę dla rozwoju agentów AI.
Obawy dotyczące kontroli dostawcy
Istnieją obawy, że MCP jest forsowane w celu zwiększenia kontroli dostawcy nad systemem. Dostawcy LLM mogą ostatecznie ograniczyć dostęp do API, podobnie jak Google utrudnił korzystanie z IMAP/SMTP z Gmail.
Korzystanie z OpenAPI umożliwia agentom pobieranie specyfikacji API z ‘/openapi.json’.
MCP umożliwia szybkie interakcje, pozwalając użytkownikom wykonywać zadania w kilka sekund, zamiast spędzać czas na przygotowywaniu danych wejściowych, wysyłaniu ich do API, analizowaniu danych wyjściowych i powtarzaniu procesu dla każdej wiadomości.
Piaskownica i zagrożenia bezpieczeństwa
Jednym z największych problemów jest to, jak dane wyjściowe jednego narzędzia serwera MCP mogą wpływać na inne narzędzia w tym samym wątku wiadomości. Wymaga to piaskownicy między narzędziami, aby zapobiec niezamierzonym konsekwencjom. Laboratoria Invariant zajęły się tym za pomocą opisów narzędzi, podczas gdy inni używali załączników zasobów MCP. Brak piaskownicy pogarsza ryzyko związane z prompt injection.
Jest to porównywane do SQL injection – systemu skleconego na szybko, w którym luki można wykorzystać w dowolnym momencie przy minimalnej obserwowalności.
Interfejs monitowania jest również podatny na formę SQL injection, ponieważ model nie może odróżnić wiarygodnych części monitu od danych wejściowych skażonych przez użytkownika. Rozwiązanie tego problemu wymaga fundamentalnych zmian w kodowaniu, dekodowaniu i szkoleniu modelu.
Umożliwia to zarówno prompt injection, jak i tool injection, potencjalnie prowadząc do wykonania niezaufanego kodu.
Konteneryzacja i kontrolowany dostęp
Jeden z programistów stworzył serwer MCP, który uruchamia kontener Docker z zamontowanym kodem projektu. To podejście umożliwia LLM dostęp do całego zestawu narzędzi Unix i narzędzi specyficznych dla projektu w środowisku piaskownicy.
Ten agentowy przepływ pracy, napędzany przez interfejs oparty na czacie, okazał się bardziej skuteczny niż tradycyjne metody.
Kluczem jest zapewnienie agentom MCP dostępu do tego, czego potrzebują, i niczego więcej. Konteneryzacja i przejrzysty UX narzędzi są kluczowe dla łagodzenia zagrożeń bezpieczeństwa.
Maszyny wirtualne i dostęp do Internetu
Przyznanie agentom komputera z minimalną instalacją systemu Linux (jako maszyna wirtualna lub kontener) może dać lepsze wyniki, umożliwiając im pobieranie informacji z Internetu. Rodzi to jednak obawy dotyczące bezpieczeństwa związane ze złośliwymi instrukcjami i eksfiltracją danych.
Ograniczenie dostępu do zaufanych stron internetowych może złagodzić niektóre zagrożenia, ale nawet zaufane źródła mogą hostować złośliwe treści. Należy starannie rozważyć kompromis między prawdopodobieństwem napotkania złośliwych instrukcji a korzyściami produktywności.
Różnice między pracownikami a agentami AI są znaczące. Pracownicy są osobami prawnymi podlegającymi prawom i umowom, zapewniającymi odpowiedzialność. Agenci AI nie mają tych ram prawnych, co utrudnia zaufanie.
Wczesne etapy rozwoju MCP
MCP został ogłoszony dopiero w listopadzie 2024 r., a RFC aktywnie się rozwija.
Niektórzy uważają całą koncepcję osobistego asystenta AI, w tym MCP, za fundamentalnie wadliwą.
Początkowy nacisk na asystentów AI pod koniec lat 90. i na początku XXI wieku nie powiódł się, ponieważ agregatory treści z integracją pionową i siłą nabywczą okazały się bardziej skuteczne. Doprowadziło to do powstania platform takich jak Expedia i eBay.
Systemy wieloagentowe wymagają od programistów wpływania na stan agentów, co jest trudnym zadaniem programistycznym.
Granice darmowej wartości
Pragnienie ‘us