接入外部MCP服务：以腾讯云日志服务平台为例（Cls）
一、接入腾讯云 CLS MCP,本地不写 Server
MCP 有两个角色,谁提供工具谁实现 Server:
- 腾讯云提供 CLS MCP → Server 是腾讯云写的、托管在云上,已经上线了。
- 你的 Agent → 只是 Client,负责连上去、发现工具、调用工具。
二、接入远端 MCP Server 的完整流程
从"什么都没有"到"Agent 能调用腾讯云 CLS 工具",一共 6 步:
第 1 步:拿到云端端点信息
从腾讯云控制台获得:
- MCP 服务 URL(通常是
https://cls.tencentcloudapi.com/mcp/xxx/sse这种含/sse/的托管地址) - 鉴权方式(密钥 SecretId/SecretKey,或临时凭证 Token)
- 支持的 transport(腾讯云托管一般是 sse)
第 2 步:配置 Client 连接参数
对应你 config.py
bash
mcp_cls_transport: str = "sse" # 本来就是 sse
mcp_cls_url: str = "https://mcp.cls.tencentcloudapi.com/.../sse" # ← 换成云端一、MCP 的两个角色(先分清,后面全通了)
┌──────────────┐ MCP协议 ┌──────────────┐
│ MCP Client │ ────────────> │ MCP Server │
│ (消费工具) │ 连接/调用 │ (提供工具) │
│ 你的 Agent │ │ 谁实现谁提供 │
└──────────────┘ └──────────────┘- 谁拥有数据/能力,谁写 Server。 CLS 的数据在腾讯云,所以理应腾讯云写 Server。
- 你的项目永远是 Client。 无论连本地 mock 还是连云端,你的代码都不用改逻辑,只改配置里的 url / transport。
二、接入腾讯云 CLS 官方 MCP 的完整流程
核心:你一行 Server 代码都不用写,只动配置。
Step 1 --- 在腾讯云开通 CLS 的托管 MCP 服务
腾讯云控制台会给你三样东西:
- 一个 端点 URL (通常长这样:
https://mcp.cls.tencentcloudapi.com/xxx/sse) - 鉴权方式(SecretId/SecretKey,或以 Header / query 携带的 token)
- 它声明好的 transport (腾讯云托管 MCP 一般是 SSE,所以配置注释里写"URL 含 /sse/ 需用 sse")
Step 2 --- 改你项目里的配置,指向远程端点
把 config.py 从本地地址换成腾讯云地址:
python
mcp_cls_transport: str = "sse" # 本来就是 sse
mcp_cls_url: str = "https://mcp.cls.tencentcloudapi.com/.../sse" # ← 换成云端Step 3 --- 把密钥注入(不要写死在代码里)
真实场景通过 .env 提供密钥,并在 client 建立连接时带上 header。当前你的 mcp_servers 只有 {transport, url};接云端时通常要扩展一个 headers/鉴权字段:
python
"cls": {
"transport": "sse",
"url": self.mcp_cls_url,
"headers": {"Authorization": f"Bearer {self.cls_token}"}, # 云端需要
}Step 4 --- 启动,Client 自动完成"连接 → 发现工具 → 调用"
MultiServerMCPClient 连上云端后自动做三件事,你无需干预:
- 连接:按 sse 协议连远程端点
- 工具发现(tools/list):拉回腾讯云 CLS 暴露的工具清单(如日志查询、检索)及其 schema
- 调用(tools/call):Agent 决定用哪个工具,Client 把请求转发到云端,拿回结果
→ cls_server.py 这个本地文件在这种模式下直接作废、可删除。
三、两种模式对比:自己写 Server vs 连别人的 Server
| 维度 | 本地自己写 FastMCP Server(现状) | 接腾讯云托管 MCP |
|---|---|---|
| 要不要写 Server | 要,@mcp.tool() 一个个实现(cls_server.py |
不用,腾讯云已实现 |
| 数据来源 | 你自己造的 mock 假数据 | 云端真实日志数据 |
| transport | streamable-http(本地) | 一般 sse(云端) |
| 鉴权 | 无(本机 127.0.0.1) | 需要密钥/签名 |
| 你要改的 | 写并维护 server 代码 | 只改 url + 加鉴权 header |
| Client 代码 | 完全不用动 → 因为面向统一接口 | 完全不用动 |
| 运维责任 | 自己起进程、保活(还记得启动竞态那个坑吗) | 腾讯云保证可用性 |
最关键的洞察 :无论哪种模式,你项目 mcp_client.py的调用逻辑一行都不用改 ------因为 MCP 是标准协议,Client 只认 {transport, url},不关心对面是本地 mock 还是腾讯云。这就是 config.mcp_servers 这个字典存在的意义:把"接谁"变成纯配置项,实现可插拔。
四、各自的应用场景
本地自己写 Server 适合
- 开发/联调阶段:没有云账号、不想产生费用、要离线跑通链路 → 用 mock 先把 Agent 端到端流程验证对
- 数据源是内部/私有的 :公司自研监控系统、内网 Prometheus,厂商没有现成 MCP,只能自己封装
- 需要定制工具逻辑:官方 MCP 的参数/返回不满足,你要裁剪包装
- 教学/演示:像这个项目,面试作品不可能真连生产云,本地 mock 最合适
接厂商托管 Server 适合
- 数据本身就在云上:日志在腾讯云 CLS、监控在云监控 → 直接用官方 MCP 最省事、数据最真
- 要鉴权/审计/合规:官方 Server 自带权限体系,自己写反而要重新造
- 不想维护 Server:高可用、升级、协议兼容都交给厂商
五、一句话总结
接腾讯云 CLS 不需要 本地再写 Server,只在配置里把 url 换成云端端点、补上鉴权 header,Client 逻辑完全不动。本地写 Server 是"没有现成提供方时的自造轮子/联调 mock",连云端 Server 是"数据在厂商、直接复用其能力" ------两者的分界线是"谁拥有数据、谁负责实现",而对 Client 来说都是同一个
{transport, url}配置。
面试加分表述(如果问到这块)
"我特意把 MCP 接入设计成面向协议、配置驱动 :Client 侧只依赖
{transport, url},开发期连本地 FastMCP mock,上线时改成腾讯云托管端点加鉴权即可,切换零改代码。这样做是为了在没有云账号时也能端到端验证 Agent 工具链路,同时保证后续替换真实数据源不动核心逻辑。"
这体现的是依赖倒置 / 可插拔设计意识,比"我写了个 mock"要高一个层次。