MCP for 可观测2.0 —— 6个用好MCP的实践

MCP 简述

MCP 是一种开放协议，用于标准化应用程序如何向 LLM 提供上下文。可以将 MCP 视为 AI 应用程序的 USB-C 端口。就像 USB-C 提供了一种将设备连接到各种外围设备和配件的标准化方式一样，MCP 提供了一种将 AI 模型连接到不同数据源和工具的标准化方式。

• MCP 主机 (MCP Hosts)：例如 Claude Desktop、IDE 或希望通过 MCP 访问数据的 AI 工具等程序
• MCP 客户端 (MCP Clients)：与服务器保持 1:1 连接的协议客户端
• MCP 服务器 (MCP Servers)：轻量级程序，每个程序通过标准化的模型上下文协议 (MCP) 公开特定的功能
• 本地数据源 (Local Data Sources)：您的计算机的文件、数据库和 MCP 服务器可以安全访问的服务
• 远程服务 (Remote Services)：可通过互联网访问的外部系统（例如，通过 API），MCP 服务器可以连接到这些系统

快速开始

把MCP框架理解为“大模型插件”，并且你也可以很方便地编写自己的“插件”功能。

• [必须] 首先你需要一个支持MCP的Client，参考下一章节。在本文中，使用的是 Cherry Studio 和DeepChat Client。
• [必须] 需要准备LLM API。准备好api key。在本文中，使用的是阿里云百炼。如果没有api key，也可以使用本地化大模型（ollama）本地化相关功能参考：https://ata.atatech.org/articles/11020220022

• [可选] 按需添加 MCP Server，参考下两章节。
• [可选] 编写属于自己的 MCP Server。在https://github.com/modelcontextprotocol仓库下，选择您期望的SDK。添加自定义功能的Tools，就可以启动Server，供大模型调用了。

配置如下：

Awesome MCP Clients 推荐

完整列表参考：https://github.com/punkpeye/awesome-mcp-clients

对比参考：https://modelcontextprotocol.io/clients

笔者推荐：

• Cherry Studio

• DeepChat

• AIaW (注意内部数据安全)

Awesome MCP Servers 推荐

完整列表参考：https://github.com/punkpeye/awesome-mcp-servers

文档实例列表：https://modelcontextprotocol.io/examples

官方列表：https://github.com/modelcontextprotocol/servers

按需添加即可。

MCP Server for 阿里云可观测2.0

可观测2.0

过去一年，我们迈向了通用可观测之路。从“监控”到“可观测”，不仅是技术升级，更是对复杂系统认知的深化。通过因果推理的三个层级（关联、干预、反事实），可观测性能够实现从被动观测到主动预测的能力提升。企业数字化需要将黑盒系统转化为白盒，通过采集、存储和分析多模态数据（如Log、Trace、Metric等），优化运营效率。

随着分布式系统和技术栈的复杂化，可观测性成为确保系统稳定性和性能的关键。然而，许多企业面临可观测数据混乱的问题，如缺乏标准化、数据存储分散、分析效率低及知识难以沉淀。为解决这些问题，我们提出了UModel——可观测数据之魂，一种通用的可观测“交互语言”。

UModel基于本体论思想，通过Set和Link组成的图模型描述IT世界，定义了EntitySet、LogSet、MetricSet等核心类型，以及EntitySetLink、DataLink等关联关系。它支持灵活扩展，引入CommonSchema降低使用门槛，并提供Explorer、告警与事件集等功能提升易用性。UModel不仅实现了数据的标准化和统一建模，还支持算法和大模型对数据的高效利用，助力构建全新的“可观测2.0”体系。

融合 MCP 能力

在可观测2.0中融合MCP能力，是一种很合适的尝试，一定程度上可以通过对话的方式，让用户对可观测2.0整体使用方式有更好的感知，并且可以协助用户感知系统、分析问题——只用自然语言交流。

特性如下：

• 根据某服务，检索服务上下游、依赖的中间件和基础设施
• 分析某服务的指标情况
• 查询某服务是否存在错误请求trace id，并进一步智能分析

可观测基础信息能力查询

特性如下：

• 查询可观测2.0中多类信息：
  • 获取可用区
  • 查找workspace
  • 查询entity 和 topo能力
  • 查询 Umodel Schema 并生成图片展示。

设计好MCP Servers的亲身实践（血泪踩坑）

