GitHub MCP Server, repozytorium dla asystenta

GitHub MCP Server, czyli asystent, który widzi Twoje repozytorium

Asystent kodu pracujący lokalnie widzi pliki, ale nie widzi tego, co dzieje się wokół nich: zgłoszeń, propozycji zmian, wyników potoku budowania, historii dyskusji. Serwer MCP GitHuba wypełnia tę lukę, udostępniając te rzeczy jako narzędzia, które model może wywołać.

Efekt jest odczuwalny przy zadaniach, które dotąd wymagały przeklejania. Pytanie o to, dlaczego dany test przestał przechodzić, albo prośba o poprawkę do zgłoszenia opisanego przez kogoś innego, stają się jednym poleceniem zamiast serii kopiowań z przeglądarki.

Wariant zdalny i lokalny

Serwer istnieje w dwóch postaciach i wybór między nimi jest pierwszą decyzją.

Wariant zdalny działa po stronie GitHuba, więc nie instalujesz nic i nie zarządzasz tokenem ręcznie, bo uwierzytelnianie odbywa się standardowym przepływem autoryzacyjnym. To najprostsza droga i wystarcza w większości zastosowań.

Wariant lokalny uruchamiasz jako kontener albo plik wykonywalny i podajesz mu własny token. Sięgasz po niego, gdy pracujesz z instalacją GitHuba we własnej infrastrukturze, gdy polityka firmy nie pozwala na połączenie zewnętrzne albo gdy chcesz precyzyjnie kontrolować, co serwer widzi.

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": ["run", "-i", "--rm",
        "-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
        "-e", "GITHUB_TOOLSETS=repos,issues,pull_requests",
        "ghcr.io/github/github-mcp-server"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_TOKEN}"
      }
    }
  }
}

Konfiguracja trafia do pliku ustawień narzędzia, którego używasz, na przykład Cursora albo asystenta w terminalu. Sam protokół opisuje szerzej tekst o MCP.

Zestawy narzędzi

Domyślnie serwer włącza pięć zestawów: kontekst, repozytoria, zgłoszenia, propozycje zmian i użytkowników. Wszystko, co potrafi, czyli kilkadziesiąt narzędzi, dokłada dopiero zestaw o nazwie all. Przy takim komplecie model częściej wybiera niewłaściwe narzędzie, a opis każdego zajmuje miejsce w kontekście.

Zestawy pozwalają włączyć tylko to, czego faktycznie używasz. Do pracy nad kodem zwykle wystarczają repozytoria, zgłoszenia i propozycje zmian. Do diagnozowania potoku budowania dochodzą przebiegi akcji. Do przeglądania bezpieczeństwa alerty skanowania.

W wariancie zdalnym zestaw wskazujesz nagłówkiem albo fragmentem adresu, w lokalnym zmienną środowiskową. Efekt jest ten sam: krótsza lista narzędzi i trafniejsze wybory modelu.

Praktyczna zasada brzmi: zostań przy zestawie domyślnym albo zawęź go do trzech pozycji, a kolejne dokładaj, gdy zauważysz, że czegoś brakuje. Odwrotna kolejność, czyli włączenie wszystkiego i wyłączanie po fakcie, kończy się tym, że nikt tego nie porządkuje.

Tryb tylko do odczytu

To najważniejsze ustawienie z perspektywy bezpieczeństwa i warto je rozumieć dokładnie.

Tryb tylko do odczytu wyłącza wszystkie narzędzia zapisujące: tworzenie zgłoszeń, komentowanie, scalanie, wypychanie zmian. Działa jako filtr nadrzędny, więc obowiązuje nawet wtedy, gdy w konfiguracji poprosisz o zestaw zawierający narzędzia zapisujące.

To rozróżnienie ma znaczenie praktyczne, bo pozwala oddzielić dwa rodzaje pracy. Asystent, który ma pomagać w rozumieniu kodu i odpowiadaniu na pytania, nie potrzebuje prawa zapisu. Asystent, który ma otwierać propozycje zmian, potrzebuje, ale wtedy jest to świadoma decyzja z ograniczonym zakresem.

