App Intents vs. MCP: Die Routing-Frage

Zwei Protokolle, App Intents und MCP, erlauben beide einem externen Agenten, die Domäne einer App zu bedienen. Sie fallen nicht in eines zusammen. Die Frage ist, was wohin gehört und warum jedes Protokoll für seinen eigenen Aufrufer die richtige Antwort ist.

Apple hat App Intents ausgeliefert, um Apple Intelligence eine typisierte, deklarative Oberfläche zu geben, mit der sich Apps von Drittanbietern bedienen lassen, ohne deren UI zu berühren.¹ Anthropic hat das Model Context Protocol ausgeliefert, um jedem LLM eine typisierte, server-vermittelte Oberfläche zu geben, mit der sich jedes Werkzeug bedienen lässt, ohne dessen UI zu berühren.² Die Formen ähneln sich. Die Aufrufer nicht. Wer beide als eine einzige Oberfläche behandelt, erhält eine Architektur, die keinem von beiden gerecht wird.

Die beiden vorherigen Beiträge dieses Clusters behandelten jedes Protokoll für sich: App Intents in App Intents sind Apples neue API zu Ihrer App, MCP in Zwei Agenten-Ökosysteme, eine Einkaufsliste. Im vorliegenden Beitrag geht es um die Routing-Frage. Wann bekommt eine Fähigkeit einen AppIntent, wann ein MCP-Tool, wann beides — und was bleibt ausschließlich innerhalb der App zugänglich?

TL;DR

• App Intents sind der einzige Weg zu Apple Intelligence, Siri, Shortcuts und dem Vorschlagssystem der Plattform. Das System stellt sie ab der Installation und über App-Updates bereit; Donation und Indexierung von App Shortcuts bringen sie in Spotlight- und Siri-Vorschläge.
• MCP-Tools sind der Weg zu jedem LLM außerhalb von Apple (Claude, ChatGPT, Gemini, lokale Modelle). Als Transport dienen stdio oder Streamable HTTP, wobei .mcpb ein Paketformat ist, das üblicherweise einen lokalen stdio-Server mitliefert; der Host lädt die Tools zu Sitzungsbeginn. Die aktuelle Spezifikationsrevision ist 2025-11-25, und ein Release Candidate vom 2026-07-28 baut das Protokoll um einen zustandslosen Kern herum um⁶⁷.
• Beide Protokolle treffen sich bei einem typisierten Schema, einer Form aus entity → action → result und der Parameterauflösung. Sie unterscheiden sich bei Identität, Persistenz, Latenz und der Darstellungsoberfläche.
• Die Routing-Regel: Wenn die Fähigkeit etwas ist, wonach ein Benutzer Siri fragen oder was er aus Spotlight aufrufen könnte, dann App Intents. Wenn die Fähigkeit etwas ist, das ein Entwickler in eine Claude-Code-Sitzung oder einen externen Agentenlauf einbinden könnte, dann MCP. Die meisten Apps brauchen für dieselbe Domäne beides.

Zwei Protokolle, dieselbe Form

Beide Protokolle definieren einen Operationsvertrag zwischen einem externen Aufrufer und der Domäne einer App. Der Vertrag besteht aus drei Teilen: dem Schema (was der Aufrufer verlangen kann), dem Resolver (wie die App die vom Schema benannten Entitäten findet) und der Aktion (was ausgeführt wird und was zurückkommt).

App Intents formulieren den Vertrag in Swift. Die Protokolloberfläche besteht aus AppIntent, AppEntity und AppEnum; @Parameter-Makros treiben das Schema an, und func perform() liefert das Ergebnis.³ Das Schema wird zur Kompilierzeit erzeugt und bei der Installation mit der App ausgeliefert. Apple Intelligence, Siri, Shortcuts und Spotlight lesen alle dasselbe Schema und leiten eine typisierte Anfrage über denselben Einstiegspunkt perform().

