Architektura MCP: pełne omówienie techniczne z diagramami

Architektura MCP to podstawowy zestaw komponentów i reguł komunikacji, które umożliwiają działanie MCP (Model Context Protocol). MCP to standard open source, a architektura MCP to infrastruktura, na której on działa.

Każda architektura MCP zawiera trzy podstawowe komponenty i jest wokół nich zbudowana: hosta, klienta i serwer. Strukturę komunikacji MCP często opisuje się jako złożoną z warstwy danych i warstwy transportowej. Warstwa danych to zestaw reguł określających sposób formatowania wiadomości (żądania MCP są wysyłane w formacie JSON-RPC 2.0). Warstwa transportowa przenosi te wiadomości, wykorzystując Streaming HTTP w przypadku połączeń zewnętrznych.

Architektura MCP to struktura serwerowa implementująca Model Context Protocol – otwarty standard łączenia modeli AI z narzędziami, zasobami takimi jak bazy danych oraz promptami rozszerzającymi kontekst wejściowy. Elementy te określa się łącznie mianem „prymitywów”. Ostatecznie architektura MCP pozwala modelom LLM wykrywać dostępne narzędzia i wykonywać przepływy pracy bez konieczności regularnych aktualizacji po stronie klienta.

Diagram architektury MCP: aplikacja AI wymienia żądania z serwerem MCP, który udostępnia narzędzia, zasoby i prompty.

Od czasu wprowadzenia przez Anthropic architektura MCP stała się powszechnie stosowana w przepływach pracy AI. Wynika to głównie z tego, że zastępuje systemy wymagające więcej konserwacji, np. oparte na wielu połączeniach API, bez utraty wydajności. Ponieważ cała dostępna funkcjonalność znajduje się za serwerem MCP, potrzebne jest tylko jedno połączenie, a aktualizacje i nowe funkcje są od razu dostępne dla aplikacji klienckiej.

MCP daje modelom LLM możliwość wykrywania i wywoływania dostępnych dla nich narzędzi, promptów i zasobów – w lokalnym systemie aplikacji hosta lub u zewnętrznego dostawcy.

W przypadku narzędzi, które zapewniają dostęp do zewnętrznych funkcji, wykrywanie polega na wysłaniu przez hosta wywołania tools/list do serwera MCP w celu ustalenia, które narzędzia są dostępne. Model LLM (lub w niektórych przypadkach host) może następnie odczytać opisy dostępnych narzędzi i w razie potrzeby zażądać ich użycia. Prompty i zasoby korzystają z podobnego procesu.

Diagram komponentów architektury MCP: host zawierający model LLM, orkiestrator i klienta łączy się z serwerem MCP w dwóch krokach – najpierw wykrywanie, potem żądania – a serwer MCP udostępnia narzędzia, zasoby i prompty.

Stanowi to przeciwieństwo niestandardowej architektury opartej na API, która była dotąd normą w tworzeniu oprogramowania i w której funkcje spoza aplikacji trzeba było wywoływać za pomocą dedykowanych połączeń z precyzyjnie sformatowanymi żądaniami.

Aplikacja hosta to centralna platforma orkiestracji, która łączy się z modelem LLM. Znane narzędzia, takie jak Perplexity i Claude Desktop, mogą pełnić funkcję hostów w systemie MCP.

W prostym przepływie pracy użytkownik zadaje pytanie za pośrednictwem interfejsu czatu. Komponent orkiestratora hosta dodaje następnie do pytania kontekst, informując model LLM, które prymitywy MCP są dostępne, wraz z opisem ich możliwości.

Klient to komponent oprogramowania w aplikacji AI. MCP zapewnia standardowy interfejs, dzięki któremu klient komunikuje się z wewnętrznymi i zewnętrznymi serwerami MCP na podstawie instrukcji hosta lub modelu LLM. Jego zadaniem jest nawiązanie połączenia, formatowanie wiadomości JSON-RPC, wysyłanie żądań i odbieranie odpowiedzi.

Terminy „host MCP” i „klient MCP” bywają używane zamiennie. Rozróżnienie to jest jednak przydatne, ponieważ host, taki jak Perplexity, może jednocześnie orkiestrować wiele klientów MCP. Złożony przepływ pracy AI może wymagać dostępu do dziesiątek, a nawet setek osobnych serwerów MCP, a każdy z nich będzie korzystał z osobnego połączenia.

