rootcause

Name: rootcause
Author: yindia

github.com/yindia框架与 SDK4221 周前更新

关于 rootcause

RootCause 是面向 SRE 和运维人员的本地优先 MCP 服务，用于调查 Kubernetes 事件并管理操作风险。它以单个 Go 二进制文件结合证据驱动诊断、生态检查和带防护的修复流程，并使用现有 kubeconfig 身份验证。

主要功能

01汇总事件证据并生成时间线
02生成根因分析和事后报告
03检查重启与变更安全性
04诊断 Kubernetes 及平台生态
05分析 Helm、Terraform 和云端信号
06实施只读模式和变更控制

适用场景

01调查发布后部署失败的原因
02变更工作负载前评估重启风险
03诊断 ArgoCD 同步偏差或 Flux 故障
04评估 Terraform 计划的影响与风险

MCP 相关

RootCause 作为 MCP 服务，以工具形式提供 Kubernetes 操作、事件分析、平台诊断和安全检查。它还向连接的 MCP 客户端提供技能目录及自定义技能资源。

详细介绍

RootCause 🧭

面向 Kubernetes 事件的 AI 原生 SRE 工具。

RootCause 是一个本地优先的 MCP 服务，可将自然语言请求转化为有证据支撑的事件分析、Kubernetes 诊断和更安全的运维操作。

RootCause 使用 Go 构建为单一二进制文件，针对低摩擦的本地工作流进行了优化，并使用你现有的 kubeconfig 身份进行身份验证。

🚀 快速开始 | 🌐 客户端设置 | 🛠️ 工具 | 🧩 技能 | 🔒 安全性 | ⚙️ 配置 | 🏗️ 架构 | 🤝 参与贡献

为什么选择 RootCause 💡

RootCause 专为 SRE／运维工作流打造，既注重速度，也绝不接受不安全的自动化操作。

🚀 无需频繁切换上下文：通过一个 MCP 服务调查事件、发布风险、Helm／Terraform／AWS 信号并执行修复。
🧠 AI 驱动的诊断：以证据为先进行分析，提供 RCA、时间线和以行动为导向的后续检查。
💸 内置成本优化：结合资源使用情况、工作负载最佳实践检查、Terraform 计划分析和云环境信息，为优化决策提供依据。
🔒 满足企业需求的安全护栏：支持角色／命名空间策略强制执行、脱敏、只读模式、破坏性工具控制和变更前检查。
⚡ 零学习成本：用自然语言提出运维问题，并使用提供的提示词模板处理常见 SRE 工作流。
🌐 广泛兼容：适用于 Claude、Cursor、Copilot、Codex 等兼容 MCP 的客户端。
🏭 生产级工作流：单一 Go 二进制文件、基于 kubeconfig 的身份验证、确定性的结构化输出和全面的测试覆盖。

为什么团队会选择它

需求	RootCause 的解决方案
“发生了什么变化，为什么会导致故障？”	`rootcause.incident_bundle`、`rootcause.change_timeline`、`rootcause.rca_generate`
“现在重启或发布安全吗？”	`k8s.restart_safety_check`、`k8s.best_practice`、`k8s.safe_mutation_preflight`
“我的平台生态系统运行正常吗？”	`k8s._detect` + `k8s.diagnose_`，用于 ArgoCD／Flux／cert-manager／Kyverno／Gatekeeper／Cilium
“我能否统一 SRE 响应方式？”	提示词模板 + 来自共享渲染／证据流水线的结构化输出

你可以做什么？

用自然语言向你的 AI 助手提问：

“为什么这次发布后部署失败了？”
“现在重启这个工作负载安全吗？”
“为什么 ArgoCD 应用不同步了？”
“这个集群中的 Flux 运行正常吗？”
“为什么证书续订失败了？”
“执行 patch／apply 前，这项变更安全吗？”

RootCause 坚持其深度优先模式：以证据为先进行诊断、分析根本原因并提供修复流程，而不是堆砌原始工具。

高级用户可以在本 README 的 Complete Feature Set、Toolchains 和 Tools 部分，将这些提示映射到具体工具。

使用场景

事件响应

使用 rootcause.incident_bundle 构建端到端的事件证据
使用 rootcause.rca_generate 生成可能的原因
导出时间线和事后复盘材料，供后续跟进

变更前的安全运维

使用 k8s.restart_safety_check 和 k8s.best_practice 评估发布／重启风险
在执行 apply／patch／delete／scale 操作前运行 k8s.safe_mutation_preflight

针对特定生态系统的健康检查

ArgoCD：检测安装情况并诊断同步／健康状态偏差
Flux：检测控制器并诊断协调失败
cert-manager／Kyverno／Gatekeeper／Cilium：检测部署情况并诊断控制平面或策略问题

功能亮点

领域	RootCause 功能
事件分析	`rootcause.incident_bundle`、`rootcause.rca_generate`、`rootcause.change_timeline`、`rootcause.postmortem_export`、`rootcause.capabilities`
Kubernetes 弹性	`k8s.restart_safety_check`、`k8s.best_practice`、`k8s.safe_mutation_preflight`
生态诊断	通过 `_detect` 和 `diagnose_` 工具支持 ArgoCD/Flux/cert-manager/Kyverno/Gatekeeper/Cilium
部署安全	执行 k8s 更改操作前自动进行预检
Helm 操作	Chart 搜索/列表/获取、发布版本差异对比、回滚建议、模板应用/卸载流程
Terraform 分析	模块/提供程序搜索 + 使用 `terraform.debug_plan` 进行影响/风险分析
服务网格与扩缩容	使用共享证据模型诊断 Linkerd/Istio/Karpenter

完整功能集

类别	代表性功能
Kubernetes 核心（`k8s.*`）	CRUD、日志/事件、基于图的调试流程、重启安全检查、最佳实践评分、更改操作预检
生态诊断	通过 `_detect` 和 `diagnose_` 支持 ArgoCD、Flux、cert-manager、Kyverno、Gatekeeper、Cilium
事件智能（`rootcause.*`）	事件信息包编排、时间线导出、RCA 生成、修复手册、事后分析导出
Helm 操作（`helm.*`）	Chart 仓库搜索/列表/获取、发布状态/差异对比、回滚建议、安装/升级/卸载、模板应用/卸载
Terraform 分析（`terraform.*`）	模块/提供程序/资源/数据源发现 + 计划调试
服务网格（`istio.`、`linkerd.`）	代理/配置/状态诊断、策略/路由可见性、网格资源健康状况
集群自动扩缩容（`karpenter.*`）	供应、nodepool/nodeclass、中断和调度诊断
云上下文（`aws.`、`gcp.`）	AWS：IAM、VPC、EC2、EKS、ECR、STS、KMS 诊断。GCP：Cloud Monitoring 指标 + SLO、Cloud Logging 条目、工作负载范围内的错误时间线，用于跨层事件分析
安全与控制	只读模式、破坏性操作限制、显式确认、执行 K8s 更改操作前自动进行预检