MCP formuliert den Vertrag in JSON-RPC über stdio oder Streamable HTTP. Die Protokolloberfläche sind die Methoden tools/list und tools/call; jedes Tool deklariert einen Namen, eine Beschreibung und ein inputSchema (die Spezifikation 2025-06-18 ergänzte ein optionales outputSchema für strukturierte Rückgaben, und die Revision 2025-11-25 legt JSON Schema 2020-12 als Standarddialekt fest, ergänzt Tool-Icons als Metadaten und formalisiert die Governance über Anthropic hinaus).⁴⁶ Ein MCP-Host (Claude Desktop, Claude Code, Cursor, die ChatGPT-Desktop-App) entdeckt die Tools zu Sitzungsbeginn und ruft sie namentlich mit einer JSON-Nutzlast auf. Der Host führt das Modell aus, der Server das Tool. Zudem befindet sich das Protokoll mitten im Übergang: Der Release Candidate vom 2026-07-28 baut MCP um einen zustandslosen Kern herum neu auf, der auf gewöhnlicher HTTP-Infrastruktur läuft, verlagert langlaufende Arbeit in eine Tasks-Erweiterung und ergänzt server-gerenderte UI über MCP Apps⁷. Das Routing-Argument weiter unten übersteht diese Revision unbeschadet, denn nichts daran ändert, wer der Aufrufer ist.

Die Form ist dieselbe: Schema, Resolver, Aktion. Der Unterschied liegt darin, wer welches Teil ausführt und wo die Vertrauensgrenze verläuft. App Intents laufen im App-Prozess, auf dem Gerät des Benutzers, unter den Entitlements der App, wobei das System das Routing der Aufrufe vermittelt. MCP-Server laufen dort, wo der Entwickler sie betreiben wollte (lokal über stdio, gehostet über HTTP, als eingebettetes Bundle), wobei das Host-LLM das Routing der Aufrufe über eine unbegrenzte Menge von Tools vermittelt.

Ein dritter Aufrufer mit derselben Form verdient Erwähnung, weil er das Bild vervollständigt: Das On-Device-Modell hinter Apples Foundation Models Framework ruft App-Code über dessen Tool-Protokoll auf — eine benannte, beschriebene, typisierte Fähigkeit wie die beiden anderen. Eine gut geschnittene Domänenschicht bedient alle drei Oberflächen, ohne zu wissen, welche gerade aufruft.

Worin die beiden Protokolle sich unterscheiden

Jenseits der äußeren Form sind vier operative Unterschiede für das Routing entscheidend:

Identität und Persistenz. App Intents sprechen in AppEntity-Typen, die das System speichern, anzeigen und später erneut auflösen kann. Der Wassereintrag, den ich heute per Hey Siri, protokolliere 250 ml in Water sichere, überlebt Neustarts, synchronisiert sich über die iCloud-Geräte des Benutzers und lässt sich später von anderen Intents referenzieren (Zeig mir die gestrigen Wassereinträge). Das System verfolgt die Entitäts-ID über all diese Aufrufe hinweg,³ und iOS 27 dehnt die Geschichte auf die Hardware aus: Eine Entität, die SyncableEntity erfüllt, trägt eine über die Geräte eines Benutzers hinweg konsistente Kennung, sodass Siri ein Gespräch über dasselbe Objekt vom iPhone an den Mac und weiter an die Watch übergeben kann.⁸ MCP ist selbst ein zustandsbehaftetes Protokoll mit Lebenszyklusverwaltung, und Streamable HTTP unterstützt Session-IDs für Verbindungskontinuität, doch dauerhafte Domänenidentität bleibt Sache des Servers; es gibt kein Gegenstück auf Protokollebene zu AppEntity-Kennungen, auf das sich ein Host-Modell über Sitzungen hinweg verlassen könnte. MCP unterstützt resources für persistente Referenzdaten, und die Spezifikation 2025-11-25 ergänzt experimentelle Tasks, um dauerhafte Anfragen zu verfolgen, doch die Identität von Domänenobjekten bleibt eine serverseitige Verantwortung statt eines erstklassigen Protokollvertrags.⁴⁶ Die zugrunde liegende Disziplin ist dieselbe, die innerhalb der eigenen Datenschicht der App gilt: stabile Kennungen, die den Prozess überdauern — für SwiftData behandelt in Schema-Disziplin.

