Protokół Model Context (MCP) oraz uwagi dotyczące implementacji serwera MCP w języku Go

Długi artykuł o specyfikacjach i implementacji MCP w GO

Page content

Oto opis Protokołu Kontekstu Modelu (MCP), krótkie uwagi dotyczące sposobu implementacji serwera MCP w Go, w tym struktura wiadomości i specyfikacja protokołu.

Robots and MCP

Omówienie Protokołu Kontekstu Modelu (MCP)

Protokół Kontekstu Modelu (MCP) to otwarty, standardowy framework (wprowadzony przez Anthropic w późnym 2024 roku) do łączenia modeli językowych AI z zewnętrznymi źródłami danych, narzędziami i systemami. Jego celem jest rozwiązanie problemu „N×M integracji”, dostarczając uniwersalnego interfejsu do rzeczy takich jak odczytywanie plików, wykonywanie funkcji (narzędzia) i korzystanie z kontekstowych promptów w różnych aplikacjach. MCP nie jest protokołem prywatnym ani wewnętrznym; jest to otwarty standard z oficjalną specyfikacją i otwartą implementacją referencyjną. W rzeczywistości, główne dostawcy AI (w tym OpenAI i Google DeepMind) ogłosiły wsparcie dla MCP po jego wprowadzeniu, podkreślając, że ma on być szeroko przyjętym standardem, a nie rozwiązaniem zależnym od dostawcy.

Cel i architektura MCP

MCP ma na celu standardyzację sposobu, w jaki aplikacje dostarczają kontekstu do LLM – często używana analogia to „port USB-C dla aplikacji AI”. Definiując wspólny protokół, MCP umożliwia asystentom AI i narzędziami bezproblemowe interfejsowanie się z bazami danych, systemami plików, API i innymi zasobami bez niestandardowych integracji. To pomaga modelom językowym generować bardziej odpowiednie i aktualne odpowiedzi, zapewniając im bezpieczny dostęp do danych, które potrzebują.

Architektura: MCP opiera się na modelu klient-serwer z wyraźnym rozdzieleniem ról:

  • MCP Host: Aplikacja nadrzędna (np. klient rozmowy lub IDE), która zarządza połączeniami. Zawiera jedną lub więcej MCP klientów (łączników).
  • MCP Client: Instancja łącznika (wewnątrz hosta), która nawiązuje sesję 1:1 z serwerem MCP. Klient zarządza cyklem życia sesji, kieruje wiadomości i wdraża wszelkie uprawnienia użytkownika lub polityki bezpieczeństwa.
  • MCP Server: Lekki serwis, który udostępnia konkretne możliwości (dostęp do określonych danych lub funkcji) za pośrednictwem protokołu MCP. Każdy serwer może opakować źródło danych (pliki, baza danych, API itp.) lub narzędzie. Wiele serwerów może działać równolegle, każdy dostarczając różnych integracji.
  • Źródła danych/usługi: Rzeczywiste zasoby, z którymi serwery interfejsują się – mogą to być lokalne pliki i bazy danych lub usługi zdalne (API sieciowe, aplikacje SaaS itp.). Serwer MCP działa jako adapter do tych zasobów, zapewniając, że model językowy uzyskuje dostęp do danych tylko za pośrednictwem standardowego protokołu.

Ta konstrukcja inspirowana jest Protokołem Serwera Języka (LSP) z świata IDE. Podobnie jak LSP umożliwia każdemu edytorem wsparcie dla każdego języka programowania za pomocą wspólnego protokołu, MCP umożliwia każdemu zastosowaniu AI połączenie z dowolną integracją narzędzia, która mówi MCP. To rozdzielanie oznacza, że programiści narzędzi AI mogą napisać serwer MCP raz i będzie on działał z wieloma klientami AI, a programiści aplikacji AI mogą dodawać nowe integracje po prostu wstawiając serwer MCP, unikając kodu integracji niestandardowych.

Protokół i struktura wiadomości

