prymitywy MCP

Podstawowe typy możliwości w MCP. Po stronie serwera: narzędzia (funkcje do wywołania), zasoby (dane do odczytu po URI) i prompty (szablony). Po stronie klienta: elicitation, sampling i roots, przy czym dwa ostatnie zdeprecjonowano w specyfikacji 2026-07-28.

W Polsce nazywane też:

narzędzia zasoby promptymożliwości MCPtypy kontekstu MCP

MCP nie jest jednym mechanizmem, tylko kilkoma. Rozróżnienie między nimi decyduje o tym, co serwer może udostępnić, a czego nie — i jest pierwszą rzeczą, którą warto zrozumieć przed pisaniem własnego serwera.

Trzy prymitywy serwera

Narzędzia (Tools) to funkcje, które model może wywołać. Każde ma nazwę, opis i schemat argumentów. To jedyny prymityw wykonujący działania.

Zasoby (Resources) to dane do odczytania, identyfikowane adresem URI — pliki, rekordy, dokumenty. Nie wykonują niczego, tylko dostarczają treść do kontekstu.

Prompty (Prompts) to gotowe szablony, które serwer oferuje klientowi. Uruchamia je zwykle użytkownik, nie model.

Prymitywy klienta

Klient również może oferować możliwości serwerowi: elicitation, czyli pytanie użytkownika o dane w trakcie działania, sampling, czyli prośbę o wykonanie zapytania do modelu, oraz roots, czyli informację o tym, na jakich katalogach lub adresach serwer może operować.

W specyfikacji 2026-07-28 sampling, roots i logging zostały zdeprecjonowane. Pozostają w dokumencie na czas okna deprecjacji, ale nowe implementacje mają korzystać z parametrów narzędzi, bezpośrednich API dostawców oraz standardowych mechanizmów logowania.

Dlaczego to rozróżnienie ma znaczenie praktyczne

Wielu autorów serwerów udostępnia wszystko jako narzędzia, także dane, które powinny być zasobami. Skutkiem jest rozrost katalogu narzędzi, konkurencja opisów i spadek trafności wyboru. Dane, których model ma tylko użyć, a nie na nich działać, należą do zasobów.

Negocjacja możliwości

Przy nawiązaniu połączenia klient i serwer deklarują, które prymitywy obsługują i czy potrafią zgłaszać zmiany listy. Wersja specyfikacji jest ustalana w tym samym momencie i oznaczana datą.

wersjonowanie specyfikacji MCPWersje specyfikacji MCP oznaczane datą (np. 2025-11-25, 2026-07-28) i uzgadniane podczas inicjalizacji połączenia. Kolejne rewizje wprowadzały zmiany niewsteczne, więc serwer napisany pod jedną wersję nie musi działać z klientem obsługującym inną. Od 2026-07-28 obowiązuje polityka deprecjacji z minimum dwunastomiesięcznym oknem.dopytanie użytkownikaMechanizm MCP pozwalający serwerowi zatrzymać wykonanie i poprosić użytkownika o dane — doprecyzowanie, potwierdzenie, brakujący parametr. Zaprojektowany z człowiekiem w pętli: klient musi pokazać, który serwer pyta, i umożliwić odrzucenie. Pytanie może pojawić się wyłącznie w trakcie obsługi żądania zainicjowanego przez użytkownika.definicja narzędziaOpis narzędzia przekazywany modelowi: nazwa, opis słowny, schemat parametrów i pola wymagane. To jedyne, co model o narzędziu wie — więc opis jest promptem i decyduje o trafności wyboru. Trafia do kontekstu przy każdym obrocie pętli, więc jest też stałą pozycją w rachunku.przeciążenie narzędziamiSpadek trafności wyboru narzędzia wraz ze wzrostem liczby dostępnych narzędzi, połączony ze wzrostem kosztu każdego obrotu pętli. Wynika z tego, że wszystkie definicje trafiają do kontekstu przy każdym wywołaniu i konkurują ze sobą. Remedium: ładowanie warunkowe, grupowanie i rozdzielenie ról.Protokół kontekstu modeluOtwarty standard Anthropic umożliwiający agentom AI łączenie się z zewnętrznymi narzędziami, bazami danych i API w ustandaryzowany sposób — jak USB dla modeli językowych.