Mcp2http

🚀 MCP2HTTP

MCP2HTTP是一個最小化的傳輸適配器，它能讓使用標準輸入輸出（stdio）的MCP客戶端與無狀態的HTTP MCP服務器建立連接，為MCP協議的應用拓展了新的可能性。

🚀 快速開始

MCP2HTTP可使模型上下文協議客戶端，通過stdio傳輸與使用HTTP通信的MCP服務器建立連接。即便MCP通常採用stdio（用於本地進程）或Server-Sent Events（SSE）傳輸，此適配器也能將其橋接到常規的HTTP端點，實現新的集成。該適配器僅處理基本的傳輸層轉換，並通過客戶端生成的唯一標識符Session-Id頭提供可選的狀態跟蹤，保留協議語義，讓客戶端和服務器直接交互，無需使用SSE，能與無服務器平臺和遺留系統無縫協作。

✨ 主要特性

客戶端生成的會話跟蹤

• 適配器會自動生成唯一標識符（UUID），並將其作為Session-Id頭包含在每個請求中。這種客戶端生成會話ID的方式類似於1996年提出的Session-Id提案（未正式納入HTTP標準），簡單實用，旨在補充（而非替代）適當的身份驗證。
• 128位十六進制UUID格式具備抗碰撞能力，利用了普遍的標識符標準，非常適合在無狀態的HTTP環境中關聯請求。為防止碎片化並確保行為一致，符合此設計的服務器實現應拒絕非128位十六進制Session-Id值（帶或不帶破折號）。若不需要會話跟蹤，服務器可完全忽略Session-Id頭。該功能可選，方便那些僅需請求間相關性而不想增加額外複雜性的實現。

能力過濾

• 適配器會從initialize響應中記錄服務器的功能，並阻止對未聲明能力的請求。這解決了某些MCP客戶端每分鐘多次重複輪詢未廣告能力的問題。通過在請求到達服務器之前進行篩選，當服務器僅支持特定功能（如tools），而客戶端仍持續靜默輪詢時，可減少不必要的負載。

通知處理

• 無ID的消息（通知）會被默默地丟棄。這種處理方式與HTTP的請求/響應架構自然契合。在MCP通過無狀態HTTP實現時，丟棄通知是合理選擇，這也是像mcp-golang HTTP傳輸等其他實現得出的結論。儘管notifications/initialized可能會引人關注，但處理通知的一致性帶來的實際好處更為重要。不過，HTTP MCP服務器仍可選擇優雅地處理通知，以防其他實現確實轉發它們。

💻 使用示例

基礎用法

配置您的MCP客戶端以以下格式調用此命令：

npx -y mcp2http <endpoint-url> ["Header: Value"...]

例如，在Claude Desktop配置文件（claude_desktop_config.json）中：

{
  "mcpServers": {
    "my-mcp-server": {
      "command": "npx",
      "args": [
        "-y",
        "mcp2http",
        "http://localhost:3000/mcp"
      ]
    }
  }
}

高級用法

您還可以添加任意數量的HTTP頭作為參數。例如，要包含一個身份驗證令牌：

{
  "mcpServers": {
    "my-mcp-server": {
      "command": "npx",
      "args": [
        "-y",
        "mcp2http",
        "https://example.com/mcp",
        "Authorization: Bearer token123"
      ]
    }
  }
}

⚠️ 重要提示

您需要一個功能正常的MCP HTTP端點。很快將提供一個示例服務器。

📄 許可證

本項目採用MIT許可證。