mail-mcp

Name: mail-mcp
Author: tecnologicachile

ローカル

github.com/tecnologicachileコミュニケーション1125 日前に更新

リポジトリ

mail-mcp について

mail-mcpは、AIエージェントによるメールの読み取り、検索、管理を可能にするRust製MCPサーバーです。IMAP、SMTP、EWS、Microsoft Graphに対応し、OAuth2と複数アカウントを扱えます。

主な機能

01メールの読み取り、検索、送信、返信、転送
02IMAP、SMTP、EWS、Graph対応
03OAuth2と複数アカウント
04下書きの作成、更新、送信
05メールボックス横断・スレッド検索

活用シーン

01メールを検索して会話全体を取得
02送信前に確認する下書きを準備
03異なるメールバックエンドのアカウントを管理

MCP 対応

メールの読み取り、検索、送信、下書き管理のツールをAIエージェントに提供するMCPサーバーです。標準のstdioに加え、ステートレスなStreamable HTTPにも対応します。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

インストール方法は未掲載です

このサーバーのパッケージやリモートエンドポイントはまだ取得できていません。プロジェクトの README の手順に従ってください。

リポジトリ

ツール

ツール一覧はまだ取得されていません

ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。

詳細

mail-mcp

AI エージェント向けの本番運用対応メール MCP サーバー
IMAP + SMTP + EWS + Microsoft Graph API — Rust で開発

ほとんどのメール MCP サーバーが対応しているのは、IMAP による読み取りだけです。このサーバーはすべてに対応しています。読み取り、検索、送信、返信、転送、一括操作、Microsoft Graph API、Exchange Web Services を、実際の OAuth2、マルチアカウント、マルチプロバイダーに対応して提供します。速度と安全性を重視し、Rust で開発されています。

v0.6.1 の新機能

RUST_LOG=info では、メッセージの内容はログに記録されません。 このレベルでは rmcp ライブラリがすべての JSON-RPC レスポンスを完全な形でログに記録していたため、HTTP トランスポートではメッセージの件名と本文がサーバーログ（systemd サービスの場合はジャーナル）に出力されていました。RUST_LOG でグローバルレベルを info 以上の詳細度に設定すると、RUST_LOG で個別に指定されない限り、rmcp のレベルは warn に制限されるようになりました（デバッグ時は、たとえば RUST_LOG=info,rmcp=info と指定します）。stdio トランスポートではレスポンスはログに記録されておらず、RUST_LOG が未設定の場合も動作に変化はありません。v0.6.0 以前を HTTP 経由で使用している場合は、RUST_LOG=info,rmcp=warn を設定してください。
EWS の設定スコープを修正しました。 Microsoft は現在、https://outlook.office365.com/EWS.AccessAsUser.All を AADSTS70011（invalid_scope）で拒否します。クイックスタートでは https://outlook.office.com/EWS.AccessAsUser.All を使用します。既存の EWS トークンは引き続き使用できます。これは新しいトークンを取得する場合にのみ影響します。

v0.6.0 の新機能

オプトインしない限り、既存のインストール環境に変更はありません。

シェルおよび PowerShell でのインストールにセルフアップデートを追加しました。 インストーラーは mail-mcp-update もインストールするようになりました。これを実行すると、インストール環境をそのまま最新リリースに更新できます。Homebrew でのインストールは、引き続き brew upgrade で更新します。
ローテーションされた OAuth2 リフレッシュトークンを使用し、保存できるようになりました。 Microsoft はリフレッシュのたびに新しいリフレッシュトークンを返します。以前のサーバーはそのトークンを破棄し、設定済みのトークンが期限切れになるまで、それを使ってリフレッシュを続けていました。現在は、最新のトークンを使ってリフレッシュします。再起動後もトークンを保持するには、MAIL_OAUTH2_TOKEN_STORE にファイルパスを設定してください（ファイルは 0600 で書き込まれ、書き込みに失敗しても致命的なエラーにはなりません）。設定でリフレッシュトークンを変更した場合は、常にその設定が保存済みのトークンより優先されます。
ツールとフィールドの説明に送信ルールを追加しました。 プレビューしてから確定するルールと、「body_text と body_html は別々のフィールドである」というルールが、送信ツールと本文フィールドにも表示されるようになりました。これにより、サーバーの指示を転送しない MCP ゲートウェイでも確認できます。mail-mcp をゲートウェイの背後で実行した場合にほかに何が変わるかについては、MCP ゲートウェイの背後で実行するを参照してください。

v0.5.0 の新機能

新機能：下書きツール（draft_create、draft_update、draft_send、 draft_delete、draft_list）により、 #3 と #17 を解決しました。エージェントはアカウント自身の「下書き」フォルダーにメッセージを保存し、編集してから後で送信できます。そのため、まず人がメールクライアントで確認できます。同じ5つのツールはすべてのバックエンドで動作します。IMAP + SMTP、Exchange Web Services、Microsoft Graph の中から、アカウントごとに選択されます（EWS の設定があればそれを使用し、なければ Graph の設定、さらにそれもなければ IMAP を使用）。list_all_accounts はバックエンドを drafts_with で報告します。
独立した制御設定：MAIL_DRAFTS_ENABLED（デフォルトは false）。これは MAIL_IMAP_WRITE_ENABLED とは独立しています。既存の draft_id に対する操作では、まず対象が本当に下書きであることを確認します（IMAP の「下書き」フォルダー、EWS の IsDraft、Graph の isDraft）。そのため、下書きを有効にしても、ほかのメールの移動や削除が許可されることはありません。また、draft_send には MAIL_SMTP_WRITE_ENABLED も必要です。
Graph アカウントで下書きを使うには Mail.ReadWrite スコープが必要です。アカウントのセットアップを参照してください。EWS の添付ファイル処理（SaveOnly を指定した CreateItem の後に CreateAttachment を実行）は、 #14 で @verdelyi が提案した方法に沿っています。
修正：SMTP メッセージに送信者のドメインの Message-ID が付くようになりました （#7）。以前は lettre が独自の Message-ID を送信しなかったため、送信ツールが返す ID は空で、「送信済み」のコピーにも Message-ID がありませんでした。
IMAP（Zoho）と Microsoft Graph で実環境での動作を確認しました。EWS の下書き処理は単体テストで検証しています。

v0.4.17 の新機能

