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.
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", …} }
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.
- Opis narzędzia zawiera
_meta.ui.resourceUriwskazujący na zasóbui://… - Host pobiera ten zasób z serwera — zwykle jest to spakowany HTML+JS+CSS
- Host renderuje go w piaskownicy
<iframe> - App i host rozmawiają przez
postMessage— własnym dialektem MCP z prefiksemui/*(np.ui/initialize), część metod (np.tools/call) jest współdzielona z core
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ć.
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.