Podłączanie bazy danych, przeglądarki i zewnętrznych API przez MCP

Czego się nauczysz

• Gdzie i jak konfigurować serwery MCP w VS Code
• Jak myśleć o integracjach typu browser, database i API bez vendor lock-in
• Jak zarządzać trustem, enable/disable i zakresem działania serwerów

Najważniejsza decyzja nie brzmi: jaki serwer zainstalować

Brzmi: gdzie ten serwer ma żyć i jaki zakres ma dostać.

To od tego zależy, czy MCP stanie się użytecznym rozszerzeniem workflow, czy źródłem chaosu i zaufania rozdawanego za szeroko.

Masz dwa podstawowe miejsca konfiguracji

Docs pokazują dwa główne warianty:

• workspace: .vscode/mcp.json
• user profile: globalny mcp.json w profilu użytkownika

To rozróżnienie jest bardzo praktyczne.

Workspace-level ma sens, gdy:

• integracja jest częścią projektu
• chcesz współdzielić konfigurację z zespołem
• serwer powinien działać tylko w konkretnym repo

User-level ma sens, gdy:

• to Twoje prywatne narzędzie pomocnicze
• korzystasz z niego w wielu repozytoriach
• nie chcesz commitować konfiguracji do projektu

mcp.json to kontrakt operacyjny

W konfiguracji definiujesz serwery w obiekcie servers. Dla każdego określasz m.in.:

• sposób uruchomienia
• komendę i argumenty albo URL
• ewentualne środowisko i katalog roboczy
• opcjonalnie sandboxing

To nie jest tylko informacja dla VS Code. To jest jawna deklaracja, jakie zewnętrzne capability trafiają do Twojego workflow.

Zacznij od klas integracji, nie od produktów

Najzdrowszy sposób planowania MCP wygląda tak:

• browser / UI automation
• database / query context
• external API / operational data

Dopiero potem wybierasz konkretny serwer.

To porządkuje myślenie. Najpierw pytasz: czego agentowi naprawdę brakuje? Dopiero potem: z jakiego serwera to dostarczę?

Browser MCP to dobry przykład capability operacyjnego

Quickstart z Playwright MCP jest dobry, bo bardzo wyraźnie pokazuje przewagę MCP nad samym opisem tekstowym.

Agent nie tylko czyta o stronie. Potrafi:

• wejść na stronę
• wykonać akcje
• zrobić screenshot
• sprawdzić wynik

To jest właśnie różnica między agentem z ogólnym promptem a agentem z realnym capability.

Baza danych i API to zwykle dwa różne przypadki użycia

Przy bazie danych najczęściej zależy Ci na dwóch rzeczach:

• bezpiecznym, czytelnym kontekście
• ograniczonym dostępie do operacji

Przy API częściej chodzi o:

• pobieranie danych operacyjnych
• wykonywanie akcji na zewnętrznym systemie
• zasilanie promptu aktualnym stanem świata

Dlatego nie każda integracja powinna od razu być write-capable. Bardzo często read-only server daje większą wartość i mniejsze ryzyko.

Dodanie serwera to dopiero początek

Po konfiguracji musisz jeszcze ogarnąć cykl życia serwera:

• start i restart
• enable albo disable
• output log
• cache narzędzi

VS Code daje do tego kilka ścieżek:

• Extensions view
• MCP: List Servers
• code lensy w pliku mcp.json

To ważne, bo problemy z MCP bardzo często nie wynikają z pomysłu na integrację, tylko z banalnych problemów operacyjnych: serwer nie wstał, ma złą konfigurację albo zmienił capability i wymaga restartu.

Trust prompt nie jest formalnością

Gdy dodajesz albo zmieniasz serwer MCP w workspace, VS Code pyta, czy mu ufasz. I słusznie.

Lokalny serwer MCP może uruchamiać dowolny kod na Twojej maszynie. Jeśli traktujesz trust prompt jak kolejne okno do przeklikania, to omijasz najważniejszy punkt kontroli.

Warto przyjąć prostą zasadę:

• najpierw czytam konfigurację
• potem oceniam źródło serwera
• dopiero potem uruchamiam

Enable albo disable to też narzędzie architektoniczne

Nie każdy serwer musi działać cały czas.

To bardzo ważny nawyk: aktywuj tylko te capability, które są potrzebne dla aktualnego typu pracy.

Jeśli robisz refaktor backendu, browser automation prawdopodobnie nie jest Ci potrzebne. Jeśli testujesz UI, baza danych może być zbędna. Mniej aktywnych serwerów to:

• mniej szumu w tool pickerze
• mniejsza powierzchnia zaufania
• lepsze skupienie agenta

Sandbox i sekrety wymagają dyscypliny

Docs wprost odradzają hardcode’owanie sekretów. Zamiast tego sugerują input variables albo env files.

W przypadku lokalnych serwerów stdio można też rozważyć sandboxing, ale trzeba pamiętać o ograniczeniu: na Windows ta warstwa nie działa.

To znaczy, że na Windows główna ochrona to nadal dobra konfiguracja, jawny trust i rozsądny dobór serwerów.

Ćwiczenie praktyczne

Zaprojektuj własne mcp.json dla projektu, w którym agent ma mieć dostęp do:

• przeglądarki albo testów UI
• jednego zewnętrznego API

Odpowiedz:

• co trzymasz w .vscode/mcp.json, a co na poziomie user profile
• które serwery mają być stale włączone, a które tylko okazjonalnie
• jak przechowujesz dane uwierzytelniające
• które capability powinny być tylko read-only

Kluczowe wnioski

• Najpierw projektujesz klasę integracji, dopiero potem wybierasz konkretny serwer MCP.
• mcp.json definiuje realny zakres capability i zaufania, nie tylko techniczną konfigurację.
• Workspace-level i user-level służą do różnych typów workflow.
• MCP trzeba aktywnie zarządzać: startem, restartem, trustem, enable/disable i logami.

Co dalej

Skoro wiesz już, jak konsumować serwery MCP, pora odwrócić perspektywę: jak zaprojektować własny serwer, żeby agent dostał naprawdę użyteczne tools, resources i prompts.