@tdabasinskas による #35 の 新機能：imap_search_all_mailboxes。アカウント内の選択可能なすべてのメールボックスを一度に検索し、最も新しい一致結果をメールボックス名とともに返します。iCloud のように「すべてのメール」フォルダーがないプロバイダー向けに設計されており、会話が受信トレイ、送信済みメッセージ、プロジェクトフォルダーなどに分散している場合に便利です。検索は MAIL_IMAP_SEARCH_CONCURRENCY 個の接続に分散されます（デフォルトは 4、1..=8 の範囲に制限）。検索に失敗したメールボックスは報告されますが、検索全体は中断されません。 include_mailboxes／exclude_mailboxes で対象を絞り込めます。
@tdabasinskas による #34 の Message-ID によるスレッド検索。 imap_search_messages に新しい thread_message_id 条件が追加されました。指定した ID と一致するメッセージ、および In-Reply-To または References にその ID を含むすべてのメッセージを検索するため、エージェントは1回の検索で会話全体を取得できます。

v0.4.16 の新機能

@tdabasinskas による #33 の imap_list_mailboxes の上限が設定可能になり、結果にも表示されるようになりました。以前、このツールは200を超えるメールボックスを通知なく除外していました。フォルダー数がさらに多いアカウント（例：iCloud の217個）では、Sent Messages などのフォルダーが表示されませんでした。上限は MAIL_IMAP_MAX_MAILBOXES で設定できるようになりました（デフォルトは 200、1..=10000 の範囲に制限）。また、レスポンスには追加項目として total と truncated が含まれるため、クライアントは上限に達した一覧か、完全な一覧かを常に判別できます。この変数を設定しない限り、動作に変更はありません。

v0.4.15 の新機能

@tdabasinskas が #32 で実装した 新機能：オプトイン方式のストリーム可能な HTTP トランスポート。 MAIL_MCP_TRANSPORT=http を設定すると、stdio の代わりに MCP のストリーム可能な HTTP（ステートレス）を提供します。MCP ゲートウェイの背後にある別のマシンでサーバーを実行する場合に便利です。デフォルトでは 127.0.0.1:8000 の /mcp にバインドされ、MAIL_MCP_HTTP_HOST / MAIL_MCP_HTTP_PORT / MAIL_MCP_HTTP_PATH で設定できます。SIGINT/SIGTERM 時には正常にシャットダウンします。エンドポイントには組み込みの認証機能がありません。ループバック上、または認証機能を備えたゲートウェイの背後でのみ使用してください。 docs/advanced-configuration.md#remote-http-transport を参照してください。デフォルトは引き続き stdio です。この変数を設定しない限り、変更はありません。

v0.4.14 の新機能

コミュニティによるリリースです。2 件の変更はいずれも外部のコントリビューターによるものです。ありがとうございます！

@mjones-PL が #31 で実装し、 #11 を解決した 新機能：MAIL_ATTACHMENT_UPLOAD_DIR — 送信する file_path 添付ファイルを指定範囲内に制限。制限がない場合、送信ツールはサーバープロセスがアクセスできるすべてのファイルを読み取ります。プロンプトインジェクションを受けたモデルが、SSH キーや .env ファイルを添付ファイルとして外部に送信する可能性があります。この変数にディレクトリを設定すると、すべての file_path が正規化され（.. とシンボリックリンクを解決）、そのディレクトリ内に収まっている必要があります。ファイルが存在しない場合も範囲外の場合も同じエラーを返すため、このチェックを使ってファイルの存在を探ることはできません。オプトイン方式です。未設定の場合、動作は変わりません。docs/security.md#outbound-attachment-scope を参照してください。
@arwack が #30 で実装した 修正：FROM_EMAIL の検証で、ドットのない内部ホストが拒否されなくなりました。 v0.4.13 へのアップグレードに関する注意点に対処します。企業の内部リレーで使われる noreply@localhost や alerts@intranet のようなアドレスが再び受け入れられる一方、実際の入力ミスのチェック（複数の @、空白、空のローカル部）は引き続き行われます。この問題のために v0.4.13 へのアップグレードを見送っていた場合は、v0.4.14 に安全にアップグレードできます。

v0.4.13 の新機能

@arwack が #29 で実装した effective_from() ヘルパーと FROM_EMAIL の起動時検証。同氏による #19 の続編です。 from_email → user のフォールバックが 1 か所（SmtpAccountConfig::effective_from()）に集約され、MAIL_SMTP_<ID>_FROM_EMAIL は最初の送信時に失敗するのではなく、サーバーの起動時に検証されるようになりました。
アップグレード前にお読みください — 動作変更： 不正な FROM_EMAIL （複数の @、空白、空のローカル部、またはドットのないドメイン）があると、 すべてのアカウントでサーバーが起動しなくなりました。user@localhost や alerts@intranet のようなドットのないドメインも現在は拒否される点にご注意ください。このような内部リレーアドレスを使用している場合は、アップグレードを見送ってください。ドットのルールを緩和するフォローアップが #29 で検討されています。
@tordable が #28 で APPEND のワイヤーフォーマットテストを強化しました。すべての append テストで、メールボックスの引用符、通知されたリテラルの長さ、ペイロードのバイト単位での一致が検証されるようになりました。

v0.4.12 の新機能

コミュニティによるリリースです。2つの変更はどちらも外部のコントリビューターによるものです。ありがとうございます！

iCloud のメールボックスエイリアスに対応し、読み取りによってメッセージが既読にならないようにしました。 @felipefdl による変更で、 #16 に含まれています。短いメールボックス名は、検索、コピー、移動の際に、各プロバイダーの実際のフォルダー名（iCloud の Sent → Sent Messages、Gmail の Sent → [Gmail]/Sent Mail、Trash → Deleted Messages など。複数言語に対応）に解決されるようになりました。生のメッセージ取得には BODY.PEEK[] を使用するため、MCP 経由でメッセージを読んでも副作用として \Seen が設定されなくなりました。PEEK を拒否するサーバー向けには BODY[] にフォールバックします（#23 で削除された非推奨の RFC822 アイテムは使用しません）。作者が実際の iCloud メールボックスで検証済みです。エイリアス解決のテストと iCloud のセットアップ手順も含まれています。
マルチステージ Dockerfile と docker-compose を最適化しました。 @monssefbaakka による変更で、 #5 に含まれています。cargo-chef によるレイヤーキャッシュ、TARGETARCH に対応した musl クロスビルド（amd64/arm64）、および scratch ランタイムイメージを採用しました。イメージサイズは 25.5 MB から 16.9 MB に縮小し、stdio 経由の MCP initialize/tools-list に応答することを確認済みです。コードベースの let-chains に 1.88 以上が必要なため、ツールチェーンのバージョン指定を Rust 1.90 に更新しました。

v0.4.11 の新機能

コミュニティによるバグ修正リリースです。修正はどちらも外部のコントリビューターによるものです。ありがとうございます！