经验一：Tools 接口精简化、原子化

写在前面：MCP Server ≠ SDK API，是和人打交道的接口。

这里的“和人打交道”，是全方面的，无论是接口的理解，参数，还是返回，都要求简洁易懂。“三岁小孩都能懂”的MCP Server Tools才是好Tools。

举个例子🌰：

SLS 的 getLogs SDK API 是这样的

def get_logs(
ak: str,
sk: str,
region_id: str,
project: str,
logstore:str,
query: str,
from_timestamp: int,
to_timestamp: int,
topic: str,
line: int,
offset: int,
reverse: boolean,
powerSql: boolean
) -> list[Any]:

这个接口如果直接给到大模型作为Tools，可以说调用的成功率为0，因为这是一个非常复杂的接口：

1. 主要的瓶颈在 query 怎么写，语法是怎样的，对模型挑战非常大。这种场景适合A2A（Agent协作），生成可靠的SLS query作为一个Agent，此处不过多展开。
2. 假设我们解决了query的问题，API中的很多基础信息需要多轮对话获得：aksk、region、project、logstore，实际使用上这种环境变量级别的参数重复性非常高。
3. 参数中带了时间窗口，这一点需要谨慎，详情见经验二。
4. 参数中带了topic、line、offset、reverse、powerSql这种不常用参数，使用默认值能搞定大部分请求的参数就不带。

对于这些问题，在整体的实践后，认为在阿里云上，使用MCP Server和用户交互的架构，可能需要做一些改变。

朴素想法：

真正适用的：

首先，这里的MCP Server的生命周期应该是在用户进入到Workspace后，才创建。阿里云提供给用户的MCP交互 Client + MCP Server 是非常轻量的，一个用户、一次Workspace访问就是一次生命周期。而此时MCP Server是带上aksk、Workspace name、region id等环境变量信息的，里面的各种Tools无需关心这种基础的参数了。

然后，随着用户业务的范围，可以创建若干对应模块的Tools以供用户按需调用。最后，需要把常用的操作封装MCP Tools，而不是给出一个万能的“query”接口。

因此，给出的getLogs，优化过后的MCP Server Tools版本应该是这样的：

A2A 模式：

def get_log_tool(
query: str,
from_timestamp: int = Field(
int(datetime.now().timestamp()) - 3600, description="from timestamp,unit is second"
),
to_timestamp: int = Field(
int(datetime.now().timestamp()), description="to timestamp,unit is second"
)
) -> list[Any]:

def gen_sls_query(
text: str,
) -> str:

功能模块化模式（仅示例）：

# 获取logstore的index信息
def get_index():
pass

# 获得fields字段聚合的统计信息
def get_fields_desc(
filter: str,
fields: List[str],
from_timestamp: int = Field(
int(datetime.now().timestamp()) - 3600, description="from timestamp,unit is second"
),
to_timestamp: int = Field(
int(datetime.now().timestamp()), description="to timestamp,unit is second"
)
) -> list[Any]:
# * and upstream_status >= 400 | SELECT request_uri, upstream_status, COUNT (*) AS cnt
# FROM log
# GROUP BY request_uri, upstream_status
# ORDER BY cnt DESC
# LIMIT 10


# 统计UV
def get_uv(
filter: str,
field: str
from_timestamp: int = Field(
int(datetime.now().timestamp()) - 3600, description="from timestamp,unit is second"
),
to_timestamp: int = Field(
int(datetime.now().timestamp()), description="to timestamp,unit is second"
)
) -> list[Any]:
# * | SELECT COUNT(DISTINCT client_ip) AS unique_visitors FROM log

这里不需要ak、sk、project、logstore信息的原因是，这里的MCP应该是在logstore打开的时候启动的，因此已经知道基础环境信息了。

这样的功能模块划分仅为示例，仅作说明。

经验二：Tools 接口参数默认化。慎用时间参数。

案例：一个查询SQL Query的Tools，接口是这样的：

def o11y_list_entities(
ctx: Context,
query: str = Field(default=None, description="query"),
from_timestamp: int = Field(
..., description="from timestamp,unit is second"
),
to_timestamp: int = Field(
..., description="to timestamp,unit is second"
)
) -> list[str]:

为了方便大模型使用，特意增加了一个tool 用于调用时间相关的参数：

