App Intents kontra MCP: pytanie o routing

Dwa protokoły, App Intents i MCP, pozwalają zewnętrznemu agentowi obsługiwać domenę aplikacji. Nie sprowadzają się jednak do jednego. Pytanie brzmi: co trafia gdzie i dlaczego każdy z protokołów jest właściwą odpowiedzią dla swojego własnego wywołującego.

Apple wypuściło App Intents, aby dać Apple Intelligence typowaną, deklaratywną powierzchnię do obsługi aplikacji innych producentów bez dotykania ich interfejsu.¹ Anthropic wypuściło Model Context Protocol, aby dać dowolnemu LLM typowaną powierzchnię pośredniczoną przez serwer, pozwalającą obsłużyć dowolne narzędzie bez dotykania jego interfejsu.² Kształty są podobne. Wywołujący już nie. Traktowanie ich jako jednej powierzchni daje architekturę, która nie zadowala żadnego z nich.

Dwa wcześniejsze wpisy w tym klastrze omawiały każdy protokół osobno: App Intents w tekście App Intents to nowe API Apple do Twojej aplikacji, a MCP w tekście Dwa ekosystemy agentów, jedna lista zakupów. Niniejszy wpis dotyczy pytania o routing. Kiedy dana funkcja dostaje AppIntent, kiedy dostaje narzędzie MCP, kiedy dostaje jedno i drugie, a co pozostaje wystawione wyłącznie wewnątrz aplikacji?

TL;DR

• App Intents to jedyna droga do Apple Intelligence, Siri, Shortcuts oraz systemowego stosu podpowiedzi. System udostępnia je od momentu instalacji i wraz z aktualizacjami aplikacji; donacja i indeksowanie App Shortcuts wprowadzają je do Spotlight i do podpowiedzi Siri.
• Narzędzia MCP to droga do każdego LLM spoza Apple (Claude, ChatGPT, Gemini, modele lokalne). Transportem jest stdio albo Streamable HTTP, a .mcpb to format pakowania, który zwykle dostarcza lokalny serwer stdio; host ładuje narzędzia na początku sesji. Obowiązująca rewizja specyfikacji to 2025-11-25, a release candidate z 2026-07-28 przebudowuje protokół wokół bezstanowego rdzenia⁶⁷.
• Oba protokoły zbiegają się przy typowanym schemacie, kształcie entity → action → result i rozwiązywaniu parametrów. Rozchodzą się przy tożsamości, trwałości, opóźnieniu i powierzchni prezentacji.
• Reguła routingu: jeśli funkcja jest czymś, o co użytkownik mógłby poprosić Siri albo co mógłby wywołać ze Spotlight, wybieramy App Intents. Jeśli funkcja jest czymś, co deweloper mógłby podpiąć do sesji Claude Code albo do uruchomienia zewnętrznego agenta, wybieramy MCP. Większość aplikacji potrzebuje obu rozwiązań dla tej samej domeny.

Dwa protokoły, ten sam kształt

Oba protokoły definiują kontrakt operacyjny między zewnętrznym wywołującym a domeną aplikacji. Kontrakt składa się z trzech części: schematu (o co wywołujący może poprosić), resolwera (jak aplikacja znajduje encje nazwane w schemacie) oraz akcji (co się wykonuje i co wraca).

App Intents wyrażają kontrakt w Swifcie. Powierzchnię protokołu tworzą AppIntent, AppEntity i AppEnum, przy czym makra @Parameter napędzają schemat, a func perform() zwraca wynik.³ Schemat powstaje w czasie kompilacji i zostaje dołączony do aplikacji przy instalacji. Apple Intelligence, Siri, Shortcuts i Spotlight czytają ten sam schemat i kierują typowane żądanie przez ten sam punkt wejścia perform().

