App Intents kontra MCP: Pytanie o routing

Dwa protokoły, App Intents oraz MCP, pozwalają zewnętrznemu agentowi operować na domenie aplikacji. Nie zlewają się jednak w jeden. Pytanie brzmi: który dokąd trafia i dlaczego każdy z nich jest właściwą odpowiedzią dla swojego wywołującego.

Apple wprowadziło App Intents, aby dać Apple Intelligence typowaną, deklaratywną powierzchnię do operowania aplikacjami innych firm bez ingerencji w ich UI.¹ Anthropic wprowadził Model Context Protocol, aby dać dowolnemu LLM typowaną powierzchnię pośredniczoną przez serwer, służącą do operowania dowolnym narzędziem bez ingerencji w jego UI.² Kształty są podobne. Wywołujący — nie. Traktowanie ich jako jednej powierzchni daje architekturę, która nie zadowala żadnego z nich.

Dwa wcześniejsze posty z tego klastra omówiły każdy protokół osobno: App Intents w App Intents to nowe API Apple do Pańskiej aplikacji, MCP w Dwa ekosystemy agentów, jedna lista zakupów. Obecny post dotyczy pytania o routing. Kiedy dana funkcja otrzymuje AppIntent, kiedy otrzymuje narzędzie MCP, kiedy oba, a co pozostaje udostępnione tylko wewnątrz aplikacji.

TL;DR

• App Intents to jedyna droga do Apple Intelligence, Siri, Shortcuts oraz systemowego stosu sugestii. System udostępnia je od momentu instalacji oraz poprzez aktualizacje aplikacji, a przekazywanie i indeksowanie App Shortcuts wprowadza je do Spotlight i sugestii Siri.
• Narzędzia MCP to droga do każdego LLM spoza Apple (Claude, ChatGPT, Gemini, modele lokalne). Transportem jest stdio lub Streamable HTTP, przy czym .mcpb stanowi format pakowania, który zazwyczaj dostarcza lokalny serwer stdio; host ładuje narzędzia w momencie sesji.
• Oba protokoły zbiegają się w typowanym schemacie, kształcie entity → action → result oraz w rozwiązywaniu parametrów. Rozchodzą się natomiast w tożsamości, trwałości, opóźnieniach i powierzchni renderowania.
• Reguła routingu: jeżeli funkcja jest czymś, o co użytkownik mógłby zapytać Siri lub przywołać ze Spotlight — App Intents. Jeżeli funkcja jest czymś, co programista mógłby podpiąć do sesji Claude Code lub uruchomienia zewnętrznego agenta — MCP. Większość aplikacji potrzebuje obu dla tej samej domeny.

Dwa protokoły, ten sam kształt

Oba protokoły definiują kontrakt operacyjny pomię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 zapytać), resolvera (jak aplikacja znajduje encje, które schemat nazywa) oraz akcji (co się wykonuje i co wraca).

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

MCP wyraża kontrakt w JSON-RPC nad stdio lub Streamable HTTP. Powierzchnią protokołu są metody tools/list i tools/call, gdzie każde narzędzie deklaruje nazwę, opis oraz inputSchema (przy czym specyfikacja 2025-06-18 dodaje opcjonalne outputSchema dla zwrotów strukturalnych).⁴ Host MCP (Claude Desktop, Claude Code, Cursor, aplikacja desktopowa ChatGPT) odkrywa narzędzia na początku sesji i wywołuje je po nazwie z ładunkiem JSON. Host uruchamia model; serwer uruchamia narzędzie.

Kształt jest taki sam: schemat, resolver, akcja. Różnica polega na tym, kto uruchamia każdy z elementów i gdzie znajduje się granica zaufania. App Intents działają wewnątrz procesu aplikacji, na urządzeniu użytkownika, w ramach uprawnień aplikacji, z systemem pośredniczącym w routingu wywołań. Serwery MCP działają tam, gdzie programista zdecydował się je uruchomić (lokalne stdio, hostowane HTTP, osadzony pakiet), z hostem LLM pośredniczącym w routingu wywołań po nieograniczonym zbiorze narzędzi.

W czym oba protokoły się różnią

Poza powierzchownym kształtem dla routingu istotne są cztery różnice operacyjne:

Tożsamość i trwałość. App Intents mówią w kategoriach typów AppEntity, które system może przechowywać, prezentować i ponownie rozwiązywać później. Wpis o wodzie zapisany dziś poprzez Hej Siri, zapisz 250 ml w Water przetrwa restarty, zsynchronizuje się pomiędzy urządzeniami iCloud użytkownika i może być przywoływany przez inne intenty później (Pokaż wczorajsze wpisy o wodzie). System śledzi identyfikator encji we wszystkich tych wywołaniach.³ MCP sam w sobie jest protokołem stanowym z zarządzaniem cyklem życia, a Streamable HTTP wspiera identyfikatory sesji dla ciągłości połączenia, jednak trwała tożsamość domenowa pozostaje sprawą serwera; nie ma odpowiednika identyfikatorów AppEntity na poziomie protokołu, na których model hosta mógłby polegać między sesjami. MCP wspiera resources dla trwałych danych referencyjnych, lecz tożsamość pozostaje odpowiedzialnością po stronie serwera, a nie kontraktem protokołu pierwszej klasy.⁴

