カスタム SSE MCP サーバ（リモート HTTP エンドポイント）

stdio と SSE：HTTP が必要なとき

stdio はサーバがローカル機にいるときに最適です。Docker 内、リモートホスト、社内マイクロサービスとして動かすときは、MCP は HTTP + Server-Sent Events（SSE）でレスポンスストリームをサポートします。

Cursor（ネイティブ SSE 対応）

Cursor は url フィールドを直接読みます：

{
  "mcpServers": {
    "remote-tools": {
      "url": "https://mcp.internal.example.com/sse",
      "headers": {
        "Authorization": "Bearer your-token-here"
      }
    }
  }
}

Claude Desktop（mcp-remote ブリッジ経由）

Claude Desktop は現状 stdio サーバを期待するので、公式 mcp-remote ブリッジでリモートエンドポイントをラップします：

{
  "mcpServers": {
    "remote-tools": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.internal.example.com/sse",
        "--header",
        "Authorization: Bearer your-token-here"
      ]
    }
  }
}

ブリッジはローカルで stdio サーバとして動き、JSON-RPC フレームをリモート SSE エンドポイントへプロキシします。

なぜレスポンスに SSE を使うのか

MCP のレスポンスは大きくなりえます（ツール結果、リソース一覧）。SSE は生成と同時にバイトをストリーム配信するため、モデルは全体を待たずに先頭から処理を始められます。リクエスト側は通常の HTTP POST + JSON ボディです。

SSE が向かないケース

• シングルユーザー・シングルマシン構成 — stdio がよりシンプルで高速。
• サーバがローカルファイルや HTTP 越しに届かない Unix ソケットに依存する場合。
• レイテンシが集中化より重要なとき — SSE の往復は最低でも 1 回の TCP 往復を含みます。

認証パターン

ヘッダ Bearer トークンが最もシンプルです。マルチテナント構成では OAuth とリフレッシュトークン — OAuth2 フロービジュアライザ で標準的な交換手順を確認できます。