Domyślne włączenie trybu odczytu i rozszerzanie uprawnień tylko tam, gdzie to potrzebne, jest tanie i usuwa całą kategorię problemów. Nieodwracalna operacja wykonana przez pomyłkę modelu boli bardziej niż konieczność zmiany ustawienia raz na tydzień.

Uprawnienia tokenu

Przy wariancie lokalnym token jest jedyną granicą tego, co serwer może zrobić, więc jego zakres wymaga uwagi.

Token o szerokim zakresie daje dostęp do wszystkich repozytoriów, do których masz dostęp Ty. Przy koncie w organizacji to bywa kilkaset repozytoriów, także tych, o których nie pamiętasz. Token o zawężonym zakresie, przypisany do konkretnych repozytoriów i konkretnych uprawnień, ogranicza to do rzeczy, nad którymi faktycznie pracujesz.

Rozsądny zestaw uprawnień do pracy nad kodem obejmuje odczyt zawartości repozytorium, odczyt i zapis zgłoszeń oraz propozycji zmian. Uprawnienia administracyjne, zarządzanie organizacją i dostęp do sekretów nie są potrzebne i nie powinny się tam znaleźć.

Warto też ustawić datę wygaśnięcia. Token bez terminu żyje, dopóki ktoś go nie usunie, a nikt nie usuwa tokenów, o których zapomniał.

Wstrzykiwanie promptu przez treść zgłoszeń

To zagrożenie specyficzne dla tej integracji i rzadko omawiane, a warte zrozumienia.

Serwer pobiera treść zgłoszeń, komentarzy i opisów propozycji zmian, a ta treść pochodzi od dowolnej osoby, która może otworzyć zgłoszenie w Twoim repozytorium. Jeśli asystent traktuje ją jak instrukcję, a nie jak dane, ktoś z zewnątrz może wpłynąć na to, co asystent zrobi.

W repozytorium publicznym to nie jest scenariusz teoretyczny. Zgłoszenie zawierające tekst udający polecenie może skłonić model do wykonania działania, którego nikt nie zamierzał, zwłaszcza gdy asystent ma prawo zapisu i dostęp do innych narzędzi.

Trzy rzeczy ograniczają to ryzyko. Pierwsza to tryb tylko do odczytu wszędzie, gdzie zapis nie jest potrzebny. Druga to zawężenie tokenu do repozytoriów, nad którymi pracujesz. Trzecia to przeglądanie tego, co asystent zamierza zrobić, zanim to zrobi, zamiast pozwalania na wykonywanie działań bez potwierdzenia.

Konfiguracja wariantu zdalnego

Wariant zdalny konfiguruje się adresem, więc zmiana zakresu narzędzi sprowadza się do zmiany jednej linii.

{
  "mcpServers": {
    "github": {
      "url": "https://api.githubcopilot.com/mcp/x/repos/readonly"
    }
  }
}

Fragment adresu wskazuje zestaw, a końcówka włącza tryb tylko do odczytu. Alternatywnie ten sam efekt osiągniesz nagłówkami, co bywa wygodniejsze przy konfiguracji generowanej programowo.

Ten układ pozwala na rzecz, która przy jednym serwerze byłaby niemożliwa: podłączenie dwóch wpisów o różnych uprawnieniach. Jeden z pełnym zestawem w trybie odczytu do przeglądania i pytań, drugi wąski z prawem zapisu wyłącznie do zgłoszeń. Asystent widzi wtedy dużo, a może zmienić niewiele.

Warto sprawdzić, jak Twoje narzędzie obsługuje uwierzytelnianie przy wariancie zdalnym. Część klientów przeprowadza przepływ autoryzacyjny automatycznie przy pierwszym użyciu, część wymaga podania tokenu mimo wszystko, a to zmienia sposób konfiguracji.

Jak to zmienia codzienną pracę

