MCP服务器自动发现工具

MCP Discovery Hub是一个基于DLNA/UPnP原理的零配置网络工具,用于自动发现和管理本地网络中的MCP服务器,支持多协议执行和LLM集成。

  • by kunwarmahen
  • Python
  • 本地部署
  • 更新于
在 GitHub 查看 kunwarmahen/mcp-discovery-hub-mcast

使用说明

MCP探索中心

在网络中自动发现和管理模型上下文协议(MCP)服务器。

受DLNA(数字生活网络联盟)和UPnP(通用即插即用)的启发,MCP发现中心为AI工具发现带来了零配置网络功能。就像您的电视能自动找到Chromecast设备,您的手机能发现AirPlay音箱一样,MCP发现中心也能自动在您的局域网中找到并连接到MCP服务器。

哲学

为什么选择DLNA/UPnP?因为它们有效。你的设备几十年来一直在无需配置的情况下相互发现。我们将同样的经过实战检验的原则应用于人工智能:

问题 DLNA/UPnP 解决方案 MCP 发现中心
发现 设备广播“我在这里!” 服务器通过多播UDP广播
配置 零配置,即开即用™ 零配置,即开即用™
服务描述 XML 描述符 JSON 工具模式
控制 SOAP/HTTP 协议 REST/WebSocket + JSON-RPC
多设备 无缝集成 多服务器编排

无需手动配置每个MCP服务器,只需启动它们,中心节点就会自动发现所有内容。

问题

您的网络中运行着多台MCP服务器,但是:

  • 😫 没有简单的方法来发现它们
  • 🔌 每个服务器都需要手动配置
  • 🤝 没有统一的界面来与多个服务器进行交互
  • 🚀 在不同的大型语言模型(LLM)提供商之间切换意味着需要重新配置一切

解决方案

Scan Network → Discover Tools → Chat with Any LLM
(Just like DLNA discovers your smart TV)

核心功能:

  • 自动发现MCP服务器 在您的网络上(UPnP风格的发现)
  • 浏览工具 在一个界面上查看所有已发现的服务器
  • 选择工具 你想使用(拖放式)
  • 与你的大型语言模型聊天 无缝使用选定的工具
  • **支持多语言模型(Multi-LLM)**Ollama、OpenAI、Claude、Gemini、vLLM等
  • 漂亮的用户界面 具备实时发现和流式响应功能
  • 零配置 - 只需启动服务器,它们就会出现

它是如何工作的

发现过程

DLNA/UPnP 发现:

  1. 设备广播:“我在这里!我是一个媒体服务器!”
  2. 控制点监听并记录设备信息
  3. 用户从列表中选择设备
  4. 控制点连接并使用设备服务

MCP发现中心流程:

  1. 集线器监听多播公告:“谁是MCP服务器?”
  2. 服务器广播:“我在这里!这是我的工具。”
  3. 工具会实时出现在您的界面上
  4. 用户选择工具并与大型语言模型(LLM)聊天

建筑学

MCP Servers (any type)
├── Traditional (JSON-RPC)
├── FastMCP HTTP (JSON-RPC)
└── FastMCP Streamable (Simplified)
        ↓
   Multicast UDP 239.255.255.250:5353
   (Like SSDP in UPnP)
        ↓
┌─────────────────────────────────────┐
│   Discovery Hub (port 8000)         │
│   (Like UPnP Control Point)         │
├─────────────────────────────────────┤
│ • Network Listening & Probing       │
│ • Tool Catalog Management           │
│ • Multi-protocol Execution          │
│ • LLM Integration (multi-provider)  │
└─────────────────────────────────────┘
        ↓
   WebSocket & REST API
        ↓
┌──────────────┬──────────────┬──────────┐
│  Web UI      │  CLI Tools   │ LLM Apps │
│  (Like DLNA  │              │          │
│   Control    │              │          │
│   Point App) │              │          │
└──────────────┴──────────────┴──────────┘

序列图

Client         Discovery Hub    MCP Server
│              │                │
├─ Scan ─────>│                │
│              │                │
│              ├─ Listen for broadcasts or probe
│              ├──────────────────────────>│
│              │                │
│              │<─ Service Description ──│
│              │ (Tools, capabilities)   │
│              │                │
│<─ Server Found─┤                │
│  (Real-time)   │                │
│                │                │
├─ Chat + Tools─>│                │
│                ├─ Execute Tool──>│
│                │                │
│                │<─ Tool Result ─┤
│<─ LLM Response-┤                │
│  (Streaming)   │                │

