先看代码demo代码. ├── agent.py └── mcp_server.pymcp_server.py负责启动一个 MCP Server并暴露一个工具get_monitor_metrics。agent.py负责启动 MCP client通过 stdio 连接 MCP server调用工具拿到监控指标然后把指标交给大模型分析。agent ↓ 调用 MCP Tool MCP server ↓ 返回监控指标 agent ↓ 拼 prompt LLM ↓ 输出分析结论实践一下 Step1: 获取监控数据 { timestamp: 1770000000, cpu_usage: 86.42, memory_usage: 91.33, pod_restart_count: 8, api_error_rate: 12.5, qps: 3200, latency_ms: 1800 } Step2: Agent 分析 当前系统存在异常风险。 主要问题包括 1. CPU 使用率较高 2. 内存使用率较高 3. Pod 重启次数偏多 4. 接口错误率和延迟偏高 建议下一步优先查看 Pod 重启原因、应用错误日志、接口依赖服务状态以及最近发布记录。MCP 的传输模式stdioSSE/HTTPWebSocket前面 demo 用的是stdiostdio 模式stdio是最适合本地工具的模式。它的通信方式很朴素agent 启动 MCP Server 子进程然后通过标准输入、标准输出通信在本文 Demo 里就是这段server_params StdioServerParameters( commandpython3, args[mcp_server.py] ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: await session.initialize() result await session.call_tool(get_monitor_metrics)它的执行关系类似这样Agent 进程 ├── 启动子进程python3 mcp_server.py ├── stdin 写请求 └── stdout 读响应 MCP Server 子进程 ├── stdin 读请求 └── stdout 写响应stdio 的优点很明显简单不用开端口不用配网关不用考虑公网访问安全边界清楚它只在本机进程之间通信不天然暴露网络入口适合本地工具比如本地文件检索、本地 Git 操作、本地数据库查询、本地脚本封装都很适合 stdio但它也有缺点不适合多客户端共享一个 agent 拉起一个子进程更多是一对一的使用方式不适合远程服务如果监控平台在远端、数据库在远端、多个 agent 都要复用同一个 MCP Serverstdio 就不太优雅生命周期跟 agent 绑定agent 退出子进程通常也就结束了所以 stdio 的最佳场景是本地开发、本地工具、单 Agent 调用、追求简单和低暴露面SSE/HTTP 模式SSE/HTTP 更适合远程 MCP server。SSE 全称是 Server-Sent Events可以理解成服务端通过 HTTP 连接持续向客户端推送事件客户端通过 HTTP 发起请求服务端通过 SSE 这类长连接返回消息流MCP Server 可以作为一个独立 Web 服务长期运行SSE/HTTP 的优点适合远程部署MCP Server 可以部署在服务器、K8s、内网服务里agent 通过 URL 访问方便多客户端复用多个 agent、多个用户可以连接同一个 MCP Server更容易接入网关和鉴权因为它是 HTTP 体系可以结合 API Gateway、Ingress、OAuth、Token、TLS、审计日志等能力适合企业内部工具平台比如把监控平台、CMDB、工单系统、知识库都封装成独立 MCP Server然后统一挂到内网缺点也很现实部署复杂度更高要考虑端口、域名、证书、鉴权、跨网络访问安全风险更高一旦暴露 HTTP 服务就要认真考虑权限控制。不要把能查生产数据、能执行命令、能操作工单的 MCP Server 裸奔到公网运维成本更高服务可用性、限流、日志、监控、升级都要考虑SSE/HTTP 的最佳场景是远程工具服务、团队共享、企业内网、多 agent 复用、需要鉴权审计的生产场景websocket 模式websocket 是全双工长连接。和 SSE 相比SSE 更偏服务端持续推给客户端而 WebSocket 是双方都可以持续发消息WebSocket 的优点双向实时通信能力更强客户端和服务端都能主动发送消息适合长时间会话比如远程 IDE、交互式工具、实时状态订阅、多人协作场景。适合需要低延迟交互的场景如果 MCP Tool 背后是一个持续运行的交互系统websocket 会更自然。但它的缺点也明显连接状态管理更复杂断线重连、心跳、连接数、会话恢复都要处理网关和代理配置更麻烦虽然现在很多网关都支持 websocket但排查起来通常比普通 HTTP 更烦不一定是 MCP 最常用选择在很多 MCP 实践里stdio 和 HTTP/SSE 更常见WebSocket 的最佳场景是长连接、低延迟、双向实时交互、会话型工具、远程协作类 MCP 服务三种模式怎么选传输模式适合场景优点缺点stdio本地工具、本地开发、单 agent 调用简单、安全、不暴露端口不适合远程复用SSE/HTTP远程 MCP server、团队共享、企业内网易部署到服务端、易接网关鉴权运维和安全复杂度更高websocket实时交互、长连接、双向通信低延迟、交互能力强连接管理复杂总结
