MCP 2026protokół od zera · wydanie 2026-07-28
część III · warstwa opcjonalna · negocjowana capabilities

Rdzeń protokołu schudł. Extensions dowożą resztę.

Tasks, MCP Apps i Skills over MCP nie są już „eksperymentalnymi dodatkami do core" — są osobnymi, wersjonowanymi rozszerzeniami, które klient i serwer muszą jawnie wynegocjować.

Jak negocjuje się rozszerzenie

Extensions żyją w polu extensions wewnątrz capabilities — osobno po stronie klienta i serwera. Identyfikator MUSI mieć prefiks (te same zasady co klucze _meta), a pusty obiekt {} znaczy „wspieram, bez dodatkowych ustawień":

{ "capabilities": {
    "roots": {},
    "extensions": {
      "io.modelcontextprotocol/ui": { "mimeTypes": ["text/html;profile=mcp-app"] }
    }
  } }
{ "capabilities": {
    "tools": {},
    "extensions": { "io.modelcontextprotocol/tasks": {} }
  } }

Reguła fallbacku: jeśli jedna strona wspiera rozszerzenie, a druga nie — strona wspierająca MUSI albo wrócić do zachowania z rdzenia protokołu, albo odrzucić żądanie błędem. Nigdy nie „udawać", że wynegocjowano coś, czego druga strona nie zna.

Tasks — długo trwające operacje

Blokowanie połączenia na czas trwania operacji (CI pipeline, batch, zatwierdzenie przez człowieka) nie skaluje się — timeouty transportu i pośredników zabijają je po kilku-kilkunastu sekundach. Tasks dają serwerowi trwały uchwyt zamiast tego: taskId, po którym klient odpytuje.

cykl życia zadania — kliknij stan

Kliknij stan powyżej.

{ "result": {
    "resultType":"task",
    "task": { "taskId":"tsk_8f2a", "status":"working",
      "ttlMs":600000, "pollIntervalMs":2000 }
  } }
tasks/get { "taskId":"tsk_8f2a" }

{ "status":"completed", "result": {"resultType":"complete", } }
✅ Co to daje Twojemu serwerowi

Jeśli owijasz coś, co już ma własny system zadań (deploy w chmurze, kolejka), Tasks to naturalne mapowanie 1:1 — zwracasz istniejący job ID jako taskId i rozwiązujesz go, gdy zewnętrzny system skończy. Klient decyduje o pollingu; jeśli wspierasz notifications/tasks przez subscriptions/listen, oszczędzasz mu ciągłego odpytywania.

MCP Apps — interaktywne UI w rozmowie

Tekst nie wystarcza, gdy użytkownik ma kliknąć region na mapie albo przeciągnąć suwak budżetu. MCP Apps pozwalają serwerowi zwrócić prawdziwą, interaktywną stronę HTML, renderowaną w piaskownicy wewnątrz rozmowy — nie jako link, tylko jako część czatu.

Jak to działa
  1. Opis narzędzia zawiera _meta.ui.resourceUri wskazujący na zasób ui://…
  2. Host pobiera ten zasób z serwera — zwykle jest to spakowany HTML+JS+CSS
  3. Host renderuje go w piaskownicy <iframe>
  4. App i host rozmawiają przez postMessage — własnym dialektem MCP z prefiksem ui/* (np. ui/initialize), część metod (np. tools/call) jest współdzielona z core
Model bezpieczeństwa

App nie ma dostępu do DOM hosta, ciasteczek ani local storage. Zasób deklaruje _meta.ui.csp (dozwolone originy) i opcjonalnie permissions (np. mikrofon, kamera). Host kontroluje, które narzędzia app może wywołać.

💡 Nawet to się już zmieniło

Wcześniejsze robocze wersje tego rozszerzenia (SEP-1865, cytowane też w Twoich notatkach z bloga MCP) posługiwały się typem MIME text/html+mcp. Bieżąca dokumentacja negocjacji capabilities pokazuje już text/html;profile=mcp-app — sam mechanizm jest jeszcze młodszy niż reszta rewizji 2026-07-28 i wart śledzenia na bieżąco.

Skills over MCP working group

Trzecie wymienione rozszerzenie to sposób na przekazywanie bogatych, ustrukturyzowanych instrukcji dla przepływów pracy agenta — odkrywanych i konsumowanych przez MCP. W przeciwieństwie do Tasks i MCP Apps, na chwilę zbierania materiału do tego dokumentu żyje jako temat grupy roboczej społeczności, a nie zamknięta specyfikacja SEP — traktuj go jako kierunek, nie gotowy kontrakt do implementacji.