MCP wyraża kontrakt w JSON-RPC po stdio albo Streamable HTTP. Powierzchnię protokołu tworzą metody tools/list i tools/call, a każde narzędzie deklaruje nazwę, opis oraz inputSchema (specyfikacja 2025-06-18 dodała opcjonalny outputSchema dla ustrukturyzowanych zwrotów, a rewizja 2025-11-25 ustanawia JSON Schema 2020-12 jako dialekt domyślny, dodaje ikony narzędzi jako metadane i formalizuje zarządzanie poza Anthropic).⁴⁶ Host MCP (Claude Desktop, Claude Code, Cursor, aplikacja desktopowa ChatGPT) wykrywa narzędzia na starcie sesji i wywołuje je po nazwie z ładunkiem JSON. Host uruchamia model, serwer uruchamia narzędzie. Protokół znajduje się przy tym w trakcie przemiany: release candidate z 2026-07-28 przebudowuje MCP wokół bezstanowego rdzenia działającego na zwykłej infrastrukturze HTTP, przenosi długo trwającą pracę do rozszerzenia Tasks i dodaje interfejs renderowany po stronie serwera przez MCP Apps⁷. Poniższy argument o routingu przechodzi tę rewizję bez szwanku, ponieważ nic w niej nie zmienia tego, kim jest wywołujący.

Kształt jest ten sam: schemat, resolwer, akcja. Różnica polega na tym, kto wykonuje każdy z elementów i gdzie przebiega granica zaufania. App Intents działają w procesie aplikacji, na urządzeniu użytkownika, w ramach uprawnień aplikacji, a system pośredniczy w kierowaniu wywołań. Serwery MCP działają tam, gdzie zdecydował się je uruchomić deweloper (lokalne stdio, hostowany HTTP, osadzony bundle), a w kierowaniu wywołań po nieograniczonym zbiorze narzędzi pośredniczy model hosta.

Warto nazwać trzeciego wywołującego o tym samym kształcie, bo dopełnia on obraz: model działający na urządzeniu, stojący za frameworkiem Foundation Models firmy Apple, wywołuje kod aplikacji przez swój protokół Tool — nazwaną, opisaną, typowaną funkcję, dokładnie jak dwa pozostałe. Dobrze wykrojona warstwa domenowa zasila wszystkie trzy powierzchnie, nie wiedząc, która właśnie wywołuje.

Gdzie oba protokoły się rozchodzą

Poza kształtem powierzchni dla routingu liczą się cztery różnice operacyjne:

Tożsamość i trwałość. App Intents mówią typami AppEntity, które system potrafi przechować, zaprezentować i później ponownie rozwiązać. Wpis o wodzie, który zapisuję dziś przez Hej Siri, zapisz 250 ml w Water, przetrwa ponowne uruchomienia, synchronizuje się między urządzeniami iCloud użytkownika i może zostać później przywołany przez inne intenty (Pokaż mi wczorajsze wpisy o wodzie). System śledzi identyfikator encji we wszystkich tych wywołaniach,³ a iOS 27 rozciąga tę opowieść na sprzęt: encja zgodna z SyncableEntity niesie identyfikator spójny między urządzeniami użytkownika, dzięki czemu Siri potrafi przekazać rozmowę o tym samym obiekcie z iPhone’a na Maca, a dalej na Watcha.⁸ MCP samo w sobie jest protokołem stanowym z zarządzaniem cyklem życia, a Streamable HTTP obsługuje identyfikatory sesji dla ciągłości połączenia, jednak trwała tożsamość domenowa pozostaje sprawą serwera; na poziomie protokołu nie ma odpowiednika identyfikatorów AppEntity, na którym model hosta mógłby polegać między sesjami. MCP udostępnia resources dla trwałych danych referencyjnych, a specyfikacja 2025-11-25 dodaje eksperymentalne taski do śledzenia trwałych żądań, jednak tożsamość obiektów domenowych pozostaje odpowiedzialnością po stronie serwera, a nie pełnoprawnym kontraktem protokołu.⁴⁶ Leżąca u podstaw dyscyplina jest ta sama, która obowiązuje we własnej warstwie danych aplikacji: stabilne identyfikatory przeżywające proces, opisane dla SwiftData w tekście o dyscyplinie schematu.