Latenz und Akku. Der perform()-Rumpf eines App Intent läuft im Kontext der App oder einer App-Erweiterung auf dem Gerät. Jede Netzwerknutzung stammt aus dem eigenen Code der App oder aus der umgebenden Apple-Intelligence-/Siri-Schicht, nicht aus dem Intent-Vertrag selbst. Eine typisierte Aktion auf dem Gerät, die ein typisiertes Ergebnis zurückgibt, ist im Regelfall schnell. MCP-Tools durchlaufen selbst lokal ein stdio-JSON-RPC-Framing mit einer eigenen Prozessgrenze, und entfernte MCP-Tools kosten HTTP-Roundtrips. Das Latenzbudget ist ein anderes. Ein App Intent für 250 ml protokollieren kann innerhalb eines Siri-Gesprächszugs abschließen. Ein entferntes MCP-Tool kann zum Engpass einer Claude-Code-Sitzung werden.

Darstellungsoberfläche. App Intents liefern Ergebnisse, die Apple Intelligence in die System-UI rendert: ein Banner auf dem Sperrbildschirm, eine Siri-Antwort, eine Shortcuts-Ausgabe, ein Spotlight-Ergebnis. Die App bestimmt nicht, wie das Ergebnis präsentiert wird. MCP-Tools geben Content-Blöcke zurück (Text, Bilder, Audio, eingebettete Ressourcen oder strukturierte Inhalte), die das Host-Modell liest und über deren Darstellung es entscheidet. Eine Claude-Code-Sitzung mag das Ergebnis dem Entwickler zurück zitieren, es zusammenfassen oder in einen Folgeaufruf einspeisen. Die Entscheidung über die Darstellung liegt auf der Modellebene.

Auffindbarkeit. Apple Intelligence stellt App Intents ab der Installation bereit; Donation und Indexierung von App Shortcuts bringen die Intents anhand des Benutzerverhaltens in Spotlight-Suchen und Siri-Vorschläge, und App-Updates sowie dynamische Entitäten passen die Oberfläche mit der Zeit an. Der Benutzer tippt nie einen Tool-Namen. MCP-Hosts lesen die Tools zu Sitzungsbeginn; der Benutzer (oder der System-Prompt) entscheidet, welche Tools das Modell sehen darf. Auf der MCP-Seite ist Discovery explizite Konfiguration, auf der App-Intents-Seite implizite Systeminferenz.

Die beiden Protokolle unterscheiden sich bei Identität, Latenz, Darstellung und Discovery — vier Eigenschaften, die aus einer einzigen Grundunterscheidung folgen. App Intents bedienen einen Agenten auf Systemebene, den der Benutzer nicht konfiguriert hat. MCP bedient einen Agenten auf Sitzungsebene, den der Entwickler konfiguriert hat. Andere Aufrufer, andere Pflichten.

Die Routing-Regel

Die Fähigkeitskarte einer App mit beiden Protokollen sieht so aus:

                    ┌──────────────────────────────────────────┐
                    │           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

Die Routing-Regel besteht aus drei Fragen, in dieser Reihenfolge.

Ist die Fähigkeit etwas, wonach der Benutzer Siri fragen oder was er aus Shortcuts aufrufen würde? Wenn ja, braucht die Fähigkeit einen App Intent. 250 ml Wasser protokollieren, Eine Meditation starten, Bananen auf meine Liste setzen, Was habe ich gestern gewogen sind Intents, weil der Benutzer sie laut aussprechen, in Spotlight eintippen oder in Shortcuts verketten könnte. Für solche Fähigkeiten ist der App Intent nicht optional; nichts anderes bringt Sie auf die First-Party-Agentenoberfläche von Apple Intelligence.

