Global-MCP-Server
# Global-MCP-Server
Trae 全局 MCP server(global-diff-ops):VLA-Diff 项目运维工具(一期只读 + 二期写操作)。
本目录是独立部署副本(源头位于 VLA_Diff 仓库的 VLA-Diff-MCP/),在 Trae 全局 MCP 配置中注册。
## 运行形态
本部署以 `VLADIFF_MCP_PROFILE=ops` 运行(见全局 mcp.json 的 env):
暴露 11 个运维工具,**不含 `publish_prompt`**。该敏感写操作(伪造大模型指令)
仅由 VLA_Diff 工作区的 MCP 实例(`vla-diff-prompt`,profile=prompt)提供,
避免全局误用。工具裁剪逻辑见 server.py 中 `_tool` 装饰器。
## 功能
通过 MCP 协议向 Agent 提供稳定工具,替代每次临场拼 bash 命令:
### 一期:只读工具
| 工具 | 说明 | 运行位置 |
|------|------|----------|
| `ros_topic_status` | 查询 ROS 话题频率 + 最新消息 | 容器 `ros_noetic_uss_nav` |
| `ros_topic_echo` | 读取 ROS 话题最近 n 条消息 | 容器 |
| `process_status` | 查询关键服务进程状态 | 宿主机 |
| `tmux_status` | 列出 tmux 会话 | 宿主机 |
| `tmux_capture` | 抓取 tmux 会话 pane 输出 | 宿主机 |
| `read_log` | 读取 agent_run / scene_graph 日志 | 容器 |
### 二期:写操作工具
| 工具 | 说明 | 安全机制 |
|------|------|----------|
| `publish_prompt` | ~~向 /agent_prompt 发布伪造指令~~ **本部署不暴露**(仅 VLA_Diff 工作区实例提供) | — |
| `tmux_send` | 向 tmux 会话发送命令(不存在时自动创建,不 kill-session) | 无(按复用规则操作) |
| `restart_service` | 重启 ego_planner 等(先杀后启,后台运行) | **confirm=True 显式确认** |
| `exec_cmd` | 容器内任意 shell 命令兜底 | 无白名单,谨慎使用 |
### SSH 远程执行工具
| 工具 | 说明 | 安全机制 |
|------|------|----------|
| `ssh_exec` | 在远程主机执行 shell 命令;host 支持 `~/.ssh/config` 别名(如 moon)或 user@ip(如 diff@10.176.224.12) | 密码仅经环境变量传递(sshpass -e),不进 ps/日志 |
| `ssh_hosts` | 列出 ~/.ssh/config 中全部主机别名及连接信息 | 只读 |
认证策略:默认走 `~/.ssh` 密钥(BatchMode,失败即报错不挂起);
传 `password` 参数时走密码认证。同一主机 10 分钟内复用 TCP 连接
(ControlMaster),连续执行多条命令免重复认证。
## 环境准备
```bash
# 创建虚拟环境并按 uv.lock 安装依赖(标准 .venv,已被 .gitignore 忽略)
uv sync
```
## 运行
```bash
.venv/bin/python server.py
```
默认 stdio 传输,由 MCP 客户端(Trae 全局配置 `~/.config/Trae CN/User/mcp.json`)以子进程方式拉起。
## 前置条件
- Docker 容器 `ros_noetic_uss_nav` 已创建(ROS 相关工具依赖)
- 未启动时,ROS 类工具会返回明确错误,tmux / 进程类工具不受影响
## 扩展方向
- 更多可重启服务:elastic-tracker、tracking_service 等(按需加入 `KNOWN_RESTART`)
- 服务配置化:将启动命令迁移到 YAML,避免写死在代码里
TDQS
Scored across 11 tools
Most tools target distinct layers: ROS topics, host processes, tmux sessions, log files, and remote hosts. Minor overlap exists between process_status and tmux_status for service verification, and tmux_capture/read_log both retrieve output, but their contexts are clearly described.
There is a mix of patterns: tmux_status, tmux_capture, process_status, and ssh_hosts follow object/action style, while read_log, restart_service, and exec_cmd use action/object style. The prefixes help readability, but the inconsistency prevents a higher score.
11 tools is well-scoped for a server covering ROS monitoring, process/log inspection, tmux interaction, command execution, and remote SSH access. Each tool has a distinct operational purpose and none feel redundant.
The server covers the main diagnostic and operational workflows: checking statuses, reading logs, restarting a service, sending tmux commands, and executing shell commands locally or remotely. It lacks a generic service control lifecycle and remote file operations, but exec_cmd and ssh_exec cover many edge cases.