Model Context Protocol: architektura i koncepcja

Czego się nauczysz

• Czym MCP jest naprawdę, a czym nie jest
• Jak wygląda model klient-serwer między VS Code a serwerem MCP
• Jakie capability poza tools daje dziś MCP w praktyce

MCP to nie “plugin do AI”

To częsty skrót myślowy i warto go od razu wyprostować.

Model Context Protocol to otwarty standard łączenia modeli i agentów z zewnętrznymi narzędziami oraz usługami. VS Code jest klientem MCP. Serwer MCP wystawia capability, które klient potrafi odkryć i wykorzystać.

To oznacza, że MCP nie jest funkcją jednego vendora i nie jest tylko sztuczką do dołączenia Playwrighta. To warstwa integracyjna.

Mentalny model: VS Code jako klient, serwer jako dostawca capability

Najprostszy model wygląda tak:

• VS Code uruchamia albo łączy się z serwerem MCP
• serwer ogłasza, jakie capability udostępnia
• agent w VS Code może używać ich w czasie realizacji zadania

W praktyce agent nie rozmawia bezpośrednio z bazą, przeglądarką czy API. Rozmawia z narzędziem, które zostało wystawione przez serwer MCP.

To rozdzielenie jest ważne, bo od razu ustawia granice odpowiedzialności.

MCP daje więcej niż tools

Jeśli myślisz o MCP tylko jako o nowych toolach w pickerze, widzisz tylko część obrazu.

Aktualne docs opisują co najmniej te capability:

• tools
• resources
• prompts
• sampling
• authorization
• roots
• MCP Apps

To zmienia sposób myślenia o integracji.

Tools wykonują operacje. Resources dostarczają kontekst. Prompts dają gotowe workflow. Sampling pozwala serwerowi korzystać z modeli użytkownika. MCP Apps mogą zwrócić interaktywny UI w czacie.

Transport też ma znaczenie

VS Code wspiera przede wszystkim:

• stdio
• http
• sse jako legacy

To nie jest detal implementacyjny bez znaczenia.

stdio jest naturalne dla lokalnych serwerów uruchamianych procesem. http ma sens dla serwerów zdalnych. Od tego zależą potem kwestie deploymentu, auth, sandboxingu i operacyjnego utrzymania.

Narzędzia, zasoby i prompty to trzy różne rzeczy

To rozróżnienie jest krytyczne.

Tool odpowiada za akcję: coś sprawdza, zapisuje, pobiera albo analizuje.

Resource dostarcza dane jako kontekst. Użytkownik może je dołączyć do promptu albo otworzyć bezpośrednio w VS Code.

Prompt to gotowy szablon rozmowy wystawiany przez serwer jako slash command.

Jeśli wrzucasz wszystko do jednego worka “narzędzia MCP”, potem bardzo trudno projektować serwer sensownie.

Gdzie MCP siedzi względem innych sposobów rozszerzania VS Code

W dokumentacji deweloperskiej jest dobra wskazówka: jeśli potrzebujesz głębokiej integracji z API VS Code i dystrybucji przez Marketplace, czasem lepszym wyborem będzie extension tool. Jeśli chcesz przenośny serwer działający także poza samym VS Code, MCP jest naturalnym kierunkiem.

Najprościej:

• built-in tools: to, co daje samo VS Code
• extension tools: integracja mocno osadzona w ekosystemie rozszerzeń
• MCP: otwarty interfejs do zewnętrznych capability

Quickstart z Playwrightem dobrze pokazuje ideę

Docs wykorzystują Playwright MCP jako przykład startowy i to nieprzypadkowo.

To pokazuje pełną ścieżkę wartości:

• instalujesz serwer
• potwierdzasz trust
• VS Code odkrywa toolsy
• agent zaczyna używać nowych capability w naturalnym workflow

Czyli MCP nie zmienia tego, jak prosisz agenta o zadanie. Zmienia to, co agent ma realnie do dyspozycji.

MCP to standard rozszerzania, nie gwarancja jakości integracji

Samo wdrożenie MCP nie oznacza jeszcze, że integracja jest dobra.

Dopiero projekt capability decyduje, czy agent będzie skuteczny:

• czy tool jest atomowy
• czy resource jest czytelny
• czy prompt jest sensownie nazwany
• czy auth jest poprawnie rozwiązane

MCP daje wspólny język. Nie daje za Ciebie dobrej architektury.

Kluczowe wnioski

• MCP to otwarty standard łączenia agentów z zewnętrznymi capability.
• VS Code pełni rolę klienta, a serwer MCP dostarcza narzędzia, zasoby, prompty i inne funkcje.
• MCP nie ogranicza się do tools; obejmuje też resources, prompts, auth, sampling i MCP Apps.
• Najważniejsza korzyść MCP polega na rozszerzeniu realnych możliwości agenta bez zmiany samego modelu pracy w czacie.

Co dalej

Masz już mentalny model MCP. Następny krok to praktyka: jak konfigurować serwery MCP w VS Code i jak sensownie podłączać przeglądarkę, bazy danych i zewnętrzne API do codziennej pracy z agentem.