Diagram hosta MCP, takiego jak Perplexity, który orkiestruje trzy klienty MCP, z których każdy jest połączony z własnym serwerem MCP, np. bazą danych, plikami lub zewnętrznym API.

Serwer udostępnia wszystkie narzędzia, z których może korzystać narzędzie oparte na AI. Z perspektywy architektury serwer MCP interpretuje przychodzące żądanie i w razie potrzeby łączy się z żądanymi prymitywami.

Serwery MCP mogą zapewniać dostęp do trzech kategorii prymitywów:

Narzędzia: Są to w zasadzie zewnętrzne funkcje oprogramowania. W tradycyjnym podejściu opartym na API aplikacja do analityki internetowej mogłaby pobierać dane za pomocą sformatowanego żądania do zewnętrznego serwera. W architekturze MCP cała funkcjonalność zewnętrznego dostawcy jest dostępna przez jedno połączenie, a żądania są tworzone zgodnie ze standardowymi regułami formatowania.
Zasoby: Zasoby to źródła danych zapewniające kontekst tylko do odczytu. Dobrym przykładem są schematy baz danych. Serwer MCP udostępnia różne źródła informacji dostępne dla hosta. Jeśli host wysyła zapytanie do bazy danych, np. w formie wyszukiwania SQL wygenerowanego przez model LLM, jest to traktowane jako żądanie narzędzia.
Prompty: Są to szablony promptów wielokrotnego użytku, które pomagają modelom LLM wykonywać określone zadania. Użytkownik lub host wywołuje prompt zamiast narzędzia, ponieważ do wykonania zadania potrzebne są gotowe instrukcje. Często predefiniowane zadania w aplikacji hosta, takie jak opcja „przejrzyj kod” lub „przeanalizuj dane”, są przechowywane jako prompty, które użytkownik może wybrać.

Warto też zauważyć, że MCP i API nie są technologiami wzajemnie się wykluczającymi. Serwer MCP może udostępniać wywołania API, które są dostępne w odpowiedzi na żądanie wykrywania. Kluczowe jest to, że za ich utrzymanie odpowiada dostawca MCP, a nie klient.

Warstwa danych w architekturze MCP to zestaw reguł określających sposób formatowania żądań, odpowiedzi i powiadomień. Standardowym językiem wiadomości jest JSON-RPC.

Każda architektura MCP opiera się na podstawowym procesie: (1) inicjalizacja i wykrywanie przez hosta, (2) odpowiedź serwera MCP oraz (3) wywołanie przez hosta (czasami decyduje o nim model LLM), przy czym każdy etap to osobna wiadomość JSON.

Diagram warstwy danych MCP: użytkownik wysyła prompt do aplikacji hosta, w której model LLM współpracuje z klientem MCP; klient wysyła żądanie do serwera MCP (narzędzia, zasoby, prompty) i otrzymuje wynik, a host zwraca odpowiedź użytkownikowi.

Przyjrzyjmy się na dwóch przykładach, jak działa wykrywanie narzędzi (mogą one dotyczyć również zasobów lub promptów):

Wykrywanie narzędzi przed generowaniem przez model LLM: Host inicjuje klienta MCP, który wysyła żądanie tools/list (dotyczące listy dostępnych narzędzi serwera MCP). Model LLM analizuje tę listę podczas generowania i określa, czy potrzebne jest konkretne narzędzie, zasób lub prompt.
Udostępnienie modelowi LLM opcji wyszukiwania: W systemie agentowym host dodaje do kontekstu wejściowego opcję wykrywania, np. search-tools, a model LLM może w razie potrzeby zażądać wyszukiwania.

Narzędzia, które są w przeważającej mierze zewnętrznymi funkcjami aplikacji, zazwyczaj wybiera model LLM lub host. Zasoby i prompty są zwykle żądane na polecenie użytkownika lub przez hosta.

Tak wygląda żądanie tools/list do serwera MCP z wymyślonej aplikacji do notatek:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

W tym przykładzie “id”:101 identyfikuje żądanie za pomocą identyfikatora, dzięki czemu klient może dopasować odpowiedzi, a pole “params” zawiera dodatkowe informacje o kliencie, takie jak nazwa klienta (notes-app-client) i jego możliwości.

