使用说明
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 发现:
- 设备广播:“我在这里!我是一个媒体服务器!”
- 控制点监听并记录设备信息
- 用户从列表中选择设备
- 控制点连接并使用设备服务
MCP发现中心流程:
- 集线器监听多播公告:“谁是MCP服务器?”
- 服务器广播:“我在这里!这是我的工具。”
- 工具会实时出现在您的界面上
- 用户选择工具并与大型语言模型(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 服务器
通过模型上下文协议实现的容器管理。
多播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
企业/公司网络
一些企业网络完全阻止多播。解决方案:
-
使用备用HTTP探测:
curl -X POST http://localhost:8000/scan-network \ -H "Content-Type: application/json" \ -d '{"ports": [3000, 3001, 3002, 8080, 9000]}' -
请求网络团队允许多播范围
224.0.0.0/4以及IGMP协议 -
使用支持多播的VPN 如果从外部网络连接
-
在同一子网中部署集线器 作为服务器以降低防火墙复杂性
用例
单一网络部署
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(大型语言模型) | 基本 | 完全支持 |
贡献;助力
我们欢迎贡献!需要改进的方面包括:
- 额外的传输协议
- 身份验证与授权
- 服务器性能监控
- 高级工具链接和工作流
- 网页用户界面改进
- 文档与示例
- 测试覆盖率
许可证
MIT 许可证 - 查看 许可证 文件中包含详细信息。
资源
- 模型上下文协议 - MCP规范
- UPnP/DLNA(通用即插即用网络/数字生活网络联盟) - 零配置灵感
- FastAPI - 后端框架
- React - 前端框架
- Ollama(注:Ollama是一个开源的机器学习框架,用于训练和部署机器学习模型,此处直接音译,实际使用时可能需要根据上下文确定具体含义或保持原样) - 本地LLM运行时
支持
- 📖 书籍 文档
- 🐛 这个符号在中文里通常被用来表示“虫子”或者“小错误”(在编程或软件领域),但直接翻译这个符号本身并没有一个固定的中文对应词,所以可以简单地说它代表“虫子”或根据上下文翻译为“小错误”。如果需要一个更具体的翻译,可以结合使用场景来解释。 问题
- 💬 讨论
项目进化
- 版本1.0: 原始博客文章 - DLNA/UPnP概念的诞生
- v1.0 仓库: github.com/kunwarmahen/mcp-discovery-hub 翻译为中文是:“github.com/kunwarmahen/mcp发现中心”。不过,这里的“发现中心”是根据“discovery hub”的直译,具体翻译可能需要根据该项目的实际功能或上下文进行调整。如果“mcp-discovery-hub”是一个特定项目或平台的名称,那么可能需要查找该项目的官方中文名称或常用译名 - 基于HTTP探测的发现
- v2.0 仓库: github.com/kunwarmahen/mcp-discovery-hub-mcast 翻译为中文是:“github.com/kunwarmahen/mcp发现中心-多播”。不过,这里的“mcast”通常作为“multicast”的缩写,在中文中更常翻译为“多播”。所以,更完整的翻译可能是:“github.com/kunwarmahen/mcp发现中心-多播(Multicast)”。但为了简洁,通常也会直接翻译为“github.com/kunwarmahen/mcp发现中心-多播” - 组播UDP发现(此版本)
由开发者用心打造,为开发者而生。如果您觉得有用,请给它点个星! ⭐