想法很好，现实很骨感，实际使用中，经常出现传入并不合法的 from to 的情况：

导致接口直接报错，因为传入不合法的参数，这种场景甚至必须重启client和Server。

有时也会传入离谱的时间参数，导致后续的回答并不理想：

时间戳这里提供的是 2023-06-25 00:00:00。大模型对“现在的时间”概念模糊。提供的示例对于一个只保存30天的LogStore来说仍然查不出数据。

更好的方式：

def o11y_list_entities(
ctx: Context,
query: str = Field(default=None, description="query"),
from_timestamp: int = Field(
int(datetime.now().timestamp()) - 3600, description="from timestamp,unit is second"
),
to_timestamp: int = Field(
int(datetime.now().timestamp()), description="to timestamp,unit is second"
),
) -> list[str]:

直接给出最近1小时的默认值，极大概率都可以覆盖期望的查询，只需考虑query的传入，不用纠结时间的细节设置。如果返回为空，模型会考虑是否是时间问题，并反馈。

经验三：精简输出，避免过长的上下文输出

一些不好的例子：查询workspace的list（返回500个workspace），查询某个workspace下接入的entity类型（返回200个）

MCP Server 和 SDK API 的功能不能完全等价看待，MCP 本质上是给人作为终端显示的，因此人眼看不过来（体感：大于20个的数量）都是意义不大的内容。每个接口的输出都应该控制limit。可以考虑通过加入筛选检索，或者直接截断输出到10个。

除了体感之外，过长的json response会严重卡慢后续模型的输出速度、影响上下文理解效果。

以上是一般json接口的经验。在实践中，我们还会遇到这类场景：希望Tools返回一幅图（以svg或png的形式）。尝试了几种方案：

• 直接返回<svg></svg> 的data xml：client不会正常显示。且会因为返回数据较大而卡慢速度。
• 使用MCP SDK的Image 类，返回"url": f"data:image/png;base64,{tool_result.data}"：多数client不会正常显示，且需要模型是多模态模型。
• 使用图片辅助服务，直接返回markdown的url格式：效果较好。

Args:
ctx: MCP上下文，用于访问可观测客户端
workspace_name: Workspace 名称，必须完全匹配Workspace