修正：厳格な IMAP サーバー（iCloud など）で、Sent への保存が通知なく失敗していました。 @dominikknafelj による修正で、 #26 に含まれています。#25 で報告されました。v0.4.10 で導入された \Seen フラグが、RFC 3501 の括弧付きフラグリストの構文（APPEND "Sent" \Seen … ではなく APPEND "Sent" (\Seen) …）を使わずに送信されていました。これは、async-imap がフラグ引数をそのまま埋め込むためです。厳格なサーバーは APPEND を拒否し、ツールが status: ok を返す一方で、送信済みコピーが失われていました。送信前にフラグを正規化するようになり、smtp_send_message／smtp_reply_message／smtp_forward_message のレスポンスには新たに saved_to_sent フィールドが含まれるようになりました（保存が有効な場合は true／false、無効な場合は null）。これにより、呼び出し元でアーカイブの失敗を検出できます。 @tordable も同じ根本原因を並行して特定し、#24 で修正しました。
修正：iCloud でメッセージの読み取り結果が空になっていました。 @tdabasinskas による修正で、 #23 に含まれています。生のメッセージ取得には非推奨の RFC822 アイテムを使用していました。iCloud はこれを受け入れるものの、内容を設定しません。取得には IMAP4rev1 の BODY[] アイテムを使用するようになりました。\Seen の動作は同じで、あらゆる環境で機能します。モックサーバーのリグレッションテストで、ワイヤーフォーマットを固定しています。

v0.4.10 の新機能

コミュニティからのリリースです。3つの変更すべてが外部のコントリビューターによるものです。ありがとうございます！

NetEase IMAP との互換性（126.com / 163.com / yeah.net）： @pep-27 が #21 で対応しました。NetEase のサーバーは、自分自身を識別しないクライアントからのメールボックスへのアクセスを拒否します。mail-mcp は、サーバーが ID 機能を通知した場合、認証後に RFC 2971 の ID コマンドを送信するようになりました。モックサーバーを使ったリグレッションテストと、docs/account-setup.md の NetEase セットアップドキュメントも含まれています。
MAIL_SMTP_<ID>_FROM_EMAIL — 送信者アドレスの上書き： @arwack が #19 で対応しました。SMTP 認証には個人アカウントを使い、From アドレスにはグループアドレスを使う共有／グループメールボックス向けの設定です。送信、返信（全員に返信する際の自分のアドレス判定を含む）、転送に適用されます。未設定の場合は _USER にフォールバックします。
送信済みメールのコピーに \Seen が付くようになりました： @ray-of-darkness が #9 で対応しました。SMTP 送信後に MCP が Sent フォルダーへ追加するコピーが、未読として表示されなくなりました。

v0.4.9 の新機能

新しいツール imap_get_attachment — 添付ファイルを1つダウンロードしてディスクに保存します。 これまでは、添付ファイルのバイトデータを取得する方法は imap_get_message（添付ファイルの メタデータ と、任意で抽出した PDF の テキスト を返します。バイナリデータは返しません）と、imap_get_message_raw（最大 1 MB で、レスポンスに base64 エンコードされます）しかありませんでした。X 線画像を含む 7 MB のメールは、上限を超えるため取得できず、レスポンスに出力するとモデルのコンテキストを圧迫してしまいます。
仕組み： message_id とセレクター（imap_get_message が各添付ファイルについて返す値である part_id、または filename）を指定して imap_get_attachment を呼び出します。サーバーはメッセージ全体を取得し（サーバー側にサイズ上限はありません）、指定されたパートだけを抽出してデコードし、ディスクに書き込みます。返されるのは { file_path, filename, content_type, part_id, size_bytes } です。バイナリデータはレスポンスに含まれないため、コンテキストを小さく保てます。保存されたパスは、ローカルのリーダー（画像説明ツールや PDF リーダーなど）にそのまま渡せます。
ファイルの保存先： output_dir 引数が指定されていればそのディレクトリ、そうでなければ MAIL_ATTACHMENT_DOWNLOAD_DIR 環境変数で指定されたディレクトリ、どちらもなければシステムの一時ディレクトリです。パストラバーサルを防ぐため、ファイル名はサニタイズされ（ベース名のみを使用し、制御文字を除去します）、衝突を避けるためメッセージ UID とパート ID が先頭に付加されます。
任意のインライン base64： include_base64: true を設定すると、添付ファイルが max_inline_bytes 以下の場合に限り（デフォルトは 256 KiB）、バイトデータもレスポンスに含められます。デフォルトでは無効です。

v0.4.8 の新機能

SAVE_SENT がアカウントごとに設定できるようになり、プロバイダーを考慮したデフォルト値が適用されます。 以前は、IMAP APPEND を使って送信メールのコピーを「送信済み」フォルダーに保存するかどうかを、単一のグローバルフラグ MAIL_SMTP_SAVE_SENT で制御していました。問題は、送信済みメールをサーバー側ですでに保存するプロバイダー（Gmail、Zoho）では、「送信済み」に同一のコピーが2つできる一方、汎用 SMTP サーバーや Office 365（SMTP 送信時に自動保存しない）では、フラグが false の場合にコピーが完全に失われてしまうことでした。
プロバイダーを考慮したデフォルト値（何も設定されていない場合）：
- Gmail（smtp.gmail.com）：サーバー側で保存し、Message-ID で重複を排除するため、MCP は追加保存しません（false）。
- Zoho（smtp.zoho.com）：サーバー側で保存しますが、重複を排除しません。そのため、重複を避けるために MCP は追加保存しません（false）。
- Office 365／汎用 SMTP：SMTP 送信時に自動保存しないため、MCP は追加保存します（true）。そうしないと、送信済みコピーが失われてしまいます。
アカウントごとの上書き設定：MAIL_SMTP_<ID>_SAVE_SENT=true|false がすべての設定より優先されます。グローバル設定の MAIL_SMTP_SAVE_SENT も引き続き使えます（プロバイダーのデフォルト値より優先され、アカウントごとの設定には劣後します）。
優先順位：アカウントごとの設定 → グローバル設定 → プロバイダーを考慮したデフォルト値。

プロバイダー	サーバー側で自動保存	MCP のデフォルト
Gmail	はい（重複排除あり）	`false`
Zoho	はい（重複排除なし）	`false`
Office 365（SMTP）	いいえ	`true`
汎用 SMTP／リレー	いいえ	`true`

v0.4.7 の新機能