Komunikacja: Komunikacja MCP opiera się na trwały, stanowym sesjach za pomocą JSON-RPC 2.0. Wszystkie żądania i odpowiedzi są zgodne z formatem JSON-RPC (z polem "jsonrpc": "2.0", nazwami metod, parametrami i skorelowanymi ID). Każda strona – klient lub serwer – może wysyłać żądania lub powiadomienia, umożliwiając dwukierunkową interakcję. Sesja MCP zazwyczaj zaczyna się od weryfikacji:

  • Klient inicjuje żądanie initialize, proponując wersję protokołu i reklamując swoje możliwości (które funkcje obsługuje). Na przykład, klient może wskazać, że może obsługiwać żądania serwera “sampling” lub dostarczać określone korzenie dla dostępu do plików. Serwer odpowiada swoją wersją protokołu i możliwościami, kończąc na tym, które funkcje są włączone w tej sesji (MCP korzysta z systemu negocjacji możliwości podobnego do opcjonalnych funkcji w LSP). Jeśli istotne możliwości lub wersja są niekompatybilne, połączenie jest zakończone zgrzytliwie.
  • Po osiągnięciu porozumienia, klient wysyła powiadomienie initialized, aby oznaczyć gotowość. Po tym normalne operacje mogą się rozpocząć. Sesja pozostaje otwarta dla ciągłego wymiany wiadomości JSON-RPC, dopóki jedna ze stron nie wysyła komendy wyjścia.

Transport: MCP nie wymusza jednego kanału transportu – działa nad każdym kanałem, który może przesyłać tekst JSON. Zwykle serwer MCP uruchamiany jest jako podproces i komunikuje się przez STDIO (potoki stdin/stdout) dla lokalnych integracji. Jest to analogiczne do działania serwerów języka i jest wygodne dla lokalnych narzędzi (host może uruchomić proces serwera i przesyłać wiadomości). Alternatywnie, serwery MCP mogą działać jako niezależne usługi dostępne przez HTTP. Specyfikacja MCP definiuje strumieniowy transport HTTP, w którym serwer udostępnia pojedynczy punkt końcowy HTTP dla wywołań JSON-RPC (klienci wysyłają żądania POST, a serwer może odpowiadać lub przesyłać wyniki przez Server-Sent Events dla długotrwałych operacji). W każdym przypadku, wiadomości są liniami UTF-8 JSON, a protokół obsługuje przesyłanie odpowiedzi i wiadomości inicjowanych przez serwer (podchód HTTP+SSE pozwala serwerowi na przesyłanie powiadomień lub częściowych wyników asynchronicznie). Wskazówki bezpieczeństwa zalecają, że lokalne serwery powinny być powiązane z localhost i weryfikować nagłówki Origin, aby zapobiec niepożądanemu dostępowi zdalnemu, a także, że należy stosować odpowiednie autoryzacje (np. tokeny lub przepływy OAuth) dla serwerów zdalnych.

Format wiadomości: MCP wykorzystuje trzy typy wiadomości JSON-RPC: Żądania, Odpowiedzi i Powiadomienia. Żądanie zawiera id, ciąg method i (opcjonalnie) params (zwykle obiekt JSON z argumentami). Odbiorca musi odpowiedzieć odpowiednimi danymi (z dopasowanym id), zawierającymi albo result albo error. Powiadomienia są jak jednokierunkowe wiadomości z method i parametrami, ale bez id (więc nie otrzymują odpowiedzi). MCP nakłada kilka reguł na podstawowy JSON-RPC (np. id musi być niepusty i nie ponownie używany w sesji), aby zachować przejrzystość.

Sesja i stan: Połączenie jest traktowane jako stanowe – klient i serwer utrzymują kontekst o możliwościach drugiego i ewentualnie pewnym stanie sesji (np. subskrypcje zmian, trwające operacje itp.). Istnieją również zdefiniowane procedury dla bezpiecznego wyjścia (np. klient może wysłać żądanie wyjścia lub po prostu zamknąć kanał transportu; serwery powinny obsługiwać czyszczenie, a obie strony implementują timeouty dla operacji zawieszonych). Obsługa błędów następuje zgodnie z konwencjami JSON-RPC (odpowiedzi błędów mają kod i wiadomość), a specyfikacja definiuje standardowe kody błędów dla określonych warunków (np. brak uprawnień, narzędzie nie znaleziono itp.). MCP oferuje również narzędzia do rozwiązywania problemów przekroczonych: np. istnieją wbudowane powiadomienia o aktualizacjach postępu, anulowaniu długotrwałego żądania (CancelledNotification), wiadomości logowania/debugowania i zmiany konfiguracji. Te narzędzia pomagają zarządzać długimi lub złożonymi interakcjami (np. klient może anulować trwającą operację narzędzia, a serwer może wysyłać ostrzeżenia do klienta itp.).

