企业官网建设流程全解析

接入外部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]

mcp_cls_transport: str="sse"# 本来就是 ssemcp_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] 从本地地址换成腾讯云地址:

mcp_cls_transport:str="sse"# 本来就是 ssemcp_cls_url:str="https://mcp.cls.tencentcloudapi.com/.../sse"# ← 换成云端

Step 3 — 把密钥注入(不要写死在代码里)

真实场景通过.env提供密钥,并在 client 建立连接时带上 header。当前你的mcp_servers只有{transport, url};接云端时通常要扩展一个 headers/鉴权字段:

"cls":{"transport":"sse","url":self.mcp_cls_url,"headers":{"Authorization":f"Bearer{self.cls_token}"},# 云端需要}

Step 4 — 启动,Client 自动完成"连接 → 发现工具 → 调用"

MultiServerMCPClient连上云端后自动做三件事,你无需干预:

1. 连接:按 sse 协议连远程端点
2. 工具发现(tools/list):拉回腾讯云 CLS 暴露的工具清单(如日志查询、检索)及其 schema
3. 调用(tools/call):Agent 决定用哪个工具,Client 把请求转发到云端,拿回结果

→cls_server.py这个本地文件在这种模式下直接作废、可删除。

三、两种模式对比:自己写 Server vs 连别人的 Server

最关键的洞察:无论哪种模式,你项目 [mcp_client.py]的调用逻辑一行都不用改——因为 MCP 是标准协议,Client 只认{transport, url},不关心对面是本地 mock 还是腾讯云。这就是config.mcp_servers这个字典存在的意义:把"接谁"变成纯配置项,实现可插拔。

四、各自的应用场景

本地自己写 Server 适合

1. 开发/联调阶段:没有云账号、不想产生费用、要离线跑通链路 → 用 mock 先把 Agent 端到端流程验证对
2. 数据源是内部/私有的:公司自研监控系统、内网 Prometheus,厂商没有现成 MCP,只能自己封装
3. 需要定制工具逻辑:官方 MCP 的参数/返回不满足,你要裁剪包装
4. 教学/演示:像这个项目,面试作品不可能真连生产云,本地 mock 最合适

接厂商托管 Server 适合

1. 数据本身就在云上:日志在腾讯云 CLS、监控在云监控 → 直接用官方 MCP 最省事、数据最真
2. 要鉴权/审计/合规:官方 Server 自带权限体系,自己写反而要重新造
3. 不想维护 Server:高可用、升级、协议兼容都交给厂商

五、一句话总结

接腾讯云 CLS不需要本地再写 Server,只在配置里把 url 换成云端端点、补上鉴权 header,Client 逻辑完全不动。本地写 Server 是"没有现成提供方时的自造轮子/联调 mock",连云端 Server 是"数据在厂商、直接复用其能力"——两者的分界线是"谁拥有数据、谁负责实现",而对 Client 来说都是同一个{transport, url}配置。

面试加分表述(如果问到这块)

“我特意把 MCP 接入设计成面向协议、配置驱动:Client 侧只依赖{transport, url},开发期连本地 FastMCP mock,上线时改成腾讯云托管端点加鉴权即可,切换零改代码。这样做是为了在没有云账号时也能端到端验证 Agent 工具链路,同时保证后续替换真实数据源不动核心逻辑。”

这体现的是依赖倒置 / 可插拔设计意识,比"我写了个 mock"要高一个层次。