Ist die Fähigkeit etwas, das ein externer Agent steuern können sollte? Wenn ja, braucht die Fähigkeit ein MCP-Tool. Aus einer Claude-Code-Sitzung einen Artikel auf die Einkaufsliste setzen, Den Zustand von Get Bananas in den Kontext eines Cursor-Agenten lesen, Einen Workflow von einem entfernten, werkzeugnutzenden LLM auslösen sind MCP-Tools, weil der Aufrufer nicht Apple Intelligence ist; der Aufrufer ist dasjenige LLM, das der Entwickler angebunden hat. Das MCP-Tool kann dieselbe Swift-Funktion der Domänenschicht umhüllen, die auch der App Intent aufruft, doch die Protokolloberfläche ist JSON-RPC über den vom Entwickler gewählten Transport.

Muss die Fähigkeit eine einzelne Sitzung überdauern, mit stabiler, systemweit bekannter Identität? Wenn ja, ist der Weg über App Intents die natürliche Wahl, denn das System liefert Ihnen AppEntity-Identität, Query-Unterstützung und Persistenzsemantik gratis. Wenn nein, kann das MCP-Tool einen Content-Block zurückgeben, dauerhafte Identität dem Ermessen des Servers überlassen und sich die Kosten der Entitätsmodellierung sparen.

Die meisten nicht-trivialen App-Fähigkeiten landen in der Spalte beides. Eine Fähigkeit zum Protokollieren von Wasser in Water hat einen AppIntent (damit Siri diktieren kann) und ein MCP-Tool (damit eine Claude-Code-Sitzung aus einem exportierten Protokoll nachtragen kann). Beide Wege teilen sich eine Swift-Funktion; die Funktion weiß nicht, welcher Aufrufer sie ausgelöst hat.⁵

Im Code sieht die Form nach einer Domänenmethode und zwei Adapter-Hüllen aus, die beide diese Methode aufrufen:

// 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)")

Die beiden Adapter sehen unterschiedlich aus, weil ihre Aufrufer unterschiedlich sind. Die Funktion, die sie aufrufen, ist dieselbe.

Was in der App bleibt

Eine kleine, aber wichtige Menge von Fähigkeiten sollte der App vorbehalten bleiben. Sie an eines der beiden Protokolle zu routen, ist ein Fehler.

Fähigkeiten des UI-Zustands. „Öffne den dritten Tab“, „scroll nach unten“, „hebe diese Zeile hervor“ sind keine Domänenoperationen. Es sind Interaktionsprimitive. App Intents unterstützen einen Teil davon über OpensIntent und Shortcuts, doch die Gattung passt schlecht; der Benutzer will meist ein Ergebnis, keine Navigation. Die MCP-Unterstützung für UI-Navigation ist noch schlechter: Das Modell steuert keinen Bildschirm, es steuert ein Werkzeug.

Fähigkeiten, die einen Menschen körperlich einbeziehen. Fotoaufnahme, biometrische Authentifizierung, Eingabe sensibler personenbezogener Daten, jeder Ablauf, bei dem der Benutzer auf den Bildschirm schauen und tippen muss. Apples CameraCaptureIntent gibt es für Kamera-Abläufe, doch die Entwurfsabsicht ist, eine Aufnahmeaktivität im Vordergrund zu starten, und nicht, einem Agenten Kamerazugriff im Hintergrund zu gewähren. Die ehrliche Regel für beide Protokolle: Kamera, Biometrie und die Eingabe sensibler Daten sollten als Vordergrund-UI mit ausdrücklicher Bestätigung des Benutzers laufen, nicht als stille Intent- oder Tool-Aufrufe. Halten Sie diese Fähigkeiten hinter der UI der App und lassen Sie den Agenten den Benutzer zum Bildschirm führen, nicht durch ihn hindurch.

