O czym jest ten film
- Konektory Claude’a nie ograniczają się do gotowych integracji (GitHub, Gmail, Drive) — można zbudować własny, do własnej aplikacji.
- Autor pokazuje motywację na przykładzie swojej aplikacji księgowej: zamiast klikać po formularzu, wrzuca zdjęcie paragonu i agent zakłada wpis kosztowy.
- Cały tutorial przechodzi ścieżkę end-to-end: nowy projekt → aplikacja → wdrożenie na produkcję → serwer MCP → konektor w Claudzie.
- Aplikacja demonstracyjna to klon Trello — tablica kanban z organizacjami, zespołami, rolami i zaproszeniami.
- Kluczowy element metodyki: nie oddawać agentowi wysokopoziomowego planu, tylko kazać mu rozbić go na szczegółowy plan wdrożenia i osobne pliki funkcji z kryteriami akceptacji.
- Agent musi mieć możliwość samodzielnego testowania aplikacji w przeglądarce (Playwright MCP albo odpowiednik) i ponownego użycia tych samych danych testowych.
- Wdrożenie: GitHub → Vercel → baza Postgres (Neon) w chmurze, plus typowa pułapka z migracjami w komendzie budowania.
- Serwer MCP to warstwa pośrednia — agent wywołuje narzędzia, a nie klika w interfejs użytkownika.
- Uwierzytelnianie przez OAuth (biblioteka Better Auth) sprawia, że agent działa jako konkretny zalogowany użytkownik, a dostęp można w każdej chwili odebrać.
- Gotowy konektor działa jednocześnie w Claude Web, aplikacji desktopowej i Claude Code, a każde narzędzie można zablokować albo wymusić zatwierdzanie.
Redakcyjne tłumaczenie
Po co własny konektor
Konektory Claude’a są już dobrze znane — łączą Claude’a z GitHubem, Gmailem, Dyskiem, Motion i dziesiątkami aplikacji zewnętrznych. Znacznie mniej osób wie, że można zbudować własny konektor do własnej aplikacji.
Weźmy jako przykład Pulse Books — aplikację księgową, którą zbudowałem na potrzeby swojej firmy. Za każdym razem, gdy muszę zarejestrować nowy koszt, muszę zalogować się do aplikacji, przeklikać się przez interfejs i wypełnić formularz. To potrafi być czasochłonne, a najchętniej po prostu oddałbym to zadanie asystentowi AI. Dlatego zbudowałem konektor Pulse Books. Łączy on Claude’a z moją aplikacją i pozwala mu działać w niej w moim imieniu.
W praktyce wygląda to tak: wgrywam do agenta zdjęcie paragonu i proszę o utworzenie wpisu kosztowego. Agent może dopytać o rzeczy, których nie da się jednoznacznie wywnioskować — na przykład do jakiej kategorii przypisać wydatek — a następnie tworzy rekord kosztu w moim imieniu. Wszystko odbywa się bezpiecznie, wewnątrz aplikacji i wyłącznie na tych funkcjach, które sam zdecydowałem się udostępnić. Kiedy agent kończy pracę i odświeżam listę kosztów, widzę tam nowy rekord razem z załączonym paragonem.
W tym materiale zbudujemy wszystko krok po kroku. Pokażę właściwy sposób zakładania nowego projektu, zbudujemy serwer MCP z uwierzytelnianiem OAuth, wdrożymy aplikację na produkcję i na końcu podłączymy ją do Claude’a — albo do dowolnego innego agenta.
(Informacja dodatkowa: MCP — Model Context Protocol — to otwarty standard opisujący, w jaki sposób aplikacja udostępnia modelowi zestaw narzędzi do wywołania. Konektor w Claudzie to po prostu podpięty do konta serwer MCP.)
Konfiguracja środowiska pracy
Możecie korzystać z dowolnego agenta kodującego — Claude’a w aplikacji desktopowej, Codeksa, czego tylko chcecie. Ja będę używał Claude Code wewnątrz VS Code, bo dzięki temu widzę wszystkie generowane pliki.
Zaczynam od pustego projektu i od jednej bardzo przydatnej umiejętności (skill), do której link zostawiam w opisie filmu. To umiejętność, której używam do zakładania nowych aplikacji. Jeśli nie lubicie konfigurować stosu technologicznego od zera albo obawiacie się, że aplikacja nie będzie skalowalna, to najlepszy sposób startu z dowolną aplikacją webową.
Ze strony umiejętności wystarczy skopiować komendę instalacyjną i przekazać ją swojemu agentowi kodującemu z prośbą o instalację. Ja otwieram terminal, wklejam komendę, wybieram Claude Code, instaluję na poziomie globalnym — żeby nie musieć powtarzać tego przy kolejnych projektach — wybieram dowiązanie symboliczne i przechodzę przez instalację. Gotowe. Otwieram Claude Code i sprawdzam, wpisując „start”, czy umiejętność jest dostępna. Jest.
Plan aplikacji
Przechodzę w tryb planowania i piszę, że chcę stworzyć klon Trello, w którym członkowie zespołu współpracują na wspólnej tablicy kanban. Aplikacja ma obsługiwać wiele organizacji, zespołów i ról. Ma być możliwość zapraszania nowych członków zespołu linkiem zapraszającym. Uwierzytelnianie użytkowników — e-mail i hasło. Karty na tablicy kanban mają się dać przeciągać. Na końcu dodaję: użyj umiejętności do startu nowej aplikacji.
Co się teraz stanie: agent wciągnie tę umiejętność, a razem z nią sporo wiedzy potrzebnej do skutecznego budowania aplikacji. Zada mnóstwo pytań doprecyzowujących, żeby zrozumieć, o czym właściwie jest ta aplikacja, i użyje stosu technologicznego sprawdzonego w prawdziwych wdrożeniach produkcyjnych. To bardzo ułatwi późniejsze wypuszczenie aplikacji na produkcję i skalowanie jej do setek czy tysięcy użytkowników.
Jeśli kiedykolwiek próbowaliście budować aplikacje, wiecie, jak trudne bywa obsłużenie organizacji, zespołów, członków i ról. Zrobienie tego samodzielnie to koszmar. Ta umiejętność zawiera gotowe klocki, z których agent zbuduje praktycznie dowolną aplikację webową. Tutaj na przykład widzę informację, że wtyczka organizacji w Better Auth natywnie obsługuje organizacje, zespoły, role i zaproszenia. Nie budujemy więc wszystkiego od zera — korzystamy z komponentów wskazanych przez umiejętność.
Agent zadaje serię pytań doprecyzowujących. Odpowiadam na nie, ale przy jednym chcę się zatrzymać: prędzej czy później agent zapyta o bazę danych, i to jest naprawdę ważny wybór. Zwykle stoi on między SQLite a Postgresem. SQLite jest świetny, jeśli nigdy nie planujecie wdrażać aplikacji na produkcję — utworzy plik bazy w katalogu projektu, ze wszystkimi danymi: informacjami o użytkownikach, o zadaniach i tak dalej. Ale przy wdrożeniu produkcyjnym, które tu robimy, staje się to problemem. Dlatego na tym etapie wybieram Postgresa w Dockerze.
(Informacja dodatkowa: SQLite trzyma dane w jednym pliku na dysku serwera. Na platformach hostingowych typu Vercel, gdzie system plików jest ulotny, taki plik znika przy kolejnym wdrożeniu — stąd wybór Postgresa.)
Od planu ogólnego do planu wdrożeniowego
Kiedy Claude kończy plan, wciskam Escape, wracam do trybu edycji i dyktuję głosem polecenie, żeby zapisał plan w katalogu projektu, w folderze .claude, w podfolderze z planami. Lubię trzymać plany razem z kodem projektu.
Ale sam plan mi nie wystarcza. Chcę szczegółowy plan wdrożenia, rozbity na pojedyncze funkcje — żeby dało się je realizować zespołowo albo jedną komendą w jednej sesji. Wciągam więc plan ponownie i proszę: rozwiń ten plan, stwórz szczegółowy plan wdrożenia, zapisz go w tym samym folderze pod nazwą implementation-plan.md. Następnie rozbij plan na poszczególne funkcje i zapisz je jako osobne pliki w katalogu projektu. Każdy plik funkcji ma zawierać szczegóły techniczne wdrożenia oraz kryteria akceptacji.
Zapewne zastanawiacie się, po co to wszystko. Czemu po prostu nie przekazać planu Claudowi i nie kazać go zrealizować? Po pierwsze, ten plan nie zawiera wystarczających informacji, by programista mógł na jego podstawie zbudować rzecz poprawnie. Jeśli macie doświadczenie programistyczne, zobaczycie po lekturze, że to projekt architektury aplikacji na bardzo wysokim poziomie. Nikt o tym nie mówi, ale gdybyście oddali taki plan prawdziwemu programiście, wyniki byłyby bardzo nierówne i część funkcji z dużym prawdopodobieństwem zostałaby pominięta.
Robiąc to, co robimy, zmuszamy agenta, żeby naprawdę przemyślał plan i sposób realizacji. I wierzcie mi — agent sam zorientuje się, że coś najprawdopodobniej pominął. W tej chwili, kiedy do was mówię, przechodzi właśnie przez rozumowanie o tym, które wersje bibliotek trzeba zainstalować. To zdrowy etap, przez który warto przejść.
(Informacja dodatkowa: autor odsyła tu do swojego bezpłatnego kursu i opisanego w nim własnego frameworku pracy z agentami kodującymi.)
Umożliwienie agentowi testowania własnej pracy
Kiedy agent pracuje, chcę mu przygotować grunt pod sukces. Jeśli pracujecie w IDE albo w terminalu, tak jak ja, trzeba zainstalować serwer MCP albo umiejętność, która pozwoli agentowi otworzyć aplikację w przeglądarce i fizycznie ją przetestować. Jeśli używacie aplikacji desktopowej Claude’a albo ChatGPT, mają one wbudowaną przeglądarkę i ten krok możecie pominąć.
Otwieram nową sesję Claude Code, wklejam adres i proszę o instalację serwera MCP Playwright. Wiem, że wielu z was woli przeglądarkę agentową albo umiejętność Playwright — to nie ma znaczenia, cokolwiek wolicie. Chodzi wyłącznie o to, żeby dać agentowi jakikolwiek sposób sprawdzenia własnej pracy.
Serwer zainstalował się na poziomie użytkownika, więc w katalogu projektu nie zobaczycie żadnych plików — za to Playwright będzie dostępny dla wszystkich moich agentów.
Kolejna rzecz to plik AGENTS.md / CLAUDE.md. Tworzę oba pliki: w CLAUDE.md po prostu odwołuję się do AGENTS.md, a sam AGENTS.md trzymam bardzo prosty. Dodaję sekcję „Testowanie aplikacji” i wpisuję: zawsze testuj aplikację przy użyciu serwera MCP Playwright — albo umiejętności Playwright, albo umiejętności przeglądarki agentowej, w zależności od tego, co zainstalowaliście. Dorzucam jeszcze jedną rzecz, którą lubię: używaj ponownie tych samych danych, nie twórz nowych danych użytkownika przy każdym teście, przechowuj je w pliku test-data.json — który też może leżeć w folderze .claude.
O co chodzi: kiedy agent testuje aplikację, otwiera ją w przeglądarce, próbuje się zalogować i orientuje się, że nie ma loginu ani hasła. Zakłada więc nowe konto testowe. Problem w tym, że przy następnym teście nie użyje tych samych danych, tylko będzie odtwarzał wszystko od zera. Ten zapis to naprawia.
Realizacja funkcji
Agent tymczasem utworzył wszystkie pliki funkcji. Wychodzę z Claude Code, żeby serwer MCP zaczął działać, i uruchamiam go ponownie. W trybie edycji porządkuję folder z planami — tworzę podfolder „foundation” i przenoszę do niego pliki funkcji oraz plan wdrożenia.
Dalej zależy to od agenta, którego używacie. Jeśli korzystacie z tańszych modeli albo modeli otwartoźródłowych, radzę po prostu przeciągnąć plik z planem wdrożenia razem z jednym plikiem funkcji i poprosić agenta o zrealizowanie tej jednej funkcji. Po zakończeniu wyczyśćcie rozmowę, wciągnijcie plan wdrożenia z kolejną funkcją i powtarzajcie cykl aż do końca.
Jeśli używacie Codeksa albo Claude Code, alternatywą jest uruchomienie komendy realizującej cały cel naraz. Wciągam folder „foundation” i piszę: zrealizuj wszystkie funkcje z tego folderu, nie zatrzymuj się, dopóki wszystko nie zostanie wdrożone i przetestowane. I to tyle — można odejść od komputera i pozwolić agentowi pracować.
Kiedy sprawdzam postęp, agent prowadzi testy end-to-end przez serwer MCP Playwright: otwiera okno przeglądarki i przechodzi przez aplikację od początku do końca, żeby upewnić się, że wszystko działa. Po zakończeniu mam w pełni działający system. Loguję się, tworzę organizację, dostaję tablicę kanban. Dodaję zadanie „kup chleb”, zapisuję, a po kliknięciu w zadanie mogę przypisać do niego osobę i uzupełnić dodatkowe informacje.
Wdrożenie na produkcję
Sama aplikacja nie jest tu jednak sednem. Naprawdę interesuje nas serwer MCP i konektor Claude’a. Zanim jednak do tego przejdziemy, musimy wdrożyć aplikację na produkcję. Żeby Claude — a zwłaszcza Claude w przeglądarce — mógł wykryć waszą aplikację, musi ona działać pod publicznym adresem URL. W przeciwnym razie Claude nie ma żadnej możliwości zobaczenia aplikacji działającej na waszym własnym sprzęcie.
Na szczęście jest to bardzo proste i darmowe. Przechodzę przez ten etap szybko (autor odsyła do osobnego, pełnego materiału z własnego kursu).
Najpierw tworzę repozytorium GitHub — nazywam je „Claude connector repository” i ustawiam jako publiczne, żebyście mogli sobie ten projekt obejrzeć i skopiować. Po otwarciu na GitHubie widać, że cały kod z mojej maszyny został wypchnięty do zdalnego repozytorium. To służy też jako kopia zapasowa kodu.
Kod nie jest jeszcze jednak dostępny publicznie. Kolejny krok to wdrożenie u firmy hostingowej — używam Vercela, który jest darmowy i bardzo prosty w konfiguracji. Wchodzę na vercel.com, zakładam konto i loguję się, klikam „Add New Project”, wyszukuję nowo utworzony projekt i importuję go. Wracam do projektu, otwieram plik ze zmiennymi środowiskowymi i kopiuję wszystkie wartości.
Trzeba jednak wprowadzić kilka zmian. Adres bazy Postgres wskazuje teraz na localhost, co jest błędne — musimy wskazać bazę działającą w chmurze, bo nie możemy używać czegoś, co działa na naszej maszynie. To również jest proste: wracam do panelu Vercela w drugiej karcie, wchodzę w „Storage”, tworzę nową bazę danych, wybieram Neon Serverless Postgres, przechodzę dalej, nadaję nazwę, tworzę. Kolejny krok pomijam, a następnie klikam „Show secret”, wyszukuję zmienną z adresem Postgresa i kopiuję wszystko po znaku równości. Wracam do zmiennych i ustawiam nową wartość.
Na razie to jedyna zmiana. Do zmiennej z adresem bazowym Better Auth wrócimy, kiedy poznamy wygenerowaną domenę — obecnie wciąż wskazuje na localhost. Klikam „Deploy”.
Projekt został wdrożony. Wracam do panelu, kopiuję wygenerowaną domenę, wchodzę w zmienne środowiskowe, edytuję adres bazowy Better Auth, wstawiam tam tę domenę, zapisuję zmianę i wdrażam ponownie, żeby nowe wartości zaczęły obowiązywać.
Diagnozowanie błędu na produkcji
Zmiany zostały zastosowane. Otwieram domenę i sprawdzam, czy wszystko działa — aplikacja jest teraz pod publicznym adresem, więc każdy, kto zna ten URL, ma do niej dostęp. Klikam „Get started”, próbuję założyć konto — i zauważam, że to nie działa. Zamiast pominąć ten fragment, pokażę wam, jak diagnozować takie problemy.
W takich sytuacjach wracam do Vercela, w projekcie wchodzę w „Logs” i szukam czerwonych wpisów. Po kliknięciu można je skopiować. Wracam do Claude’a i piszę: próbowałem wdrożyć na Vercela i przy próbie zalogowania dostaję taki błąd — po czym wklejam cały tekst.
Rozwiązaniem okazała się komenda budowania, czyli polecenie uruchamiane przez Vercela przy wdrożeniu projektu na ich serwer. Zawierała tylko next build. Claude dopisał do niej migrację bazy danych, dzięki czemu przy wdrożeniu tworzone są tabele w bazie. Aplikacja padała na produkcji właśnie dlatego, że tabel w bazie jeszcze nie było — nie uruchomiliśmy migracji.
Kod źródłowy jest dostępny w opisie filmu, więc możecie po prostu przekopiować moją komendę budowania do swojego projektu. Jeśli pamiętam, zaktualizuję też o tę zmianę umiejętność do startu nowej aplikacji.
Tym razem udaje mi się założyć konto. Nazywam je „claude demo”, tworzę organizację i pierwszą kartę: „create claude connections tutorial”. Dodaję kartę i gotowe.
Jak to działa: serwer MCP i warstwa uwierzytelniania
To jest przepływ pracy, który wszyscy znacie. Zbudowaliśmy aplikację, działa na produkcji, może nawet macie już prawdziwych użytkowników. I w tym momencie możecie zdecydować, że chcecie udostępnić tę aplikację agentom AI przez serwer MCP — a w tym materiale również jako konektor Claude’a.
Na szczęście to bardzo proste. Wracam do projektu i instaluję kilka zależności, które pomogą agentowi to ogarnąć. Instalujemy dwie nowe umiejętności. Pierwsza to umiejętność Better Auth — wchodzę na jej stronę i uruchamiam komendę instalacyjną w projekcie, wybierając Claude Code i poziom projektu. Druga to umiejętność MCP Buildera — kopiuję komendę i uruchamiam ją w terminalu. Ta druga da agentowi obszerną dokumentację referencyjną na temat budowania serwerów MCP.
Zasada działania jest taka. Mamy Claude’a — albo innego agenta, albo Codeksa, cokolwiek używacie — i musimy dać mu dostęp do naszej aplikacji, która działa na serwerze WWW i na tym etapie wymaga interfejsu użytkownika do jakiejkolwiek interakcji. Nie chcemy, żeby agent łączył się bezpośrednio z interfejsem użytkownika. Agent ma bezpośrednio wywoływać narzędzia dostępne w aplikacji.
Żeby to osiągnąć, wystawiamy zdalny serwer MCP. Serwer udostępnia narzędzia, które agent może wywołać, a te narzędzia w tle rozmawiają z aplikacją. Może na przykład istnieć narzędzie „utwórz koszt”, wystawione przez zdalny serwer MCP, a ten serwer wywołuje w aplikacji funkcję w rodzaju „utwórz wpis kosztowy”, która tworzy realny rekord w bazie danych i, dajmy na to, wgrywa plik.
Budowanie serwerów MCP potrafi być bardzo techniczne — jest tu mnóstwo ruchomych części. Prostszym rozwiązaniem jest zainstalowanie umiejętności, która nauczy agenta, jak zbudować serwer MCP; zawiera ona zestaw dokumentów referencyjnych, z których agent może się tego nauczyć.
Druga rzecz to dobre praktyki Better Auth. Better Auth to nasza biblioteka uwierzytelniania użytkowników — to dzięki niej użytkownicy bezpiecznie rejestrują się i logują w naszej aplikacji. Ale udostępnia ona coś, co jest bardzo ważne dla serwerów MCP. Claude nie może po prostu wywołać naszej aplikacji. Claude musi się najpierw w niej uwierzytelnić, żebyśmy wiedzieli, kim jest rzeczywisty użytkownik korzystający z agenta. Agent nie może też po prostu zalogować się do aplikacji — istnieje specjalny protokół, który to umożliwia, a Better Auth bardzo to ułatwia.
Wygląda to tak. Agent wywołuje serwer MCP. Serwer MCP mówi: „Nie mam pojęcia, kim jesteś. Wiem, że jesteś agentem próbującym pracować z tą aplikacją, ale za tym żądaniem musi stać ważne konto użytkownika”. Jeśli to ja korzystam z agenta, chcę, żeby Claude działał w moim imieniu — musi więc użyć mojego rzeczywistego, zalogowanego użytkownika.
Żeby zweryfikować to konto — czyli żeby agent się przedstawił i uwierzytelnił w naszej aplikacji — przechodzimy przez protokół OAuth. Użytkownik zostaje poproszony o uwierzytelnienie się i zatwierdzenie dostępu tego agenta do tej aplikacji. Kiedy użytkownik zatwierdzi żądanie, w aplikacji agenta albo w jego środowisku zapisywany jest bezpieczny token. Oznacza to, że wszystkie kolejne żądania będą przepuszczane przez warstwę OAuth i agent będzie miał dostęp do naszej aplikacji. W każdej chwili możemy odebrać dostęp do serwera MCP albo po stronie klienta po prostu zerwać to połączenie.
To są zatem nasze dwie ruchome części: musimy stworzyć serwer MCP i włączyć OAuth w warstwie uwierzytelniania. Brzmi to bardzo technicznie, ale obiecuję — jest naprawdę proste.
W opisie filmu udostępnię artykuł z oficjalnej dokumentacji Better Auth, wyjaśniający, jak działa wtyczka OAuth. Umiejętność Better Auth powinna to już zawierać, ale w chwili nagrywania panuje pewne zamieszanie, bo istnieje jeszcze przestarzała strona o MCP — opisuje ona, jak Better Auth uwierzytelniał dostawców MCP wcześniej. To się niedawno zmieniło i to właśnie ta druga strona jest teraz źródłem prawdy.
Prompt, który buduje serwer MCP
Wracam do sesji Claude Code i wysyłam następujący prompt:
Potrzebuję, żebyś stworzył zdalny serwer MCP dla naszej aplikacji. Ten serwer MCP ma wystawiać wszystkie narzędzia pozwalające agentowi AI na pełną interakcję z naszą aplikacją w imieniu użytkownika. Serwer MCP ma działać pod ścieżką:
domena/mcp.Masz do dyspozycji dwie umiejętności, które ci w tym pomogą: umiejętność Better Auth oraz umiejętność MCP Buildera. Dodatkowy kontekst znajdziesz na tej stronie — [adres dokumentacji dostawcy OAuth].
Bardzo ważne: ten serwer MCP ma również działać jako konektor Claude’a. — [adres artykułu Anthropic o podłączaniu serwerów MCP jako konektorów].
Ten ostatni adres bardzo pomoże agentowi. Nawiasem mówiąc, to jest normalne — to inżynieria kontekstu. Staramy się dać agentowi możliwie dużo kontekstu, żeby zbudował niezawodne rozwiązanie. Ten artykuł od Anthropic zawiera instrukcje, jak skonfigurować serwery MCP do podłączenia się do Claude’a jako konektor. Link znajdziecie w opisie filmu.
Jeśli macie istniejącą aplikację, którą chcecie udostępnić AI, to naprawdę jedyny prompt, jakiego potrzebujecie.
Weryfikacja i podłączenie konektora
Agent skończył wszystkie zmiany związane z MCP. Poprosiłem go też o utworzenie commita i wypchnięcie zmian na produkcję. Teraz piszę do Claude’a: właśnie wdrożyłem to na produkcję, sprawdź proszę serwer MCP, czy wszystko jest na miejscu — i wklejam adres zakończony /mcp. Przerwałem mu w trakcie, ale zdążył potwierdzić, że wszystko świeci na zielono.
Przy okazji: kiedy loguję się do aplikacji, mam teraz sekcję „Connections”. Pokazuje wszystkie podłączone aplikacje i agentów oraz nasz punkt końcowy połączenia.
Pozostaje sprawdzić, czy uda się dodać ten konektor do Claude’a. Klikam „Add connectors”, „Manage connectors”, potem „Add” i „Add custom connector”. Jako nazwę aplikacji wpisuję „Lanes”, wklejam nasz adres URL i klikam „Add”. Zostaję poproszony o połączenie z aplikacją — to dokładnie ten etap, na którym musimy uwierzytelnić się w niej sami. Klikam „Connect” i pojawia się dedykowana strona, którą zawdzięczamy Better Auth. Zezwalam Claude’owi na dostęp, dostaję potwierdzenie połączenia i zamykam kartę.
W Claudzie jesteśmy połączeni, a nasz agent ma dostęp do wszystkich narzędzi. Mamy zestaw narzędzi tylko do odczytu, a także narzędzia do zapisu i usuwania — jak tworzenie karty czy tworzenie linku zapraszającego. I znowu: możemy kontrolować dostęp do każdego z tych narzędzi. Albo od strony aplikacji, każąc Claude Code usunąć pewną funkcjonalność, albo z tego poziomu — możemy zdecydować, że dane narzędzie wymaga zatwierdzenia, że powinno być całkowicie zablokowane albo że ma być zatwierdzane automatycznie.
Test w praktyce
Otwieram nową sesję Claude’a — tym razem w aplikacji desktopowej. Warto pokazać, że działa to również w Claudzie w przeglądarce: mam go otwartego, wchodzę w konektory, w zarządzanie konektorami i widzę tam połączenie „Lanes”. Oznacza to, że jest ono dostępne w Claude Web, w aplikacji desktopowej Claude’a, a także w Claude Code.
Piszę: utwórz nowe zadanie w Lanes, nazwij je „update claude code course in Agentic Labs”. Claude prosi o zgodę na wywołanie narzędzi — wybieram „zawsze zezwalaj” — i dodaje nowe zadanie. Wracam do aplikacji i faktycznie tam jest.
Zadanie nie ma na razie przypisanej osoby, piszę więc: przypisz proszę to zadanie do mnie. Gotowe — karta jest przypisana. Sprawdzam: klikam w kartę i rzeczywiście, przypisana do Leona. To bardzo ważne. Agent, dzięki połączeniu OAuth, faktycznie wie, kim jesteście. Działa w tej aplikacji w waszym imieniu, więc wszystkie zmiany, jakie wprowadza, będą widoczne pod waszym użytkownikiem.
Piszę dalej: zmień status tego zadania na „doing”. Karta powinna przenieść się do kolumny „doing” — i przenosi się. Na koniec: wypisz wszystkie zadania przypisane do mnie. Gdybyśmy mieli w tej organizacji więcej członków, moglibyśmy przypisywać zadania również im. U mnie przypisane jest jedno zadanie: „update claude code course in Agentic Labs”.
(Informacja dodatkowa: na koniec autor zaprasza do swojej płatnej społeczności z kursem pracy z agentami kodującymi.)
10 najważniejszych takeaways — z kontekstem zastosowania
1.Własny konektor to sposób na ominięcie interfejsu użytkownika we własnej aplikacji
Na czym polega: Zamiast klikać po formularzach własnej aplikacji, wystawiasz zdalny serwer MCP i podpinasz go do Claude’a jako konektor. Agent wywołuje wtedy funkcje aplikacji bezpośrednio, a nie przez UI.
Jak stosować: Zacznij od jednego, najbardziej uciążliwego przepływu — takiego, który powtarzasz codziennie i który polega na wypełnianiu formularza. Właśnie ten wystaw jako pierwsze narzędzie MCP.
Na co uważać: Wystawiaj wyłącznie te funkcje, które świadomie chcesz udostępnić. Serwer MCP to nowa powierzchnia dostępu do twoich danych — wszystko, co tam wystawisz, agent może wywołać.
2.Aplikacja musi mieć publiczny adres URL
Na czym polega: Claude — zwłaszcza w wersji przeglądarkowej — nie ma żadnej możliwości dotarcia do serwera działającego na twoim komputerze. Konektor wymaga wdrożenia na produkcję.
Jak stosować: Planuj wdrożenie od początku projektu, nie po fakcie: GitHub jako repozytorium, Vercel (lub inny hosting) jako środowisko, baza danych w chmurze.
Na co uważać: Publiczny URL oznacza, że każdy, kto go zna, może otworzyć twoją aplikację. Kontrola dostępu i uwierzytelnianie muszą już wtedy działać, a nie „będą dorobione później”.
3.Wybór bazy danych podejmujesz raz i na długo
Na czym polega: Agent zapyta o SQLite albo Postgresa. SQLite trzyma dane w pliku w projekcie — świetnie dla aplikacji, która nigdy nie opuści twojego komputera. Postgres jest właściwym wyborem, jeśli planujesz produkcję.
Jak stosować: Jeśli w planach jest jakiekolwiek wdrożenie, od razu wybierz Postgresa (autor korzysta z Postgresa w Dockerze lokalnie i Neon Serverless Postgres na produkcji).
Na co uważać: To pytanie pojawia się w środku serii pytań doprecyzowujących i łatwo je przeklikać automatycznie. Późniejsza migracja z SQLite jest kosztowna.
4.Wysokopoziomowy plan nie nadaje się do implementacji
Na czym polega: Plan generowany przez agenta w trybie planowania to architektura na bardzo ogólnym poziomie. Oddany do realizacji — komukolwiek, człowiekowi czy agentowi — daje nierówne wyniki i pominięte funkcje.
Jak stosować: Zrób drugi krok: każ agentowi rozwinąć plan do szczegółowego planu wdrożenia i rozbić go na osobne pliki funkcji, każdy ze szczegółami technicznymi i kryteriami akceptacji.
Na co uważać: To dodatkowy koszt czasu i tokenów, którego łatwo uniknąć „na skróty” — ale to właśnie na tym etapie agent sam wyłapuje braki i ustala wersje bibliotek.
5.Trzymaj plany razem z kodem
Na czym polega: Autor zapisuje plany w katalogu projektu, w podfolderze .claude, i porządkuje je w podfoldery tematyczne.
Jak stosować: Kolokuj dokumenty planistyczne z kodem — dzięki temu wchodzą do repozytorium, wersjonują się razem z projektem i możesz je wciągać do kolejnych sesji jednym przeciągnięciem.
Na co uważać: Jeśli repozytorium jest publiczne, plany też będą publiczne. Nie umieszczaj w nich sekretów ani szczegółów, których nie chcesz pokazywać.
6.Agent musi umieć sam przetestować to, co zbudował
Na czym polega: Bez dostępu do przeglądarki agent nie zweryfikuje własnej pracy. Autor instaluje serwer MCP Playwright (alternatywnie: umiejętność Playwright lub przeglądarka agentowa) na poziomie użytkownika.
Jak stosować: Zainstaluj jedno z tych narzędzi globalnie, żeby było dostępne we wszystkich projektach, i zapisz w AGENTS.md regułę, że każda zmiana ma być przetestowana end-to-end.
Na co uważać: Serwer MCP zaczyna działać dopiero po restarcie sesji agenta. Aplikacje desktopowe Claude’a i ChatGPT mają wbudowaną przeglądarkę — tam ten krok jest zbędny.
7.Wymuś ponowne użycie danych testowych
Na czym polega: Bez wyraźnej instrukcji agent przy każdym teście zakłada nowe konto i odtwarza dane od zera. Autor wpisuje do AGENTS.md: używaj ponownie tych samych danych, trzymaj je w test-data.json.
Jak stosować: Dodaj tę regułę do pliku instrukcji od razu przy zakładaniu projektu, razem z lokalizacją pliku z danymi testowymi.
Na co uważać: Plik z danymi testowymi zawiera hasła. Trzymaj go poza repozytorium publicznym albo używaj wyłącznie danych jednorazowych.
8.Typowa pułapka wdrożenia: brak migracji w komendzie budowania
Na czym polega: Aplikacja wdrożyła się poprawnie, ale logowanie padało, bo w bazie produkcyjnej nie było jeszcze tabel — komenda budowania zawierała tylko next build, bez migracji.
Jak stosować: Dopisz uruchomienie migracji do komendy budowania na hostingu, żeby tabele powstawały przy każdym wdrożeniu. Gdy coś padnie, wejdź w logi hostingu, skopiuj czerwone wpisy i wklej je agentowi razem z opisem, co robiłeś.
Na co uważać: Automatyczne migracje przy każdym buildzie to wygoda, ale przy istniejącej bazie z prawdziwymi danymi migracja destrukcyjna zadziała równie automatycznie.
9.OAuth to nie formalność — to on decyduje, kim jest agent
Na czym polega: Agent nie „loguje się” do aplikacji. Przechodzi przez OAuth: użytkownik zatwierdza dostęp, w środowisku agenta zapisuje się bezpieczny token i od tej pory żądania przechodzą przez warstwę uwierzytelniania. Dzięki temu zmiany wprowadzone przez agenta są widoczne pod twoim kontem.
Jak stosować: Użyj biblioteki uwierzytelniania, która ma gotową wtyczkę dostawcy OAuth (autor korzysta z Better Auth) i sprawdź, czy sięgasz po aktualną dokumentację — starsza strona o MCP w Better Auth jest przestarzała, źródłem prawdy jest strona o dostawcy OAuth.
Na co uważać: Dostępu można w każdej chwili odebrać — po stronie aplikacji albo klienta. Warto mieć w aplikacji ekran pokazujący aktywne połączenia i faktycznie na niego zaglądać.
10.Kontroluj poszczególne narzędzia, zwłaszcza te zapisujące i usuwające
Na czym polega: Po podłączeniu konektora agent widzi wszystkie wystawione narzędzia — także zapisujące i usuwające, jak tworzenie karty czy generowanie linku zapraszającego. Każde da się zablokować, wymusić zatwierdzanie albo dopuścić automatycznie.
Jak stosować: Domyślnie zostawiaj automatyczne zatwierdzanie tylko narzędziom do odczytu. Dla operacji nieodwracalnych i tych o skutkach zewnętrznych wymagaj potwierdzenia.
Na co uważać: Kliknięcie „zawsze zezwalaj” przy pierwszym pytaniu — tak jak w demonstracji autora — wyłącza tę ochronę na stałe. Prawdziwy filtr powinien być po stronie aplikacji: nie wystawiaj narzędzia, którego agent nie ma prawa wywołać.