Returns:
![Schema](http://localhost:9688/xxx.svg})
Schema 的 markdown 内容，直接作为你的输出打印并展示

效果：

经验四：避免Tools和Tools输入输出的链式传递

好的实践：Tool原子能力，一个Tool做独立一件事。

不好的实践：Tool1 -> output -> Tool2 input -> output -> Tool3

实践中链式传递也可以做到，但有一定概率传入的参数不符合预期，且不好控制。

有一些还不错的自我修复能力是，当大模型发现参数报错的时候，会调用依赖的上一个Tools验证一下参数正确性。这种情况有一定概率修复，但并非完全可以。有时会执拗地认为自己没错：

在同一次问题中，通常链式传递表现尚可。如果是在同一会话中第二次询问，并不会获得第一次询问调用的接口的每一个信息，或者判断错误。

• 实践场景一：

Tool1：查询service的关联上下游，返回

[
{
"id": "apm@apm.service:dc7495605d8395b3788f9b54defcb826",
"type": "upstream",
"name": "gateway",
},
{
"id": "apm@apm.service:97cd7e28783143028d7e8e9c8dbce99c",
"type": "downstream",
"name": "checkout",
},
]

然后其他一些分析……省略

对话上下文中，第二次询问，请帮我查询checkout服务的信息。

模型会直接把checkout直接传入Tool2（参数只有一个id，并在Prompt注释中说明很详细）

第二次对话必须复制apm@apm.service:97cd7e28783143028d7e8e9c8dbce99c完整，才会正确传递参数。

• 实践场景二：

有一个Tool返回trace ids，返回了一个列表：

[
"93b9111f425a4b6cab6548aa68d18f04",
"e165fede431c4c178d1e7e399c92b70d",
"ce7d4e9f74634252969adfd62b509fd6",
"e824356ddf4f42d884abe7c6a2d55d66",
]

每一个值是trace id。

期望的是模型使用每一个trace id调用分析的接口，但是模型会自己传错

经验五：在接口实现开工之前，首先以模拟数据作为尝试

模型使用接口的方式，可能和预期不一样。接口的设计可能需要大量改动，才能让模型按照你想要的方式运作，尤其涉及Tools链式调用的时候，更要谨慎。

在设计MCP接口的时候，首先定义Tools接口信息，然后编写Tools的注释说明（引导Prompt），接着按照预期实现的返回数据，mock一些假数据直接返回。在交互的过程中不断调整接口信息、注释信息，直到假数据可以按照预期正常工作，最后再开始接口的开发，否则如果先实现接口，返工率极高，十分心痛。

经验六：有时模型会“盲目自信”、“假装工作”。适当调低temperature。

请至钉钉文档查看附件《trace 拼接错误，时间错误，自己生成.mp4》

这个case里面，trace id传错是第一个问题，之前（经验四）已经讲过。

在之后，又遇到了时间的坑。（经验二）

在发生错误之后，模型并不会提示问题，而是结合一些正确的接口输入输出数据，自己悄悄生成假模假样的数据……像不像论文里瞎编数据的无良大学生[狗头]。

这里上下游的数据也是假的，从id也能看出来。

这个问题调低tempreture可以缓解，但是并非可以完全解决，MCP本质上还是依赖生成模型，而生成模型是否适合一些严肃严格场景的接口，这里稍稍打一个问号。

除此之外，观察到如果在同一对话上下文中多次问类似实体，但id不同的实体，模型似乎并不会真正调用接口了，而是直接生成tool的输入参数，建议用户去调（谁是老板？？）。

还有一种场景是受上下文影响过大，会参考上次的输出，然后新实体的关联、上下游也和上次调用的实体关联、上下游一样（糊弄我是吧？？）

总结

MCP是标准化LLM上下文交互的开放协议，包含主机、客户端、服务器及数据源组件，支持连接本地/远程服务。用户需配置支持MCP的客户端（如Cherry Studio）和LLM API（如阿里云百炼），并可扩展官方/自定义MCP服务器。阿里云可观测2.0通过UModel统一多模态数据交互，解决系统复杂性带来的观测难题，实现从被动监控到主动预测的升级。

MCP Server 设计注意事项和思考

MCP作为人、LLM、业务场景融合的媒介和工具，是新一代交互工具的萌芽，但仍然存在很多设计场景上的注意点。

如果判断下来都是“是”，则非常适合MCP场景。

一些不适合的场景，通过某种转化，可以变成适合的场景。比如股票交易系统不提供交易接口，只提供股票代码查询的能力，规避安全性问题。提供股票查询后，规避返回股票信息具体细节，而引导模型输出报告，模型会输出对这支股票的看多看空思路和依据，提升宽容性。

同时也可以发现，MCP天生适合理解业务短平快的需求场景，如果想解决一个非常复杂的任务，MCP接口可能还不够，需要A2A + 更高级的协作、超长上下文的理解。

一些优秀的MCP应用场景

1. bing 搜索、Github搜索、网盘搜索等各类搜索引擎 MCP

理由：独立、简洁（返回Top5相关）、宽容（一定程度上）、鲁棒、安全。

1. 高德地图 MCP 生成旅游路线

理由：独立、宽容（每次不同甚至有新鲜感）、鲁棒（有高德地图稳定的系统为支持）、安全。

1. Web浏览器自动化，相关爬取、统计、分析

理由：独立、简洁（输出约束一下）、宽容、鲁棒。

1. FileSystem

理由：独立、简洁、宽容（理由是linux命令行llm非常懂，不太可能写错）、安全（不提供rm能力）

1. Redis

理由：独立、简洁、宽容（非严肃Redis数据库）

可观测2.0 + AI的未来展望

MCP适用于短平快的独立接口能力，对于复杂需求，更适合A2A或更强大的模式。更多结合AI的能力，不仅仅有MCP，可观测2.0 + AI，还有更多可能。

参考

1. https://modelcontextprotocol.io/introduction
2. https://github.com/punkpeye/awesome-mcp-clients
3. https://modelcontextprotocol.io/clients
4. https://deepchat.thinkinai.xyz/
5. https://help.aliyun.com/zh/model-studio/get-api-key
6. https://github.com/punkpeye/awesome-mcp-servers
7. https://modelcontextprotocol.io/examples
8. https://github.com/modelcontextprotocol/servers
9. https://ata.atatech.org/articles/11020220022
10. https://ata.atatech.org/articles/11020252410
11. https://ata.atatech.org/articles/11020344825