Langlaufende Hintergrundarbeit. Beide Protokolle haben hier echte Primitive bekommen, und die Rechnung hat sich von „niemals“ zu „mit der Maschinerie des Protokolls, bewusst“ verschoben. Auf Apple-Seite lässt LongRunningIntent in iOS 27 einen Intent über das 30-Sekunden-Limit des Systems hinaus im Hintergrund laufen, unter der Bedingung, dass er Fortschritt meldet (das Protokoll verfeinert ProgressReportingIntent), wobei Live Activities diesen Fortschritt darstellen⁸. Auf MCP-Seite ergänzt die Spezifikation 2025-11-25 experimentelle Tasks für dauerhafte Anfragen mit Polling und verzögerter Ergebnisabholung, die im Release Candidate vom 2026-07-28 zu einer Tasks-Erweiterung aufsteigen⁶⁷. Die ehrliche Grenze lautet nun: Nutzen Sie die Primitive, wenn der Aufrufer die Arbeit angestoßen hat und ihr zusehen will; behalten Sie die Arbeit hinter der eigenen UI der App, wenn der „Fortschritt“, den ein Konsument braucht, reichhaltiger ist als ein Prozentwert, oder wenn ein Host-Modell beim Warten seine Argumentationskette in einen Timeout laufen ließe. Die Anfrage wurde eingereiht, hier ist der Statusbildschirm bleibt der richtige Rückgabewert für alles Offene.

Alles, was die Daten eines anderen Benutzers berührt. Die Vertrauensgrenze ist in beiden Protokollen der aufrufende Agent. Apple Intelligence läuft unter dem iCloud-Konto des Benutzers. MCP läuft unter den Zugangsdaten, die der Entwickler hinterlegt hat. Operationen, die mehrere Benutzer umspannen (Teilen, Zugriff über mehrere Konten, administrative Aktionen), sind über keines der beiden Protokolle sicher, weil die aufrufende Identität die falsche Identität ist.

Was ich anders bauen würde

Mit der obigen Routing-Regel im Kopf würde ich die Domänenschicht einer Swift-App so entwerfen, wie ich heute APIs an der Grenze eines Dienstes entwerfe. Die Domänenmethoden nehmen typisierte Eingaben und geben typisierte Ausgaben zurück, ohne eingebackene Protokollannahmen. App Intents umhüllen Domänenmethoden dünn mit @Parameter-Schema und perform()-Klebecode. MCP-Tools umhüllen dieselben Domänenmethoden dünn mit JSON-Schema und stdio-Framing. Beide Protokolle sind dünne Adapter; die Arbeit steckt in der Domäne.

Daraus folgen zwei Konsequenzen.

Die Identität des Aufrufers ist Sache der Domäne, nicht des Protokolls. Der Rumpf des App Intent erhält vom System aufgelöste Parameter und läuft in einem Kontext, in dem der Benutzer den systemeigenen Ablauf zur Intent-Auslösung durchlaufen hat. Der Rumpf des MCP-Tools erhält jene Zugangsdaten, die der Host arrangiert hat. Beide reichen sie als ausdrückliches Argument caller an die Domänenmethode weiter. Die Domänenmethode setzt Autorisierung, Bestätigungsabfragen und alle weiteren Domäneninvarianten durch. Keines der beiden Protokolle darf so tun, als wäre der Aufrufer der Benutzer.

Beide Adapter zeigen dieselbe Menge an Angeboten. Die Entscheidung, welche Fähigkeiten welchem Aufrufer offenstehen, steht in zwei Manifesten und nicht verstreut im Protokollcode. Eine neue Fähigkeit hinzuzufügen heißt: eine Domänenmethode, zwei Adapter-Hüllen, zwei Manifesteinträge. Eine Fähigkeit zu entfernen ist symmetrisch. Aus der obigen Matrix wird eine echte Datei.