重大な修正 — graph_send_message がスレッド返信の添付ファイルを何も通知せずに破棄していました。 in_reply_to と attachments を指定して呼び出すと、createReply → PATCH → send のフローで、/me/messages/{id} への PATCH に添付ファイルが含まれていました。Microsoft Graph は Message.attachments をナビゲーションプロパティとして扱い、PATCH 時にこのフィールドを何も通知せずに破棄していました（2xx 応答でエラーなし）。そのため、メッセージはファイルのない単一パートの text/html として送信されていました。MCP は status: ok を返すため、呼び出し元は成功したと思い込んでいました。データが見えない形で失われていました。
修正内容： send_via_reply() では、PATCH の後、送信の前に、添付ファイルを1つずつ POST /me/messages/{draft_id}/attachments にアップロードするようになりました。3 MB 未満のファイルはインラインで送信されます（base64 の contentBytes を含む JSON）。3 MB 以上のファイルには、4 MB 単位の PUT を使う createUploadSession を使用します。型チェックに通る編集でこの不具合が再発しないよう、PatchDraftRequest 構造体から attachments フィールドを削除しました。
すでに正常に動作していたフローに変更はありません。 send_via_sendmail（in_reply_to のない新規メッセージ）は、JSON に attachments をインラインで含めて POST /me/sendMail を使用します。Graph はこのエンドポイントではこのフィールドを受け付け、破棄することはありません。この経路には変更を加えていません。
回帰テストを追加： patch_draft_request_never_serializes_attachments は、構造体にこのフィールドが再追加されると失敗します。
参考： リポジトリのルートにある BUG_GRAPH_ATTACHMENTS.md に、完全な再現手順、根本原因、修正の根拠となった実証データを記載しています。

v0.4.6 の新機能

HARD RULE #1 をサーバー側で強制。 プロンプトのみで3回にわたって強化（v0.4.3 → v0.4.4 → v0.4.5）しても、LLM が文字列 </body_text><parameter name="body_html"> のマークアップを受信者の受信トレイに漏らすことがありました。v0.4.6 では実際のバリデーターを追加し、body_text または body_html にツール呼び出しのラッパー構文が含まれている場合、SMTP／Graph／EWS を試みる前にツール呼び出しを拒否します。このチェックは5つすべての送信経路（smtp_send_message、smtp_reply_message、smtp_forward_message、graph_send_message、ews_send_message）に組み込まれています。
禁止マーカーは大文字と小文字を区別せず、人間のやり取りで正当に使われることのない擬似タグだけに厳密に限定されています。対象は <body_text>、</body_text>、<body_html>、</body_html>、<function_calls>、</function_calls>、<invoke name=、</invoke>、および <parameter name="body_*"> です。XML スキーマについて <parameter> に言及する技術的な内容や、コード例に <invoke> が含まれる場合など、一般的な技術内容は引き続き通過します。
HARD RULE #1 の文言を更新し、サーバー側で拒否されることを明記しました。これにより、LLM は無視できる提案ではなく、厳守すべき契約であると認識できます。
クリーンな呼び出し元に破壊的変更はありません。適切な形式のメッセージは、これまでどおり送信されます。

v0.4.5 の新機能

serverInfo が name="mail-mcp" とクレートの version を返すようになりました（これまではフレームワーク独自の rmcp 0.16.0 が返されていましたが、リリース間で変わることはありませんでした）。/mcp でアクティブなバージョンを確認する際に便利です。また、（サーバー、バージョン）をキーとするクライアント側のキャッシュが、バージョン更新のたびに無効化されるようになります。
MCP の指示を再構成しました：重要な3つの連結防止ルール（v0.4.3 と v0.4.4 ではブロックの末尾にあり、切り詰められたり注意が薄れたりする可能性がありました）が、タイトルの直後、冒頭に HARD RULE #1、#2、#3 として配置されました。3つの短い段落にまとめています（以前は長いセクションが3つで、合計約1500文字でした）。
サーバーの機能に変更はありません。 SMTP／IMAP／EWS／Graph、ツールセット、動作はこれまでどおりです。クライアントに公開されるテキストのみが変更されました。

これらのルールを適用するための重要事項

claude --continue（または /resume）でセッションを再開するクライアントは、MCP の system_prompt を更新しません。セッションの最初のハンドシェイクで受け取ったものを使い続けます。セッション開始時に v0.4.5 より前のバージョンを使用していた場合、ディスク上のバイナリを更新しても、ルールはコンテキストに反映されません。ルールを適用するには、プロジェクトで新しいセッションを開始してください（--continue は使用しないでください）。

v0.4.4 の新機能

MCP の instructions にプレビューの表示ルールを追加しました。LLM が送信前にユーザーへメールのプレビューを見せるときは、本文を読みやすい形式（Markdown 形式の箇条書き、太字、テキスト＋URL 形式のリンク）で1つだけ表示し、メッセージが multipart 形式で送信されることを伝えます。ただし、生の HTML ソース（<p>、<strong>、<a href> など）をプレビューにそのまま出してはいけません。理由は2つあります。
1. 確認する人が読みたいのはメッセージであり、マークアップの監査ではありません。HTML を表示してもノイズになります。
2. プレビューにプレーンテキスト文字列と HTML 文字列の両方を並べて表示すると、最終的なツール呼び出しで LLM が両者を連結する原因になってきました（v0.4.3 で記録された不具合です）。プレビューから HTML ソースを隠すことで、そうしたくなる要因をなくせます。
これは v0.4.3 で導入された プレビューとツール呼び出しは同じではない というルールを補完するものです。

v0.4.3 の新機能

不正なツール呼び出しを防ぐサーバー側のガイダンス。 MCP の instructions ブロックで、呼び出し元の LLM に対し、 body_text と body_html は個別の JSON フィールドであり、絶対に連結してはならないことを明示するようになりました。以前の表現（「body_text と body_html の両方を送信する」）は曖昧で、一部の LLM はこれを「単一の body_text 文字列の中に <body_text>...</body_html> の疑似タグを付けて両方を連結する」と解釈していました。そうなると、受信者には内容が文字化けして重複して表示されます。また、この MCP を通じて保存されたコピーを後から Claude のセッションで開くと、Usage Policy によってブロックされます（漏れ出した <invoke>...</invoke> が、安全性フィルターにプロンプトインジェクションの試みと判断されるためです）。新しい指示では、正しい例と誤った例を示し、メールのフィールド内での疑似タグやツール呼び出しのラッパー構文を禁止します。

v0.4.2 の新機能

リリースパイプラインを修正：CI リリースワークフローの publish-npm ジョブを無効にしました。上流のフォークから引き継がれたもので、この組織が所有していないスコープ @bradsjm/mail-imap-mcp-rs への公開を試みていたため、リリースのたびにこのステップで 404 が発生していました。詳しい説明と、必要に応じて npm への公開を再度有効にする方法については、以下の「リリース」を参照してください。
タグのプッシュでリリースを自動開始：.github/workflows/release.yml が push: tags: ['v*'] で実行されるようになりました。vX.Y.Z のタグを付けてプッシュするだけでリリースできます。手動での実行手段として workflow_dispatch も引き続き利用できます。
整理：残存していた init-npm-placeholder.yml ワークフローを削除しました（フォークの npm スコープも参照していました）。
ドキュメント：README に、新しいリリース手順と npm に関する判断を説明する「リリース」セクションを追加しました。

v0.4.1 の新機能