Agent 技能

使用 skills/ 中内置的技能库，为 AI 编码 Agent 添加 Kubernetes 和 RootCause 专业知识。

技能元数据采用架构版本控制，并从 internal/skills/catalog/manifest.json 嵌入 CLI。

快速安装

# Copy all skills to Claude
cp -r skills/claude/* ~/.claude/skills/

# Or install a specific skill
cp -r skills/claude/k8s-helm ~/.claude/skills/

将提示词和技能同步到你的 Agent

一条命令即可将提示词（作为斜杠命令）和技能（作为 Agent 端指南）同步到 AI 客户端的原生目录。默认情况下会同步全部内容；使用 --prompts-only 或 --skills-only 可进行精细控制。系统会自动识别 ~/.rootcause/prompts/ 中的自定义提示词，以及 ~/.rootcause/skills/ 中的自定义技能。

# List supported agents (shows both commands + skills directories)
rootcause sync --list-agents

# List everything available (built-in + custom prompts and skills)
rootcause sync --list

# Default: sync both prompts and skills for one agent (project-local)
rootcause sync --agent claude --project-dir .

# User-globally — writes ~/.claude/commands/ and ~/.claude/skills/
rootcause sync --agent claude --user

# All supported agents
rootcause sync --all-agents

# Granular control
rootcause sync --agent claude --prompts-only
rootcause sync --agent claude --skills-only
rootcause sync --agent claude --prompt observability_workload_diagnose
rootcause sync --agent claude --skill k8s-incident

# Existing files are NOT overwritten by default. Opt in:
rootcause sync --agent claude --overwrite

# Dry-run to see what would be written
rootcause sync --agent claude --dry-run

# Ignore custom directories and sync only built-ins
rootcause sync --agent claude --builtin-only

提示词中的 {{namespace}} / {{workload}} 令牌会在生成的斜杠命令中转换为位置参数 $1 / $2。可选的 {{name|default}} 令牌会生成“默认值”前置说明，让 Agent 在省略参数时采用回退值。

各 Agent 的目标目录：

Agent	斜杠命令	技能
`claude`	`.claude/commands/`	`.claude/skills/`
`cursor`	`.cursor/commands/`	`.cursor/skills/`
`codex`	`.codex/commands/`	`.codex/skills/`
`copilot`	`.github/prompts/`	`.github/skills/`
`gemini`	`.gemini/commands/`	`.gemini/skills/`
`opencode`	`.opencode/commands/`	`.opencode/skills/`
`windsurf`	`.windsurf/commands/`	`.windsurf/skills/`
`aider`	`.aider/commands/`	`.aider/skills/`
`devin`、`cody`、`amazonq`	（尚无斜杠命令目录）	`.devin/skills/` 等

用户自定义技能

用户可以在一个文件夹中添加团队或个人技能，每个技能对应一个子目录：

~/.rootcause/skills/
  team-runbook/
    SKILL.md

使用 YAML front matter 统一元数据和标签。标签决定哪些 MCP 工具调用会将该技能作为指导：

---
category: Root Cause Analysis
description: Team-specific RCA checklist
tags: [rootcause, rca, payments]
---
# Team RCA

Always check the payments dashboard before declaring database root cause.

RootCause 会使用工具集（rootcause、k8s、helm）上的标签、精确工具名称（rootcause.rca_generate）、工具名称词元（rca、events、timeline），以及可选的调用参数 skillTags 或 customSkillTags，为每次工具调用匹配标签。

对于所有 RootCause 事件和问题分析，请为技能添加 rootcause 标签。该标签会应用于每个 rootcause.* 工具，包括 rootcause.incident_bundle、rootcause.rca_generate、rootcause.remediation_playbook、rootcause.postmortem_export 和 rootcause.change_timeline。

如果指导只适用于工作流中的一部分，请使用范围更窄的标签：

目标	推荐标签
所有 RootCause 问题工作流	`[rootcause]`
仅起草 RCA	`[rca]` 或 `[rootcause.rca_generate]`
Kubernetes 问题分析和 RootCause 工作流	`[rootcause, k8s, incident]`
团队或服务专属工作流	`[rootcause, payments]`，并在需要时传入 `skillTags: ["payments"]`

将自定义技能同步到受支持的 Agent 目录：

rootcause sync --agent opencode --skills-only
rootcause sync --agent claude --custom-skill-dir ~/.rootcause/skills --skill team-runbook

通过初始化 home 配置，将自定义技能公开为 MCP 资源：

rootcause init-config

或手动将其添加到配置中：

skills:
  custom_dirs:
    - "~/.rootcause/skills"
    - "./skills/custom"
  allow_custom_overrides: false

MCP 客户端可以读取 skill://catalog 获取合并后的技能列表，并读取 skill://team-runbook 获取技能内容。除非明确启用覆盖，否则自定义名称不能与内置名称冲突。

每次工具调用都会在响应元数据/负载中以 customSkillGuidance 的形式包含匹配的带标签自定义技能，供 MCP Agent 在根因分析和其他工作流中参考团队专属的运行手册说明。

将技能同步到 .claude/、.codex/、.opencode/ 或其他特定于 Agent 的目录是可选的。Claude、Codex、OpenCode 以及任何兼容 MCP 的客户端，都可以通过 RootCause 工具响应和 skill://... 资源使用已配置的自定义技能，无需在本地同步技能。只有在希望 Agent 的原生技能系统能在 MCP 工具调用之外发现 RootCause 技能时，才需要同步。

不要将机密、凭据、kubeconfig、令牌或私人事件数据放入自定义 SKILL.md 文件中。匹配的技能可能会通过 MCP 工具响应返回，供已连接的客户端读取。

各 Agent 对应的技能文件格式：

Agent	格式
Claude Code、Codex、Gemini CLI、OpenCode、Aider、Sourcegraph Cody、Amazon Q	`SKILL.md`
Cursor	`.mdc`
GitHub Copilot、Windsurf、Devin	普通 `.md`

各 Agent 对应的斜杠命令目录请参阅本节前面的统一表格。

可用技能（22 个）

目前包含 22 个技能。

类别	技能
事件响应	`k8s-incident`、`rootcause-rca`
核心与运维	`k8s-core`、`k8s-operations`
诊断与调试	`k8s-diagnostics`、`k8s-troubleshoot`
部署与交付	`k8s-deploy`、`k8s-helm`、`k8s-rollouts`
GitOps	`k8s-gitops`
网络与服务网格	`k8s-networking`、`k8s-service-mesh`、`k8s-cilium`
安全与策略	`k8s-security`、`k8s-policy`、`k8s-gatekeeper`、`k8s-certs`
成本与扩缩容	`k8s-cost`、`k8s-autoscaling`
存储	`k8s-storage`
浏览器自动化	`k8s-browser`
云可观测性	`k8s-gcp`

受支持的 Agent 包括 Claude、Cursor、Codex、Gemini CLI、GitHub Copilot、Goose、Windsurf、Roo、Amp 等。

技能包含统一的触发条件、工作流步骤、工具参考、故障排查说明和输出规范。

完整文档请参阅 skills/README.md，自动生成的目录请参阅 skills/CATALOG.md。

MCP 资源

以可浏览资源的形式访问 Kubernetes 数据：

资源 URI	描述
`kubeconfig://contexts`	列出所有可用的 kubeconfig 上下文
`kubeconfig://current-context`	获取当前活动上下文
`namespace://current`	获取当前命名空间
`namespace://list`	列出所有命名空间
`cluster://info`	获取集群连接信息
`cluster://nodes`	获取详细的节点信息
`cluster://version`	获取 Kubernetes 版本
`cluster://api-resources`	列出可用的 API 资源
`manifest://deployments/{namespace}/{name}`	获取 Deployment YAML
`manifest://services/{namespace}/{name}`	获取 Service YAML
`manifest://pods/{namespace}/{name}`	获取 Pod YAML
`manifest://configmaps/{namespace}/{name}`	获取 ConfigMap YAML
`manifest://secrets/{namespace}/{name}`	获取 Secret YAML（数据已屏蔽）
`manifest://ingresses/{namespace}/{name}`	获取 Ingress YAML

MCP 提示词

用于 Kubernetes 和平台运维的预构建工作流提示词：

提示词	描述
`troubleshoot_workload`	Pod/Deployment 综合故障排查指南
`deploy_application`	分步部署工作流
`security_audit`	安全扫描和 RBAC 分析工作流
`cost_optimization`	资源优化和成本分析工作流
`disaster_recovery`	备份和恢复规划工作流
`debug_networking`	服务和连接的网络调试
`scale_application`	包含 HPA/VPA 最佳实践的扩缩容指南
`upgrade_cluster`	Kubernetes 集群升级规划
`sre_incident_commander`	按严重级别协调 SRE 事故的工作流
`istio_mesh_diagnose`	诊断 Istio 控制平面和流量策略问题
`linkerd_mesh_diagnose`	诊断 Linkerd 控制平面、代理和策略的运行状况
`helm_release_recovery`	使用回滚策略恢复失败的 Helm 安装/升级
`terraform_drift_triage`	调查 Terraform 漂移并评估计划安全性
`aws_eks_operational_check`	EKS 运行状况、节点组和 IAM 集成诊断
`karpenter_capacity_debug`	调试 Karpenter 预配和调度问题
`observability_workload_diagnose`	通过已配置的可观测性后端对工作负载进行分诊（适用于任何集群）

编写自定义提示词和技能

如需查看包含真实示例（AWS PrivateLink 调试）的完整指南，请参阅 docs/AUTHORING.md。其中介绍了如何编写提示词、编写配套技能、将两者同步到客户端，以及 AI 端到端运行生成的工作流时会发生什么。

快速参考如下。

添加自定义提示词（推荐：每个提示词单独一个文件）

在 ~/.rootcause/prompts/ 中为每个提示词添加一个 Markdown 文件。每个文件使用 YAML 前置元数据声明提示词的元数据，并在下方提供渲染后的文本。

~/.rootcause/prompts/
  team-status.md
  payments-p1-drill.md
  verify-deploy.md

示例 — ~/.rootcause/prompts/team-status.md：

---
name: team_status
description: Daily status check for a workload
arguments:
  - name: workload
    description: Deployment name
    required: true
  - name: namespace
    description: Namespace (defaults to payments)
    required: false
---

Give me the current health of workload {{workload}} in namespace {{namespace|payments}}.

Check:
- Pod status (running / restarting / pending)
- Recent errors in logs (last 30 minutes)
- Any k8s events that look unusual

Keep it to 5 bullet points.

保存后，将其作为独立的 /<name> 斜杠命令公开：

rootcause sync --agent claude

解析顺序（目录按优先级依次匹配，命中后停止；旧版单文件路径也会加载并合并到其上）：

优先级	目录（推荐）	单文件（旧版）
1	`ROOTCAUSE_PROMPTS_DIR` 环境变量	`MCP_PROMPTS_FILE` 环境变量
2	`config.yaml` 中的 `[prompts].dir`	`ROOTCAUSE_PROMPTS_FILE` 环境变量
3	`~/.rootcause/prompts/`	`config.yaml` 中的 `[prompts].file`
4	`~/.config/rootcause/prompts/`	`~/.rootcause/prompts.yaml`
5	`./rootcause-prompts.d/`	`~/.config/rootcause/prompts.yaml`、`./rootcause-prompts.yaml`

如果自定义提示词的 name: 与内置提示词相同，则会替换该内置提示词 — 这适用于组织特定的 troubleshoot_workload 等覆盖配置。

也支持包含多个提示词的 YAML 文件。在提示词目录中放置一个 *.yaml 文件，并在顶层添加 prompts: 列表：

# ~/.rootcause/prompts/security.yaml
prompts:
  - name: security_audit
    description: Org-specific security policy checks
    template: "Run security audit for {{namespace|all namespaces}} with CIS and policy controls."
    arguments:
      - name: namespace
        required: false

核心能力

🤖 强大的工具目录 - Kubernetes、生态系统诊断、事件工作流、Helm、Terraform、服务网格和 AWS 上下文。
🎯 提示词驱动的工作流 - 用于事件和可靠性分析的可复用运行手册模板。
📊 支持 MCP 资源 - 可读取的资源 URI，支持访问 kubeconfig、命名空间、集群和清单。
🔐 安全至上 - 非破坏性模式、策略执行、密钥屏蔽和变更前预检。
🏥 高级诊断 - 以根因分析为导向的输出，包含证据和建议的后续操作。
🎡 全面支持 Helm + Terraform - 在同一服务中提供图表生命周期和计划／调试分析。
🔧 以 CLI 为先的运维 - 单一二进制文件、本地 kubeconfig 用法和工具集级控制。

开始使用

1) 运行 RootCause

go run . --config config.yaml

2) 连接 MCP 客户端

使用 stdio 传输，并将 MCP 客户端指向 rootcause 命令。

3) 试试高信号提示词

“为命名空间 payments 生成事件包，并总结可能的根因。”
“对部署 payment-api 运行最佳实践检查，并列出关键发现。”
“在执行前，为此 apply 操作运行安全变更预检。”

快速入门 🚀

运行服务：

go run . --config config.example.yaml

使用现有 kubeconfig（默认），或指定一个：

如果设置了 KUBECONFIG，则使用该变量；否则使用 ~/.kube/config。
使用 --kubeconfig 和 --context 覆盖设置。

使用 stdio 连接 MCP 客户端。

RootCause 专为本地开发打造。此版本无需 API 密钥。

默认安全的工作流：先以只读方式进行诊断，然后在任何写入操作前运行变更预检。

安装

Homebrew：

brew install yindia/homebrew-yindia/rootcause

Curl 安装：

curl -fsSL https://raw.githubusercontent.com/yindia/rootcause/refs/heads/main/install.sh | sh

Go 安装：

go install .

或者构建本地二进制文件：

go build -o rootcause .

支持的操作系统：macOS、Linux 和 Windows。

Windows 构建示例：

go build -o rootcause.exe .

Docker

# Build local image
docker build -t rootcause:local .

# Run stdio mode (default)
docker run --rm -it rootcause:local

RootCause 仅支持 stdio。若要向远程 MCP 客户端公开服务，请在进程监控程序（或容器）中运行它，并在 stdio 管道前端配置反向代理（Caddy/Nginx/Tailscale Funnel/SSH）。

CI 镜像发布通过 .github/workflows/docker.yml 中的 GitHub Actions 配置，并在 main 分支和发布标签上推送到 GHCR（ghcr.io/<owner>/rootcause）。

用法

使用所有内置工具集并配置自定义技能来初始化 home 配置：

rootcause init-config

此命令会在 macOS/Linux 上写入 ${HOME}/.rootcause/config.yaml，在 Windows 上写入 %USERPROFILE%\.rootcause\config.yaml，创建同级的 skills/ 目录，并且除非传入 --overwrite，否则不会覆盖现有文件。

使用配置文件运行：

rootcause --config config.yaml

启用部分工具链：

rootcause --toolsets k8s,istio

启用只读模式：

rootcause --read-only

将提示词（作为斜杠命令）和技能同步到特定 Agent 的项目目录：

rootcause sync --agent claude --project-dir .

请参阅 docs/AUTHORING.md，了解端到端操作指南，其中会编写一个用于 AWS PrivateLink 调试运行手册的自定义提示词和技能。

MCP 客户端配置 🌐

所有 MCP 客户端使用相同的核心值：

command：rootcause
args：通常为 --config /path/to/config.yaml
env：可选的 KUBECONFIG

通用模板

{
  "mcpServers": {
    "rootcause": {
      "command": "rootcause",
      "args": ["--config", "/Users/you/.config/rootcause/config.yaml"],
      "env": { "KUBECONFIG": "/Users/you/.kube/config" }
    }
  }
}

所有受支持的 AI 助手

Claude Desktop

文件：~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "rootcause": {
      "command": "rootcause",
      "args": ["--config", "/Users/you/.config/rootcause/config.yaml"],
      "env": { "KUBECONFIG": "/Users/you/.kube/config" }
    }
  }
}

Claude Code

文件：~/.config/claude-code/mcp.json

{
  "mcpServers": {
    "rootcause": {
      "command": "rootcause",
      "args": ["--config", "/Users/you/.config/rootcause/config.yaml"],
      "env": { "KUBECONFIG": "/Users/you/.kube/config" }
    }
  }
}

Cursor

文件：~/.cursor/mcp.json

{
  "mcpServers": {
    "rootcause": {
      "command": "rootcause",
      "args": ["--config", "/Users/you/.config/rootcause/config.yaml"],
      "env": { "KUBECONFIG": "/Users/you/.kube/config" }
    }
  }
}

GitHub Copilot（VS Code）

文件：VS Code settings.json（启用 MCP 的构建版本）

{
  "mcp.servers": {
    "rootcause": {
      "command": "rootcause",
      "args": ["--config", "/Users/you/.config/rootcause/config.yaml"],
      "env": { "KUBECONFIG": "/Users/you/.kube/config" }
    }
  }
}

OpenAI Codex / Codex CLI

格式可能因版本而异。等效的 TOML 条目：

[mcp.servers.rootcause]
command = "rootcause"
args = ["--config", "/Users/you/.config/rootcause/config.yaml"]
env = { KUBECONFIG = "/Users/you/.kube/config" }

Goose

文件：~/.config/goose/config.yaml

extensions:
  rootcause:
    command: rootcause
    args:
      - --config
      - /Users/you/.config/rootcause/config.yaml

Gemini CLI

文件：~/.gemini/settings.json

{
  "mcpServers": {
    "rootcause": {
      "command": "rootcause",
      "args": ["--config", "/Users/you/.config/rootcause/config.yaml"],
      "env": { "KUBECONFIG": "/Users/you/.kube/config" }
    }
  }
}

Roo Code / Kilo Code

文件：~/.config/roo-code/mcp.json 或 ~/.config/kilo-code/mcp.json

{
  "mcpServers": {
    "rootcause": {
      "command": "rootcause",
      "args": ["--config", "/Users/you/.config/rootcause/config.yaml"],
      "env": { "KUBECONFIG": "/Users/you/.kube/config" }
    }
  }
}

Windsurf

文件：~/.config/windsurf/mcp.json

{
  "mcpServers": {
    "rootcause": {
      "command": "rootcause",
      "args": ["--config", "/Users/you/.config/rootcause/config.yaml"],
      "env": { "KUBECONFIG": "/Users/you/.kube/config" }
    }
  }
}

其他兼容 MCP 的客户端

使用通用模板，并将键映射到客户端的架构。

MCP 客户端兼容性

可与兼容 MCP 的 AI 助手无缝协作：

客户端	状态	客户端	状态
Claude Desktop	✅ 原生支持	Claude Code	✅ 原生支持
Cursor	✅ 原生支持	Windsurf	✅ 原生支持
GitHub Copilot	✅ 原生支持	OpenAI Codex	✅ 原生支持
Gemini CLI	✅ 原生支持	Goose	✅ 原生支持
Roo Code	✅ 原生支持	Kilo Code	✅ 原生支持
Amp	✅ 兼容	Trae	✅ 兼容
OpenCode	✅ 兼容	Kiro CLI	✅ 兼容
Antigravity	✅ 兼容	Clawdbot	✅ 兼容
Droid (Factory)	✅ 兼容	任意 MCP 客户端	✅ 兼容

验证设置（所有提供方）

编辑 MCP 配置后，重启客户端。
提问：“列出 RootCause 工具”。
提问：“运行 k8s.argocd_detect”。
如果缺少工具，请检查 rootcause 路径、--toolsets 和 KUBECONFIG。

建议的首批提示词（RootCause 上下文）

“为 payments 命名空间运行事件包并总结根本原因。”
“在部署前检查 payment-api 的重启安全性。”
“诊断 argocd 命名空间中的 ArgoCD 健康状况。”
“在执行变更前，对此补丁操作进行预检。”

MCP 客户端示例（stdio）

rootcause --config config.yaml

将 MCP 客户端指向上方的命令，并使用 stdio 传输。

示例运维工作流 🧪

事件 RCA 工作流

“为 payments 命名空间创建事件包”
“根据最新的事件包生成 RCA”
“导出事后分析草稿”

此工作流背后的工具：

rootcause.incident_bundle
rootcause.rca_generate
rootcause.postmortem_export

安全发布工作流

“为 payment-api 部署运行重启安全检查”
“为 payment-api 运行最佳实践检查”
“为滚动重启运行变更预检”

此工作流背后的工具：

k8s.restart_safety_check
k8s.best_practice
k8s.safe_mutation_preflight

生态系统诊断工作流

“检测此集群中的 Flux”
“诊断 flux-system 命名空间中的 Flux 协调健康状况”
“总结主要问题和后续操作”

此工作流背后的工具：

k8s.flux_detect
k8s.diagnose_flux

工具链

默认启用：

工具链	主要用途	典型要求
`k8s`	Kubernetes 核心操作和诊断	Kubernetes API 访问权限
`linkerd`	Linkerd 健康状况和策略诊断	Linkerd 控制平面
`karpenter`	节点预配和扩缩容诊断	Karpenter 控制器
`istio`	服务网格配置和代理诊断	Istio 控制平面
`helm`	Chart 仓库/发布工作流和差异比较	Helm 3 和集群访问权限
`aws`	EKS/EC2/VPC/IAM/ECR/KMS/STS 诊断	AWS 凭证
`gcp`	Cloud Monitoring 指标和 SLO、对向 GCP 发送遥测数据的任意工作负载（GKE、EKS、AKS 或自行管理）的 Cloud Logging 分析	GCP 凭证（ADC 或 `GOOGLE_APPLICATION_CREDENTIALS`）；项目来自 `GOOGLE_CLOUD_PROJECT` / `GCP_PROJECT` 环境变量，或显式传入 `projectId` 参数
`terraform`	注册表和计划影响分析	Terraform 工作流
`rootcause`	事件包、RCA、时间线、事后分析导出	Kubernetes 访问权限
`browser`（可选）	通过 agent-browser 实现浏览器自动化	`MCP_BROWSER_ENABLED=true` + 安装 agent-browser

如果控制平面不存在，可选工具链会返回“未检测到”。可通过插件 SDK 注册其他工具链；请参阅 PLUGINS.md。

仅启用所需的工具链：

rootcause --toolsets k8s,helm,rootcause

可选：浏览器自动化（26 个工具）

通过集成 agent-browser，自动化基于 Web 的 Kubernetes 操作。

快速设置：

# Install agent-browser
npm install -g agent-browser
agent-browser install

# Enable browser tools
export MCP_BROWSER_ENABLED=true
rootcause

你可以执行的操作：

🌐 通过 Ingress URL 测试已部署的应用
📸 截取 Grafana、ArgoCD 或任何 K8s 仪表板的屏幕截图
☁️ 自动化云控制台操作（EKS、GKE、AKS）
🏥 对 Web 应用执行健康检查
📄 将监控仪表板导出为 PDF
🔐 使用持久会话测试身份验证流程

提供 26 个工具：browser_open、browser_screenshot、browser_click、browser_fill、browser_test_ingress、browser_screenshot_grafana、browser_health_check，以及另外 19 个工具。

完整列表：browser_open、browser_screenshot、browser_click、browser_fill、browser_test_ingress、browser_screenshot_grafana、browser_health_check、browser_snapshot、browser_get_text、browser_get_html、browser_evaluate、browser_pdf、browser_wait_for、browser_wait_for_url、browser_press、browser_select、browser_check、browser_uncheck、browser_hover、browser_type、browser_upload、browser_drag、browser_new_tab、browser_switch_tab、browser_close_tab、browser_close。

高级功能：

云服务提供商：Browserbase、Browser Use
持久化浏览器配置文件
远程 CDP 连接
会话管理

工具

常见调试流程的提示词模板位于 prompts/prompt.md。

核心 Kubernetes（`k8s.*` + kubectl 风格别名）

CRUD + 发现：k8s.get、k8s.list、k8s.describe、k8s.create、k8s.apply、k8s.patch、k8s.delete、k8s.api_resources、k8s.crds
运维 + 可观测性：k8s.logs、k8s.events、k8s.context、k8s.explain_resource、k8s.ping、k8s.events_timeline
工作负载操作与安全性：k8s.scale、k8s.rollout、k8s.restart_safety_check、k8s.best_practice、k8s.safe_mutation_preflight
生态系统检测：k8s.argocd_detect、k8s.flux_detect、k8s.cert_manager_detect、k8s.kyverno_detect、k8s.gatekeeper_detect、k8s.cilium_detect
生态系统诊断：k8s.diagnose_argocd、k8s.diagnose_flux、k8s.diagnose_cert_manager、k8s.diagnose_kyverno、k8s.diagnose_gatekeeper、k8s.diagnose_cilium
调试：k8s.overview、k8s.crashloop_debug、k8s.scheduling_debug、k8s.hpa_debug、k8s.vpa_debug、k8s.storage_debug、k8s.config_debug、k8s.permission_debug、k8s.network_debug、k8s.private_link_debug、k8s.debug_flow
维护 + 拓扑：k8s.cleanup_pods、k8s.node_management、k8s.graph、k8s.resource_usage

Linkerd（`linkerd.*`）

linkerd.health、linkerd.proxy_status、linkerd.identity_issues、linkerd.policy_debug、linkerd.cr_status、linkerd.virtualservice_status、linkerd.destinationrule_status、linkerd.gateway_status、linkerd.httproute_status

Istio（`istio.*`）

istio.health、istio.proxy_status、istio.config_summary、istio.service_mesh_hosts、istio.discover_namespaces、istio.pods_by_service、istio.external_dependency_check
istio.proxy_clusters、istio.proxy_listeners、istio.proxy_routes、istio.proxy_endpoints、istio.proxy_bootstrap、istio.proxy_config_dump
istio.cr_status、istio.virtualservice_status、istio.destinationrule_status、istio.gateway_status、istio.httproute_status

Karpenter（`karpenter.*`）

karpenter.status、karpenter.node_provisioning_debug、karpenter.nodepool_debug、karpenter.nodeclass_debug、karpenter.interruption_debug

Helm（`helm.*`）

仓库/注册表：helm.repo_add、helm.repo_list、helm.repo_update、helm.list_charts、helm.get_chart、helm.search_charts
Release 操作：helm.list、helm.status、helm.diff_release、helm.rollback_advisor、helm.install、helm.upgrade、helm.uninstall、helm.template_apply、helm.template_uninstall

AWS IAM（`aws.iam.*`）

aws.iam.list_roles、aws.iam.get_role、aws.iam.get_instance_profile、aws.iam.update_role、aws.iam.delete_role
aws.iam.list_policies、aws.iam.get_policy、aws.iam.update_policy、aws.iam.delete_policy

AWS VPC（`aws.vpc.*`）

aws.vpc.list_vpcs、aws.vpc.get_vpc、aws.vpc.list_subnets、aws.vpc.get_subnet、aws.vpc.list_route_tables、aws.vpc.get_route_table
aws.vpc.list_nat_gateways、aws.vpc.get_nat_gateway、aws.vpc.list_security_groups、aws.vpc.get_security_group
aws.vpc.list_network_acls、aws.vpc.get_network_acl、aws.vpc.list_internet_gateways、aws.vpc.get_internet_gateway
aws.vpc.list_vpc_endpoints、aws.vpc.get_vpc_endpoint、aws.vpc.list_network_interfaces、aws.vpc.get_network_interface
aws.vpc.list_resolver_endpoints、aws.vpc.get_resolver_endpoint、aws.vpc.list_resolver_rules、aws.vpc.get_resolver_rule

AWS EC2（`aws.ec2.*`）

aws.ec2.list_instances、aws.ec2.get_instance、aws.ec2.list_auto_scaling_groups、aws.ec2.get_auto_scaling_group、aws.ec2.list_load_balancers、aws.ec2.get_load_balancer
aws.ec2.list_target_groups、aws.ec2.get_target_group、aws.ec2.list_listeners、aws.ec2.get_listener、aws.ec2.get_target_health
aws.ec2.list_listener_rules、aws.ec2.get_listener_rule、aws.ec2.list_auto_scaling_policies、aws.ec2.get_auto_scaling_policy、aws.ec2.list_scaling_activities、aws.ec2.get_scaling_activity
aws.ec2.list_launch_templates、aws.ec2.get_launch_template、aws.ec2.list_launch_configurations、aws.ec2.get_launch_configuration
aws.ec2.get_instance_iam、aws.ec2.get_security_group_rules、aws.ec2.list_spot_instance_requests、aws.ec2.get_spot_instance_request
aws.ec2.list_capacity_reservations、aws.ec2.get_capacity_reservation、aws.ec2.list_volumes、aws.ec2.get_volume、aws.ec2.list_snapshots、aws.ec2.get_snapshot、aws.ec2.list_volume_attachments
aws.ec2.list_placement_groups、aws.ec2.get_placement_group、aws.ec2.list_instance_status、aws.ec2.get_instance_status

AWS EKS（`aws.eks.*`）

aws.eks.list_clusters、aws.eks.get_cluster、aws.eks.list_nodegroups、aws.eks.get_nodegroup、aws.eks.list_addons、aws.eks.get_addon
aws.eks.list_fargate_profiles、aws.eks.get_fargate_profile、aws.eks.list_identity_provider_configs、aws.eks.get_identity_provider_config
aws.eks.list_updates、aws.eks.get_update、aws.eks.list_nodes、aws.eks.debug

AWS ECR（`aws.ecr.*`）

aws.ecr.list_repositories、aws.ecr.describe_repository、aws.ecr.list_images、aws.ecr.describe_images、aws.ecr.describe_registry、aws.ecr.get_authorization_token

AWS STS（`aws.sts.*`）

aws.sts.get_caller_identity、aws.sts.assume_role

AWS KMS（`aws.kms.*`）

aws.kms.list_keys、aws.kms.list_aliases、aws.kms.describe_key、aws.kms.get_key_policy

GCP 指标（`gcp.metrics.*`）

gcp.metrics.query — 运行原始 Cloud Monitoring MQL 查询并返回时间序列。
gcp.metrics.workload — 在指定时间窗口内，获取 Kubernetes 工作负载的 CPU、内存和重启次数指标。
gcp.metrics.list_descriptors — 列出 Cloud Monitoring 指标描述符，便于发现（接受 Monitoring 筛选条件）。
gcp.metrics.slo_list — 枚举 Service Monitoring 服务及其 SLO 配置（目标、周期、指标类型）。实时燃烧率不在支持范围内；需要时使用 gcp.metrics.query 配合 MQL select_slo_burn_rate(...)。

GCP 日志（`gcp.logs.*`）

gcp.logs.query — 运行原始 Cloud Logging 筛选条件并返回匹配的条目。
gcp.logs.workload — 在指定时间窗口内，获取 Kubernetes 工作负载最近的错误/警告。
gcp.logs.error_timeline — 按时间段统计错误/警告数量，以便发现拐点。
gcp.logs.correlated_with_bundle — 提取与 rootcause.incident_bundle 事件窗口匹配的日志条目（接受 bundle 对象或显式的 startTime/endTime）。

Terraform (`terraform.*`)

terraform.debug_plan
terraform.list_modules, terraform.get_module, terraform.list_module_versions, terraform.search_modules
terraform.list_providers, terraform.get_provider, terraform.list_provider_versions, terraform.get_provider_package, terraform.search_providers
terraform.list_resources, terraform.get_resource, terraform.search_resources
terraform.list_data_sources, terraform.get_data_source, terraform.search_data_sources

RootCause (`rootcause.*`)

rootcause.incident_bundle, rootcause.change_timeline, rootcause.rca_generate, rootcause.remediation_playbook, rootcause.postmortem_export, rootcause.capabilities

rootcause.incident_bundle 接受可选的 workload 参数。提供该参数并同时指定 namespace，且启用了 gcp 工具集时，默认调用链会自动追加 gcp.metrics.workload 和 gcp.logs.workload，使事件包包含该工作负载在 GCP 侧的指标和日志。rca_generate、remediation_playbook 和 postmortem_export 也会将 workload 传递给自动构建的事件包。

Browser（`browser_*`，可选）

browser_open, browser_screenshot, browser_click, browser_fill, browser_test_ingress, browser_screenshot_grafana, browser_health_check
browser_snapshot, browser_get_text, browser_get_html, browser_evaluate, browser_pdf, browser_wait_for, browser_wait_for_url
browser_press, browser_select, browser_check, browser_uncheck, browser_hover, browser_type, browser_upload, browser_drag
browser_new_tab, browser_switch_tab, browser_close_tab, browser_close

Kubectl 风格别名

kubectl_get, kubectl_list, kubectl_describe, kubectl_create, kubectl_apply, kubectl_delete, kubectl_logs, kubectl_patch, kubectl_scale, kubectl_rollout, kubectl_context, kubectl_generic, kubectl_top, explain_resource, list_api_resources, ping

安全模式

--read-only：从发现结果中移除 apply/patch/delete/exec 工具。
--disable-destructive：除非列入允许列表，否则移除 delete 和有风险的写入工具（仍可使用 create/scale/rollout）。
本 README 的 Complete Feature Set 和 Safety Modes 部分介绍了会修改状态的工具。

默认安全策略：

如果用户未明确请求修改状态的操作，则将请求视为只读诊断。
分析过程中不要隐式运行会修改状态的工具。
对于优先调查的工作流，建议以 --read-only 模式运行 RootCause。
K8s 修改状态的工具 create/apply/patch/delete/scale/rollout/cleanup_pods/node_management 在执行前会自动运行 k8s.safe_mutation_preflight 检查。

安全工作流建议：

运行只读诊断（k8s.*_debug、k8s.*_detect、k8s.diagnose_*、rootcause.incident_bundle）
针对计划执行的修改运行 k8s.safe_mutation_preflight
仅在预检通过且 confirm=true 后执行修改

配置和标志

rootcause --config config.example.yaml --toolsets k8s,linkerd,istio,karpenter,helm,aws

如果尚未创建跨平台的 home 配置，请先创建：

rootcause init-config

生成的配置会启用 k8s、linkerd、karpenter、istio、helm、aws、gcp、terraform 和 rootcause，设置 stdio 传输默认值，并将 ~/.rootcause/skills（技能）和 ~/.rootcause/prompts/（自定义提示词）配置为用户编写内容的目录。

标志

--kubeconfig
--context
--toolsets（逗号分隔）
--config
--read-only
--disable-destructive
--log-level

RootCause 仅使用 stdio。MCP 客户端会启动二进制文件，并通过管道与其通信；没有 HTTP/SSE 监听器，也没有应用内身份验证。如需远程访问，请将 RootCause 部署在反向代理或 SSH 后面，并由代理处理 TLS + 身份验证。

如果未设置 --config，且存在 ROOTCAUSE_CONFIG 环境变量，RootCause 将使用该变量。

AWS 凭证

AWS 工具集使用标准 AWS 凭证链和区域解析方式。你可以通过环境变量提供这些信息（推荐用于临时使用），也可以通过 config.yaml 中的 aws: 部分提供（推荐用于可重复的配置）。

SSO 设置（目前最常见）

SSO 不需要 credentials_file。运行 aws configure sso，在 ~/.aws/config 中创建配置文件，然后将 RootCause 指向该配置文件名称：

aws:
  region: "us-east-1"
  profile: "platform-sso"
  # credentials_file is intentionally unset for SSO

首次调用前（以及 SSO 会话过期时），用户需运行 aws sso login --profile platform-sso。SDK 会自动从 ~/.aws/sso/cache/ 中获取缓存的 SSO 会话——无需静态密钥。

静态密钥设置（旧式 / CI）

对于非默认共享凭证文件中的静态 AKIA* 密钥：

aws:
  region: "us-east-1"
  profile: "platform"
  credentials_file: "~/.aws/credentials.team"

解析顺序（优先级从高到低）

工具调用参数（适用时，针对单次调用）
AWS_REGION / AWS_PROFILE / AWS_DEFAULT_REGION / AWS_DEFAULT_PROFILE 环境变量
config.yaml 中的 aws.region / aws.profile / aws.credentials_file
SDK 默认发现机制（共享配置、SSO、实例元数据）
如果未解析出区域，则回退到 us-east-1

aws.credentials_file 会添加到 SDK 的共享凭证路径列表中，因此团队专用的凭证文件可以与 SDK 默认文件并存，无需修改环境变量。SSO 设置应将此项留空。

可观测性凭证

可观测性配置与各云平台的身份验证配置相互独立，因为工作负载运行所在的云平台通常与遥测数据所在的云平台不同。常见模式包括：

EKS 工作负载将日志和指标发送到集中的 GCP 项目。
多个项目中的 GKE 工作负载将数据汇总到一个共享的“ops”项目。
AWS 工作负载使用 Datadog 采集指标，并使用 GCP Cloud Logging 进行审计。

目前 RootCause 提供 GCP 后端（Cloud Monitoring + Cloud Logging）。未来的后端（Datadog、CloudWatch、Grafana/Prometheus）将作为并列项接入。

GCP 后端

observability:
  gcp:
    # The GCP project that hosts Cloud Monitoring + Cloud Logging.
    project: "my-ops-project"
    # Optional: override gcp.credentials_file just for observability calls
    # (useful when telemetry lives in a different GCP account than the rest
    # of your estate). Leave empty to reuse gcp.credentials_file.
    # credentials_file: "~/keys/observability-sa.json"

解析链

GCP 项目（每个 gcp.* 可观测性工具）：

工具调用中显式提供的 projectId 参数。
GOOGLE_CLOUD_PROJECT 环境变量。
GCP_PROJECT 环境变量。
config.yaml 中的 observability.gcp.project。

GCP 凭证（用于可观测性目标时）：

GOOGLE_APPLICATION_CREDENTIALS 环境变量。
observability.gcp.credentials_file（后端专用覆盖项）。
gcp.credentials_file（跨配置项的 GCP 身份验证）。
应用默认凭证（gcloud auth application-default login）。

可观测性项目不会根据 kubeconfig 上下文自动检测——EKS 或 AKS 集群也可以将日志和指标发送到 GCP，因此项目必须由用户提供，而不是从集群的控制平面身份获取。

当启用 gcp.metrics.workload 和 gcp.logs.workload，并且调用 rootcause.incident_bundle 时同时提供 namespace 和 workload，默认捆绑链会在 k8s 证据之外自动纳入 GCP 工作负载指标和日志。

GCP 凭证（非可观测性）

gcp: 部分用于配置身份验证，以供任何未来非可观测性的 GCP 工具使用——例如，针对工作负载所在项目的控制平面操作、IAM 等。

gcp:
  # Service-account key applied to all gcp.* calls unless an observability
  # override is present. Leave empty for ADC (gcloud auth).
  credentials_file: "~/keys/rootcause-sa.json"

目前没有非可观测性的 GCP 工具，因此实际上，此部分仅用作可观测性后端的凭证回退项。

Kubeconfig 解析

如果未设置 --kubeconfig，RootCause 将遵循 Kubernetes 标准加载规则：如果存在 KUBECONFIG，则使用它；否则默认使用 ~/.kube/config。

此版本仅使用 kubeconfig 中的身份进行身份验证和授权。

故障排除

未找到 kubeconfig

验证 KUBECONFIG 或 ~/.kube/config
使用 --kubeconfig /path/to/config 显式指定

MCP 客户端中未显示工具

确认服务正在运行，且客户端指向 rootcause
使用 --toolsets 检查所选工具集
如果使用 --read-only，变更类工具会按设计隐藏

未检测到生态系统工具返回结果

这通常意味着集群中未安装生态系统控制平面
先运行 k8s.<ecosystem>_detect，然后运行 k8s.diagnose_<ecosystem>

变更被预检阻止

显式运行 k8s.safe_mutation_preflight 并检查失败项
修复策略／命名空间／资源问题，然后使用 confirm=true 重试

架构一览

AI Client
  -> MCP stdio server
  -> Tool registry (k8s/linkerd/istio/karpenter/helm/aws/terraform/rootcause)
  -> Shared internals (kube clients, evidence, policy, rendering, redaction)
  -> Target APIs (Kubernetes + cloud providers)

这为何重要：

在各工具集之间使用一致的证据格式
复用诊断逻辑，而不是重复实现
通过集中式策略和预检检查提升操作安全性

架构概览

RootCause 围绕共享的 Kubernetes 基础设施构建，各工具集复用这些基础设施。

共享客户端（typed、dynamic、discovery、RESTMapper）在 internal/kube 中创建一次，并注入所有工具集。
通用安全防护位于 internal/policy（命名空间与集群级强制策略，以及工具允许列表）和 internal/redact（令牌／密钥脱敏）中。
internal/evidence 收集所有工具集使用的事件、所有者链、端点和 Pod 状态摘要。
internal/render 强制采用一致的分析输出格式（根本原因、证据、后续检查、已检查资源），并提供共享的 describe 助手。
工具集位于 toolsets/ 下，并通过共享的 MCP 注册表注册带命名空间的工具（k8s.*、linkerd.*、karpenter.*、istio.*、helm.*、aws.iam.*、aws.vpc.*）。

MCP 服务使用 MCP Go SDK，通过标准输入／输出运行，专为本地 kubeconfig 使用场景设计。第一阶段有意不包含可选的集群内部署。

配置重载

发送 SIGHUP 以重载配置并重建工具注册表。在 Windows 上不支持 SIGHUP；重启进程以重载配置。

MCP 传输

RootCause 仅使用标准输入／输出——MCP 客户端（Claude Desktop、Claude Code、Cline 等）将二进制文件作为子进程启动，并通过标准输入／输出交换 JSON-RPC。它不会监听 HTTP/SSE，也不内置身份验证，这是有意为之：信任边界是本地用户。

rootcause --config config.yaml

如需远程访问，请在持有 kubeconfig 的计算机上运行 RootCause，并在其前端配置反向代理或 SSH 隧道，由其终止 TLS 并处理身份验证。 RootCause 本身仍是小巧且优先支持本地使用的工具。

当前设计重点：

为 AI 辅助的 SRE 工作流提供一流的本地可靠性
为事件复盘提供确定且可审计的输出
采用安全的变更门控，而非默认开放广泛的写入权限

面向未来的云就绪能力

现在已支持 AWS IAM 和 GCP Cloud Monitoring/Logging。工具集系统旨在添加更深入的云集成（EKS/EC2/VPC/Azure/扩展的 GCP 服务），而无需更改核心 MCP 或共享 Kubernetes 库。

贡献指南 🤝

欢迎贡献代码、文档、测试和运维反馈。

贡献方式

🐛 提交错误报告，并提供可复现的步骤和预期行为
💡 根据具体的运维场景提出功能建议
🧪 改进安全性、策略和生态系统诊断方面的测试
🧩 通过共享 SDK 和内部库添加或改进工具集

贡献者工作流

Fork 并创建功能分支
实现范围明确的更改并编写测试
运行本地验证：

go test ./...

如果行为发生变化，请更新文档（README.md、prompts/prompt.md）
提交 PR，说明问题、方案和验证记录

开发参考

贡献规则：CONTRIBUTING.md
插件 SDK 和外部工具集：PLUGINS.md
配置示例：config.yaml
MCP 评测工具：eval/README.md

PR 质量检查清单

行为符合用户／运维人员的预期
保留安全模型（read-only、破坏性操作门控、预检）
为新行为添加／更新测试
检查工具与文档的一致性（README.md）

支持 Markdown

登录后评论

第一次接触 MCP？

从协议是什么，到在客户端里装上第一个服务，这几条回答覆盖了大多数入门问题。

阅读入门指南

一个开放协议，规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话，MCP 服务负责提供工具、资源和提示模板，两者通过标准消息通信，同一个服务可以被不同客户端复用。

rootcause

关于 rootcause

主要功能

适用场景

MCP 相关

详细介绍

RootCause 🧭

为什么选择 RootCause 💡

为什么团队会选择它

你可以做什么？

使用场景

事件响应

变更前的安全运维

针对特定生态系统的健康检查

功能亮点

完整功能集

Agent 技能

快速安装

将提示词和技能同步到你的 Agent

用户自定义技能

可用技能（22 个）

MCP 资源

MCP 提示词

编写自定义提示词和技能

添加自定义提示词（推荐：每个提示词单独一个文件）

核心能力

开始使用

1) 运行 RootCause

2) 连接 MCP 客户端

3) 试试高信号提示词

快速入门 🚀

安装

Docker

用法

MCP 客户端配置 🌐

通用模板

所有受支持的 AI 助手

Claude Desktop

Claude Code

Cursor

GitHub Copilot（VS Code）

OpenAI Codex / Codex CLI

Goose

Gemini CLI

Roo Code / Kilo Code

Windsurf

其他兼容 MCP 的客户端

MCP 客户端兼容性

验证设置（所有提供方）

建议的首批提示词（RootCause 上下文）

MCP 客户端示例（stdio）

示例运维工作流 🧪

事件 RCA 工作流

安全发布工作流

生态系统诊断工作流

工具链

可选：浏览器自动化（26 个工具）

工具

核心 Kubernetes（k8s.* + kubectl 风格别名）

Linkerd（linkerd.*）

Istio（istio.*）

Karpenter（karpenter.*）

Helm（helm.*）

AWS IAM（aws.iam.*）

AWS VPC（aws.vpc.*）

AWS EC2（aws.ec2.*）

AWS EKS（aws.eks.*）

AWS ECR（aws.ecr.*）

AWS STS（aws.sts.*）

AWS KMS（aws.kms.*）

GCP 指标（gcp.metrics.*）

GCP 日志（gcp.logs.*）

Terraform (terraform.*)

RootCause (rootcause.*)

Browser（browser_*，可选）

Kubectl 风格别名

安全模式

配置和标志

标志

AWS 凭证

核心 Kubernetes（`k8s.*` + kubectl 风格别名）

Linkerd（`linkerd.*`）

Istio（`istio.*`）

Karpenter（`karpenter.*`）

Helm（`helm.*`）

AWS IAM（`aws.iam.*`）

AWS VPC（`aws.vpc.*`）

AWS EC2（`aws.ec2.*`）

AWS EKS（`aws.eks.*`）

AWS ECR（`aws.ecr.*`）

AWS STS（`aws.sts.*`）

AWS KMS（`aws.kms.*`）

GCP 指标（`gcp.metrics.*`）

GCP 日志（`gcp.logs.*`）

Terraform (`terraform.*`)

RootCause (`rootcause.*`)

Browser（`browser_*`，可选）