Funkcje i operacje MCP

Po zainicjalizowaniu sesji MCP umożliwia wymianę kontekstu i poleceń w strukturalny sposób. Główne funkcje serwera MCP to Prompty, Zasoby i Narzędzia (każda z nich serwer deklaruje, czy obsługuje podczas inicjalizacji):

  • Prompty: Zdefiniowane szablony promptów lub instrukcje, które serwer może dostarczyć klientowi. Są to zazwyczaj pomocniki wyzwalane przez użytkownika (użytkownik jawnie wybiera prompt, który wstawia do rozmowy, np. za pomocą polecenia w UI). MCP oferuje metody do listy dostępnych promptów i pobierania zawartości promptu. Na przykład, klient może wywołać prompts/list, aby uzyskać listę szablonów promptów (każdy z nazwą, opisem i opcjonalnymi parametrami). Aby pobrać prompt, klient używa prompts/get z nazwą promptu i wartościami argumentów; serwer zwraca zawartość promptu (często jako zestaw wiadomości, które klient wstrzykuje do kontekstu LLM). Prompty umożliwiają ponowne wykorzystanie złożonych instrukcji lub przepływów pracy (np. „szablon recenzji kodu”), które użytkownik może wywołać na żądanie. Serwery wskazują możliwość prompts (z opcjonalnymi podfunkcjami, takimi jak listChanged, aby powiadomić klienta, jeśli zestaw promptów zmienia się dynamicznie).

  • Zasoby: Strukturalne dane lub treści, które dostarczają kontekstu modelowi. Zasoby to zazwyczaj pliki, dokumenty, wpisy w bazie danych – informacje, które asystent AI może odczytać lub odwołać się do. MCP standardizuje sposób identyfikowania i przesyłania zasobów: każdy zasób ma identyfikator URI (np. file:///ścieżka/do/pliku.txt lub niestandardowy schemat dla baz danych). Klienci mogą zapytać, jakie zasoby są dostępne za pomocą resources/list (serwer może udostępnić drzewo katalogów, listę ostatnich dokumentów itp.). Odpowiedź serwera zawiera metadane dla każdego zasobu (URI, nazwa, typ, opis itp.). Następnie klient może żądać zawartości konkretnego zasobu za pomocą resources/read, przekazując URI. Serwer odpowiada zawartością zasobu, która może być tekstem (dla plików), lub strukturalnymi danymi (MCP obsługuje różne typy treści, takie jak tekst, JSON, binarny itp., z typami MIME). Istnieje również wsparcie dla szablonów zasobów (parametryzowanych zasobów identyfikowanych przez URI szablonu, które klient może wypełnić, np. zapytanie do bazy danych, gdzie użytkownik dostarcza parametr). Jeśli jest włączona, serwery mogą wysyłać powiadomienia, gdy zasoby się zmieniają (np. notifications/resources/updated) lub pozwalać klientom subskrybować zmiany na zasobie (resources/subscribe). W projektowaniu MCP, zasoby są sterowane przez aplikację: aplikacja hosta (klient) zazwyczaj decyduje, które zawartość zasobu rzeczywiście wstrzykuje do kontekstu modelu (często po potwierdzeniu użytkownika lub na podstawie kontekstu UI).

  • Narzędzia: Wykonywalne funkcje lub działania, które serwer udostępnia modelowi do wywołania. Narzędzia reprezentują operacje, które AI może wykonać – np. wywołać zewnętrzną API, uruchomić zapytanie do bazy danych, wysłać e-mail lub zmodyfikować plik. Każde narzędzie ma nazwę i schemat JSON dla swoich parametrów wejściowych (i opcjonalnie wyjściowych), więc AI (lub klient) wie, jakie argumenty oczekuje. Narzędzia są zazwyczaj sterowane przez model: idea jest taka, że językowy model (agenta) decyduje, czy i kiedy użyć narzędzia w trakcie rozmowy, aby zaspokoić żądanie użytkownika. Jednak dla bezpieczeństwa, użytkownik ludzki lub aplikacja hosta mogą mediacjonować użycie narzędzia (np. wymagać kliknięcia potwierdzenia). Użycie narzędzi w MCP obejmuje dwie główne operacje: listowanie i wywoływanie. Klient może wywołać tools/list, aby uzyskać dostępne narzędzia i ich schematy. Na przykład, serwer może wylistować narzędzie get_weather z opisem i schematem wejściowym, który wymaga ciągu „location”. Następnie, gdy model zdecyduje się użyć narzędzia (lub użytkownik je wywoła), klient wysyła żądanie tools/call z nazwą narzędzia i obiektem JSON z argumentami. Serwer wykonuje funkcję i zwraca wynik, zwykle jako pole result.content, które może zawierać tekst lub strukturalne dane (MCP obsługuje zwracanie wielu części treści, np. tekst plus obraz itp., choć tekst jest powszechny). Prosty przykład: wywołanie narzędzia get_weather może zwrócić tekstowy ładunek takie jak „Obecna pogoda w Nowym Jorku: 72°F, częściowo zachmurzone” jako zawartość, którą asystent może przedstawić. Narzędzia mogą również wskazywać błędy (odpowiedź ma flagę isError lub obiekt błędu, jeśli coś poszło nie tak). Podobnie jak prompty i zasoby, możliwość tools może mieć opcjonalną flagę listChanged, aby powiadomić, gdy dostępne narzędzia zmieniają się w czasie działania (np. dynamicznie załadowany/wyjęty wtyczka).

Oprócz powyższych funkcji oferowanych przez serwer, MCP również definiuje funkcje oferowane przez klienta (możliwości, które serwery mogą wykorzystać, jeśli klient je obsługuje). Te obejmują Sampling, Roots i Elicitation:

  • Sampling pozwala serwerowi żądać od klienta (i jego LLM) wykonania wnioskowania modelu w ramach sesji. Na przykład, serwer może rozpocząć wywołanie LLM (np. aby kontynuować łańcuch myślenia lub podsumować coś), wysyłając żądanie takie jak sampling/request – klient następnie pobierze model i zwróci wynik. To umożliwia agentyzowane zachowania, w których serwer może kierować AI, aby pomagał w swoich własnych podzadaniach. (Wszystkie takie działania są podległe zgodzie użytkownika i polityce – np. użytkownik może musieć wyrazić zgodę, aby pozwolić serwerowi wywołać model dla dodatkowych zapytań.)

  • Roots pozwala serwerowi badać lub działać w określonych dozwolonych katalogach lub URI. Klient może dostarczyć listę „pierwiastków” katalogów/URI, do których serwer ma dostęp, za pomocą roots/list. Jest to funkcja bezpieczeństwa, która zapewnia, że serwer wie o granicach (np. które drzewa folderów może odczytać).

  • Elicitation pozwala serwerowi prosić klienta o uzyskanie więcej informacji od użytkownika, jeśli to konieczne. Na przykład, jeśli narzędzie potrzebuje brakującego fragmentu informacji, który nie został dostarczony, serwer może wysłać żądanie elicitacji, które klient (UI) przetłumaczy na prompt użytkownika („Integracja X wymaga Twojego klucza API, proszę wpisać go”). W ten sposób serwer może interaktywnie zbierać dane wejściowe przez klienta.

Wszystkie te funkcje są opcjonalne i negocjowane na wstępie. Kluczowym aspektem projektowania MCP jest to, że negocjacja możliwości odbywa się podczas inicjalizacji – klient i serwer reklamują, które z powyższych funkcji obsługują, więc obie strony wiedzą, jakie operacje są dostępne w sesji. Na przykład, jeśli serwer nie deklaruje możliwości tools, klient nie będzie próbował żądań tools/list lub tools/call z nim. Ta elastyczność oznacza, że MCP może ewoluować z nowymi funkcjami w czasie, jednocześnie zachowując kompatybilność wsteczną (nieobsługiwanie metod po prostu nie zostanie użyte, jeśli nie zostanie negocjowane).

Implementacje, SDK i budowanie serwera MCP (szczególnie w Go)

Oficjalna specyfikacja i dokumentacja: Autorytatywna specyfikacja MCP jest dostępna publicznie, w tym formalny schemat wszystkich typów wiadomości. Jest utrzymywana na stronie Model Context Protocol i GitHub. Specyfikacja jest zdefiniowana w pliku TypeScript (z odpowiadającym jej JSON Schema), który dokładnie dokumentuje wszystkie żądania, odpowiedzi i struktury. Strona dokumentacji (modelcontextprotocol.io) oferuje przewodniki, FAQ i szczegółowe omówienia każdej funkcji i typu wiadomości, a także narzędzie „MCP Inspector” do interaktywnego debugowania. Choć MCP nie jest (jeszcze) standardem IETF ani ISO, jest on rozwijany jako otwarty standard z udziałem społeczności i korzysta z terminologii RFC 2119 dla wymagań. Jest to rozwijany protokół (wersje są datowane; np. 2025-06-18 to niedawna wersja), z polityką wersjonowania do zarządzania zmianami.

Referencyjne implementacje: Anthropic otworzył źródło kilku łączników serwera MCP i SDK po wprowadzeniu MCP. Istnieje organizacja GitHub modelcontextprotocol, która hostuje specyfikację i kilka repozytoriów. Wyróżnione jest repozytorium „servers”, które zawiera kolekcję gotowych implementacji serwera MCP dla typowych usług i źródeł danych. Służą one jako referencyjne integracje i często mogą być używane bez żadnych modyfikacji lub jako szablony dla serwerów niestandardowych. Na przykład, oficjalne repozytorium zawiera serwery dla Google Drive (dostęp i wyszukiwanie w Google Drive), Slack (komunikacja w przestrzeni roboczej i zawartość kanałów), GitHub/Git (kontekst repozytorium kodu), PostgreSQL (tylko do odczytu zapytań baz danych z informacjami o schemacie), Google Maps (API lokalizacji i kierunków), Puppeteer (przeglądanie sieci i skrapowanie) i wiele innych. Instalując lub uruchamiając te serwery, aplikacja AI takie jak Claude lub Cursor może natychmiast uzyskać tę integrację. Istnieje również serwis rejestru MCP (open-source w Go) dla indeksowania dostępnych serwerów, a wiele innych przyczynek społecznościowych rozwijających MCP w różnych dziedzinach (od CRM do danych blockchain).

SDK i biblioteki: Aby ułatwić budowanie własnych serwerów/klIENTÓW MCP, dostępne są oficjalne SDK w wielu językach. W 2025 roku projekt oferuje SDK dla TypeScript/Node, Python, Java (i Kotlin), C# (rozwijany wraz z Microsoftem), Ruby (z Shopify), Swift i innych. Te biblioteki obsługują „plumbing” protokołu – np. zarządzanie transportem JSON-RPC, implementację specyfikacji schematu i dostarczanie pomocniczych API do rejestrowania narzędzi lub udostępniania zasobów. Na przykład, SDK TypeScript może być używany do szybkiego napisania serwera w Node.js, a SDK Python umożliwia integrację MCP w aplikacjach Python. W podejściu SDK programiści nie muszą ręcznie konstruować wiadomości JSON-RPC ani implementować pełnego maszynowego stanu; zamiast tego wywołują wysokiej poziomu metody, aby wysyłać żądania lub publikować możliwości.

Implementacja w Go: Go stał się popularnym wyborem dla serwerów MCP ze względu na swoje zalety wydajności i współbieżności (dobrze nadają się do obsługi wielu równoległych żądań). Obecnie dostępny jest oficjalny SDK w Go, utrzymywany w spółce z zespołem Go w Google. (To zostało ogłoszone w kwietniu 2025 roku, a pierwsza stabilna wersja ma zostać wydana w sierpniu 2025 roku.) SDK w Go oferuje pakiet mcp do budowania klientów/serywerów i pomocniczy jsonschema do schematów narzędzi. Używając SDK w Go, programiści mogą utworzyć serwer MCP za pomocą kilku wywołań. Na przykład, można utworzyć nowy serwer z nazwą i wersją, a następnie dodać narzędzia za pomocą AddTool, dostarczając definicję narzędzia (nazwa, opis, schemat wejściowy) wraz z funkcją obsługi w Go, która zostanie wykonana, gdy to narzędzie zostanie wywołane. SDK zajmuje się eksponowaniem narzędzia w protokole (reklamując je w tools/list i obsługując żądania tools/call). Podobnie można udostępnić zasoby lub prompty za pomocą analogicznych API. Na koniec uruchamia się serwer – na przykład, server.Run(ctx, mcp.NewStdioTransport()) uruchomi przetwarzanie wiadomości JSON-RPC przez stdio, dopóki klient nie rozłączy się. Na stronie klienta, SDK w Go może uruchomić podproces i połączyć się za pomocą mcp.NewCommandTransport(exec.Command("myserver")), a następnie klient może wywołać session.CallTool(ctx, params), aby wywołać narzędzie i łatwo uzyskać wynik w kodzie Go.

Przykład: Dokumentacja oficjalnego SDK w Go pokazuje prosty „serwer powitalny”. Serwer rejestruje narzędzie "greet", które pobiera imię i zwraca ciąg powitalny. Klient następnie wywołuje to narzędzie według nazwy i wypisuje wynik. To ilustruje podstawowy wzorzec: zdefiniuj narzędzie -> klient wywołuje narzędzie -> otrzymaj wynik. W tle to odpowiada wiadomościom JSON-RPC ("method": "tools/call", params: {"name": "greet", ...} i odpowiedzi zawierającej result.content z tekstem), jak zdefiniowane w specyfikacji MCP.

Przed wydaniem oficjalnego SDK w Go społeczność stworzyła własne biblioteki w Go. Wyróżnione jest projekt mcp-go Eda Zynda (mark3labs/mcp-go), który był powszechnie używany i wpłynął na projekt oficjalnego SDK. Inna biblioteka, mcp-golang przez Metoro, zapewniała implementację i API w Go (artykuł bloga Dev przez Eltona Minetto korzysta z tej biblioteki w pierwszym kwartale 2025 roku). Te społecznościowe SDK pozwoliły programistom w Go eksperymentować z MCP wczesnie – na przykład, jeden tutorial pokazuje, jak zbudować serwer MCP, który wyszukuje portugalskie kody pocztowe (CEP) poprzez udostępnienie narzędzia „zipcode” za pomocą biblioteki mcp-golang od Metoro. W tym przykładzie, serwer Go rejestruje funkcję, która wywołuje zewnętrzną API, aby znaleźć adres na podstawie ZIP, i zwraca wynik jako tekst – umożliwiając asystentowi AI na żądanie pobranie informacji o adresie przez MCP. Inna instrukcja demonstruje opakowanie niestandardowej bazy danych w pamięci (DiceDB) jako serwera MCP za pomocą SDK mcp-go od mark3labs: definiuje narzędzie ping, aby sprawdzić połączenie z bazą danych, oraz inne narzędzia do operacji danych. Te przykłady pokazują, jak prosto można stworzyć integrację MCP: większość kodu to logika biznesowa (wywołania API, zapytania do bazy danych itp.), podczas gdy SDK zajmuje się przewodnikiem JSON-RPC.

Budowanie serwera MCP w Go (Podsumowanie tutorium)

Aby omówić proces, oto typowy przepływ z użyciem Go SDK lub podobnej biblioteki:

  1. Ustawienie serwera: Inicjalizuj nową instancję serwera z podstawowymi informacjami (nazwa, wersja i zadeklaruj obsługiwane możliwości). Na przykład w Go: server := mcp.NewServer("MyServer", "1.0.0", nil) utworzy serwer, który (domyślnie) obsługuje podstawowe funkcje protokołu. Można włączyć konkretne możliwości, takie jak sugestie/zasoby/narzędzia, poprzez opcje lub po prostu rejestrując te funkcje (dodanie narzędzia lub zasobu oznacza, że ta możliwość jest aktywna).

  2. Rejestrowanie funkcji: Dodaj funkcjonalności, które chcesz udostępnić:

    • Jeśli udostępniasz Narzędzia, zdefiniuj schemat każdego narzędzia i jego obsługę. Na przykład używając AddTool z Go SDK: podaj mcp.Tool{Name: "...", Description: "..."} i funkcję obsługującą, która przyjmuje żądanie i zwraca wynik (który może zawierać tekst lub inne treści). SDK automatycznie wygeneruje schemat JSON dla danych wejściowych na podstawie typów parametrów funkcji obsługi (lub możesz go określić ręcznie).
    • Jeśli udostępniasz Zasoby, możesz użyć API do rejestracji list zasobów lub wywołania zwrotnego do odczytu treści. Na przykład w Python SDK możesz dziedziczyć po ResourceProvider; w Go SDK nadal rozwijany jest ten aspekt, ale prawdopodobnie dostarczysz funkcji do listowania i odczytu zasobów. Każdy zasób powinien mieć stabilny URI.
    • Jeśli udostępniasz Sugestie, zdefiniuj szablony sugestii (mogą być to pliki statyczne lub łańcuchy znaków) i zarejestruj je z nazwami i opcjonalnymi parametrami. Serwer będzie je promował, aby klient mógł je pobrać i wyświetlić użytkownikom.

  3. Implementacja transportu: Zdecyduj, w jaki sposób serwer będzie działał. Najprostszy sposób na lokalnym komputerze to stdio – np. server.Run(ctx, mcp.NewStdioTransport()) w Go uruchomi odczyt JSON-RPC z stdin. Jeśli serwer ma być sieciowy, możesz zaimplementować handler HTTP, który będzie używał Go SDK do akceptowania JSON-RPC przez HTTP (oficjalny Go SDK może wkrótce zawierać pomocniczy moduł do transportu HTTP/SSE).

  4. Testowanie klientem: Możesz przetestować serwer za pomocą klienta kompatybilnego z MCP. Na przykład Claude 2 (Claude for Desktop) od Anthropic obsługuje ładowanie lokalnych serwerów MCP; skonfiguruj Claude, aby uruchamiał lub łączył się z twoim binarką serwera. Istnieje również narzędzie CLI o nazwie mcp-cli oraz interfejs graficzny MCP Inspector do testowania serwerów bez pełnego klienta AI – te narzędzia wysyłają żądania MCP do serwera i pokazują wyniki, co pomaga w debugowaniu.

  5. Bezpieczeństwo i uprawnienia: Podczas budowania serwera rozważ uwierzytelnienie i zakresy uprawnień. Dla lokalnych serwerów host może je uruchomić z określonymi uprawnieniami systemu operacyjnego lub dostarczyć klucze API przez środowisko. Dla serwerów zdalnych użyj nagłówków uwierzytelniających lub przepływów OAuth. MCP zawiera specyfikację autoryzacji dla transportu HTTP (serwer może wymagać tokena, a klient może go wysłać). Zawsze upewnij się, że serwer dostępuje tylko do danych, które użytkownik zezwolił (np. szanuj katalogi główne dostarczone przez klienta i nie wyciekaj danych gdziekolwiek indziej) – wytyczne MCP podkreślają zgodę użytkownika, prywatność danych i bezpieczeństwo narzędzi jako fundamentalne.

Podsumowując, MCP to formalny, ale elastyczny protokół łączący LLM z światem zewnętrznym. Nie jest to wewnętrzny API przypisany do jednej firmy, ale otwarty standard z rosnącym zastosowaniem i bogatym ekosystemem integracji. Protokół definiuje wyraźne struktury wiadomości (oparte na JSON-RPC) i zestaw operacji (metody dla sugestii, narzędzi, zasobów itp.), które mogą zaimplementować każdy kompatybilny klient/serwer. Dokumentacja i specyfikacje oficjalne są dostępne, a liczne SDK, biblioteki i przykładowe serwery (w tym w Go) ułatwiają implementację. Korzystając z MCP, programiści mogą tworzyć aplikacje AI oparte na AI, które bezpiecznie wykorzystują istniejące dane i usługi, bez konieczności ponownego tworzenia logiki integracji dla każdego nowego modelu lub zestawu danych.

Przydatne linki