Opóźnienie i bateria. Ciało perform() w App Intent wykonuje się w kontekście aplikacji lub jej rozszerzenia, na urządzeniu. Każde użycie sieci pochodzi z własnego kodu aplikacji albo z otaczającej warstwy Apple Intelligence/Siri, a nie z samego kontraktu intentu. Typowana akcja na urządzeniu, zwracająca typowany wynik, jest w typowym przypadku szybka. Narzędzia MCP, nawet lokalne, przechodzą przez ramkowanie JSON-RPC po stdio z osobną granicą procesu, a zdalne narzędzia MCP kosztują rundy HTTP. Budżet opóźnienia jest inny. App Intent typu zapisz 250 ml może zdążyć w oknie jednej tury rozmowy z Siri. Zdalne narzędzie MCP może okazać się wąskim gardłem sesji Claude Code.

Powierzchnia prezentacji. App Intents zwracają wyniki, które Apple Intelligence renderuje w interfejsie systemu: baner na ekranie blokady, odpowiedź Siri, wyjście Shortcuts, wynik w Spotlight. Aplikacja nie decyduje o tym, jak wynik zostanie zaprezentowany. Narzędzia MCP zwracają bloki treści (tekst, obrazy, audio, osadzone zasoby albo treść ustrukturyzowaną), które model hosta czyta i o których prezentacji sam rozstrzyga. Sesja Claude Code może zacytować wynik deweloperowi, streścić go albo podać do kolejnego wywołania. Decyzja o prezentacji zapada na poziomie modelu.

Odkrywalność. Apple Intelligence udostępnia App Intents od instalacji wzwyż; donacja i indeksowanie App Shortcuts wprowadzają intenty do wyszukiwań Spotlight i podpowiedzi Siri w oparciu o zachowanie użytkownika, a aktualizacje aplikacji oraz encje dynamiczne z czasem korygują tę powierzchnię. Użytkownik nigdy nie wpisuje nazwy narzędzia. Hosty MCP czytają narzędzia na starcie sesji; to użytkownik (albo prompt systemowy) decyduje, które narzędzia model może zobaczyć. Po stronie MCP odkrywanie to jawna konfiguracja, po stronie App Intents — niejawne wnioskowanie systemu.

Oba protokoły rozchodzą się przy tożsamości, opóźnieniu, prezentacji i odkrywaniu: cztery własności wynikają z jednego rozróżnienia u korzenia. App Intents obsługują agenta na poziomie systemu, którego użytkownik nie konfigurował. MCP obsługuje agenta na poziomie sesji, którego deweloper skonfigurował. Inni wywołujący, inne zobowiązania.

Reguła routingu

Mapa funkcji aplikacji korzystającej z obu protokołów wygląda tak:

                    ┌──────────────────────────────────────────┐
                    │           App's domain capabilities       │
                    │                                            │
                    │  ┌─────────┐  ┌─────────┐  ┌─────────┐    │
                    │  │  CRUD   │  │ Queries │  │ Actions │    │
                    │  └─────────┘  └─────────┘  └─────────┘    │
                    └────┬────────────┬────────────┬────────────┘
                         │            │            │
              ┌──────────┴──────┐    │   ┌────────┴──────────┐
              │                 │    │   │                   │
              ▼                 ▼    ▼   ▼                   ▼
       ┌────────────┐    ┌─────────────────────┐    ┌──────────────┐
       │ App Intents │    │ Both (AppIntent +   │    │  MCP tools   │
       │   only      │    │  MCP tool wrapper)  │    │    only      │
       └────────────┘    └─────────────────────┘    └──────────────┘
            │                       │                       │
       Siri / Spotlight       Cross-protocol           Claude Code,
       Shortcuts              capabilities             external agents,
       Apple Intelligence     where both callers       LLM tooling,
       proactive surfaces     should reach the         dev workflows
                              same domain

Reguła routingu to trzy pytania, po kolei.