Die Grenze der Apple-Plattform für die nächsten Jahre liegt nicht darin, sich für ein Protokoll zu entscheiden. Die Grenze liegt darin, beide als orthogonale Verträge zu behandeln, die auf derselben Domänenschicht zusammenkommen. Agenten von Apple Intelligence haben eine Reihe von Pflichten gegenüber dem Benutzer (sie laufen auf dem Gerät, sie sprechen Siri, sie rendern über das System). Externe LLM-Agenten haben eine andere Reihe von Pflichten gegenüber dem Entwickler (sie laufen irgendwo, sie sprechen JSON-RPC, sie rendern über dasjenige Modell, das der Entwickler gewählt hat). Beide verdienen eine typisierte Oberfläche in Ihre App hinein. Keiner verdient es, die einzige Oberfläche zu sein.

Wann man nicht beides bauen sollte

Das Argument schneidet in beide Richtungen. Manche Apps brauchen das eine Protokoll und nicht das andere.

Reine Verbraucher-Werkzeuge ohne Entwickleroberfläche. Eine Taschenlampe. Ein Erkenner für Vogelstimmen. Ein Maßband in erweiterter Realität. Der Benutzer möchte es vielleicht per Siri aufrufen (App Intents sind nützlich), aber kein Entwickler bindet es in einen LLM-Workflow ein (MCP wäre Kosmetik).

Reine Entwicklerwerkzeuge ohne Endbenutzeroberfläche. Ein MCP-Server zum Formatieren von Code. Ein Werkzeug zur Repository-Suche. Ein Prüfer für Paketversionen. Der Benutzer ist der Entwickler in einer Claude-Code-Sitzung; Siri und Apple Intelligence spielen keine Rolle.

Apps, die keiner der beiden Agentenklassen gut dienen. Hochgradig interaktive Spiele, Echtzeit-Mehrspieler-Apps, Apps, deren Wert darin liegt, in der App und auf dem Bildschirm zu sein. Keines der Protokolle passt gut; die richtige Antwort ist eine großartige App und kein Agentenvertrag.

Die Entscheidung lautet nicht standardmäßig eines oder beide. Die Entscheidung lautet wofür ist diese App da, und wer sonst könnte ihre Domäne bedienen wollen. Die Antwort kann keines, eines oder beide sein. Die Kosten, eines zu bauen, sind gering, wenn die Domänenschicht gut geschnitten ist. Die Kosten, auf dieser Domänenschicht beide zu bauen, sind ebenfalls gering. Die Kosten, eines nicht zu bauen, obwohl der Anwendungsfall es verlangt, sind das vollständige Fehlen der Fähigkeit auf dieser Agentenoberfläche.

Was dieses Muster für den Apple-Stack unter iOS 26+ bedeutet

Zwei Erkenntnisse.

1. Behandeln Sie App Intents und MCP als orthogonale Verträge auf derselben Domäne, nicht als konkurrierende Protokolle. Apple Intelligence, Siri, Shortcuts und Spotlight sind eine Aufruferklasse mit Pflichten auf Systemebene. Claude, Cursor, ChatGPT und der Rest sind eine zweite Aufruferklasse mit Pflichten auf Sitzungsebene. Beide verdienen typisierten Zugriff. Die Domänenschicht darunter ändert sich nicht.

2. Die Routing-Regel lautet wer aufruft, nicht was läuft. Der App Intent und das MCP-Tool können dieselbe Swift-Funktion aufrufen. Sie unterscheiden sich in den Pflichten, die der Aufrufer trägt, in der Darstellung, die sie zurückbekommen, und in der Persistenz, die sie erwarten. Bringen Sie die Funktion in Ordnung; halten Sie die Protokollschichten dünn.

Das vollständige Cluster Apple Ecosystem: typisierte App Intents für Apple Intelligence, MCP-Server für LLM-übergreifende Agenten, Live Activities für die Zustandsmaschine des Sperrbildschirms, Liquid-Glass-Muster für die visuelle Schicht und Ausliefern auf mehreren Plattformen für die geräteübergreifende Reichweite. Der Hub liegt bei der Serie Apple Ecosystem. Für den größeren Zusammenhang von iOS mit KI-Agenten siehe den Leitfaden zur iOS-Agentenentwicklung.