修正：save_to_sent_folder が、手作業で作成したテキストのみの代替データではなく、送信したものと完全に同じ RFC822 バイト列（lettre.formatted() 経由）をアーカイブするようになりました。送信済みフォルダーのコピーに HTML 本文、 multipart/alternative の構造、RFC 2047 エンコードされた件名が保持されます。アクセント記号が ??? に置き換わることがなくなり、HTML も暗黙に削除されなくなりました。
改善：送信済みフォルダーのローカライズされた検出に対応しました。 Enviado[s]、Elementos enviados、Enviadas、Itens enviados、 Envoyés、Éléments envoyés、Gesendet、Posta inviata、 Verzonden、Wysłane と、ネストされたフォルダー名にも対応します。以前は英語名のみが認識されていたため、Zoho やローカライズされた IMAP アカウントでは存在しない "Sent" フォルダーにフォールバックしていました。
改善：smtp_forward_message が body_html を受け付けるようになりました（以前はプレーンテキストのみがハードコードされていました）。
改善：EWS の送信で、bcc、in_reply_to、references（ <t:InternetMessageHeaders> 経由）に対応し、宛先と件名の長さに関する完全な検証も追加しました。これにより、SMTP および Graph の送信処理と同等になりました。
改善：Graph API のスレッド処理におけるフォールバックがログに記録されるようになりました。メッセージ検索の HTTP 呼び出しに失敗した場合（レート制限、5xx、権限エラーなど）は WARN を記録し、実際のエラーによりスレッド処理が劣化したことを運用担当者が把握できるようにします。元のメッセージが正当に見つからなかった場合は DEBUG を記録します。
リファクタリング：EWS の XML 解析を部分文字列の照合から quick-xml に移行しました。潜在的な名前空間衝突のバグ（<soap:Body> と <t:Body>）を修正し、XML エンティティと CDATA を正しくデコードするとともに、 = を含む属性値（base64 に似た EWS アイテム ID で一般的）も処理できるようにしました。
整理：cargo build --release の警告がゼロになりました。
テスト：テスト数が 47 から 64 に増えました。

このプロジェクトを選ぶ理由

	mail-mcp	一般的なメール MCP
IMAP の読み取り／書き込み	18 個のツール	3～5 個のツール
SMTP の送信／返信／転送	対応	非対応または不具合あり
Microsoft Graph API	対応	非対応
EWS（Exchange Web Services）	対応	非対応
OAuth2（XOAUTH2）	ネイティブ対応	非対応
マルチアカウント	対応	単一アカウント
Microsoft 365 + Hotmail	両方に対応	通常どちらにも非対応
言語	Rust（高速、安全）	TypeScript/Python
テスト	単体テスト＋統合テスト 64 件	モックのみ
リリースビルドの警告	0 件	さまざま

機能マトリックス

プロバイダー	IMAP	SMTP	Graph API	EWS	OAuth2	複数アカウント
Microsoft 365（エンタープライズ）	はい	管理者の設定による	はい	はい	はい	はい
Hotmail / Outlook.com	はい	MS によりブロック	はい	はい	はい	はい
Gmail	はい	はい	—	—	はい	はい
Apple iCloud	はい	はい	—	—	—	はい
Zoho	はい	はい	—	—	—	はい
Fastmail	はい	はい	—	—	—	はい
任意の IMAP/SMTP サーバー	はい	はい	—	—	—	はい

Microsoft アカウントを追加する最も簡単な方法は EWS です — 読み取りと送信の両方に単一の OAuth2 トークンを使用します。Graph API と IMAP がブロックされているテナントでも機能します。

クイックスタート — Claude Code に任せる

このプロンプトを Claude Code にコピーして貼り付けると、すべてをインストール、コンパイル、設定します。

Install and configure the mail-mcp MCP server from https://github.com/tecnologicachile/mail-mcp

1. Clone the repo, build with cargo build --release
2. Add the MCP server to .claude.json with the binary path
3. For Microsoft accounts: use EWS (simplest) — run device code flow with
   client_id d3590ed6-52b3-4102-aeff-aad2292ab01c and scope
   https://outlook.office.com/EWS.AccessAsUser.All offline_access
   Then configure MAIL_EWS_<ID>_USER and MAIL_EWS_<ID>_REFRESH_TOKEN
4. For Gmail: configure MAIL_IMAP + MAIL_SMTP with App Password from
   https://myaccount.google.com/apppasswords
5. For Zoho: configure MAIL_IMAP + MAIL_SMTP with standard password
6. Enable write/send: MAIL_IMAP_WRITE_ENABLED=true, MAIL_SMTP_WRITE_ENABLED=true

My email accounts to configure:
- <[email protected]>

最後の行を自分のメールアドレスに置き換えてください。Claude Code が、Microsoft アカウントの OAuth2 デバイスコードフローを含む各手順を案内します。

手動セットアップ（2 分）

ビルド済みバイナリをインストールします。

# macOS and Linux (Homebrew)
brew install tecnologicachile/tap/mail-mcp

# macOS and Linux (shell installer)
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/tecnologicachile/mail-mcp/releases/latest/download/mail-mcp-installer.sh | sh

シェルおよび PowerShell のインストーラーは、既存のインストールを最新リリースに更新する mail-mcp-update もインストールします。Homebrew を使用する場合は、brew upgrade mail-mcp を実行してください。

# Windows
powershell -ExecutionPolicy Bypass -c "irm https://github.com/tecnologicachile/mail-mcp/releases/latest/download/mail-mcp-installer.ps1 | iex"

または、ソースからビルドします。

git clone https://github.com/tecnologicachile/mail-mcp.git
cd mail-mcp
cargo build --release

MCP クライアントの設定（Claude Code、Cursor など）に追加します。ビルド済みバイナリを使用する場合は、"command": "mail-mcp" を指定します。

{
  "mcpServers": {
    "mail": {
      "command": "./target/release/mail-mcp",
      "env": {
        "MAIL_IMAP_DEFAULT_HOST": "imap.gmail.com",
        "MAIL_IMAP_DEFAULT_USER": "[email protected]",
        "MAIL_IMAP_DEFAULT_PASS": "your-app-password",
        "MAIL_SMTP_DEFAULT_HOST": "smtp.gmail.com",
        "MAIL_SMTP_DEFAULT_PORT": "587",
        "MAIL_SMTP_DEFAULT_USER": "[email protected]",
        "MAIL_SMTP_DEFAULT_PASS": "your-app-password",
        "MAIL_SMTP_DEFAULT_SECURE": "starttls",
        "MAIL_IMAP_WRITE_ENABLED": "true",
        "MAIL_SMTP_WRITE_ENABLED": "true"
      }
    }
  }
}

これで完了です。AI エージェントがメールの読み取り、検索、送信、返信、管理を行えるようになります。

