Apple Messages MCP

Lies und durchsuche deine iMessage-, SMS- und RCS-Unterhaltungen von Claude aus, auf macOS.

Begleitprojekt zu claude-connector-apple-mail und claude-connector-apple-reminders.

Status: Lesen und Suchen sind solide. Senden funktioniert, ist aber bei einem echten Versand ungetestet — der Skriptaufruf ist implementiert und seine Syntax verifiziert, aber Apple hat send schon einmal kaputt gemacht, also behandle den ersten echten Versand als Test. Siehe Nachrichten senden.

Werkzeuge

Related MCP server: jons-mcp-imessage

Anforderungen

• macOS 13 Ventura oder neuer. RCS erfordert macOS 26 oder neuer.

• Voller Festplattenzugriff für die Claude-App — zum Lesen erforderlich.

• Automatisierungsberechtigung für Nachrichten — zum Senden und für Kontaktnamen erforderlich. macOS fragt diese automatisch ab.

Vollen Festplattenzugriff gewähren

1. Systemeinstellungen → Datenschutz & Sicherheit → Voller Festplattenzugriff

2. Claude aktivieren (falls nicht aufgelistet, /Applications/Claude.app mit + hinzufügen)

3. Claude beenden und neu öffnen. macOS cached diese Berechtigung beim Prozessstart, daher ist der Neustart zwingend — die Erweiterung schlägt sonst weiterhin fehl.

Warum dies vollen Festplattenzugriff benötigt, Apple Mail aber nicht

Die Apple-Mail-Erweiterung kommuniziert vollständig über Skripting mit Mail.app, daher benötigt sie keine besonderen Berechtigungen. Nachrichten kann so nicht funktionieren.

Das AppleScript-Wörterbuch von Nachrichten stellt genau vier Klassen bereit — account, chat, participant, file transfer — und keine Nachrichtenklasse. Verifiziert auf macOS 26.5.2:

$ osascript -e 'tell application "Messages" to get every text message of first chat'
syntax error: Expected "from", etc. but found identifier. (-2741)

Chats und Teilnehmer lassen sich problemlos aufzählen; Nachrichteninhalte sind schlicht nicht verfügbar. Der einzige Leseweg ist daher SQLite über ~/Library/Messages/chat.db, das TCC-geschützt ist. Im Gegensatz zur Automatisierung kann der volle Festplattenzugriff nicht programmatisch angefordert werden — der Benutzer muss ihn von Hand gewähren.

Die Erweiterung verwendet daher beide Berechtigungen für unterschiedliche Aufgaben:

Kontaktnamen stammen aus der participant-Klasse von Nachrichten (full name), die die Kontaktkarte des Benutzers liest. Das umgeht die separat geschützte Adressbuch-Datenbank — wenn die Automatisierung verweigert wird, werden Handles einfach als rohe Zahlen angezeigt.

Implementierungshinweise

attributedBody. Seit Ventura ist message.text häufig NULL und der Inhalt liegt in message.attributedBody als Apple-Typedstream — das veraltete NSArchiver-Format, das plistlib nicht lesen kann. typedstream.py dekodiert es in reinem Python, daher benötigt das Bundle keine PyObjC-Abhängigkeit. Es verankert sich am Klassennamen NSString/NSMutableString und liest die längenpräfixierte UTF-8-Nutzlast nach dem +-Typmarker. Die Dekodierung ist total: Ein nicht dekodierbarer Inhalt ergibt None, anstatt die Abfrage fehlschlagen zu lassen.

Zeitstempel. message.date ist Apple-Epoche (2001-01-01), in Sekunden vor macOS 13 und in Nanosekunden seitdem. Beides wird erkannt und behandelt.

Suche. chat.db enthält keinen Textindex, und die meisten Inhalte liegen nur in attributedBody, wo SQL sie nicht sehen kann. Diese Kombination ist übler, als sie aussieht.

Die erste Implementierung erweiterte ihr Prädikat auf m.text LIKE ? OR m.attributedBody IS NOT NULL und filterte den dekodierten Text erneut in Python. Da diese zweite Klausel für fast jede moderne Zeile wahr ist, kürzte das LIMIT der Abfrage den Scan auf die neuesten paar hundert Nachrichten, bevor der Python-Filter überhaupt lief — so verschwand jedes ältere Treffer stillschweigend. Eine Suche nach einer echten Nachricht ergab null Ergebnisse, anstatt langsam zu sein. Bei einem 916-MB-Verlauf bedeutete das, dass die Suche effektiv nur die letzten paar Tage abdeckte.

Die Lösung besteht darin, einmal statt pro Abfrage zu dekodieren. index.py spiegelt dekodierte, casefoldete Inhalte in ~/Library/Caches/apple-messages-mcp/search-index.db, mit denen Suchen dann verknüpft werden — so gelten Treffer, Filter, Sortierung und LIMIT für den gesamten Verlauf in SQL. Die Spiegelung ist:

• Inkrementell. Neue Nachrichten werden über einen message.ROWID-Wasserstand gefunden. Bearbeitungen und Rücknahmen verwenden eine vorhandene ROWID wieder, daher betrachtet jede Aktualisierung auch die letzten 2000 Zeilen — aber nur solche mit gesetztem date_edited oder mit beiden Inhalts-Spalten jetzt NULL, da das erneute Dekodieren von 2000 Blobs bei jeder Suche echte Arbeit ist, die fast immer nichts findet. Eine Bearbeitung, die Nachrichten irgendwie nicht gestempelt hat, oder eine älter als dieses Fenster, benötigt refresh_search_index(rebuild=True). Eine Verbesserung des attributedBody-Dekoders rechtfertigt ebenfalls einen Neuaufbau; das Erhöhen von SCHEMA_VERSION erzwingt einen.