Opóźnienia 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 lub z otaczającej warstwy Apple Intelligence/Siri, a nie z samego kontraktu intentu. Typowana akcja na urządzeniu zwracająca typowany wynik jest w typowych przypadkach szybka. Narzędzia MCP, nawet lokalne, przechodzą przez ramkowanie JSON-RPC po stdio z osobną granicą procesu, a zdalne narzędzia MCP ponoszą koszt rund HTTP. Budżet opóźnień jest inny. App Intent zapisz 250 ml może zakończyć się w oknie naprzemiennej wymiany Siri. Zdalne narzędzie MCP może być wąskim gardłem sesji Claude Code.

Powierzchnia renderowania. App Intents zwracają wyniki, które Apple Intelligence renderuje w UI systemu: baner Lock Screen, odpowiedź Siri, wynik Shortcuts, wynik Spotlight. Aplikacja nie kontroluje, w jaki sposób wynik się prezentuje. Narzędzia MCP zwracają bloki treści (tekst, obrazy, dźwięk, osadzone zasoby lub treść strukturalną), które model hosta odczytuje i decyduje, jak je wyeksponować. Sesja Claude Code może zacytować wynik z powrotem programiście, podsumować go lub przekazać do kolejnego wywołania. Decyzja o renderowaniu zapada w warstwie modelu.

Wykrywalność. Apple Intelligence udostępnia App Intents od momentu instalacji, przy czym przekazywanie i indeksowanie App Shortcuts wprowadza intenty do wyszukiwań Spotlight i sugestii Siri w oparciu o zachowanie użytkownika; aktualizacje aplikacji oraz dynamiczne encje w czasie modyfikują tę powierzchnię. Użytkownik nigdy nie wpisuje nazwy narzędzia. Hosty MCP czytają narzędzia na początku sesji; użytkownik (lub prompt systemowy) decyduje, które narzędzia model może zobaczyć. Po stronie MCP wykrywanie jest jawną konfiguracją, a po stronie App Intents — ukrytym wnioskowaniem systemowym.

Oba protokoły rozchodzą się w czterech właściwościach — tożsamości, opóźnieniu, renderowaniu i wykrywalności — które wynikają z jednego źródłowego rozróżnienia. App Intents obsługują agenta na poziomie systemu, którego użytkownik nie skonfigurował. MCP obsługuje agenta na poziomie sesji, którego skonfigurował programista. Różni wywołujący, różne zobowiązania.

Reguła routingu

Mapa funkcji dla aplikacji posiadającej oba protokoły 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, w kolejności.

Czy funkcja jest czymś, o co użytkownik zapytałby Siri lub uruchomiłby ze Shortcuts? Jeżeli tak, funkcja potrzebuje App Intent. Zapisz 250 ml wody, Rozpocznij medytację, Dodaj banany do listy, Ile ważyłem wczoraj są intentami, ponieważ użytkownik mógłby je wypowiedzieć na głos, wpisać do Spotlight lub połączyć w Shortcuts. App Intent jest dla tych funkcji nieopcjonalny; nic innego nie zaprowadzi Pana/Pani do firmowej powierzchni agenta Apple Intelligence.

Czy funkcja jest czymś, czym powinien móc sterować zewnętrzny agent? Jeżeli tak, funkcja potrzebuje narzędzia MCP. Dodaj pozycję do listy zakupów z sesji Claude Code, Wczytaj stan Get Bananas do kontekstu agenta Cursor, Wyzwól workflow ze zdalnego narzędzia używającego LLM są narzędziami MCP, ponieważ wywołujący nie jest Apple Intelligence; wywołującym jest dowolny LLM podpięty przez programistę. 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 nad transportem wybranym przez programistę.

Czy funkcja musi przetrwać poza pojedynczą sesję ze stabilną, znaną systemowi tożsamością? Jeżeli tak, ścieżka App Intent jest naturalnym wyborem, ponieważ system udostępnia AppEntity z tożsamością, wsparciem zapytań i semantyką trwałości za darmo. Jeżeli nie, narzędzie MCP może zwrócić blok treści, pozostawić trwałą tożsamość uznaniu serwera i pominąć koszt modelowania encji.