支持的服务器类型

该集线器智能地处理三种不同的MCP(管理控制协议)实现方式:

协议 格式 会话 发现 最适合用于
传统MCP(多通道处理器/模块等,具体含义根据上下文确定) JSON-RPC 2.0 基于会话 HTTP探测 带状态的生产环境部署
FastMCP HTTP JSON-RPC 2.0 基于会话 组播 + HTTP 容器化部署
FastMCP 可流式传输 简化版 无状态 组播 + HTTP 轻量级操作

快速入门

1. 安装并运行Discovery Hub

git clone https://github.com/kunwarmahen/mcp-discovery-hub-mcast.git
cd mcp-discovery-hub-mcast

# Backend setup
cd backend
python -m venv venv
source venv/bin/activate  # On Windows: venv\Scripts\activate
pip install -r requirements.txt
python mcp_discovery.py

集线器将在8000端口启动,并自动监听多播地址上的服务器公告。

2. 启动MCP服务器

服务器通过多播自动宣告自己的存在。启动任意MCP服务器:

传统MCP服务器

python sample_mcp_server.py

FastMCP HTTP模式

MCP_TRANSPORT=http MCP_PORT=3001 uv run main.py

FastMCP 可流式传输-HTTP 模式

MCP_TRANSPORT=streamable-http MCP_PORT=3001 uv run main.py

更多示例多播服务器

多播数据库MCP服务器

通过模型上下文协议查询和管理数据库。

db-mcp-server 翻译成中文是“数据库-MCP服务器”

多播 Podman MCP 服务器

通过模型上下文协议实现的容器管理。

Podman MCP 服务器

多播SSH MCP服务器

一个安全的模型上下文协议(MCP)服务器,支持远程SSH命令执行

ssh-mcp-server 翻译成中文是“SSH MCP 服务器”

服务器在上线时会自动被发现。

3. 设置前端(可选 - 用于美观的用户界面)

# In a new terminal
cd frontend
npm install
npm run dev

开放 http://localhost:5173 实时查看服务器出现的情况。

4. 通过API查询

# Get all discovered servers
curl http://localhost:8000/servers

# List all available tools
curl http://localhost:8000/servers | jq '.[] | .tools'

# Execute a tool
curl -X POST http://localhost:8000/execute-tool \
  -H "Content-Type: application/json" \
  -d '{
    "server_id": "192.168.1.1:3001",
    "tool_name": "list_containers",
    "arguments": {"all": true}
  }'

配置

集线器配置

# Environment variables for discovery hub
MCP_ENABLE_PASSIVE_DISCOVERY=true      # Listen for multicast broadcasts
DEBUG_LOGGING=false                     # Enable debug output
NETWORK_SCAN_PORTS=[3000,3001,3002]    # Fallback ports for manual scanning
WEBSOCKET_HEARTBEAT_INTERVAL=30        # Heartbeat interval in seconds

服务器配置

所有服务器

MCP_TRANSPORT=http                  # Transport mode
MCP_PORT=3001                       # Server port
MCP_SERVER_NAME="My Server"         # Display name in hub

广播服务器(多播发现)

MCP_ENABLE_BROADCAST=true           # Enable multicast announcements
MCP_BROADCAST_INTERVAL=30           # Broadcast every N seconds (like UPnP SSDP)
MCP_MULTICAST_ADDRESS=239.255.255.250  # Multicast group
MCP_MULTICAST_PORT=5353             # Multicast port (like UPnP)

API 参考文档

GET /servers

列出所有已发现的服务器及其工具。

回答:

[
  {
    "id": "192.168.1.1:3001",
    "name": "Podman MCP Server",
    "host": "192.168.1.1",
    "port": 3001,
    "endpoint": "/mcp",
    "status": "online",
    "protocol_type": "MCP-HTTP",
    "tools": [
      {
        "name": "list_containers",
        "description": "List containers",
        "inputSchema": {...}
      }
    ]
  }
]

POST /执行工具

在特定服务器上执行一个工具。

请求:

{
  "server_id": "192.168.1.1:3001",
  "tool_name": "list_containers",
  "arguments": { "all": false }
}

POST /扫描网络

手动扫描网络以查找服务器(如多播不可用时作为备用方案)。

请求:

{
  "ports": [3000, 3001, 3002, 8080, 9000]
}

POST /聊天

使用选定的工具向配置好的大型语言模型(LLM)发送聊天消息。

请求:

{
  "message": "List my files and create a summary",
  "selected_tools": [
    { "server_id": "192.168.1.1:3001", "tool_name": "read_file" },
    { "server_id": "192.168.1.1:3001", "tool_name": "list_directory" }
  ]
}

WS /ws

用于服务器发现和状态更新的实时WebSocket连接。

消息类型:

  • server_discovered - 发现新服务器
  • server_offline - 服务器已离线
  • chat_chunk - 实时聊天回复
  • tool_executed - 工具执行结果
  • error - 错误信息

发现协议详情

多播广播(类似于UPnP SSDP)

服务器在多播地址上广播UDP数据包 239.255.255.250:5353 每30秒:

{
  "type": "mcp-announcement",
  "uuid": "550e8400-e29b-41d4-a716-446655440000",
  "name": "Podman MCP Server",
  "host": "192.168.1.44",
  "port": 3001,
  "endpoint": "/mcp",
  "transport": "http",
  "protocol_type": "MCP-HTTP",
  "tools_count": 5,
  "ttl": 120
}

益处:

  • 无需手动配置
  • 跨网络自动服务器检测
  • 低开销(30秒广播间隔)
  • 在网络中断时仍能保持运行
  • 与网络分段配合工作

HTTP探测(回退机制)

如果多播不可用(某些网络会阻止UDP),集线器可以手动探测可配置的端口范围:

POST /scan-network
{
  "ports": [3000, 3001, 3002, 8080, 9000],
  "timeout": 5000
}

这确保了发现功能在任何环境中都能正常工作。

防火墙配置

该集线器使用多播UDP进行服务器发现(类似于UPnP/SSDP)。如果服务器无法被发现,但在禁用防火墙时可以正常工作,则说明防火墙规则正在阻止通信。

多播基础

  • 地址: 239.255.255.250 (SSDP多播组,与UPnP相同)
  • 港口: 5353 (UDP) 翻译为中文是:用户数据报协议
  • 类型多播(一对多,仅限局域网)
  • 协议IGMP(Internet组管理协议)用于组成员管理

UFW(Ubuntu/Debian)- 最常见问题

在处理Linux防火墙(尤其是UFW)上的多播流量时,这是一个非常常见且令人沮丧的问题。

为何会失败

当你禁用UFW时它能正常工作,但当规则启用时却不能,原因在于UFW的简单规则并不总是能正确处理多播和IGMP(互联网组管理协议)数据包的复杂性。

当防火墙处于活动状态时,它可能会阻止的不仅仅是数据包,还有内核用来加入多播组的IGMP数据包239.255.255.250)。 你的应用程序代码可能正在尝试加入该组,但防火墙阻止了内核接收数据包,即使你已经打开了5353/UDP端口。

解决方案:修改UFW(Uncomplicated Firewall,简单防火墙)的设置 before.rules

为了使UFW(Uncomplicated Firewall,简化防火墙)可靠地支持多播,通常需要将特定规则插入到底层(配置中) iptables UFW使用的配置文件,即 /etc/ufw/before.rules这些规则允许流量到达整个多播地址范围(224.0.0.0/4) 并明确允许IGMP协议。

注编辑此文件时务必小心。

第一步:打开 before.rules 文件

使用像……这样的文本编辑器 nano 或者 vim (与)一起;带有 sudo:

sudo nano /etc/ufw/before.rules

步骤2:添加多播和IGMP规则

在文件中向下滚动,直到找到允许入站流量的部分,通常位于顶部,在写着(某条内容的)那一行之前 # drop invalid packets在(现有内容)上方添加以下规则块 COMMIT 线路,并且理想情况下应接近其他基本协议(如ICMP/ping)被允许的地方:

#
# START MCP DISCOVERY MULTICAST RULES
#
# Allow all incoming UDP traffic to the multicast address range
# for the SSDP/MCP Discovery data packets (239.255.255.250 is in 224.0.0.0/4)
-A ufw-before-input -p udp -d 224.0.0.0/4 -j ACCEPT

# Allow IGMP (Protocol 2) for joining and maintaining multicast groups
# This is often the critical missing piece.
-A ufw-before-input -p igmp -j ACCEPT