Microsoft アカウントをお使いですか？Graph API を使用してください

Microsoft は個人アカウントでの SMTP をブロックしています。代わりに Graph API を使用してください。

{
  "env": {
    "MAIL_IMAP_DEFAULT_HOST": "outlook.office365.com",
    "MAIL_IMAP_DEFAULT_USER": "[email protected]",
    "MAIL_IMAP_DEFAULT_PASS": "your-app-password",
    "MAIL_OAUTH2_DEFAULT_PROVIDER": "microsoft",
    "MAIL_OAUTH2_DEFAULT_CLIENT_ID": "9e5f94bc-e8a4-4e73-b8be-63364c29d753",
    "MAIL_OAUTH2_DEFAULT_CLIENT_SECRET": "none",
    "MAIL_OAUTH2_DEFAULT_REFRESH_TOKEN": "<your-token>"
  }
}

デバイスコードフローを使えば、1 分でトークンを取得できます。アカウント設定ガイドをご覧ください。

37 個の MCP ツール

読み取り（10 個のツール）

ツール	機能
`list_all_accounts`	機能（IMAP、SMTP、Graph、EWS）とともにすべてのアカウントを一覧表示
`imap_list_accounts`	IMAP アカウントを一覧表示
`imap_verify_account`	接続と認証をテスト
`imap_list_mailboxes`	フォルダーを一覧表示
`imap_mailbox_status`	メッセージ数を表示
`imap_search_messages`	カーソルページネーションで検索。`thread_message_id` を指定すると、メッセージとその返信を検索
`imap_search_all_mailboxes`	すべてのメールボックスを対象に、同じ条件で一括検索（例：INBOX、送信済み、プロジェクトフォルダーに分散した会話全体）。新しい順に、メールボックス名付きで表示
`imap_get_message`	解析済みメッセージ（テキスト、HTML、添付ファイル）
`imap_get_message_raw`	RFC822 ソース
`imap_get_attachment`	添付ファイルを 1 件ディスクにダウンロード（生データのサイズ上限を回避）

書き込み（11 個のツール）

ツール	機能
`imap_update_message_flags`	フラグを追加／削除
`imap_copy_message`	コピー（アカウント間にも対応）
`imap_move_message`	フォルダーに移動
`imap_delete_message`	確認後に削除
`imap_create_mailbox`	フォルダーを作成
`imap_delete_mailbox`	フォルダーを削除
`imap_rename_mailbox`	フォルダー名を変更
`imap_append_message`	生メッセージを追加
`imap_bulk_move`	一度に最大 500 件を移動
`imap_bulk_delete`	一度に最大 500 件を削除
`imap_bulk_update_flags`	一度に最大 500 件のフラグを更新

送信（5 個のツール）

ツール	機能
`smtp_send_message`	メールを送信（テキスト／HTML、CC/BCC）
`smtp_reply_message`	スレッド用ヘッダー付きで返信
`smtp_forward_message`	元の内容をインラインで転送
`smtp_verify_account`	SMTP 接続をテスト
`graph_send_message`	Microsoft Graph API 経由で送信（返信スレッドにも対応）

EWS — Exchange Web Services（3 個のツール）

ツール	機能
`ews_search_messages`	EWS 経由でメールを検索（受信トレイ、送信済み、下書きなど）
`ews_get_message`	EWS 経由でメールの全文を取得
`ews_send_message`	EWS 経由でメールを送信

下書き（5 個のツール）

エージェントがメールを作成し、ユーザーがメールクライアントで確認するか、エージェントに送信を依頼します。どのアカウントでも同じツールセットを使用できます。下書きは IMAP の Drafts フォルダーに保存されるか、アカウントで設定されている場合は EWS または Microsoft Graph 経由で保存されます（list_all_accounts で drafts_with を確認できます）。

ツール	機能
`draft_create`	新しい下書きを保存します（CC／BCC、HTML、添付ファイル、スレッド化に対応）
`draft_update`	下書きの内容を置き換え、新しい `draft_id` を返します
`draft_send`	下書きを送信し、Drafts から削除します
`draft_delete`	下書きを削除します（下書きのみ。`confirm: true` が必要です）
`draft_list`	下書きを新しい順に一覧表示します

MAIL_DRAFTS_ENABLED=true で有効にします。MAIL_IMAP_WRITE_ENABLED とは独立しており、下書きのみを有効にした場合、エージェントは下書きを作成できますが、他のメールを移動、フラグ付け、削除することはできません。また、各下書きツールは下書き以外の ID を拒否します。draft_send にはさらに MAIL_SMTP_WRITE_ENABLED=true が必要です。Graph アカウントには Mail.ReadWrite スコープが必要です。

添付ファイル

任意の送信ツールでファイルを送信できます。方法は 2 つあります。

// Large files — MCP reads from disk (recommended)
"attachments": [{"file_path": "/path/to/report.pdf"}]

// Small files — inline base64
"attachments": [{"filename": "note.txt", "content_type": "text/plain", "content_base64": "SGVsbG8="}]

ファイル名と MIME タイプはファイルパスから自動検出されます。元の添付ファイルを転送するには、include_original_attachments: true を指定して返信します。

受信メッセージの添付ファイルをダウンロードするには、message_id と、imap_get_message から取得した part_id または filename を指定して imap_get_attachment を使用します。デコードしたファイルがディスクに書き込まれ、そのパスが返されます。サイズ上限はなく、バイナリデータがレスポンスに含まれることもありません。既定のダウンロード先ディレクトリは MAIL_ATTACHMENT_DOWNLOAD_DIR で設定します（未設定の場合はシステムの一時ディレクトリが使用されます）。呼び出しごとに output_dir を指定することもできます。

送信ツールが file_path 経由で添付できるローカルファイルを制限するには、MAIL_ATTACHMENT_UPLOAD_DIR を設定します。範囲外のパス（.. やシンボリックリンク経由のパスを含む）は拒否されます。docs/security.md を参照してください。

一括操作（2 個のツール）

ツール	機能
`imap_search_and_move`	検索して一致したメールを移動します
`imap_search_and_delete`	検索して一致したメールを削除します

セットアップヘルパー（1 個のツール）

ツール	機能
`get_setup_guide`	プロバイダー別のセットアップ手順（Microsoft OAuth2、Gmail／iCloud のアプリパスワード、Zoho など）

複数アカウント

必要な数のアカウントを設定できます。

# Gmail
MAIL_IMAP_GMAIL_HOST=imap.gmail.com
[email protected]
MAIL_IMAP_GMAIL_PASS=app-password

# Apple iCloud (App-Specific Password from appleid.apple.com)
MAIL_IMAP_ICLOUD_HOST=imap.mail.me.com
[email protected]
MAIL_IMAP_ICLOUD_PASS=app-specific-password
MAIL_SMTP_ICLOUD_HOST=smtp.mail.me.com
[email protected]
MAIL_SMTP_ICLOUD_PASS=app-specific-password
MAIL_SMTP_ICLOUD_SECURE=starttls

