用途
vllm-ops-mcp 是一个只读的运维/健康检查 MCP 服务器，面向在 WSL2 内由 systemd 管理的本地 vLLM 实例。它旨在为运维方以及其他依赖该 vLLM 实例的机器人/工具提供健康检查能力，自身不管理容器生命周期——它假定 vLLM 已经作为裸机 systemd 单元在 WSL2 中运行，而不是运行在 Docker/Podman 中。
主要能力
在该版本中，所有工具均为只读，除吞吐量上限外无需额外门控。服务器提供的健康信号均来自对 OpenAI 兼容 API 的真实 HTTP 请求（使用 urllib.request，而非 socket/connect 检查）。这是刻意设计：Get-NetTCPConnection 等基于监听器的检查会完全漏掉 WSL2 镜像网络转发的端口，一个真正健康的 127.0.0.1:8000 对从 Windows 主机运行的监听器探测可能是不可见的。该服务器将这一经验泛化为两个层级：存活（liveness）与真实生成（real generation）。
具体能力涉及：
- 健康检查分层：check_health(deep=True) 与 test_completion 会发起真实推理调用。
- GPU/VRAM 状态：get_gpu_status 调用 nvidia-smi 获取 GPU 与显存信息。
- systemd 服务状态：get_service_status 返回 systemctl 的原始 ActiveEnterTimestamp 字符串（已带时区标签，如 MDT），而非在服务器端计算运行时长——这是刻意的时钟纪律要求，需要时长应在调用侧做显式时区换算。
- 运行时 serve 参数内省：get_serve_config 读取 /proc/<pid>/cmdline，并在三种来源（live_process、exec_script、local_config_mirror）中对已知敏感模式（token、key、secret、password、passwd、credential，见 config.SENSITIVE_ARGV_FLAG_PATTERNS）的参数值统一替换为 [REDACTED]，但保留参数名可见以便诊断。
该服务器通过 wsl -d 调用 systemctl、执行 nvidia-smi，并读取 /proc/<pid>/cmdline。所有六个工具均为只读——不会启动、停止、重启或杀死任何进程；单元名/发行版名来自服务器端配置而非调用者输入，唯一到达 shell 字符串的调用者相邻路径（systemctl show 中的单元名）使用 shlex.quote 包裹。
使用方式
该服务器注册在 ~/.claude.json 中，名称为 vllm-ops-mcp（stdio，自带 .venv，对该运维方的默认设置无需环境变量覆盖）。
关于限流：check_health(deep=True) 与 test_completion 会对共享的 GPU 服务器发起真实推理调用，默认限流 20 次/分钟，可通过 VLLM_OPS_MCP_DEEP_RATE_LIMIT_PER_MIN 调整。限流的原因是此 vLLM 实例是其他机器人/工具依赖的共享基础设施，调用者频繁请求可能饿死或拖慢其他消费者，即使每次调用单独看都像是「只读」。
WSL2 相关配置：get_service_status 与 get_serve_config 的 live-process 路径默认假定该服务器进程运行在 Windows 主机上并通过 wsl -d <distro> 进入 WSL2。如果服务器进程本身原生运行在 WSL2/Linux 内，应设置 VLLM_OPS_MCP_RUNS_IN_WSL=1（使用原生 systemctl / cat，无需 wsl -d 跳转）。两条路径都有单元测试，但只有 Windows 主机路径在该运维方的真实环境中做过实测。
CI（.github/workflows/ci.yml）在每次 push/PR 时于 ubuntu-latest 上运行测试套件（单元测试 mock 了 HTTP/子进程，不需要实时服务器/GPU/WSL），若 Tests 徽章与套件实际报告不一致会导致构建失败（见 scripts/check_readme_counts.py）。
适用场景
适用于以 WSL2 + systemd 方式本地部署 vLLM 的运维者，用于：
- 区分「端口活着」与「真实推理可用」，避免监听器探测的盲区；
- 查看 GPU/显存使用情况（注意下文限制）；
- 查看 systemd 单元状态；
- 对运行中的 vLLM 进程的 serve 参数做只读内省。
限制
- 仅在 WSL2/systemd 管理且为裸机 systemd 单元的场景下设计，不是容器生命周期管理器。
- 本版本没有任何写/变更能力，也不存在可启用它的环境变量：restart_service 尚未在此代码库中实现（属于 v2 想法）。
- 在该运维方的 WSL2 GPU 直通配置下，按进程归属显存（per-process VRAM attribution）不可靠：一次真实 nvidia-smi 烟雾测试返回了空的进程列表，但同一调用的 gpus[0].memory_used_mib 正确显示该进程占用 13.7GB。这是某些 WSL2/直通配置下 nvidia-smi --query-compute-apps 的已知限制，工具会如实报告空结果（ok: true, processes: []），不会伪造归属。不要依赖 processes 做显存超额根因分析；gpus[].memory_used_mib 才是可靠信号。
- 不计算服务运行时长：get_service_status 返回原始 ActiveEnterTimestamp 字符串。
- get_serve_config 的 exec-script 回退路径是尽力而为的 shell 文本解析（处理 \ 续行与基本引号），并非精确的 argv 数组；单元处于运行状态时，始终优先使用 live-process 路径（内核的精确 argv，以 null 分隔）。
- get_serve_config 的 live-process 路径读取 /proc/<pid>/cmdline，若历史上曾通过 CLI 标志传入机密则可能包含机密（该运维方实际设置中没有——模型路径和标志均非机密；认证若有则在 exec 脚本内由环境注入，而非作为 argv 标志传入）。防御性措施是对已知敏感标志名对应的值做 [REDACTED] 替换。
- 默认 WSL2 专用，但切换接缝是显式的（见 VLLM_OPS_MCP_RUNS_IN_WSL）。
- 单 vLLM 实例、单 GPU：没有多实例/多 GPU 聚合；get_gpu_status 返回 nvidia-smi --query-gpu 枚举出的所有 GPU，而非限定为「vLLM 正在使用的 GPU」。
- 是否有商业支持：由 Jaimen Bell 维护；生产级 MCP 集成、自定义服务器或智能体可靠性工作可参见 jaimenbell.dev。是否有付费/商业服务细节暂未提供。