# Allow incoming UDP packets specifically on port 5353 (SSDP)
-A ufw-before-input -p udp --dport 5353 -d 239.255.255.250 -j ACCEPT
#
# END MCP DISCOVERY MULTICAST RULES
#

规则解释:

  • -p udp -d 224.0.0.0/4 -j ACCEPT这是一条广泛适用的规则,允许所有传入的UDP多播流量。
  • -p igmp -j ACCEPT这明确允许您的Linux内核所需的IGMP控制流量(协议2)以正确订阅到 239.255.255.250 多播组。 这往往是关键的缺失环节。
  • -p udp --dport 5353 -d 239.255.255.250 -j ACCEPT这是你可能试图通过简单的UFW命令来添加的具体规则,但将其放在 before.rules 带有目的地地址使其更加可靠。

步骤3:保存并重新加载UFW

保存文件并退出编辑器(Ctrl+X,然后 Y,然后 Enter 在 nano)。

现在,重新加载UFW服务以将更改应用到底层配置 iptables 链条:

sudo ufw reload

重新加载后,您的UFW防火墙将处于活动状态,但特殊(规则) before.rules 现在应该正确允许必要的多播控制(IGMP)和数据(UDP 5353)数据包通过,以确保您的MCP发现功能正常工作。

Windows 防火墙

如果使用Windows系统,请允许UDP端口5353用于多播:

# PowerShell (as Administrator)
New-NetFirewallRule -DisplayName "MCP Discovery Multicast" `
  -Direction Inbound `
  -Action Allow `
  -Protocol UDP `
  -LocalPort 5353 `
  -RemoteAddress "239.255.255.250" `
  -Group "MCP Discovery Hub"

macOS 防火墙

macOS 通常默认允许多播。如果出现问题:

# Check if firewall is blocking mDNS/multicast
sudo launchctl list | grep firewall

# Allow multicast if needed (usually not required)
sudo defaults write /Library/Preferences/com.apple.alf globalstate -int 1

Docker/Podman 网络

容器需要为多播进行明确的网络配置:

# Docker - use host network for multicast
docker run --network host -e MCP_ENABLE_BROADCAST=true my-server

# Podman - similar approach
podman run --network host -e MCP_ENABLE_BROADCAST=true my-server

# Or use macvlan for container-specific IPs with multicast
docker network create -d macvlan -o parent=eth0 macvlan-net
docker run --network macvlan-net -e MCP_ENABLE_BROADCAST=true my-server

企业/公司网络

一些企业网络完全阻止多播。解决方案:

  1. 使用备用HTTP探测:

    curl -X POST http://localhost:8000/scan-network \
      -H "Content-Type: application/json" \
      -d '{"ports": [3000, 3001, 3002, 8080, 9000]}'
    
  2. 请求网络团队允许多播范围 224.0.0.0/4 以及IGMP协议

  3. 使用支持多播的VPN 如果从外部网络连接

  4. 在同一子网中部署集线器 作为服务器以降低防火墙复杂性

用例

单一网络部署

192.168.1.0/24
├─ 192.168.1.10: Podman Server (port 3001)
├─ 192.168.1.20: Database Server (port 3002)
├─ 192.168.1.30: File System Server (port 3001)
└─ 192.168.1.40: Discovery Hub (port 8000)
    └─ Auto-discovers all three servers instantly

容器化环境

在Docker/Podman中部署多个MCP服务器并实现自动发现:

docker run -p 3001:3001 \
  -e MCP_TRANSPORT=http \
  -e MCP_PORT=3001 \
  -e MCP_ENABLE_BROADCAST=true \
  podman-mcp-server

多功能工具编排

1. Discover: File System MCP, Database MCP, Web Scraper MCP
2. Select: read_file, query_sql, fetch_url
3. Chat: "Read data.json, query matching records, scrape additional info"
4. LLM orchestrates all tools automatically

大型语言模型(LLM)集成

将来自多个大型语言模型(LLM)提供商的路由工具调用转发到相应的MCP服务器:

response = client.messages.create(
  model="claude-3-sonnet",
  tools=hub.get_all_tools(),
  messages=[...]
)

协议对比

传统的MCP(JSON-RPC)

  • 完全符合JSON-RPC 2.0标准
  • 基于会话的访问 Mcp-Session-Id 头球
  • 跨请求的状态保持通信
  • 最适合用于:需要状态管理的复杂工作流程