# Microsoft 365
MAIL_IMAP_WORK_HOST=outlook.office365.com
[email protected]
MAIL_OAUTH2_WORK_PROVIDER=microsoft
MAIL_OAUTH2_WORK_CLIENT_ID=your-client-id
MAIL_OAUTH2_WORK_CLIENT_SECRET=none
MAIL_OAUTH2_WORK_REFRESH_TOKEN=your-token

# Zoho
MAIL_IMAP_DEFAULT_HOST=imap.zoho.com
[email protected]
MAIL_IMAP_DEFAULT_PASS=password
MAIL_SMTP_DEFAULT_HOST=smtp.zoho.com
[email protected]
MAIL_SMTP_DEFAULT_PASS=password
MAIL_SMTP_DEFAULT_SECURE=starttls

ツール呼び出しでは account_id を使用します。例："account_id": "gmail"、"account_id": "icloud"、"account_id": "work"、"account_id": "default"。

セキュリティ

すべての接続で TLS を強制（localhost プロキシを除く）
パスワードは SecretString に格納 — ログに記録されたり、レスポンスで返されたりすることはありません
書き込み操作は制限 — 明示的に MAIL_IMAP_WRITE_ENABLED=true を設定する必要があります
送信操作は制限 — 明示的に MAIL_SMTP_WRITE_ENABLED=true を設定する必要があります
下書きは個別に制限 — MAIL_DRAFTS_ENABLED=true を設定すると、他の書き込みアクセスを許可せずに下書きを作成できます
削除の確認 — confirm: true が必要です
HTML を ammonia でサニタイズ（XSS を防止）
出力サイズを制限 — 本文、HTML、添付ファイルは設定可能な上限までに切り詰められます
OAuth2 トークンをキャッシュ（更新期限の 10 分前に更新）
レスポンスにシークレットを含めない — MCP ツール経由で認証情報が公開されることはありません
HTTP トランスポートはオプトインで、認証されません — 既定では stdio を使用します。MAIL_MCP_TRANSPORT=http は別途指定がない限りループバックにバインドされ、認証ゲートウェイの背後に配置する必要があります

設定リファレンス

環境変数の完全なリファレンス

IMAP（アカウントごと）

変数	必須	既定値	説明
`MAIL_IMAP_<ID>_HOST`	はい	—	IMAP サーバー
`MAIL_IMAP_<ID>_PORT`	いいえ	993	IMAP ポート
`MAIL_IMAP_<ID>_USER`	はい	—	ユーザー名
`MAIL_IMAP_<ID>_PASS`	はい*	—	パスワード（*OAuth2 を使用する場合は省略可能）
`MAIL_IMAP_<ID>_SECURE`	いいえ	true	TLS を使用するかどうか

SMTP（アカウントごと）

変数	必須	デフォルト	説明
`MAIL_SMTP_<ID>_HOST`	はい	—	SMTP サーバー
`MAIL_SMTP_<ID>_PORT`	いいえ	587	SMTP ポート
`MAIL_SMTP_<ID>_USER`	はい	—	ユーザー名
`MAIL_SMTP_<ID>_PASS`	いいえ	—	パスワード（OAuth2 を使用する場合は省略可能）
`MAIL_SMTP_<ID>_SECURE`	いいえ	starttls	`starttls`、`tls`、または `plain`
`MAIL_SMTP_<ID>_FROM_EMAIL`	いいえ	= `_USER`	SMTP 認証のユーザー名と異なる場合の送信者アドレス（共有メールボックスやグループメールボックスなど）

OAuth2（アカウントごと）

変数	必須	デフォルト	説明
`MAIL_OAUTH2_<ID>_PROVIDER`	はい	—	`google` または `microsoft`
`MAIL_OAUTH2_<ID>_CLIENT_ID`	はい	—	OAuth2 クライアント ID
`MAIL_OAUTH2_<ID>_CLIENT_SECRET`	はい	—	クライアントシークレット（パブリッククライアントの場合は `none`）
`MAIL_OAUTH2_<ID>_REFRESH_TOKEN`	はい	—	リフレッシュトークン

Graph API OAuth2（アカウントごと）

変数	必須	デフォルト	説明
`MAIL_GRAPH_<ID>_PROVIDER`	はい	—	`microsoft`
`MAIL_GRAPH_<ID>_CLIENT_ID`	はい	—	OAuth2 クライアント ID
`MAIL_GRAPH_<ID>_CLIENT_SECRET`	はい	—	クライアントシークレット（パブリッククライアントの場合は `none`）
`MAIL_GRAPH_<ID>_REFRESH_TOKEN`	はい	—	リフレッシュトークン（Mail.Send スコープ）

EWS — Exchange Web Services（アカウントごと、Microsoft で最も簡単な方法）

変数	必須	デフォルト	説明
`MAIL_EWS_<ID>_USER`	はい	—	メールアドレス
`MAIL_EWS_<ID>_REFRESH_TOKEN`	はい	—	OAuth2 リフレッシュトークン（EWS スコープ）
`MAIL_EWS_<ID>_CLIENT_ID`	いいえ	`d3590ed6...`（Microsoft Office）	OAuth2 クライアント ID
`MAIL_EWS_<ID>_CLIENT_SECRET`	いいえ	`none`	クライアントシークレット

ヒント： EWS で必要なのは 2 つの変数（USER + REFRESH_TOKEN）だけです。クライアント ID のデフォルトは、すべての権限が事前承認されている Microsoft Office です。

グローバル設定