Warto rozumieć, gdzie leży realna oszczędność, bo nie jest tam, gdzie się jej spodziewamy.

Nie chodzi o to, że asystent robi coś, czego człowiek nie potrafi. Chodzi o to, że przestaje być potrzebne przełączanie kontekstu między edytorem a przeglądarką. Pytanie „co się zmieniło w tym module w zeszłym miesiącu" wymaga otwarcia repozytorium, znalezienia historii, przejrzenia zmian i wrócenia do kodu. Z serwerem to jedno zdanie bez opuszczania edytora.

Druga rzecz to łączenie źródeł. Odpowiedź na pytanie, dlaczego test przestał przechodzić, wymaga zestawienia zapisu przebiegu z różnicą w kodzie i czasem z treścią zgłoszenia. Model robi to w jednym kroku, bo wszystkie trzy rzeczy ma dostępne przez narzędzia.

Trzecia to formułowanie zmian. Asystent, który przeczytał zgłoszenie razem z kodem, proponuje zmianę odnoszącą się do obu, a nie tylko do tego, co wkleiłeś w prompt.

Granica jest przy decyzjach. Serwer daje dostęp do informacji, a nie do zrozumienia, dlaczego zespół podjął taką decyzję dwa lata temu. Ta wiedza zwykle nie leży w repozytorium, tylko w rozmowach, i tam trzeba jej szukać osobno. Serwer Slacka daje asystentowi przeszukiwanie archiwum wątków, z tym że działa na tokenie osoby, która go podłączyła, więc widzi dokładnie te kanały co ona i nic ponadto.

Do czego to się nadaje w praktyce

Cztery zastosowania powtarzają się najczęściej i warto od nich zacząć.

Diagnozowanie nieudanego przebiegu potoku budowania: asystent pobiera zapis przebiegu, znajduje błąd i wiąże go ze zmianą, która go wywołała. To zadanie, które ręcznie oznacza kilka minut klikania.

Praca ze zgłoszeniem opisanym przez kogoś innego: asystent czyta opis, znajduje odpowiednie miejsce w kodzie i proponuje zmianę. Jakość zależy tu wprost od jakości opisu, więc zgłoszenie na jedno zdanie da wynik na jedno zdanie.

Przegląd własnej propozycji zmian przed poproszeniem o niego kogoś innego: asystent czyta różnicę razem z kontekstem repozytorium i wskazuje rzeczy oczywiste. To sito wstępne, a nie zastępstwo przeglądu.

Odpowiadanie na pytania o historię: kiedy ta funkcja się zmieniła, kto pisał ten moduł, czy podobny problem już się zdarzał. Tu przewaga nad wyszukiwaniem w przeglądarce polega na tym, że odpowiedź powstaje razem z kontekstem kodu.

Kontra alternatywy

Trzeci wiersz warto rozważyć, gdy zadanie jest powtarzalne. Skrypt oparty o wiersz poleceń wykonuje się tak samo za każdym razem i nic nie kosztuje, podczas gdy to samo zadanie zlecone modelowi kosztuje tokeny i bywa wykonane inaczej.

Praktyczny podział wygląda tak: rzeczy powtarzalne i dobrze określone do skryptów, rzeczy wymagające zrozumienia treści do asystenta z tym serwerem. Ta granica przesuwa się z czasem, ale wyznacza ją koszt i przewidywalność, a nie możliwości modelu.

Wdrożenie w zespole

Konfiguracja indywidualna to jedno, a ustalenia obowiązujące zespół to drugie. Kilka decyzji warto podjąć wspólnie, zanim każdy skonfiguruje serwer po swojemu.

Pierwsza dotyczy zakresu tokenów. Warto ustalić, że nikt nie używa tokenu o pełnym zakresie do pracy z asystentem, i podać przykładowy zestaw uprawnień wystarczający do codziennych zadań. Bez takiego ustalenia domyślną praktyką staje się najszersze uprawnienie, bo działa od razu.

