MCP czy CLI
7 lip 2026 · RS Management
W skrócie
- MCP jest już standardem branżowym, ale jego specyfikacja wciąż się rusza.
- Przy jednej integracji obsługiwanej przez jednego klienta zwykły skrypt z linii poleceń nadal wygrywa: niższy koszt wejścia, przewidywalne uprawnienia i kod, który należy do nas.
- Cztery kontrole ograniczają skutki ataku niezależnie od wybranej drogi.
Kiedy agent AI ma zrobić w firmie coś użytecznego, prędzej czy później musi sięgnąć do systemu, w którym leżą dane: Jiry, SharePointa, hurtowni, systemu ERP (planowanie zasobów przedsiębiorstwa) albo wewnętrznego API (interfejs programistyczny). Sposób tego połączenia bywa traktowany jako szczegół techniczny do rozstrzygnięcia przez zespół. W praktyce decyduje o tym, ile kosztuje utrzymanie integracji, kto może ją wywołać i czy po incydencie da się odtworzyć, co dokładnie agent zrobił.
Dwa sposoby podłączenia narzędzia
Pierwszy to MCP (Model Context Protocol), otwarty protokół opisujący, jak agent odkrywa narzędzia i zasoby udostępnione przez serwer oraz jak je wywołuje. Serwer MCP stoi przed systemem docelowym i mówi wspólnym językiem, a klient, czyli asystent w IDE (edytor kodu), aplikacja czatowa albo własny agent, nie musi uczyć się tego języka od nowa dla każdego systemu.
Drugi to wywołanie przez CLI (command line interface), czyli linię poleceń. Agent dostaje prawo uruchomienia konkretnego polecenia lub skryptu, a kontraktem są argumenty, kod wyjścia i format danych wypisany na standardowe wyjście. Cała logika autoryzacji, walidacji i logowania siedzi w kodzie, który zespół napisał sam.
Różnica dotyczy poziomu abstrakcji. MCP standaryzuje opis możliwości, negocjację uprawnień i sposób przekazywania wyników. Skrypt zostawia te decyzje konwencji zespołu, co bywa zaletą przy jednej integracji i problemem przy dziesięciu.
Stan protokołu we wrześniu 2026
9 grudnia 2025 MCP trafił do Agentic AI Foundation, funduszu prowadzonego pod Linux Foundation, współzałożonego przez Anthropic, Block i OpenAI, przy wsparciu Google, Microsoftu, AWS, Cloudflare i Bloomberga. W ogłoszeniu podano ponad 10 tysięcy aktywnych publicznych serwerów MCP1 i ponad 97 milionów miesięcznych pobrań bibliotek dla Pythona i TypeScriptu. Publiczny rejestr serwerów działa od września 2025.
Obowiązująca wersja specyfikacji nosi datę 2026-07-28 i przynosi największą zmianę od startu protokołu: bezstanowy rdzeń bez uzgadniania sesji, negocjację możliwości osobno dla każdego żądania, zaostrzone reguły autoryzacji oraz ramy rozszerzeń. Zmiany łamią zgodność wstecz, a poprzednia wersja nosiła datę 2025-11-25, więc integracja pisana pod starszą specyfikację wymaga przeglądu przed kolejną aktualizacją bibliotek.
Dla planowania oznacza to jedno: standard ma dziś twarde poparcie największych dostawców, a jednocześnie porusza się szybko. Integracja pisana pod MCP potrzebuje budżetu nie tylko na pierwsze uruchomienie, ale też na regularne aktualizacje bibliotek i testy zgodności.
Kiedy MCP się zwraca
Standaryzacja opłaca się wtedy, gdy to samo narzędzie ma być wywoływane z kilku miejsc. Jeden serwer obsłuży asystenta w IDE, aplikację czatową i własnego agenta, zamiast trzech osobnych klejów utrzymywanych przez trzy osoby.
Drugi mocny przypadek pojawia się, gdy serwer utrzymuje dostawca systemu. Wtedy zgodność z kolejnymi wersjami API przestaje być kosztem zespołu i staje się elementem produktu, za który ktoś inny odpowiada.
Trzeci to uwierzytelnianie po stronie serwera. Jeżeli dostęp ma być przyznawany per użytkownik, z odświeżaniem tokenów i wycofywaniem uprawnień, warstwa autoryzacyjna protokołu wykona pracę, którą inaczej trzeba napisać ręcznie i utrzymywać.
Czwarty dotyczy zmiennego zestawu narzędzi. Kiedy katalog funkcji rośnie i zmienia się co kilka tygodni, odkrywanie narzędzi w czasie działania jest wygodniejsze niż aktualizowanie promptów przy każdej zmianie.
Kiedy prostszy skrypt wystarcza
Przy jednej integracji obsługiwanej przez jednego klienta serwer MCP dokłada warstwę, która nic nie zwraca. Jeżeli w repozytorium leży już przetestowany skrypt do wystawiania faktur albo aktualizowania zgłoszeń, tańszym rozwiązaniem jest dopuszczenie agenta do jego wywołania niż przepisywanie go na protokół.
Skrypt wygrywa też przy operacjach o wysokiej stawce, gdzie chodzi o wąską i sztywną powierzchnię działania. Pięć jawnie zdefiniowanych poleceń bez dynamicznego odkrywania łatwiej przejrzeć na przeglądzie kodu niż serwer wystawiający czterdzieści narzędzi, z których agent wybierze sam.
W jednym z wdrożeń przyjęliśmy podział na odczyt i zapis. Odczyt danych idzie przez gotowy serwer MCP dostawcy, bo jest wygodny i nieszkodliwy. Każdy zapis przechodzi przez własny skrypt, z poświadczeniem trzymanym w zmiennych środowiskowych i logiem każdego wywołania. Kompromis polega na utrzymywaniu dwóch mechanizmów zamiast jednego. W zamian operacja zmieniająca stan wymaga jawnej ścieżki i zostawia ślad.
Koszt kontekstu, o którym rzadko się mówi
Definicje narzędzi zajmują miejsce w kontekście modelu. Przy kilkunastu podłączonych serwerach sam katalog potrafi pochłonąć kilkadziesiąt tysięcy tokenów, zanim agent wykona pierwszą użyteczną czynność. W listopadzie 2025 Anthropic opisał wzorzec wywoływania narzędzi MCP z poziomu kodu uruchamianego w odizolowanym środowisku: definicje ładowane na żądanie, dane pośrednie przetwarzane w kodzie, a do modelu trafia gotowy wynik. W opisanym przykładzie zadanie zeszło z ok. 150 tysięcy do ok. 2 tysięcy tokenów.2 To jeden udokumentowany przypadek, więc liczby nie warto przenosić wprost na własne środowisko, ale kierunek jest wymowny. Granica między obydwoma podejściami zaciera się, bo MCP dostarcza opis narzędzi, a wykonanie i tak schodzi do kodu.
| Wymiar | MCP | CLI i skrypty |
|---|---|---|
| Koszt wejścia | Wyższy: serwer, uprawnienia, utrzymanie | Niski: to, co zespół już ma |
| Zużycie kontekstu | Katalog narzędzi zajmuje miejsce w prompcie | Zerowe do czasu wywołania |
| Odporność na zmiany API | Opis narzędzia w jednym miejscu | Każdy skrypt osobno |
| Kto odpowiada za kod | Serwer bywa cudzy | Kod jest nasz i audytowalny |
| Kiedy wygrywa | Wiele systemów, częste zmiany | Kilka systemów, stabilne interfejsy |
Bezpieczeństwo i ślad audytowy
15 kwietnia 2026 badacze opisali klasę ataków nazwaną „Comment and Control”.3 Treść wstrzyknięta w tytuł pull requesta albo w komentarz zgłoszenia przejmowała agentów uruchamianych automatycznie w GitHub Actions, w tym Claude Code Security Review, Gemini CLI Action i GitHub Copilot Agent, i skłaniała je do wyprowadzenia sekretów ze środowiska uruchomieniowego. Producenci wypłacili nagrody za zgłoszenia, bez publicznych identyfikatorów CVE (katalog powszechnie znanych podatności).
Wniosek jest niezależny od sposobu połączenia. Agent traktuje wczytaną treść jak zaufany kontekst, a jego uprawnienia stają się uprawnieniami atakującego. Zasięg szkody ograniczają cztery kontrole stosowane razem: lista dozwolonych narzędzi, tożsamość przypisana do każdego wywołania, log zawierający argumenty i wynik oraz akceptacja człowieka przy operacjach nieodwracalnych.
Tutaj skrypt ma przewagę, która liczy się w rozmowie z audytem. Log wywołań powstaje sam z siebie, a granica uprawnień jest widoczna wprost w kodzie. Przy MCP audyt trzeba zaprojektować świadomie, bo wywołanie przechodzi przez warstwę, której zespół nie pisał, a serwer bywa cudzy. Rozszerzenia opisane osobno od rdzenia protokołu adresują ten obszar, a to, które z nich obsługuje konkretny klient, sprawdza się przy uzgadnianiu połączenia, nie przy wyborze narzędzia.
Jak rozstrzygnąć konkretny przypadek
Wystarczą cztery pytania. Ilu różnych klientów będzie wywoływać to narzędzie w ciągu najbliższego roku? Czy dostawca systemu utrzymuje serwer MCP, czy trzeba go napisać i utrzymywać samodzielnie? Czy operacja jest odwracalna, a jeśli nie, gdzie stoi punkt akceptacji człowieka? Czy w repozytorium jest już skrypt, który robi to samo i przeszedł przegląd kodu?
Najczęstszy błąd polega na traktowaniu tego wyboru jako jednorazowej decyzji dla całej organizacji. Rozsądniej rozstrzygać go osobno dla każdej integracji i zapisywać krótkie uzasadnienie, bo w perspektywie kilku miesięcy zmienią się zarówno wersje protokołu, jak i lista gotowych serwerów, które ktoś utrzymuje za nas.
Footnotes
-
Model Context Protocol, ogłoszenie o przejściu pod Agentic AI Foundation z 9 grudnia 2025, wraz z podanymi liczbami serwerów i pobrań SDK: https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/. ↩
-
Anthropic, wzorzec wywoływania narzędzi MCP z poziomu kodu: https://www.anthropic.com/engineering/code-execution-with-mcp. ↩
-
Cloud Security Alliance, nota badawcza o wykradaniu sekretów przez agentów AI w GitHub Actions: https://labs.cloudsecurityalliance.org/research/csa-research-note-comment-control-github-prompt-injection-20/. ↩
RS Management to praktyka doradcza prowadzona przez jedną osobę. Kto za nią stoi i z jakim doświadczeniem: O mnie.
Treści na blogu mają charakter informacyjny i edukacyjny. Nie stanowią porady prawnej, podatkowej ani indywidualnego doradztwa biznesowego. Zakres naszych usług opisuje regulamin.
Ten temat prowadzimy w pakiecie Automatyzacje i agenci AI: zakres + wycena + budowa + odbiór + przekazanie zespołowi.
Zobacz pakiet: Automatyzacje i agenci AI