Czy funkcja jest czymś, o co użytkownik poprosiłby Siri albo co wywołałby ze Shortcuts? Jeśli tak, funkcja potrzebuje App Intent. Zapisz 250 ml wody, Rozpocznij medytację, Dodaj banany do mojej listy, Ile ważyłem wczoraj to intenty, ponieważ użytkownik może wypowiedzieć je na głos, wpisać w Spotlight albo połączyć w łańcuch w Shortcuts. Dla takich funkcji App Intent nie jest opcjonalny; nic innego nie prowadzi do własnej powierzchni agenta Apple Intelligence.

Czy funkcja jest czymś, czym powinien móc sterować zewnętrzny agent? Jeśli tak, funkcja potrzebuje narzędzia MCP. Dodanie pozycji do listy zakupów z sesji Claude Code, Wczytanie stanu Get Bananas do kontekstu agenta Cursor, Uruchomienie workflow ze zdalnego LLM korzystającego z narzędzi to narzędzia MCP, ponieważ wywołującym nie jest Apple Intelligence; wywołującym jest ten LLM, który podpiął deweloper. Narzędzie MCP może opakować tę samą funkcję Swift z warstwy domenowej, którą wywołuje App Intent, ale powierzchnią protokołu jest JSON-RPC po transporcie wybranym przez dewelopera.

Czy funkcja musi przetrwać pojedynczą sesję ze stabilną, znaną systemowi tożsamością? Jeśli tak, droga przez App Intent pasuje naturalnie, bo system daje za darmo tożsamość AppEntity, obsługę zapytań i semantykę trwałości. Jeśli nie, narzędzie MCP może zwrócić blok treści, zostawić trwałą tożsamość uznaniu serwera i oszczędzić sobie kosztu modelowania encji.

Większość nietrywialnych funkcji aplikacji ląduje w kolumnie jedno i drugie. Funkcja zapisu wody w aplikacji Water ma AppIntent (żeby Siri mogła przyjąć dyktowanie) oraz narzędzie MCP (żeby sesja Claude Code mogła uzupełnić dane z wyeksportowanego dziennika). Obie drogi dzielą jedną funkcję Swift; funkcja nie wie, który wywołujący ją uruchomił.⁵

W kodzie kształt wygląda jak jedna metoda domenowa i dwa opakowania adapterów, które obie ją wywołują:

// Domain layer (Swift, no protocol assumptions)
func logWater(amount: Measurement<UnitVolume>, at: Date, caller: Caller) throws -> WaterEntry {
    try guards.requireWritePermission(caller)
    let entry = WaterEntry(amount: amount, timestamp: at)
    try store.insert(entry)
    return entry
}

// Adapter 1: App Intent (Apple Intelligence / Siri / Shortcuts)
struct LogWaterIntent: AppIntent {
    static var title: LocalizedStringResource = "Log Water"
    @Parameter(title: "Amount") var amount: Measurement<UnitVolume>

    func perform() async throws -> some IntentResult & ReturnsValue<WaterEntry> {
        let entry = try domain.logWater(amount: amount, at: .now, caller: .siri)
        return .result(value: entry)
    }
}

// Adapter 2: MCP tool (Claude Desktop / Code / external agent)
// Tool name "log_water" with inputSchema {amount_ml: number}
// Handler:
let entry = try domain.logWater(
    amount: .init(value: ml, unit: .milliliters),
    at: .now,
    caller: .mcp(host: hostName)
)
return .text("Logged \(entry.amount) at \(entry.timestamp)")

Oba adaptery wyglądają inaczej, bo różnią się ich wywołujący. Funkcja, którą wywołują, jest ta sama.

Co zostaje w aplikacji

Niewielki, lecz istotny zbiór funkcji powinien pozostać prywatny dla aplikacji. Kierowanie ich do któregokolwiek z protokołów jest błędem.

Funkcje stanu interfejsu. „Otwórz trzecią kartę”, „przewiń na sam dół”, „podświetl ten wiersz” nie są operacjami domenowymi. To prymitywy interakcji. App Intents obsługują część tego przez OpensIntent i Shortcuts, ale gatunkowo pasuje to słabo; użytkownik zwykle chce wyniku, a nie nawigacji. Obsługa nawigacji po interfejsie w MCP wypada jeszcze gorzej: model nie prowadzi ekranu, prowadzi narzędzie.