Druga to repozytoria wyłączone z tej integracji. Repozytoria z konfiguracją produkcyjną, kluczami wdrożeniowymi albo danymi wrażliwymi lepiej trzymać poza zakresem tokenu, nawet gdy asystent działa w trybie odczytu.

Trzecia to zasada dotycząca działań zapisujących. Propozycja zmian otwarta przez asystenta przechodzi przez ten sam przegląd co każda inna, a osoba, która ją zleciła, odpowiada za treść. To samo dotyczy komentarzy w zgłoszeniach, bo są widoczne dla klientów i osób spoza zespołu.

Czwarta to wspólny plik konfiguracyjny w repozytorium. Ustawienia zestawów narzędzi i trybu odczytu można trzymać jako plik przykładowy, żeby nowa osoba nie zaczynała od zera i nie kopiowała cudzej konfiguracji z tokenem w środku.

Typowe błędy

Pierwszy to token o pełnym zakresie. Asystent dostaje wtedy dostęp do wszystkich repozytoriów organizacji, choć pracuje nad jednym.

Drugi to włączenie wszystkich zestawów narzędzi. Kilkadziesiąt narzędzi w kontekście obniża trafność wyboru i zajmuje miejsce, które mogłoby pójść na kod.

Trzeci to praca z prawem zapisu tam, gdzie wystarczy odczyt. Tryb tylko do odczytu kosztuje jedno ustawienie i usuwa ryzyko nieodwracalnej operacji.

Czwarty to traktowanie treści zgłoszeń jak instrukcji. To dane od dowolnej osoby z zewnątrz, więc asystent powinien je czytać, a nie wykonywać.

Piąty to token bez daty wygaśnięcia zapisany w pliku konfiguracyjnym. Taki plik trafia czasem do repozytorium, a token żyje dalej.

Szósty to zlecanie asystentowi zadań opisanych jednym zdaniem. Wynik odpowiada opisowi, więc zgłoszenie w rodzaju „popraw wydajność" da propozycję, której nie da się przyjąć.

FAQ

Czym to różni się od GitHub Copilot?

To serwer udostępniający narzędzia GitHuba dowolnemu asystentowi obsługującemu protokół MCP, więc możesz go użyć w Cursorze, w asystencie terminalowym albo we własnej aplikacji. GitHub Copilot to gotowy produkt z własną integracją, bez konfiguracji, ale też z mniejszą kontrolą nad zakresem.

Wariant zdalny czy lokalny?

Zdalny jest prostszy: brak instalacji, uwierzytelnianie standardowym przepływem, aktualizacje po stronie dostawcy. Lokalny wybierasz przy instalacji GitHuba we własnej infrastrukturze, przy zakazie połączeń zewnętrznych albo gdy chcesz dokładnie kontrolować zakres tokenu.

Czy to jest bezpieczne?

Zależy od konfiguracji. Domyślny tryb tylko do odczytu, token zawężony do konkretnych repozytoriów i potwierdzanie działań zapisujących sprawiają, że ryzyko jest niewielkie. Token o pełnym zakresie z prawem zapisu i automatycznym wykonywaniem działań to zupełnie inna sytuacja.

Ile narzędzi warto włączyć?

Zestaw domyślny, czyli kontekst, repozytoria, zgłoszenia, propozycje zmian i użytkownicy, pokrywa większość codziennej pracy i nie wymaga żadnej konfiguracji. Zawężaj go do trzech pozycji, gdy zależy Ci na kontekście, a dokładaj kolejne, gdy zauważysz brak, bo krótsza lista narzędzi oznacza trafniejszy wybór po stronie modelu.

Czy działa z GitHub Enterprise?

Tak, wariant lokalny obsługuje instalacje we własnej infrastrukturze przez wskazanie adresu instancji. To zresztą jeden z głównych powodów, dla których ten wariant istnieje obok prostszego rozwiązania zdalnego.

Dokumentacja i kod stoją w repozytorium na GitHubie, a opis konfiguracji w przewodniku ustawień serwera.