サーバーは1つ、クライアントは7つ
このサーバーは、Streamable HTTP経由でModel Context Protocolを話す、単一のHTTPSエンドポイントです。JSON-RPCを乗せたPOSTが1回、JSONの返答が1回、開いたままのストリームはありません。インストールするものも、ローカルで動かすものもなく、公開ドメインではサインアップするものもありません — 設定のすべてはこのURLです。
MCPエンドポイントhttps://grabmail.io/mcp
どのMCPクライアントもリモートHTTPサーバーに対応していますが、それぞれ設定を別々のファイルに、少しずつ違うキー名で保持しています。以下の各セクションで、それぞれの正確な設定内容を示します。これらの形式は2026年9月時点のものです。それ以降に変更されている場合は、各クライアント自身のドキュメントが正となります。
シェルから、応答を確認する
どのクライアントにも触れる前に、サーバーが実在し、何を提供しているかを確認しましょう。トランスポートがごく普通のHTTPであるため、curl1回で十分です。
$ curl -s -X POST https://grabmail.io/mcp -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | jq '.result.tools[].name'"create_inbox"
"list_domains"
"list_messages"
"read_message"
"wait_for_message"
"delete_message"これがうまくいけば、以下のどのクライアントも動くはずであり、それでもクライアントが失敗する場合は、サーバー側の問題ではなくクライアント側の設定の問題です。うまくいかない場合は、ネットワークがgrabmail.ioへのアウトバウンドHTTPSを許可しているか確認してください — それがネットワーク上必要なもののすべてです。
Claude Code
コマンド1つ、どのディレクトリからでも実行できます。これはユーザー単位でサーバーを登録するため、すべてのプロジェクトで使えるようになります。
$ claude mcp add --transport http grabmail https://grabmail.io/mcp代わりにリポジトリ経由でチームと共有したい場合は、プロジェクトスコープにしてください。これによりルートに.mcp.jsonが書き込まれ、これはコミットされ、チームメンバーは承認を求められます。
$ claude mcp add --transport http --scope project grabmail https://grabmail.io/mcp{
"mcpServers": {
"grabmail": {
"type": "http",
"url": "https://grabmail.io/mcp"
}
}
}Claude Codeを再起動して/mcpを実行すると、grabmailが6つのツールとともに一覧に表示されます。このサーバーは、プロトコルのinitialize呼び出しに対して短い指示の一節でも応答し、それはClaude Codeによってモデルに渡されます — そのためエージェントは、エイリアスを渡してアドレスを待つべきことを、最初から知った状態で登場します。
Claude Desktop
リモートサーバーは、設定ファイルではなく、アプリケーションを通じて追加します。
- 設定 → コネクタ → カスタムコネクタを追加。
https://grabmail.io/mcpを貼り付けてURLとし、名前を付けます。- 新しい会話を開始すると、コネクタの下にツールが表示されます。
claude_desktop_config.jsonでローカルサーバーしか扱えないバージョンでは、mcp-remoteでリモートエンドポイントをブリッジしてください。これはローカルプロセスとして動作し、そのURLへ転送します。
{
"mcpServers": {
"grabmail": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://grabmail.io/mcp"]
}
}
}Cursor
Cursorは、プロジェクト内の.cursor/mcp.json(またはすべてのプロジェクト共通の~/.cursor/mcp.json)を読み込みます。リモートサーバーはurlとして指定します。
{
"mcpServers": {
"grabmail": {
"url": "https://grabmail.io/mcp"
}
}
}Cursorの設定 → MCPを開くと一覧表示され、そこでツールを有効化できます。エージェントモードでは、モデルが自分でそれらを呼び出します。チャットでは、名前を指定して呼んでもらうこともできます。
Windsurf
Windsurfは、サーバー設定を~/.codeium/windsurf/mcp_config.jsonに保持しており、リモートサーバーのキーはurlではなくserverUrlです — 形が異なる唯一の箇所です。
{
"mcpServers": {
"grabmail": {
"serverUrl": "https://grabmail.io/mcp"
}
}
}CascadeはMCPパネルからのリフレッシュ後にサーバーを一覧表示します。同じファイルは、Windsurfの設定 → Cascade → MCPサーバー → View raw configからも開けます。
VS Code
VS Codeのエージェントモードは、ワークスペース内の.vscode/mcp.json、またはコマンドパレットのMCP: Add Serverが書き込むユーザーレベルのファイルを読み込みます。サーバーはmcpServersではなくserversの下に置かれ、リモートサーバーはトランスポートを宣言します。
{
"servers": {
"grabmail": {
"type": "http",
"url": "https://grabmail.io/mcp"
}
}
}エディタ内のエントリの上に、小さな「Start」リンクが表示されます。それをクリックすると、チャットのツールピッカーにツールが表示され、エージェントモードは、こちらから頼まなくてもそれらを呼び出します。
Codex CLIとGemini CLI
Codex CLIは、設定を~/.codex/config.tomlにTOML形式で保持しています。リモートサーバーは、urlを持つテーブルとして指定します。
[mcp_servers.grabmail]
url = "https://grabmail.io/mcp"Gemini CLIは~/.gemini/settings.json(またはプロジェクト内の.gemini/settings.json)を読み込み、Streamable HTTPサーバーのキーはhttpUrlです。
{
"mcpServers": {
"grabmail": {
"httpUrl": "https://grabmail.io/mcp"
}
}
}どちらも、ローカルサーバーしか扱えないバージョンであれば、Claude Desktopで示したのと同じmcp-remoteブリッジ経由でこのエンドポイントに到達できます。command = "npx"、args = ["-y", "mcp-remote", "https://grabmail.io/mcp"]。
6つのツール
クライアントが何であれ、モデルには同じ名前の同じ6つのツールが見えます。呼び出しの間で管理すべき状態はなく、どのツールも、前の呼び出しが返さなかった引数を必要とすることはありません。
create_inbox- 新しいアドレスをその場で作り、エイリアスと、どちらをどこで使うかを示す
next_stepとともに返します。サーバー側で何も予約されないため、失敗することはありません。任意で、読みやすいprefixを指定できます。 wait_for_message- そのアドレスにメッセージが届くまで、最大25秒ブロックし、それから全体を返します — 件名、送信者、プレーンテキスト、HTML。
subject_containsやfrom_containsでフィルタでき、since_idを渡せば、すでにあったものは無視されます。何も届かないまま待機が終わるとtimed_outを返し、もう一度呼び出すよう促します。 read_message- idを指定して、1通のメッセージ全体を取得します。待機の時点ですでにメッセージ全体が返っているため、必要になることはほとんどありません。
list_messages- あるアドレスで待っているものすべてを、新しい順に、即座に返します — 何もない場合も含めて。
list_domains- 誰でも使える公開ドメインの一覧です。フォームがそのうちの1つを拒否したときのためのものです。
delete_message- 5日後を待たずに、今すぐメッセージを削除します。冪等であるため、リトライするエージェントにもコストはかかりません。
4つの呼び出しでできるサインアップのループ
これは、ほとんどのタスクが必要とする手順であり、クライアントが変わってもこれは変わりません。
create_inbox。アドレス、エイリアス、そしてどちらがどちらかを示すメモが返ってきます。- フォームにはエイリアスを入力します。サイトは、メールボックスに届きはするものの、それを開くことはできない、機能するアドレスを手にすることになります。
- 送信直後に、そのアドレスに対して
wait_for_messageを呼びます。subject_containsには、確認メールに含まれるはずの単語を設定します。これはブロックするため、エージェント側でループする必要はありません。 - コードは、待機が返したメッセージの中にあります。たいていの場合、それ以上の呼び出しは一切必要ありません。
Sign up for a trial at https://app.example.com/signup with a fresh GrabMail inbox.
Use the ALIAS in the form, wait for the confirmation code with wait_for_message
on the ADDRESS, enter it, and tell me the resulting login.エージェント自身の指示に何を書くか
サーバーは、接続時にモデルへ使い方を伝えますが、同じ4つのルールを自分自身のプロジェクト指示の中でも読んだモデルは、たいてい正しく守るのではなく、毎回正しく守るようになります。使っているクライアントが読み込むCLAUDE.md、.cursor/rules、.windsurfrules、AGENTS.md、GEMINI.mdのいずれかに、これを追加してください。
## Email
- To receive email, use the `grabmail` MCP server. Call `create_inbox` once per task.
- Put the **alias** it returns into forms; poll the **address** it returns with `wait_for_message`.
- Call `wait_for_message` right after submitting a form, with `subject_contains` set to a word
you expect ("code", "verify", "confirm"). If it returns `timed_out`, call it again — up to
three times — before concluding the mail was not sent.
- Never reuse an inbox across tasks. Never send anything confidential to one: it is public.最も重要な2つのルールは、教えられなければエージェントが間違えるものです。フォームにはエイリアスを入力しアドレスをポーリングすること、そしてtimed_outを「メールが送信されなかった」ではなく「もう一度呼び出す」と捉えることです。AIエージェントが読める受信箱では、この2つを、待機がメールより先に返る理由も含めて詳しく扱っています。
うまくいかないとき
| 症状 | 原因 | 対処法 |
|---|---|---|
| サーバーが一覧に表示されない | 設定ファイルが間違った場所にあるか、間違ったキー(url / serverUrl / httpUrl / servers)を使っているか、クライアントを再起動していません。 | 自分のクライアント向けのブロックを正確にコピーし、再起動してください。そして上のcurlを実行して、サーバー側の問題ではないことを確認してください。 |
| ツールは一覧に表示されるが、モデルが一切呼び出さない | クライアントのMCPパネルでツールが無効になっているか、メールのステップが存在することがモデルに伝わっていません。 | ツールを有効化し、上の指示の一節を追加してください。 |
wait_for_messageがtimed_outを返し続ける | フォームが送信されていない、エイリアスの入力ミス、サイトがそのドメインを拒否した、あるいはすでに8件の待機が実行中です。 | 最大3回まで再度呼び出してください。フォーム自体のエラーを確認してください。サインアップフォームが使い捨てメールをブロックする理由もお読みください。 |
| サイトがアドレスを無効だと言う | 公開ドメインが使い捨てメールのブロックリストに載っています。 | 独自ドメイン(MXレコード1件)か、リストに載らないドメインプールを使ってください。 |
ブリッジ(mcp-remote)が起動に失敗する | マシンにNodeがないか、npxがレジストリに到達できません。 | Node 18以上をインストールするか、URLを直接受け付けるバージョンのクライアントを使ってください。 |
完了と呼ぶ前に
- 上の
curlを自分のマシンから実行すると、6つのツールが一覧表示される。 - 再起動後、クライアントのMCPパネルにサーバーが表示され、ツールが有効になっている。
- 使っているクライアントが読み込むファイルに、指示の一節が入っている。
- テストプロンプトでサインアップが完了する: フォームにはエイリアス、待機はアドレスに対して、コードが読み取られる。
- これらの受信箱に機密情報が送られることは決してない — これらは公開されている。
セットアップとしては、これがすべてです。同じサーバーは、MCPを話すあらゆるフレームワークから使え、MCPを使わずに構築されたエージェント — LangChainの素のツール関数、OpenAI Agents SDK、あるいは自分自身のループなど — に向けては、AIエージェント向けのメールで、同じ4つのステップのREST版を紹介しています。
質問
MCPサーバーにAPIキーやアカウントは必要ですか?
いいえ。公開ドメインはキーもアカウントもヘッダーも不要で、MCPサーバーが公開しているのは、REST APIが公開しているものとまったく同じです。使い捨てメールのブロックリストに載らない有料ドメインプールだけがベアラートークンを使い、エンドポイントに対してAuthorizationヘッダーとして渡します。
Streamable HTTPですか、それともSSEですか?
Streamable HTTPです。POSTが1回、JSONの返答が1回。開いたままにしておくイベントストリームは存在しません。これが、wait_for_messageが最大25秒に制限されている理由です — SSEを期待してGETを開くクライアントには、ごく普通のJSONで、それが存在しないことが伝えられます。
複数のエージェントが同時にサーバーを共有できますか?
できます。セッション状態というものがなく、それぞれの呼び出しが必要なものをすべて運んでいます。唯一の共有された上限は、全員を合わせて同時に実行できるwait_for_messageの呼び出しが8件までという点です — それを超えると、ツールは即座にtimed_outを返し、もう一度呼び出すよう求めます。これは、上の指示の一節が対処しています。
wait_for_messageは、なぜメールが届く前に返るのですか?
何分もスリープするサーバーのワーカーは、他の誰も使えないワーカーになってしまうからです。待機は最大25秒に制限されており、失敗するのではなく、正直にtimed_outと答えます。エージェントはもう一度呼び出します。3回の呼び出しで合計1分以上の待機になり、実際に送信されたトランザクションメールであれば、それでカバーできます。
エージェントはメールを送信することもできますか?
できません。このサービスは、設計上、受信専用です。送信もできてしまうアカウント不要の無料サーバーは、1時間でスパムの中継地点になってしまうでしょう。メールを送信する必要があるエージェントには、送信用のプロバイダが必要です。こちらは、返ってきたものを読むためのものです。
受信箱は自分のエージェント専用のプライベートなものですか?
いいえ。公開ドメインでも独自ドメインでも、アドレスを知っている人なら誰でも読めます。だからこそエイリアスが存在します。サイトが手にするのは、メールボックスに届きはするものの、それを開くことはできないアドレスです。これらの受信箱に機密情報を送らせることは、エージェントに対して決してしないでください。
これらが変わった場合、どのクライアント設定を基準にすればよいですか?
それぞれのクライアント自身のドキュメントです。上記の形式は2026年9月時点のものです。サーバー側はそれらの変化とは無関係です — URLは1つのままであり、HTTP経由でリモートMCPサーバーを呼び出せるクライアントであれば、どれでも呼び出せます。