W odpowiedzi serwer MCP zwróci definicje narzędzi, które obejmują nazwy dostępnych narzędzi i powiązane z nimi szczegóły. Lista może na przykład zawierać narzędzie add-task, które pozwala aplikacji do notatek tworzyć zadania w połączonej aplikacji do zarządzania zadaniami lub kalendarzu, przypisując każdemu zadaniu tytuł i priorytet.

Tak może wyglądać żądanie:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Pole “method” informuje serwer MCP, że jest to wywołanie narzędzia, pole “name” określa, które narzędzie wywołać, a pole “arguments” dostarcza wymagane dane wejściowe.

Jeśli warstwa danych to co połączenia między klientem a serwerem MCP, warstwa transportowa to jak. Określa sposób przesyłania wiadomości: konkretny kanał oraz zasady, według których dostarczane są żądania i odpowiedzi.

MCP ma dwie ścieżki transportu:

Standardowe wejście/wyjście: Ta ścieżka jest używana, gdy serwer MCP działa w tym samym środowisku lokalnym co aplikacja hosta. Klient zapisuje żądanie JSON na standardowe wejście serwera. Serwer je odczytuje, wykonuje żądaną operację i zapisuje odpowiedź na standardowe wyjście.
Streamable HTTP: Gdy serwer MCP działa poza aplikacją hosta, klient MCP wysyła żądania do serwera za pomocą HTTP POST. Serwer odpowiada pojedynczą wiadomością JSON lub strumieniem Server-Sent Events (SSE) – trwałym kanałem „nasłuchu”, który pozwala mu zwracać wiele wiadomości w czasie.

Wielodzierżawna architektura MCP to rodzaj implementacji, która może jednocześnie obsługiwać wielu użytkowników (dzierżawców).

Dzierżawcą może być tu osoba, grupa osób lub organizacja. Implementacja może polegać na uruchomieniu osobnego serwera MCP dla każdego dzierżawcy, zapewnieniu dostępu do jednego współdzielonego serwera lub umieszczeniu zestawu serwerów za centralną bramą. Gdy używana jest brama, kieruje ona żądania do właściwych punktów końcowych na podstawie tożsamości użytkownika lub charakteru żądania.

Działa na tej samej podstawowej zasadzie co standardowa architektura MCP, ale żądania poszczególnych użytkowników są obsługiwane we własnym obszarze roboczym (nawet jeśli wiąże się to ze współdzielonymi zasobami) i uwierzytelniane oddzielnie. Rozwiązanie to jest powszechne w środowiskach korporacyjnych, a współdzielone zasoby są często preferowane, ponieważ uruchamianie wielu serwerów MCP byłoby niepotrzebnie kosztowne.

Jak w praktyce wygląda kompleksowe żądanie MCP? Wyróżnia się osiem podstawowych etapów, z których każdy obejmuje inny komponent architektury.

Schemat blokowy kompleksowego żądania MCP w ośmiu krokach: wykrywanie narzędzi, dane wejściowe użytkownika, przetwarzanie przez model, wybór narzędzia, żądanie, wykonanie narzędzia, wynik i generowanie odpowiedzi.

Tak w praktyce wygląda wywołanie narzędzia MCP na wcześniejszym przykładzie aplikacji do notatek połączonej z usługą do zarządzania zadaniami:

Wykrywanie narzędzi: Aplikacja do notatek (host) za pomocą swojego klienta MCP pobiera listę dostępnych narzędzi serwera, wysyłając żądanie tools/list. Serwer zwraca ich nazwy, opisy i oczekiwane dane wejściowe, w tym dla narzędzia add-task. Może to nastąpić, zanim prześlesz prompt.
Dane wejściowe użytkownika: Przesyłasz żądanie do aplikacji do notatek opartej na modelu LLM za pośrednictwem wbudowanego czatbota, np. „Utwórz w moim kalendarzu zadanie przejrzenia mojego nowego szkicu ze średnim priorytetem”.
Przetwarzanie przez model: Host wysyła Twoje żądanie i odpowiednie definicje narzędzi do modelu LLM.
Wybór narzędzia: Model LLM generuje ustrukturyzowane żądanie narzędzia, określając narzędzie i jego dane wejściowe: add-task z title: Przejrzyj szkic i priority: Medium. Host sprawdza, czy działanie jest dozwolone, i przekazuje żądanie do klienta MCP, który wysyła wiadomość JSON-RPC.
Żądanie: Klient MCP wysyła żądanie tools/call do swojego serwera MCP.
Wykonanie narzędzia: Serwer MCP wywołuje API aplikacji do zarządzania zadaniami, aby utworzyć nowe zadanie o określonym tytule i priorytecie.
Zwrócenie wyniku: Serwer odsyła wynik do klienta MCP, który przekazuje go hostowi. Host dodaje go do informacji przekazywanych modelowi LLM.
Generowanie odpowiedzi: Model LLM wykorzystuje wynik do wygenerowania odpowiedzi dla użytkownika, np. „Zadanie przejrzenia szkicu ze średnim priorytetem zostało utworzone”.