Funkcje wymagające obecności człowieka. Robienie zdjęć, uwierzytelnianie biometryczne, wprowadzanie wrażliwych danych osobowych, każdy przepływ wymagający, by użytkownik spojrzał na ekran i dotknął go. CameraCaptureIntent firmy Apple istnieje dla przepływów aparatu, lecz intencją projektową jest uruchomienie aktywności przechwytywania na pierwszym planie, a nie przyznanie agentowi dostępu do kamery w tle. Uczciwa reguła dla obu protokołów: aparat, biometria i wprowadzanie danych wrażliwych powinny działać jako interfejs na pierwszym planie z wyraźnym potwierdzeniem użytkownika, a nie jako ciche wywołania intentu lub narzędzia. Warto trzymać te funkcje za interfejsem aplikacji i pozwolić agentowi doprowadzić użytkownika do ekranu, a nie przez niego.

Długo trwająca praca w tle. Oba protokoły zyskały tu realne prymitywy, a rachunek przesunął się z „nigdy” do „z maszynerią protokołu, świadomie”. Po stronie Apple LongRunningIntent w iOS 27 pozwala intentowi działać poza systemowym limitem 30 sekund w tle, pod warunkiem że raportuje postęp (protokół uszczegóławia ProgressReportingIntent), a Live Activities ten postęp prezentują⁸. Po stronie MCP specyfikacja 2025-11-25 dodaje eksperymentalne taski dla trwałych żądań z odpytywaniem i odroczonym odbiorem wyniku, awansowane do rozszerzenia Tasks w release candidate z 2026-07-28⁶⁷. Uczciwa granica brzmi teraz tak: należy sięgać po te prymitywy, gdy wywołujący sam zainicjował pracę i chce ją obserwować; warto zaś trzymać pracę za własnym interfejsem aplikacji, gdy „postęp” potrzebny odbiorcy jest bogatszy niż procent albo gdy model hosta przekroczyłby limit czasu swojego łańcucha rozumowania, czekając na wynik. Żądanie trafiło do kolejki, oto ekran statusu pozostaje właściwą wartością zwracaną dla wszystkiego, co otwarte.

Wszystko, co dotyka danych innego użytkownika. Granicą zaufania w obu protokołach jest agent wywołujący. Apple Intelligence działa na koncie iCloud użytkownika. MCP działa na poświadczeniach, które podpiął deweloper. Operacje obejmujące wielu użytkowników (udostępnianie, dostęp wielokontowy, działania administracyjne) nie są bezpieczne przez żaden z protokołów, ponieważ tożsamość wywołująca jest tożsamością niewłaściwą.

Co zbudowałbym inaczej

Znając powyższą regułę routingu, zaprojektowałbym warstwę domenową aplikacji Swift tak, jak dziś projektuję API na granicy usługi. Metody domenowe przyjmują typowane wejścia i zwracają typowane wyjścia, bez wpieczonych założeń o protokole. App Intents cienko opakowują metody domenowe schematem @Parameter i klejem perform(). Narzędzia MCP cienko opakowują te same metody domenowe schematem JSON i ramkowaniem stdio. Oba protokoły są cienkimi adapterami; praca leży w domenie.

Wynikają z tego dwie konsekwencje.

Tożsamość wywołującego jest sprawą domeny, nie protokołu. Ciało App Intent otrzymuje parametry rozwiązane przez system i działa w kontekście, w którym użytkownik przeszedł przez systemowy przepływ wywołania intentu. Ciało narzędzia MCP otrzymuje te poświadczenia, które przygotował host. Oba przekazują je dalej do metody domenowej jako jawny argument caller. Metoda domenowa egzekwuje autoryzację, monity potwierdzające i wszelkie inne niezmienniki domeny. Żaden z protokołów nie ma prawa udawać, że wywołującym jest użytkownik.