FastMCP HTTP模式(JSON-RPC)

  • 带自动会话的JSON-RPC 2.0
  • 需要 notifications/initialized 初始化之后
  • 返回SSE或JSON响应
  • 最适合:希望使用HTTP模式的FastMCP库用户

FastMCP 可流式传输-HTTP(简化版)

  • 简化格式,不包含JSON-RPC包装器
  • 无需会话管理
  • 使用纯JSON直接发送HTTP请求
  • 最适合用于:轻量级无状态操作

安装

先决条件

  • Python 3.8及以上版本
  • Node.js 16+(用于前端)
  • 一个大型语言模型(LLM)提供商(如Ollama、OpenAI、Claude等)

完整设置

# Clone repository
git clone https://github.com/kunwarmahen/mcp-discovery-hub-mcast.git
cd mcp-discovery-hub-mcast

# Backend setup
cd backend
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt

# Frontend setup (optional)
cd ../frontend
npm install

# Run both (in separate terminals)
# Terminal 1: Backend
python ../backend/mcp_discovery.py

# Terminal 2: Frontend
npm run dev

# Terminal 3: LLM (if using Ollama)
ollama serve

# Terminal 4+: MCP Servers
python sample_mcp_server.py

故障排除

问题 解决方案
未发现的服务器 ✅ 确保服务器正在运行
✅ 确认服务器已具备 MCP_ENABLE_BROADCAST=true
✅ 检查防火墙是否允许UDP 5353和IGMP
✅ 测试: sudo tcpdump -i any udp port 5353
✅ 尝试备用方案: POST /scan-network
在无防火墙环境下工作正常,启用UFW(Uncomplicated Firewall)后失败 ✅ 编辑 /etc/ufw/before.rules (见上文的防火墙配置)
✅ 添加IGMP协议规则
✅ 运行 sudo ufw reload
在Linux上运行,不在Docker中运行 ✅ 使用 --network host 用于集装箱
✅ 或配置 macvlan 多播网络
✅ 检查容器网络隔离情况
WebSocket 已断开连接 ✅ 后端运行了吗?
✅ 检查防火墙/代理设置
✅ 在前端配置中验证WebSocket URL
工具未执行 ✅ 服务器在线吗?(检查状态徽章)
✅ 工具参数正确吗?
✅ 大语言模型(LLM)已配置并运行? (此句为分隔线或空白,无实际翻译内容)
网络上不支持多播 ✅ 使用备用方案: POST /scan-network
✅ 手动指定IP范围
✅ 请与网络管理员确认是否允许组播
✅ 考虑使用VPN或在子网内部署

调试多播

检查多播是否正常工作:

# Listen for multicast packets
sudo tcpdump -i any udp port 5353 -v

# In another terminal, trigger a server announcement
# (should see packets in tcpdump output)

# Test IGMP group membership (Linux)
netstat -gn | grep 239.255.255.250

# Check multicast routing
ip mroute

版本历史

功能 v1.0 v2.0
发现方法 HTTP探测 多播UDP + HTTP探测
服务器类型 1 3
配置 手动 零配置广播
协议支持 JSON-RPC JSON-RPC + 简化版
用户界面 (UI) Vite React 实时更新
多LLM(大型语言模型) 基本 完全支持

贡献;助力

我们欢迎贡献!需要改进的方面包括:

  • 额外的传输协议
  • 身份验证与授权
  • 服务器性能监控
  • 高级工具链接和工作流
  • 网页用户界面改进
  • 文档与示例
  • 测试覆盖率

见 CONTRIBUTING.md 翻译为中文是:“贡献指南.md” 或 “贡献规范文件.md”。这里,“CONTRIBUTING”通常指的是一个文件名,用于说明如何向项目做出贡献,而“.md”是Markdown文件的扩展名。因此,整个文件名可以理解为是一个关于如何参与项目贡献的指南或规范的Markdown文件 作为指南。

许可证

MIT 许可证 - 查看 许可证 文件中包含详细信息。

资源

支持

  • 📖 书籍 文档
  • 🐛 这个符号在中文里通常被用来表示“虫子”或者“小错误”(在编程或软件领域),但直接翻译这个符号本身并没有一个固定的中文对应词,所以可以简单地说它代表“虫子”或根据上下文翻译为“小错误”。如果需要一个更具体的翻译,可以结合使用场景来解释。 问题
  • 💬 讨论

项目进化


由开发者用心打造,为开发者而生。如果您觉得有用,请给它点个星! ⭐