MCP i tradycyjna architektura API są często mylone, ale to technologie komplementarne. MCP zaprojektowano specjalnie z myślą o aplikacjach opartych na AI. Rozwiązuje on problem wysokich kosztów utrzymania związanych z implementacją i zarządzaniem wieloma zakodowanymi na stałe połączeniami API.

Zapewniając aplikacji hosta jedno połączenie na każdego dostawcę funkcji lub zasób wewnętrzny, MCP pomaga rozwiązać problem przeładowanego kontekstu wejściowego (wymieniającego wszystkie API) lub ograniczonych skryptów aplikacji opartych na API.

Zamiast tego serwery MCP mogą udostępniać API (a raczej funkcje wywołujące API) w ramach swojej listy narzędzi. Gdy dostawca aktualizuje swoją aplikację i pojawia się nowe API lub zmienia się dokumentacja, wystarczy, że zaktualizuje serwer MCP. Po stronie aplikacji hosta nie są wymagane żadne zmiany w kodzie.

Bezpieczeństwo MCP jest przedmiotem licznych dyskusji od momentu jego wprowadzenia. Choć MCP jest ogólnie uważany za bezpieczną technologię, wiąże się z nim kilka zagrożeń bezpieczeństwa, z których wiele ujawnia się wyraźniej w złożonych implementacjach architektury.

Architektura MCP ma następujące potencjalne słabe punkty:

Wstrzykiwanie promptów: Użytkownik umieszcza w danych zewnętrznych złośliwy prompt, który model AI błędnie interpretuje jako instrukcję.
Nadmierne uprawnienia dostępu: Serwery MCP mogą potencjalnie udostępniać modelowi AI dużą liczbę narzędzi, co może zwiększać ryzyko problemów z bezpieczeństwem (tzw. promień rażenia).
Przypadkowe wycieki danych: Źle skonfigurowane implementacje mogą prowadzić do przekazania modelowi LLM poufnych informacji, takich jak klucze API lub dane uwierzytelniające do bazy danych.
Manipulacja systemem lokalnym: Lokalne serwery MCP są tak samo podatne na problemy systemu lokalnego, takie jak złośliwe skrypty, jak wszystkie inne aplikacje, z tą różnicą, że mogą mieć dalsze szkodliwe skutki dla agentowych systemów AI.

Żaden z tych problemów nie jest nie do pokonania. Często do zapewnienia bezpieczeństwa systemu wystarczą sprawdzone środki. Środki takie jak udział człowieka w pętli decyzyjnej, ścisła kontrola dostępu do danych wrażliwych i ochrona przed atakami na serwery to powszechne praktyki.

MCP okazał się przydatnym i popularnym otwartym standardem dla programistów. Rozwiązuje wiele problemów związanych z zakodowanymi na stałe API w aplikacjach opartych na modelach LLM i znacznie zmniejsza nakład pracy programistów przy kodowaniu.

W przyszłości podstawowa architektura hosta i serwera MCP niemal na pewno pozostanie niezmieniona. Przyszłe innowacje będą koncentrować się na zaawansowanych możliwościach agentowych w wieloetapowych przepływach pracy.

Ponadto wraz z wdrażaniem tych funkcji agentowych potrzebne będą silniejsze zabezpieczenia, a także skalowalna architektura, zwłaszcza w warstwie transportowej, ponieważ systemy AI stają się coraz bardziej rozbudowane i złożone.

Czym jest architektura MCP?

Komponenty architektury MCP: hosty, klienty i serwery

Host

Klient

Serwer

Czym jest warstwa danych w architekturze MCP?

Czym jest warstwa transportowa w architekturze MCP?

Czym jest wielodzierżawna architektura MCP?

Diagram architektury MCP: omówienie krok po kroku

Czym architektura MCP różni się od tradycyjnej architektury API?

Czy architektura MCP jest bezpieczna?

Co dalej z architekturą MCP?