MailSyncMCP

Claude から Apple Mail のすべてのアカウントを検索・閲覧・返信できます。パスワードを一切渡す必要はありません。

Gmail、Microsoft 365、iCloud、カスタムドメインの IMAP など、あらゆるアカウントで動作します。各プロバイダーと直接通信するのではなく、Mail がすでに同期したデータを読み取るためです。完全に Mac 上で動作し、どこにもアップロードされません。

この方式を採用する理由

Apple Mail は、あなたが持つすべてのアカウントをすでに同期し、その認証情報をキーチェーンに保持し、自動的に更新しています。このサーバーは Mail のローカルストアを読み取り、Mail に作成を依頼します。パスワードやトークンを一切見ることも、保存することも、再認証を引き起こすこともありません。アカウントを追加するには、Mail に追加するだけです。ここで何かを変更する必要はありません。

各プロバイダーに直接接続する方法では、Google Cloud プロジェクト、Azure アプリ登録、アカウントごとのリフレッシュトークンが必要になります。さらに悪いことに、仕事や大学のアカウントは通常、サードパーティの OAuth アプリに管理者の同意が必要で、しばしば拒否されます。Mail がすでに同期したデータを読むことで、これらすべてを回避できます。

Related MCP server: macos-mail-mcp

安全性

読み取りと検索は自由です。送信はそうではありません。

1. 認証情報なし。 漏洩や期限切れの心配がありません。

2. 2 フェーズコミット。 prepare_* ツールはリクエストを検証し、完全なプレビューを表示し、5 分で期限切れになる使い捨てトークンを返します。これらは何も変更しません。commit_action(token) だけが動作する唯一のツールで、トークンとそれ以外のものを受け取りません。したがって、送信されるメッセージは常に表示されたメッセージです。

3. クライアント権限プロンプト は commit_action で表示されます。

4. 信頼できないコンテンツのフェンシング。 メッセージ本文はラップされ、データとしてマークされて返されます。送信にはレンダリングされたプレビューのみが作成できるトークンが必要なため、メールに埋め込まれた指示によってメールが送信されることはありません。

5. 監査ログ は ~/.local/share/mailsync/audit.jsonl に追記のみで保存されます。

サーバーは stdio のみを話します。リスナーもデーモンもタイマーもないため、チャットセッションからツールが呼び出されたときだけ動作します。

MAILSYNC_READ_ONLY=1 を設定すると、セッション全体で作成を完全に無効にできます。

AppleScript について

applescript/ 内のすべてのスクリプトは、argv を通じて値を受け取る静的ファイルです。スクリプトテキストが生成されることはないため、メール内の引用符、バックスラッシュ、改行、AppleScript 構文はリテラルデータとしてそのまま残ります。tests/test_applescript_safety.py は、悪意のあるペイロードに対してこれを検証します。他の Apple Mail MCP サーバーはメッセージデータをスクリプトソースに連結し、エスケープ関数で防御しますが、このサーバーにはエスケープするためのインジェクション面がありません。

ツール

読み取り: list_accounts、search_mail、get_message、get_thread、list_attachments、save_attachment、mailbox_stats、open_in_mail、refresh_index

作成: prepare_send、prepare_reply、prepare_forward、list_pending、commit_action

メールにフラグを付けたり、移動、アーカイブ、削除するツールは意図的にありません。このサーバーが変更できるのは、新しいメッセージが送信または下書きされることだけです。

Mail へのリンク

返されるすべてのメッセージには、RFC-822 Message-ID から構築された message:// URL が含まれています。クリックすると、そのメッセージが Apple Mail で開き、チャット内の回答が実際のメッセージに追跡可能な状態で残ります。Mail がローカルに保存していないメッセージには Message-ID がないため、リンクはありません。

チャットクライアントはリンクターゲットを許可リスト（http、https、mailto）にサニタイズするため、message:// リンクはクリック可能なものではなく、無効なテキストとして表示されます。open_in_mail ツールはそのために存在します: メッセージを開くように依頼すると、Mail に直接移動します。URL はコピーやチャット外での使用のために印刷されます。

open_in_mail は whole_thread=True を受け取りますが、Mail は各メッセージを独自のウィンドウで開きます。スクリプト可能なスレッドビューはありません。メインビューアの set selected messages は繰り返しテストされましたが、macOS 26 の会話モードでは機能せず、AppleScript ブリッジが強制変換できないオブジェクトを返します。会話を読むには get_thread がより良い方法です。