Większość nietrywialnych funkcji aplikacji wpada do kolumny oba. Funkcja zapisywania wody w Water posiada AppIntent (aby Siri mogła odbierać dyktando) oraz narzędzie MCP (aby sesja Claude Code mogła uzupełnić dane z eksportowanego logu). Obie ścieżki współdzielą funkcję Swift; funkcja nie wie, kto ją wywołał.⁵

Kształt w kodzie wygląda jak jedna metoda domenowa i dwa adapterowe wrappery, które oba 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, ponieważ ich wywołujący są różni. Funkcja, którą wywołują, jest ta sama.

Co pozostaje w aplikacji

Niewielki, lecz istotny zbiór funkcji powinien pozostać prywatny dla aplikacji. Routowanie ich przez którykolwiek z protokołów to błąd.

Funkcje stanu UI. „Otwórz trzecią zakładkę”, „przewiń na dół”, „podświetl ten wiersz” nie są operacjami domenowymi. Są prymitywami interakcji. App Intents wspierają część tego poprzez OpensIntent i Shortcuts, lecz dopasowanie gatunkowe jest słabe; użytkownik zwykle chce wyniku, a nie nawigacji. Wsparcie MCP dla nawigacji UI jest jeszcze gorsze: model nie steruje ekranem, lecz steruje narzędziem.

Funkcje wymagające ciała człowieka w pętli. Robienie zdjęć, uwierzytelnianie biometryczne, wpisywanie wrażliwych danych osobowych, każdy przepływ wymagający, by użytkownik patrzył na ekran i dotykał. CameraCaptureIntent Apple istnieje dla przepływów aparatu, ale intencją projektową jest uruchomienie aktywności przechwytywania na pierwszym planie, a nie udzielenie agentowi dostępu do aparatu w tle. Uczciwa zasada dla obu protokołów: aparat, biometria oraz przepływy wpisywania danych wrażliwych powinny działać jako UI na pierwszym planie z wyraźnym potwierdzeniem użytkownika, a nie jako ciche wywołania intentów lub narzędzi. Należy trzymać te funkcje za UI aplikacji i pozwolić agentowi skierować użytkownika do ekranu, a nie przez niego.

Długotrwała praca w tle. App Intents zawierają ProgressReportingIntent do eksponowania postępu, a MCP zawiera powiadomienia o postępie i prymitywy zadań, jednak warstwa renderowania żadnego z protokołów nie jest zbudowana pod ciągły postęp w przepływach konsumenckich. Model hosta w sesji MCP zwykle przekracza limit czasu na łańcuchach wnioskowania na długo przed tym, jak wielominutowe narzędzie zakończy pracę. Dla długotrwałej pracy zwróconej do konsumenta należy eksponować operację przez własne UI aplikacji; protokoły powinny zwracać żądanie zostało zakolejkowane i odsyłać do ekranu statusu.

Wszystko, co dotyka danych innego użytkownika. Granicą zaufania w obu protokołach jest wywołujący agent. Apple Intelligence działa pod kontem iCloud użytkownika. MCP działa pod takimi poświadczeniami, jakie podpiął programista. 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ącego jest niewłaściwą tożsamością.

Co zbudowałbym inaczej

Znając powyższą regułę routingu, projektowałbym warstwę domenową w aplikacji Swift tak, jak teraz projektuję API na granicy usługi. Metody domenowe przyjmują typowane wejścia i zwracają typowane wyjścia, bez założeń protokolarnych zaszytych w kodzie. 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, a 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 takie poświadczenia, jakie zaaranżował host. Oba przekazują dalej do metody domenowej jawny argument caller. Metoda domenowa egzekwuje autoryzację, monity potwierdzeń oraz wszelkie inne niezmienniki domenowe. Żaden z protokołów nie ma prawa udawać, że wywołujący jest użytkownikiem.

Oba adaptery udostępniają ten sam zestaw afordancji. Decyzja, które funkcje wystawić któremu wywołującemu, jest uchwycona w dwóch manifestach, a nie w rozproszonym kodzie protokołu. Dodanie nowej funkcji to jedna metoda domenowa, dwa adapterowe wrappery, dwa wpisy w manifeście. Usunięcie funkcji jest symetryczne. Powyższa macierz staje się prawdziwym plikiem.

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

Kiedy nie budować obu

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

Czyste narzędzia konsumenckie bez powierzchni programistycznej. Latarka. Identyfikator ptasiego śpiewu. Miarka rozszerzonej rzeczywistości. Użytkownik mógłby chcieć przywołać ją przez Siri (App Intents są przydatne), lecz żaden programista nie podpina jej do workflowu LLM (MCP byłby kosmetyczny).

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