• Casefoldet, und nur das. Anzeigetext stammt weiterhin aus chat.db, daher ist die Spiegelung rein ein Abgleichs-Orakel. Das Speichern von str.casefold() halbiert ihre Größe und macht die Groß-/Kleinschreibung-unabhängige Übereinstimmung für Nicht-ASCII korrekt — SQLites LIKE faltet Groß-/Kleinschreibung nur für ASCII.

• Wegwerfbar. Sie liegt in ~/Library/Caches und wird bei Löschung neu aufgebaut. Nichts hier schreibt in chat.db.

Kein FTS5, trotz des früheren Plans hier: FTS5 stimmt mit ganzen Token überein, daher findet MATCH 'dentist' nie "mydentist", was enger ist als die Teilstring-Semantik, die search_messages dokumentiert. Ein Teilstring-Scan über kompakten casefoldeten Text ist bereits schnell, daher hätte FTS5 den Index für Semantiken verdoppelt, die wir nicht nutzen können. Es später hinzuzufügen ist eine begrenzte Änderung, falls eine Abfrage jemals tatsächlich schleppt.

Nur lesen und nicht sperrend. Verbindungen öffnen mode=ro und keine Anweisung verändert die Datenbank. Wenn SQLite das Live-WAL nicht schreibgeschützt öffnen kann, fällt es auf eine private Snapshot-Kopie zurück, sodass eine laufende Messages.app nie gestört wird.

Tapbacks, Bearbeitungen, Antworten. Reaktionen werden aus associated_message_type dekodiert (2000–2007, mit dem 3000er-Bereich als deren Entfernungen), verschachtelte Antworten aus thread_originator_guid und Bearbeitungen aus date_edited.

Nachrichten senden

Nachrichten hat kein Entwurfsobjekt, daher gibt es kein genaues Analogon zum Entwurf-zuerst-Design der Mail-Erweiterung. Der Schreibpfad kommt daher auf zwei Ebenen, und sie sind bewusst nicht gleichwertig.

compose_message — die sichere Standardeinstellung. Öffnet Nachrichten mit Empfänger und Inhalt vorausgefüllt über das imessage: / sms: URL-Schema und stoppt. Ein Mensch liest und drückt auf Senden, daher verlässt nichts die Maschine auf Claudes Anweisung. Dies ist auch der einzige Weg, eine neue Unterhaltung zu beginnen. Benötigt überhaupt keine Berechtigung.

send_message — stellt sofort zu. Verwendet das send der Skriptschnittstelle und kann nicht rückgängig gemacht werden. Es nimmt eine chat_id statt einer Telefonnummer, was keine Einschränkung, sondern der Punkt ist: Das Wörterbuch akzeptiert entweder einen participant oder einen chat, und das Adressieren eines bestehenden Chats per GUID lässt Nachrichten den Transport wählen (iMessage / SMS / RCS), anstatt dass der Aufrufer rät und jemandem auf iMessage still eine SMS sendet. Es erfordert außerdem confirm=True, rein als Schutz davor, versehentlich ausgelöst zu werden.

Was verifiziert ist und was nicht

Bestätigt auf macOS 26.5.2 — das Wörterbuch stellt bereit

send : direct-parameter (file | text), to: (participant | chat)

die service type-Aufzählung ist SMS, iMessage, RCS, chat hat eine GUID- id-Eigenschaft zum Adressieren, und das generierte AppleScript kompiliert.

Nicht bestätigt: dass ein echter Versand tatsächlich zustellt. Apple hat AppleScript send schon einmal kaputt gemacht, und seine Präsenz im Wörterbuch war nie ein Beweis, dass es funktioniert. Nichts in der Testsuite stellt eine Nachricht zu, daher ist der erste echte Versand das Experiment. Wenn es fehlschlägt, ist shortcuts run mit einer "Nachricht senden"-Aktion der nächste Versuch, den es wert ist.

Nachrichtentext erreicht AppleScript als osascript-Argument (on run argv), anstatt in den Skriptquelltext interpoliert zu werden, sodass ein Inhalt mit doppeltem Anführungszeichen inert ist, anstatt ein Syntaxfehler oder eine Injektion zu sein.

Das Senden von Anhängen ist nicht verdrahtet, obwohl der file-Direktparameter bedeutet, dass es in Reichweite ist.

Entwicklung

python3 tests/test_db.py       # SQL, decoder, and search-index tests
python3 tests/test_send.py     # compose URLs, send guards, argv safety
python3 tools/probe_schema.py  # verify the real chat.db (needs Full Disk Access)
./build.sh                     # test, validate manifest, pack the .mcpb

tests/test_db.py erstellt Wegwerf-Datenbanken mit dem echten Schema, sodass das SQL ohne vollen Festplattenzugriff oder echten Nachrichtenverlauf validiert werden kann. Eine davon vergrabet einen Treffer unter 3000 neueren Nachrichten, was der Regressionstest für den oben beschriebenen abgeschnittenen Suchfehler ist.

tests/test_send.py sendet nie etwas oder öffnet ein Fenster: Es deckt den URL-Builder, die Schutzklauseln und das exakte osascript-argv ab — daher ist es überall sicher und kann entsprechend nicht sagen, ob Apples send funktioniert.

Keine der beiden Suiten berührt den echten Suchindex; beide injizieren einen temporären.

Lizenz

MIT