前言

本文主要内容是对mcp的实践

mcp 更像是一套统一插座：agent 想接监控、数据库、工单、知识库，不需要每个系统都重新写一套协议，只要大家都按 mcp 的方式暴露工具就行

本文笔者就结合一个最小 demo，拆一下 mcp server 和 agent 是怎么配合的，并聊聊 mcp 常见的几种传输模式：stdio、SSE/HTTP、websocket

先看代码

demo代码

.
├── agent.py
└── mcp_server.py

• mcp_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 的传输模式

• stdio
• SSE/HTTP
• WebSocket

前面 demo 用的是 stdio

stdio 模式

stdio 是最适合本地工具的模式。它的通信方式很朴素：agent 启动 MCP Server 子进程，然后通过标准输入、标准输出通信

在本文 Demo 里，就是这段：

server_params = StdioServerParameters(
    command="python3",
    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 Server，stdio 就不太优雅
• 生命周期跟 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 服务

三种模式怎么选

总结

本文通过一个监控 demo，演示了 MCP server、MCP tool、agent 协同工作

stdio 适合本地工具和快速验证，SSE/HTTP 适合远程服务和团队共享，websocket 适合长连接、低延迟、双向实时交互场景

联系我

• 联系我，做深入的交流

至此，本文结束

在下才疏学浅，有撒汤漏水的，请各位不吝赐教...