Aplikacje, które nie obsługują dobrze żadnej z klas agentów. Wysoce interaktywne gry, aplikacje wieloosobowe w czasie rzeczywistym, aplikacje, których wartość polega na byciu wewnątrz aplikacji i na ekranie. Żaden z protokołów nie jest tu dobrym dopasowaniem; właściwą odpowiedzią jest świetna aplikacja i brak kontraktu agenta.

Decyzja nie brzmi jeden lub oba domyślnie. Decyzja brzmi do czego ta aplikacja służy i kto jeszcze mógłby chcieć operować na jej domenie. Odpowiedzią mogą być żaden, jeden lub oba. Koszt zbudowania jednego jest mały, jeżeli warstwa domenowa jest dobrze ukształtowana. Koszt zbudowania obu, na bazie tej warstwy domenowej, również jest mały. Koszt niezbudowania jednego, gdy przypadek użycia tego wymaga, to całkowita nieobecność funkcji na danej powierzchni agenta.

Co ten wzorzec oznacza dla stosu Apple na iOS 26+

Dwa wnioski.

1. Należy traktować App Intents oraz MCP jako ortogonalne kontrakty na tej samej domenie, a nie protokoły konkurencyjne. Apple Intelligence, Siri, Shortcuts i Spotlight stanowią jedną klasę wywołujących z zobowiązaniami na poziomie systemu. Claude, Cursor, ChatGPT i pozostali to druga klasa wywołujących z zobowiązaniami na poziomie sesji. Oba zasługują na typowany dostęp. Warstwa domenowa pod nimi się nie zmienia.

2. Reguła routingu to kto wywołuje, a nie co się wykonuje. App Intent oraz narzędzie MCP mogą wywoływać tę samą funkcję Swift. Różnią się zobowiązaniami, jakie niesie wywołujący, renderowaniem, jakie otrzymują, oraz trwałością, jakiej oczekują. Trzeba dobrze zbudować funkcję; warstwy protokolarne niech pozostaną cienkie.

Pełny klaster Apple Ecosystem: typowane App Intents dla Apple Intelligence, serwery MCP dla agentów wielo-LLM, Live Activities dla maszyny stanów Lock Screen, wzorce Liquid Glass dla warstwy wizualnej oraz dystrybucja wieloplatformowa dla zasięgu między urządzeniami. Hub znajduje się w serii Apple Ecosystem. Szerszy kontekst iOS z agentami AI znajduje się w przewodniku iOS Agent Development.

FAQ

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

Należy zbudować App Intent, gdy funkcja powinna sięgać do Apple Intelligence, Siri, Shortcuts lub Spotlight. Należy zbudować narzędzie MCP, gdy funkcja powinna sięgać do zewnętrznych LLM (Claude, ChatGPT, agenci w Claude Code lub Cursor). Dla funkcji domenowych, które mają obsługiwać obie klasy wywołujących, należy zbudować obie jako cienkie adaptery nad współdzieloną metodą domenową w Swift.

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

Nie. App Intents to droga do firmowego 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 wywoływać App Intents (przechodzą 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 renderowania.

Czy pojedyncza aplikacja może udostępniać swoją domenę przez oba protokoły?

Tak, i większość nietrywialnych aplikacji, które chcą pełnego zasięgu agentowego, powinna. Get Bananas (omówione w poście o serwerze MCP) oraz Water (omówiona w poście o App Intents) to wczesne przykłady. Wzorzec to warstwa domenowa pod spodem, z adapterami App Intent oraz adapterami narzędzi MCP powyżej. Oba adaptery wywołują te same funkcje Swift.

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

Apple Intelligence śledzi tożsamość AppEntity pomiędzy wywołaniami, sesjami i restartami. Model encji daje systemowi trwałe odniesienia, które użytkownik może łańcuchować pomiędzy intentami. MCP sam w sobie jest protokołem stanowym z zarządzaniem cyklem życia oraz identyfikatorami sesji w Streamable HTTP, jednak trwała tożsamość domenowa pozostaje odpowiedzialnością po stronie serwera, a nie kontraktem protokołu pierwszej klasy; model hosta nie otrzymuje z powierzchni protokołu identyfikatora równoważnego AppEntity. Koncepcja resources w MCP wspiera trwałe dane referencyjne, ale działa w tej samej warstwie należącej do serwera.

Czy są funkcje, których nie powinno się udostępniać przez żaden z protokołów?

Tak. Funkcje stanu UI (otwórz tę zakładkę, przewiń tutaj), funkcje wymagające ciała człowieka w pętli (przechwytywanie z aparatu, uwierzytelnianie biometryczne, wpisywanie wrażliwych danych), długotrwała praca w tle oraz operacje obejmujące dane wielu użytkowników powinny pozostać za UI aplikacji. Oba protokoły mają słabe prymitywy dla tych przypadków i żaden nie niesie sygnałów zaufania wymaganych do bezpiecznego operowania pomiędzy użytkownikami.

Bibliografia