Häufige Fragen

Wann sollte ich für dieselbe Fähigkeit einen App Intent und wann ein MCP-Tool bauen?

Bauen Sie einen App Intent, wenn die Fähigkeit Apple Intelligence, Siri, Shortcuts oder Spotlight erreichen soll. Bauen Sie ein MCP-Tool, wenn die Fähigkeit externe LLMs erreichen soll (Claude, ChatGPT, Agenten in Claude Code oder Cursor). Für Domänenfähigkeiten, die beiden Aufruferklassen dienen sollen, bauen Sie beides als dünne Adapter über einer gemeinsamen Swift-Domänenmethode.

Konkurrieren App Intents und MCP-Server miteinander?

Nein. App Intents sind der Weg zum First-Party-Agenten-Stack von Apple; MCP ist der Weg zu jedem anderen LLM. Apple Intelligence ruft keine MCP-Tools auf, und externe LLM-Agenten können App Intents nicht direkt auslösen (sie gehen über das System). Die beiden Protokolle bedienen verschiedene Aufruferklassen mit verschiedenen Vertrauensmodellen, verschiedenen Latenzbudgets und verschiedenen Darstellungsoberflächen.

Kann eine einzelne App ihre Domäne über beide Protokolle anbieten?

Ja, und die meisten nicht-trivialen Apps, die volle Agentenreichweite wollen, sollten das tun. Get Bananas (behandelt im Beitrag zum MCP-Server) und Water (behandelt im Beitrag zu App Intents) sind frühe Beispiele. Das Muster ist eine Domänenschicht darunter, mit App-Intent-Adaptern und MCP-Tool-Adaptern darüber. Beide Adapter rufen dieselben Swift-Funktionen auf.

Welchen Zustand verfolgt Apple Intelligence, den MCP nicht verfolgt?

Apple Intelligence verfolgt die AppEntity-Identität über Aufrufe, Sitzungen und Neustarts hinweg und mit SyncableEntity in iOS 27 auch über die Geräte des Benutzers⁸. Das Entitätsmodell gibt dem System persistente Referenzen, die der Benutzer über Intents hinweg verketten kann. MCP ist selbst ein zustandsbehaftetes Protokoll mit Lebenszyklusverwaltung und Session-IDs in Streamable HTTP, doch dauerhafte Domänenidentität ist eine serverseitige Verantwortung und kein erstklassiger Protokollvertrag; das Host-Modell erhält von der Protokolloberfläche keine Kennung, die einer AppEntity entspricht. Das resources-Konzept von MCP und die experimentellen Tasks der Spezifikation 2025-11-25 unterstützen persistente Referenzdaten und dauerhafte Anfragen, doch beide arbeiten auf derselben servereigenen Schicht⁶.

Gibt es Fähigkeiten, die ich über keines der beiden Protokolle anbieten sollte?

Ja. Fähigkeiten des UI-Zustands (öffne diesen Tab, scroll hierhin), Fähigkeiten, die einen Menschen körperlich einbeziehen (Fotoaufnahme, biometrische Authentifizierung, sensible Eingaben), und Operationen, die die Daten mehrerer Benutzer umspannen, sollten hinter der UI der App bleiben — keines der Protokolle trägt die Vertrauenssignale, die für einen sicheren Betrieb über Benutzergrenzen hinweg nötig sind. Langlaufende Hintergrundarbeit ist die Ausnahme, die sich verschoben hat: LongRunningIntent in iOS 27 und die Tasks-Erweiterung von MCP geben ihr nun echte Primitive, also bieten Sie sie bewusst über diese Maschinerie an und behalten Sie nur offene, über einen Fortschrittsbalken hinausgehende Arbeit hinter Ihrer eigenen UI.

Quellen