Oba adaptery wystawiają ten sam zestaw możliwości. Decyzja o tym, które funkcje wystawić któremu wywołującemu, zostaje zapisana w dwóch manifestach, a nie rozsiana po kodzie protokołu. Dodanie nowej funkcji to jedna metoda domenowa, dwa opakowania adapterów, dwa wpisy w manifestach. Usunięcie funkcji jest symetryczne. Powyższa macierz staje się realnym plikiem.

Granicą platformy Apple na najbliższe lata nie jest wybór jednego protokołu. Granicą jest traktowanie obu jako ortogonalnych kontraktów, które składają się na tej samej warstwie domenowej. Agenci Apple Intelligence mają jeden zestaw zobowiązań wobec użytkownika (działają na urządzeniu, mówią przez Siri, renderują przez system). Zewnętrzni agenci LLM mają inny zestaw zobowiązań wobec dewelopera (działają gdziekolwiek, mówią JSON-RPC, renderują przez model wybrany przez dewelopera). Obaj zasługują na typowaną powierzchnię do aplikacji. Żaden nie zasługuje na to, by być powierzchnią jedyną.

Kiedy nie budować obu

Argument tnie w obie strony. Niektóre aplikacje potrzebują jednego protokołu, a nie drugiego.

Czysto konsumenckie narzędzia bez powierzchni dla deweloperów. Latarka. Rozpoznawanie ptasich głosów. Miarka w rozszerzonej rzeczywistości. Użytkownik może chcieć wywołać to przez Siri (App Intents są przydatne), ale żaden deweloper nie wepnie tego w workflow z LLM (MCP byłoby ozdobą).

Czysto deweloperskie narzędzia bez powierzchni dla użytkownika końcowego. Serwer MCP formatujący kod. Narzędzie do przeszukiwania repozytorium. Inspektor wersji pakietów. Użytkownikiem jest tu deweloper w sesji Claude Code; Siri i Apple Intelligence nie odgrywają żadnej roli.

Aplikacje, które nie służą dobrze żadnej z klas agentów. Mocno interaktywne gry, aplikacje wieloosobowe działające w czasie rzeczywistym, aplikacje, których wartość polega na byciu w aplikacji i na ekranie. Żaden z protokołów tu nie pasuje; właściwą odpowiedzią jest świetna aplikacja i brak kontraktu dla agenta.

Decyzja nie brzmi jedno albo oba domyślnie. Decyzja brzmi do czego służy ta aplikacja i kto jeszcze mógłby chcieć obsługiwać jej domenę. Odpowiedzią może być: żadne, jedno albo oba. Koszt zbudowania jednego jest niewielki, jeśli warstwa domenowa jest dobrze wykrojona. Koszt zbudowania obu, na tej samej warstwie domenowej, również jest niewielki. Kosztem niezbudowania jednego, gdy wymaga tego przypadek użycia, jest całkowity brak danej funkcji na tej powierzchni agenta.

Co ten wzorzec oznacza dla stosu Apple na iOS 26+

Dwa wnioski.

1. Warto traktować App Intents i MCP jako ortogonalne kontrakty na tej samej domenie, a nie jako konkurujące protokoły. Apple Intelligence, Siri, Shortcuts i Spotlight to jedna klasa wywołujących, ze zobowiązaniami na poziomie systemu. Claude, Cursor, ChatGPT i reszta to druga klasa wywołujących, ze zobowiązaniami na poziomie sesji. Obie zasługują na typowany dostęp. Warstwa domenowa pod nimi się nie zmienia.

2. Reguła routingu dotyczy tego, kto wywołuje, a nie tego, co się wykonuje. App Intent i narzędzie MCP mogą wywoływać tę samą funkcję Swift. Różnią się zobowiązaniami, jakie niesie wywołujący, prezentacją, jaką dostają w zamian, oraz trwałością, jakiej oczekują. Należy dobrze zrobić funkcję, a warstwy protokołów zostawić cienkie.

