MCP 实战入门：用一个 demo 讲清 agent 如何调用工具

先看代码

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 服务

三种模式怎么选

总结