リンクは常に単一のメッセージを開き、その周囲の会話は開きません。Mail は 3 つの URL スキーム（mailto、message、mail-pref-pane）のみを登録しており、どれもスレッドを扱いません。AppleScript で Mail 自身のスレッドリストを操作することは試みられましたが、放棄されました: macOS 26 では set selected messages は間違った会話を選択するか、空の選択を報告します。Gmail の All Mail メールボックスと通常の INBOX の両方で確認されました。それを出荷する代わりに、get_message は会話の残りをメッセージごとのリンク付きでリストし、get_thread は交換全体を順番にレンダリングします。

インストール

python3 -m venv .venv
.venv/bin/pip install -e .
.venv/bin/python -m mailsync --build-index

登録

Claude Code と Claude for Desktop は別々のアプリで、別々の設定ファイルを持ちます。一方に登録しても、もう一方には影響しません:

使用する方に同じエントリを追加し、venv の Python を指すようにします:

{
  "mcpServers": {
    "mailsync": {
      "command": "/absolute/path/to/Apple-Mail-Sync-MCP/.venv/bin/python",
      "args": ["-m", "mailsync"]
    }
  }
}

パッケージは pip install -e . で venv にインストールされるため、エントリは作業ディレクトリに依存しません。その後、アプリを完全に終了して再度開きます。

このようなローカルサーバーは Mac 上の子プロセスとして実行されるため、そこで実行されているアプリからのみ利用できます。ブラウザの claude.ai からは到達できません。

各サーフェスは独自の OS プロセスを開始します。stdio には共有する方法がありません。ただし、両方のエントリが同じインストール済みパッケージを実行し、すべてのプロセスが ~/.local/share/mailsync/mailsync.db の同じインデックスを読み書きするため、セットアップが分岐することはありません。コードを一度編集すると、次回の再起動時に両方が反映されます。同時アクセスは安全です: インデックスは WAL モードでビジータイムアウト付きで実行され、5 つのリーダーと 2 つの同時再構築でテストされています。

フルディスクアクセス

~/Library/Mail はフルディスクアクセスの背後にあり、MCP サーバーはそれを起動したアプリの許可を継承します。Claude Code と Claude for Desktop は別々の TCC クライアントであるため、一方が動作してももう一方が動作しないことがあります。システム設定 > プライバシーとセキュリティ > フルディスクアクセスで許可し、アプリを完全に終了して再度開きます。

これがない場合でも、検索と読み取りは保護された領域の外にあるローカルインデックスから機能します。refresh_index だけが失敗するため、データは古くなります。ツールは不明瞭に失敗するのではなく、明確にその旨を伝えます。

作成にはさらに Mail.app の実行と Automation 権限が必要で、macOS は初回使用時にプロンプトを表示します。

部分メッセージ

Mail は完全にダウンロードしていないメッセージのヘッダーのみのコピーを保持します。一般的なメールボックスでは約 4 分の 1 です。これらは送信者、件名、日付、Mail が保存したプレビューテキストで検索可能です。get_message は fetch_if_partial=True を受け取り、Mail に完全なソースを要求します。これにより、サーバーから本文を取得します。これには Mail の実行が必要なため、自動ではなくオプトインです。

インデックスの仕組み

~/.local/share/mailsync/mailsync.db には、~/Library/Mail/V10/**/*.emlx から抽出されたメッセージ本文の FTS5 インデックスが保持され、Mail 自身の Envelope Index にキー付けされています。Mail のデータベースは読み取り前にコピーされ、書き込み可能に開かれたりロックされたりすることはありません。

最初のビルドは 12,800 メッセージで約 1 分かかります。その後は、mtime が変更されたファイルだけが再解析されるため、リフレッシュは 1〜2 秒です。検索は 1 桁から低い 10 桁のミリ秒で返ります。

本文は、Mail が完全にダウンロードした約 70% のメッセージで検索可能です。残りは送信者、件名、日付、Mail 自身のプレビューテキストで検索可能で、get_message はそれらにフォールバックします。Mail が同期するにつれてカバレッジは自然に向上します。

メンテナンス

Apple の Envelope Index スキーマは文書化されておらず、macOS のアップデートで変更される可能性があります。そのすべては mailsync/index.py に限定されており、本文インデックスは --build-index --full でいつでも .emlx ファイルから再構築できます。