Pełny klaster Apple Ecosystem: typowane App Intents dla Apple Intelligence, serwery MCP dla agentów działających na wielu LLM, Live Activities dla maszyny stanów na ekranie blokady, wzorce Liquid Glass dla warstwy wizualnej oraz wydawanie na wiele platform dla zasięgu między urządzeniami. Hub znajduje się w serii Apple Ecosystem. Szerszy kontekst iOS z agentami AI opisuje przewodnik po tworzeniu agentów na iOS.

Często zadawane pytania

Kiedy budować App Intent, a kiedy narzędzie MCP dla tej samej funkcji?

App Intent warto zbudować wtedy, gdy funkcja ma dosięgnąć Apple Intelligence, Siri, Shortcuts albo Spotlight. Narzędzie MCP warto zbudować wtedy, gdy funkcja ma dosięgnąć zewnętrznych LLM (Claude, ChatGPT, agentów w Claude Code albo Cursor). Dla funkcji domenowych, które powinny obsłużyć obie klasy wywołujących, należy zbudować jedno i drugie jako cienkie adaptery nad wspólną metodą domenową w Swifcie.

Czy App Intents i serwery MCP ze sobą konkurują?

Nie. App Intents to droga do własnego stosu agentowego Apple; MCP to droga do każdego innego LLM. Apple Intelligence nie wywołuje narzędzi MCP, a zewnętrzni agenci LLM nie mogą bezpośrednio uruchomić App Intents (idą przez system). Oba protokoły obsługują różne klasy wywołujących, z różnymi modelami zaufania, różnymi budżetami opóźnień i różnymi powierzchniami prezentacji.

Czy jedna aplikacja może wystawić swoją domenę przez oba protokoły?

Tak, i większość nietrywialnych aplikacji, które chcą pełnego zasięgu agentowego, powinna to zrobić. Get Bananas (opisane we wpisie o serwerze MCP) oraz Water (opisane we wpisie o App Intents) to wczesne przykłady. Wzorzec to warstwa domenowa na spodzie, a nad nią adaptery App Intent i adaptery narzędzi MCP. Oba adaptery wywołują te same funkcje Swift.

Jaki stan śledzi Apple Intelligence, którego MCP nie śledzi?

Apple Intelligence śledzi tożsamość AppEntity między wywołaniami, sesjami i ponownymi uruchomieniami, a wraz z SyncableEntity z iOS 27 również między urządzeniami użytkownika⁸. Model encji daje systemowi trwałe odwołania, które użytkownik może łączyć w łańcuch między intentami. MCP samo w sobie jest protokołem stanowym, z zarządzaniem cyklem życia i identyfikatorami sesji w Streamable HTTP, ale trwała tożsamość domenowa jest odpowiedzialnością po stronie serwera, a nie pełnoprawnym kontraktem protokołu; model hosta nie otrzymuje z powierzchni protokołu identyfikatora równoważnego AppEntity. Pojęcie resources w MCP oraz eksperymentalne taski ze specyfikacji 2025-11-25 obsługują trwałe dane referencyjne i trwałe żądania, jednak jedno i drugie działa na tej samej warstwie należącej do serwera⁶.

Czy są funkcje, których nie należy wystawiać przez żaden z protokołów?

Tak. Funkcje stanu interfejsu (otwórz tę kartę, przewiń tutaj), funkcje wymagające obecności człowieka (robienie zdjęć, uwierzytelnianie biometryczne, wprowadzanie danych wrażliwych) oraz operacje obejmujące dane wielu użytkowników powinny pozostać za interfejsem aplikacji — żaden z protokołów nie niesie sygnałów zaufania potrzebnych do bezpiecznego działania ponad granicami użytkowników. Długo trwająca praca w tle to wyjątek, który się przesunął: LongRunningIntent z iOS 27 i rozszerzenie tasks w MCP dają jej wreszcie realne prymitywy, więc warto wystawić ją świadomie przez tę maszynerię, a za własnym interfejsem zostawić wyłącznie pracę otwartą, bogatszą niż pasek postępu.

Źródła