1. MCP 是什么

MCP 是 Model Context Protocol 的缩写，是一个用于在模型和应用程序之间传递上下文的协议。

MCP 最大的价值是，在模型大战快结束，AI 应用爆发前夕，让开发者们对模型之外的能力调用有了统一的标准。如果模型、服务商各自定制一套协议，应用开发者们将面临巨大的学习成本、维护成本。同时，有了 MCP，存量的服务能力可以被复用，这无疑大大扩展了 AI 应用的边界。

每一种服务能力，都值得被抽象为一个 MCP 服务。

初期没有 MCP 时，为了查询日志、监控数据、执行 SOPS，我不得不引入各种组件的 SDK，而且受到 SDK 编程语言的限制，只能用 Golang 实现 AI Agent 的功能。有了 MCP 之后，Agent 的数量急剧的增加，通过 MCP 解耦，我可以根据具体场景使用 Cursor、TRAE 等工具快速开发上线新的能力。

2. ops-mcp-server

https://github.com/shaowenchen/ops-mcp-server 提供了运维场景下常用的 MCP 服务，包括:

2.1 Events

获取 Kubernetes 事件，其实不止是 Kubernetes 事件，而是所有事件系统的事件，包括告警事件、云厂事件等。

提供有两个工具:

• get-events-from-ops：按条件获取 Kubernetes 事件
• list-events-from-ops：列出 Kubernetes 事件

依赖于 https://github.com/shaowenchen/ops 项目，需要 ops-server 的接口访问 Nats 中的事件。

2.2 Metrics

查询 Prometheus 指标，支持即时查询和区间查询。

提供有三个工具:

• list-metrics-from-prometheus：列出 Prometheus 指标
• query-metrics-from-prometheus：即时查询 Prometheus 指标
• query-metrics-range-from-prometheus：区间查询 Prometheus 指标

2.3 Logs

查询 Elasticsearch 日志，支持全文检索和索引查询。

提供有三个工具:

• search-logs-from-elasticsearch：全文检索 Elasticsearch 日志
• list-log-indices-from-elasticsearch：列出 Elasticsearch 索引
• query-logs-from-elasticsearch：ES|QL 查询 Elasticsearch 日志

2.4 Traces

查询 Jaeger 链路，支持按服务、操作、trace ID 查询。

提供有四个工具:

• get-services-from-jaeger：列出 Jaeger 服务
• get-operations-from-jaeger：列出 Jaeger 操作
• get-trace-from-jaeger：按 trace ID 查询 Jaeger 链路
• find-traces-from-jaeger：按条件搜索 Jaeger 链路

2.5 SOPS

执行 SOPS 流程，支持按流程 ID 查询、列出流程及参数。

提供有三个工具:

• execute-sops-from-ops：执行 SOPS 流程
• list-sops-from-ops：列出 SOPS 流程
• list-sops-parameters-from-ops：列出 SOPS 流程参数

依赖于 https://github.com/shaowenchen/ops 项目，Pipeline 导出为 SOPS 流程，添加 Pipeline 即添加 SOPS 流程。

3. 设计和开发

3.1 尽可能少的 tools 数量

起初，我为了更扁平地将数据给模型，直接将每个 SOPS 导出为一个 tool，数量很快就超过了 40 个，达到了 Cursor 的上限，无法继续添加。

我全都采用了类似 RESTful 的接口设计进行重构，列出资源、获取资源详情、执行资源操作，这样大大减少了 tool 的数量。同时，也避免操作与数据耦合，新增加一个事件类型、SOPS、Metrics 指标等，完全不会影响到 MCP Server，只需要应用端调整参数即可。

3.2 tool 名字可定制

1
2
3
4
5

metrics:
  enabled: true
  tools:
    prefix: ""
    suffix: "-from-prometheus"

在启动 MCP Server 时，我允许通过配置文件定制 tool 的名字。这里的 -from-prometheus 就是 tool 名字的 suffix，指明了 tool 的来源是 Prometheus。

如果你有多个 Prometheus 实例，也可以部署多个 MCP Server，采用不同的 prefix 和 suffix 来区分，以此实现多数据源的接入。

tool 名字也是 prompt 的一部分，通过定制的 tool 名字，可以让模型更准确地理解用户意图。

3.3 采用共识的参数和返回格式

不要自作聪明地过渡设计，模型掌握的是行业内的共识，而不是你的个人经验。

同时，MCP Server 返回的数据本来就是给程序或模型使用，可读性并不是最重要的，准守规范，与其他接口保持一致即可。

因此，你会看到 MCP Server 很多逻辑只是在帮我们转发接口请求，然后返回原始数据。这样做的好处是，不在需要关心字段、格式的变化，通用性非常好。

3.4 使用 AI IDE 进行调试

通过添加下面这段配置，在 AI IDE 中集成 MCP Server 进行测试。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
  "mcpServers": {
    "ops-sse-from-ai": {
      "url": "http://x.x.x/mcp",
      "headers": {
        "Authorization": "Bearer xxx"
      }
    }
  }
}

如上图，如果使用尽可能少的 Prompt 就能让这些工具能够非常顺利地调用，说明 MCP Server 可用性非常好。实际上，我在写代码时，也会

4. 观测能力

从云原生到 AI 原生，让我印象深刻的是观测能力。没有良好的观测性，算不上是一个成熟度很高的系统。

云原生时代，各种观测项目层出不穷，创业公司也很多。AI 原生时代也会有，langfuse 出来不久就被收购，可见观测能力在 AI 时代依然重要。

谁都不愿意自己的任务跑在黑盒中，有异常无法发现，有流量无法观测，这对工程团队来说是无法接受的。

ops-mcp-server 提供了丰富的观测能力，包括:

• 基础资源使用
• tool 调用情况

5. 总结

MCP 并不能迅速提升 AI Agent 的能力，可能还会因为开发 MCP Server 延迟了 AI Agent 能力的开发。

但是，MCP 给了我们更多试错，更多尝试的机会。我们可以将 MCP 直接接入已有的超级智能体进行测试，也可以基于 MCP 快速开发多个 AI Agent 进行对比或者用在不同场景。

本篇主要介绍的是我对 MCP 的一些理解和思考，主要内容包括:

• MCP 提供了统一的能力调用标准，让开发者们可以更加专注于业务逻辑的实现
• 介绍 ops-mcp-server 提供的 Events、Metrics、Logs、Traces、SOPS 等能力
• 设计 MCP Server 时，需要注意的事项
• 观测能力的重要性