必要な値は1つだけ
ダッシュボードで作成したAPIキーを入れたAuthorization Bearerヘッダーを付けて、https://mcpemails.com/api/mcpにJSON-RPC 2.0をPOSTします。対応メソッドはinitialize、tools/list、tools/call、prompts/list、prompts/getです。
| 項目 | 値 |
|---|---|
| MCPサーバーURL | https://mcpemails.com/api/mcp |
| トランスポート | Streamable HTTP (MCP 2025-06-18) |
| 認証 | Authorization: Bearer。ダッシュボードで発行した、権限を絞ったAPIキーを使います。 |
スクリプトやHTTPクライアントの接続方法：スコープ付きAPIキー
スクリプトやHTTPクライアントはリモートMCPサーバーに対してOAuthのブラウザーフローを実行しないため、代わりにBearerトークンで認証します。ダッシュボードでAPIキーを作成し、エージェントに必要なスコープだけを選んで、スクリプトやHTTPクライアントからAuthorization: Bearerヘッダーとして送ります。キーによる接続とOAuthによる接続は同じエンドポイントにつながり、使えるツールも同じです。違うのはトークンの取得方法だけです。
curl and the raw APIを受信トレイに接続する方法
手順は4つです。最初の2つはどのクライアントでも同じで、残りはこのクライアント固有の手順です。
無料アカウントを作成してメールボックスを接続
mcpemails.comで新規登録し（カード登録は不要）、ダッシュボードの「受信トレイ」でメールボックスを接続します。受信トレイ1つはずっと無料です。
スコープ付きAPIキーを作成
ダッシュボードの「APIキー」でCreate key（キーを作成）をクリックします。名前を付け、このエージェントに必要なスコープだけを選びます：read:email、search:email、send:email、manage:folders、delete:email、manage:drafts、manage:contacts、schedule:email、manage:automations。キーはmcpe_に続く16進数64文字の形式で、表示されるのは一度だけです。ダイアログを閉じる前にコピーしてください。
エンドポイントを呼び出す
Authorizationヘッダーにキーを付けて、https://mcpemails.com/api/mcpにJSON-RPC 2.0のボディをPOSTします。まずtools/listでツールの一覧を確認し、次にinbox_listでメールボックスのIDを取得します。
レスポンスを処理する
結果はJSON-RPC 2.0で返ります。成功した結果には型付きのstructuredContentオブジェクトも含まれるので、スクリプトで文章を解析する必要はありません。
curl -X POST https://mcpemails.com/api/mcp \
-H "Authorization: Bearer mcpe_YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'どのメールボックスから接続するか迷っていますか。 プロバイダー互換性の一覧を見る
curlでつまずきやすいポイント
キーはクエリ文字列ではなくヘッダーで送る
?key=や?api_key=でのキー指定は、ヘッダー対応以前からある連携のために今も受け付けていますが、新しく作るものでは使わないでください。URLに含めた認証情報は、ブラウザーの履歴、プロキシのログ、Refererヘッダー、監視システムなど、管理できない場所に残ります。サポートしている方法はAuthorizationヘッダーです。
送信系の呼び出しは冪等キーを受け付ける。キーなしの再試行は現実的なリスク
送信、返信、転送、下書きの送信、予約送信は、任意の冪等キーを受け付け、24時間有効です。送信中のネットワークタイムアウトは本質的にあいまいで、メールはすでに送られているかもしれません。冪等キーがあれば再試行は安全です。なければ、再試行は2通目のメールになります。
長い処理は本当に長い
大きなメールボックス全体での検索と移動は、本番環境で約152秒かかった例があり、プロキシは自ら打ち切るまで最大270秒待ちます。クライアントのタイムアウトは、よくある数秒ではなくこれを踏まえた値にしてください。そうしないと、もう少しで成功する処理をキャンセルしてしまいます。
プッシュはどちらの方向にもない
Webhookも、サーバー発のイベントも、登録するコールバックURLもありません。新着メールに反応するにはポーリングが必要です。たとえばemail_readをaction: "list"と未読のみの指定で、ワークフローに合った間隔で呼び出します。レート制限はキーごとに、プランに応じた1分、1時間、1日単位で適用されます。
知っておきたい制限
- リクエストにはキーごとに、プランに応じた1分、1時間、1日単位のレート制限があります。429レスポンスにはRetry-Afterが付きます。
- サーバーはリクエストとレスポンスだけで動作します。Webhookもサーバー発のイベントもないため、新着メールがエージェントを自動で起動することはありません。届いたメールに反応するには、定期的にポーリングしてください。
- メールは呼び出しのたびにプロバイダーからその場で取得され、保存されることはありません。保存するのは暗号化したOAuthトークンまたはアプリ パスワードだけなので、トークンを取り消すかメールボックスのパスワードを変更すれば、アクセスはすぐに終わります。
curl and the raw APIとメールに関するよくある質問
MCPクライアントなしで使えますか？
はい。JSON-RPC 2.0で通信する通常のHTTPSエンドポイントなので、curl、cronジョブ、バックエンドサービス、任意のHTTPライブラリから呼び出せます。認証にはダッシュボードの「APIキー」で作成したBearerキーを使います。ツールの一覧はMCPクライアントから見えるものとまったく同じです。
対応しているJSON-RPCメソッドは？
initialize、tools/list、tools/call、prompts/list、prompts/getです。成功した結果には、人が読むためのcontentに加えて型付きのstructuredContentオブジェクトが含まれ、スクリプトではこちらを読みます。
再試行を安全にするには？
送信系の操作に冪等キーを渡します。送信、返信、転送、下書きの送信、予約送信はこれを受け付けて24時間有効にするので、タイムアウト後に同じリクエストを再試行しても2通目のメールは送られません。読み取りはもともと安全に再試行できます。
レート制限は？
キーごとに、プランに応じた1分、1時間、1日単位の制限があります。1つのキーでプランの1分あたりの上限をすべて使え、複数のキーはその上限を共有します。成功したtools/callのレスポンスにはRateLimit-Limit、RateLimit-Remaining、RateLimit-Resetが付きます。
メールはサーバーに保存されますか？
いいえ。メッセージはすべて、それを求めたリクエストのためにプロバイダーからその場で取得され、そのままクライアントに渡されます。保存するのは、以降の呼び出しで認証するための暗号化したOAuthトークンまたはアプリ パスワードだけです。ダッシュボードで受信トレイを削除するか、プロバイダー側でアクセスを取り消せば、接続はすぐに切れます。