変数	デフォルト	説明
`MAIL_IMAP_WRITE_ENABLED`	false	IMAP 書き込み操作を有効にする
`MAIL_SMTP_WRITE_ENABLED`	false	SMTP/Graph の送信操作を有効にする
`MAIL_DRAFTS_ENABLED`	false	下書きツールを有効にする（`draft_send` には `MAIL_SMTP_WRITE_ENABLED` も必要）
`MAIL_SMTP_SAVE_SENT`	false	送信済みメールを IMAP の Sent フォルダーに保存する（送信時に自動保存されないプロバイダーの場合に有効にします。たとえば、Gmail では自動保存されますが、Zoho では常に保存されるわけではありません）
`MAIL_SMTP_CONNECT_TIMEOUT_MS`	30000	SMTP TCP/TLS/認証のタイムアウト（接続フェーズ）
`MAIL_SMTP_SEND_TIMEOUT_MS`	300000	SMTP DATA 送信のタイムアウト（5 分。大きな添付ファイルに対応）
`MAIL_SMTP_TIMEOUT_MS`	(非推奨)	従来の単一タイムアウト。`MAIL_SMTP_SEND_TIMEOUT_MS` のフォールバックとして使用されます。上記の分割された変数を優先してください。
`MAIL_IMAP_CONNECT_TIMEOUT_MS`	30000	TCP 接続のタイムアウト
`MAIL_IMAP_GREETING_TIMEOUT_MS`	15000	TLS/グリーティングのタイムアウト
`MAIL_IMAP_SOCKET_TIMEOUT_MS`	300000	ソケット I/O のタイムアウト
`MAIL_IMAP_MAX_MAILBOXES`	200	`imap_list_mailboxes` が返すメールボックスの最大数（1～10000）。レスポンスには `total` と `truncated` が含まれます
`MAIL_IMAP_SEARCH_CONCURRENCY`	4	`imap_search_all_mailboxes` 用の IMAP 並列接続数（1～8）
`MAIL_OAUTH2_TOKEN_STORE`	(未設定)	ローテーションされた OAuth2 リフレッシュトークンを保存し、再起動後も保持するためのファイル（OAuth2 トークンストアを参照）
`MAIL_MCP_TRANSPORT`	stdio	MCP ストリーム可能 HTTP を提供する場合は `stdio` または `http`（リモート HTTP トランスポートを参照）
`MAIL_MCP_HTTP_HOST`	127.0.0.1	HTTP バインドアドレス（IP リテラル）
`MAIL_MCP_HTTP_PORT`	8000	HTTP バインドポート
`MAIL_MCP_HTTP_PATH`	/mcp	HTTP エンドポイントパス

## ロードマップ

次の予定 — 即時検索に対応するローカルキャッシュ

SQLite + FTS5 のローカルメールキャッシュ — 即時検索（3〜10 秒から 10 ミリ秒未満へ）
増分同期 — UIDVALIDITY + 最終 UID による差分同期
コネクションプーリング — アカウントごとの永続的な IMAP セッション
アカウント横断検索 — すべてのアカウントを一度に検索
メール統計 — 件数、上位の送信者、日付別のアクティビティ

今後の予定

ドキュメント

ガイド	説明
アカウントのセットアップ	プロバイダーごとの手順、OAuth2、アプリパスワード、Azure Client ID
ツールの仕様	ツール定義とスキーマの完全な一覧
メッセージ ID の形式	安定したメッセージ識別子の形式
カーソルページネーション	ページネーションの動作と有効期限
セキュリティ	セキュリティ機能とベストプラクティス
高度な設定	タイムアウトとパフォーマンスの調整

開発

cargo test              # 64 unit + integration tests
cargo fmt -- --check    # formatting
cargo clippy --all-targets -- -D warnings  # linting

コントリビューター向けのガイドラインは AGENTS.md を参照してください。

リリース

リリースは cargo-dist によって自動化されています。新しいバージョンをリリースするには：

Cargo.toml の version = "X.Y.Z" を更新します（リリースワークフローでは、この値がプッシュされたタグと一致することが検証されます）。
更新とリリースノートを main にコミットします。

タグを付けてプッシュします：

git tag vX.Y.Z
git push origin main --tags

.github/workflows/release.yml の push: tags: ['v*'] トリガーにより、Linux／macOS（Intel と Apple Silicon）／Windows 用のバイナリがコンパイルされ、インストーラースクリプト（.sh、.ps1）が生成され、GitHub Release が作成され、SHA256 チェックサムとともにすべての成果物が添付されます。
失敗した場合は、Actions タブからワークフローを手動で再実行できます（workflow_dispatch トリガーは緊急時の手段として残されています）。

npm への公開は意図的に無効化されています。 上流のフォークでは、所有していないスコープである @bradsjm/mail-imap-mcp-rs として公開するよう設定されていたため、npm publish を実行するたびに 404 エラーが発生していました。npm tarball は引き続き生成され、各 GitHub Release に添付されるため、ユーザーは npm install ./mail-mcp-npm-package.tar.gz で手動インストールできます。このフォークで npm レジストリへの公開を有効にするには、npm の組織（例：@tecnologicachile）を作成し、npmjs.com でこのリポジトリを指定して Trusted Publishing を設定し、dist-workspace.toml に publish-jobs = ["npm"] を設定してから、dist generate --allow-dirty を実行して release.yml に publish-npm ジョブを復元します。

コントリビューション

コントリビューションを歓迎します！最初の取り組みに適した課題は、issues をご確認ください。

mail-mcp が役に立った場合は、リポジトリに ⭐ を付けていただくと、ほかの人にも見つけてもらいやすくなります。

ライセンス

MIT License — 詳細は LICENSE をご覧ください。

Markdown 対応

ログインしてコメント

MCP は初めてですか？

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

入門ガイドを読む

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。

mail-mcp

mail-mcp について

主な機能

活用シーン

MCP 対応

設定

ツール

詳細

mail-mcp

v0.6.1 の新機能

v0.6.0 の新機能

v0.5.0 の新機能

v0.4.17 の新機能

v0.4.16 の新機能

v0.4.15 の新機能

v0.4.14 の新機能

v0.4.13 の新機能

v0.4.12 の新機能

v0.4.11 の新機能

v0.4.10 の新機能

v0.4.9 の新機能

v0.4.8 の新機能

v0.4.7 の新機能

v0.4.6 の新機能

v0.4.5 の新機能

これらのルールを適用するための重要事項

v0.4.4 の新機能

v0.4.3 の新機能

v0.4.2 の新機能

v0.4.1 の新機能

このプロジェクトを選ぶ理由

機能マトリックス

クイックスタート — Claude Code に任せる

手動セットアップ（2 分）

Microsoft アカウントをお使いですか？Graph API を使用してください

37 個の MCP ツール

読み取り（10 個のツール）

書き込み（11 個のツール）

送信（5 個のツール）

EWS — Exchange Web Services（3 個のツール）

下書き（5 個のツール）

添付ファイル

一括操作（2 個のツール）

セットアップヘルパー（1 個のツール）

複数アカウント

セキュリティ

設定リファレンス

IMAP（アカウントごと）

SMTP（アカウントごと）

OAuth2（アカウントごと）

Graph API OAuth2（アカウントごと）

EWS — Exchange Web Services（アカウントごと、Microsoft で最も簡単な方法）

グローバル設定

次の予定 — 即時検索に対応するローカルキャッシュ

今後の予定

ドキュメント

開発

リリース

コントリビューション

ライセンス

コメント

MCP は初めてですか？

MCP（Model Context Protocol）とは？

MCP サーバーとクライアントの違いは？

ローカルとリモート、どちらを選ぶべき？

Claude や Cursor にサーバーを導入するには？

掲載プロジェクトは審査されていますか？「認証済み」とは？

自分のプロジェクトが掲載されています。どう申請できますか？