Agent•3 天前•阿新聊ai

数据库、监控和设计系统：高价值 MCP 场景

数据库、监控和设计系统：高价值 MCP 场景 TL;DR： GitHub MCP 建立基础后，高价值的下一步是接入那些减少"信息搬运瓶颈"的系统。每个场景有不同的权限模型、Token 消耗特征和风险等级。引入顺序应该由团队的实际工作流决定，而不是技术难度。从 GitHub MCP 到多系统 MCP 的过渡在接入...

Claude Code Agent 工具链工程代理 MCP

数据库、监控和设计系统：高价值 MCP 场景

TL;DR： GitHub MCP 建立基础后，高价值的下一步是接入那些减少"信息搬运瓶颈"的系统。每个场景有不同的权限模型、Token 消耗特征和风险等级。引入顺序应该由团队的实际工作流决定，而不是技术难度。

从 GitHub MCP 到多系统 MCP 的过渡

在接入 GitHub MCP 之后，团队面临的选择是"下一步接什么"。这个决策不应该基于"哪个系统最酷"或"哪个配置最简单"，而应该基于团队的日常痛点和工作流瓶颈。

过渡的通用原则：

痛点驱动，不技术驱动。 如果团队每天花 20 分钟在 Sentry 和代码之间来回切换，那监控 MCP 的价值远大于设计系统 MCP，即使后者的技术实现更有趣。
只读优先，逐步扩展。 每个新 MCP 都从只读开始。只读权限让团队安全地探索工具的调用模式和输出特征，为后续可能需要的写权限积累经验。
一个系统稳定后再接入下一个。 不要同时接入三个新 MCP。每个新 MCP 都需要调整 token 配置、验证权限、建立使用习惯，同时接入多个会增加混乱。
记录每个 MCP 的引入原因和使用效果。 这份记录帮助团队在后续评估中做出更好的决策。如果某个 MCP 接入后使用频率很低，说明当初的痛点判断可能有误——这个信息比任何理论分析都有价值。

实际操作中，以下时间线是合理的：

第 1-4 周：GitHub MCP（只读）
  → 建立 MCP 使用习惯，验证权限模型

第 5-8 周：监控或数据库 MCP（只读）
  → 根据团队痛点选择
  → 后端团队优先数据库，全栈团队优先监控

第 9-12 周：项目管理 MCP（只读）
  → 建立跨系统的信息关联
  → GitHub issue ↔ Linear task 的映射

第 13 周起：按需扩展
  → 设计系统、文档系统
  → 或对已有 MCP 升级写权限（基于真实需求）

场景评估框架

在决定接入哪个 MCP 之前，用这个框架量化每个场景的价值和风险：

价值维度：
  V1: 该系统多久需要被 AI 访问一次？（每天 1 次以下 = 低，1-3 次 = 中，3 次以上 = 高）
  V2: 人工搬运该系统信息的耗时？（&#x3C; 2 分钟 = 低，2-5 分钟 = 中，> 5 分钟 = 高）
  V3: 该信息对工程判断的影响程度？（辅助 = 低，重要 = 中，关键 = 高）

风险维度：
  R1: 该系统是否涉及生产数据？（否 = 低，只读副本 = 中，生产主库 = 高）
  R2: 误操作的后果可逆性？（完全可逆 = 低，部分可逆 = 中，不可逆 = 高）
  R3: 数据敏感度？（公开 = 低，内部 = 中，敏感/合规 = 高）

综合评分：V1 + V2 + V3 - R1 - R2 - R3
  高价值低风险：≥ 5，优先接入
  中等价值可控风险：3-4，谨慎接入
  低价值或高风险：≤ 2，暂缓或拒绝

用这个框架评估五个场景：

场景	V1	V2	V3	R1	R2	R3	综合	推荐顺序
监控（Sentry/Datadog）	中	高	高	低	低	中	5	第一
数据库（schema + 只读查询）	高	高	高	中	低	中	6	第二
项目管理（Linear/Jira）	中	中	中	低	低	低	4	第三
设计系统（Figma）	低	中	中	低	低	低	3	第四
文档（Notion/Confluence）	低	中	中	低	低	低	3	第五

排序结果和直觉一致：监控和数据库对工程判断影响最大，项目管理次之，设计和文档是锦上添花。

场景间协作的真实案例

单个 MCP 场景的价值是有限的。真正的效率提升发生在多个 MCP 协作时。以下是一个真实的协作案例，展示监控 + 数据库 + GitHub 三个 MCP 如何配合完成一次完整的线上问题排查。

协作流程：支付失败排查

触发：Sentry 报告支付接口 500 错误

Step 1：监控 MCP（Sentry）
  → 获取错误详情：NullPointerException in PaymentService.process()
  → 获取 stack trace：定位到 PaymentService.java:142
  → 获取受影响用户数：过去 1 小时 47 笔交易失败
  → 获取错误趋势：错误从 14:30 开始，之前为零

Step 2：GitHub MCP
  → search_code("PaymentService") → 找到源文件
  → list_commits(since="2024-01-15T14:00:00") → 查找 14:00 后的提交
  → 发现：14:15 有一个提交修改了 PaymentService 的退款逻辑

Step 3：数据库 MCP（只读副本）
  → EXPLAIN SELECT * FROM payments WHERE status = 'failed' AND created_at > '2024-01-15 14:30:00'
  → 查询失败订单的数据特征
  → 发现：失败的都是"分期付款"类型，普通支付不受影响

Step 4：AI 综合分析
  → 时间线：14:15 代码变更 → 14:30 错误开始 → 强相关
  → 代码变更：修改了退款逻辑，但影响到了正常支付流程
  → 数据特征：只有分期付款受影响 → 提示可能是条件分支错误
  → 输出根因假设和修复建议

这个案例的关键是：如果只有监控 MCP，AI 只能看到错误但不能关联到代码变更；如果只有 GitHub MCP，AI 只能看到代码但不能了解实际影响范围；如果只有数据库 MCP，AI 只能看到数据异常但不能定位原因。三个 MCP 协作，才能在几分钟内完成从前需要 30-60 分钟的手动排查。

协作模式的 Token 消耗

支付排查案例的 Token 消耗：
  Step 1（Sentry MCP）：输入 ~3000 tokens，输出 ~1500 tokens
  Step 2（GitHub MCP）：输入 ~2000 tokens，输出 ~1000 tokens
  Step 3（数据库 MCP）：输入 ~1000 tokens，输出 ~800 tokens
  Step 4（AI 推理）：输出 ~2000 tokens
  总计：~11300 tokens

对比手动排查的人工耗时：
  Step 1 手动：Sentry 查找 + 复制 → 5-10 分钟
  Step 2 手动：GitHub 搜索 + 翻阅提交 → 10-15 分钟
  Step 3 手动：数据库查询 + 分析 → 10-15 分钟
  Step 4 手动：综合分析 → 10-20 分钟
  总计：35-60 分钟

效率提升：从 35-60 分钟降到 3-5 分钟（包含 AI 推理时间）
Token 成本：约 0.03 美元（按 Claude Sonnet 定价）

场景一：监控系统（Sentry / Datadog）

工作流

监控 MCP 的核心价值是"从错误到代码"的快速定位。没有 MCP 时，开发者看到报警 → 打开 Sentry → 复制错误信息 → 打开 Claude Code → 粘贴 → AI 分析 → 手动查找相关代码。有了 MCP，整个过程变成一句自然语言指令。

典型任务链：
  "分析最近一个 P1 错误"
  → MCP: Sentry 获取最新 P1 issue
  → MCP: 获取 stack trace 和上下文
  → MCP: GitHub 搜索相关代码文件
  → MCP: GitHub 获取最近部署记录
  → AI: 综合分析 → 给出假设和修复方向

权限矩阵

Sentry MCP 权限分级：

| 操作 | Trial | Stable | 说明 |
|------|-------|--------|------|
| 读取 issue 列表 | ✅ | ✅ | 核心功能 |
| 读取 issue 详情（stack trace、tags、context） | ✅ | ✅ | 核心功能 |
| 读取 release 信息 | ✅ | ✅ | 关联部署 |
| 搜索 issue | ✅ | ✅ | 按关键词/标签搜索 |
| 更新 issue 状态 | ❌ | ✅ | 标记为已查看 |
| 删除 issue | ❌ | ❌ | 永远不允许 |
| 修改项目配置 | ❌ | ❌ | 永远不允许 |
| 修改 alert 规则 | ❌ | ❌ | 永远不允许 |

Token 消耗和延迟特征

Sentry MCP 的 Token 消耗模型：

典型单次错误分析：
  MCP 调用次数：2-4 次
  输入 token（MCP 返回数据）：2000-5000
  - issue 元信息：~200 tokens
  - stack trace：~500-2000 tokens（取决于深度）
  - tags 和 context：~300-1000 tokens
  - breadcrumb 数据：~500-1500 tokens

  AI 分析输出：~1000-2000 tokens

  总计：~4000-9000 tokens/次

延迟：
  Sentry API 响应：200-800ms/调用
  多次调用串行执行总延迟：1-3 秒
  AI 推理时间：5-15 秒

注意：stack trace 和 breadcrumb 数据可能很长。
Sentry MCP server 应该限制返回的 frame 数量（建议 ≤ 20）
和 breadcrumb 数量（建议 ≤ 50）。

场景二：数据库（Schema 理解 + 只读查询）

工作流

数据库 MCP 的核心价值不是"让 AI 写 SQL"，而是让 AI 理解数据模型。开发者经常在实现新功能时需要理解"这张表和那张表的关系是什么"、"这个字段的实际数据分布是什么样的"。

典型任务链：
  "在 users 表和 orders 表之间实现一个新的查询"
  → MCP: 获取 users 表 schema
  → MCP: 获取 orders 表 schema
  → MCP: 获取外键关系和索引
  → AI: 理解数据模型 → 生成正确的查询代码
  → (可选) MCP: 在只读副本上 EXPLAIN 验证查询性能

权限矩阵

数据库 MCP 权限分级：

| 操作 | Trial | Stable | 说明 |
|------|-------|--------|------|
| 读取 schema（表、列、类型、约束） | ✅ | ✅ | 核心功能 |
| 读取索引和关系（外键、唯一约束） | ✅ | ✅ | 核心功能 |
| 执行 EXPLAIN | ✅ | ✅ | 查询计划分析 |
| 执行 SELECT（只读副本） | ✅ | ✅ | 数据分布理解 |
| 执行 SELECT（生产主库） | ❌ | ❌ | 永远不允许 |
| 执行 INSERT/UPDATE/DELETE | ❌ | ❌ | 永远不允许 |
| 执行 DDL（CREATE/ALTER/DROP） | ❌ | ❌ | 永远不允许 |

强制约束：
  - 连接目标：只读副本，不接主库
  - 查询超时：5 秒
  - 返回行数上限：100 行
  - 禁止的 SQL 关键字：INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, TRUNCATE

真实配置

{
  "mcpServers": {
    "postgres-read-only": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "${DB_READ_REPLICA_URL}",
        "QUERY_TIMEOUT": "5000",
        "MAX_ROWS": "100"
      }
    }
  }
}

对应的环境变量配置：

# 只读副本的连接字符串
export DB_READ_REPLICA_URL="postgresql://mcp_readonly:password@replica.internal:5432/mydb?sslmode=require"

数据库用户 mcp_readonly 的权限配置（PostgreSQL）：

-- 创建只读用户
CREATE USER mcp_readonly WITH PASSWORD 'random-secure-password';

-- 只授予连接权限
GRANT CONNECT ON DATABASE mydb TO mcp_readonly;

-- 只授予 USAGE 权限（可以查看 schema）
GRANT USAGE ON SCHEMA public TO mcp_readonly;

-- 只授予 SELECT 权限（不能修改任何数据）
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mcp_readonly;

-- 确保未来新建的表也自动授权
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO mcp_readonly;

-- 设置查询超时
ALTER USER mcp_readonly SET statement_timeout = '5000ms';

Token 消耗特征

数据库 MCP 的 Token 消耗模型：

Schema 探索（高频）：
  MCP 调用次数：2-5 次
  输入 token（schema 数据）：500-3000
  - 单表 schema：~100-300 tokens
  - 关系和索引：~200-500 tokens
  总计：~1500-5000 tokens/次

数据查询（中频）：
  MCP 调用次数：1-3 次
  输入 token（查询结果）：500-3000
  - 100 行数据：~1000-3000 tokens（取决于列数）
  总计：~1500-5000 tokens/次

关键风险：SELECT * FROM large_table
  如果不做行数限制，一次查询可能返回数千行。
  100 行数据约 1000-3000 tokens，
  10000 行数据可能达到 100000+ tokens，
  直接撑爆上下文窗口。
  → MAX_ROWS 限制是强制性的。

场景三：项目管理（Linear / Jira）

工作流

项目管理 MCP 的核心价值是"让 AI 理解任务上下文"。Issue 描述了要做什么，但任务的优先级、验收标准、关联需求和迭代归属也影响实现决策。

典型任务链：
  "实现 LINEAR-456"
  → MCP: 获取 task 详情（标题、描述、标签、优先级）
  → MCP: 获取 task 的验收标准和关联需求
  → MCP: 获取当前 sprint 的其他 task（了解上下文）
  → MCP: GitHub 搜索相关代码
  → AI: 综合理解需求和代码 → 制定实现计划

权限矩阵

Linear MCP 权限分级：

| 操作 | Trial | Stable | 说明 |
|------|-------|--------|------|
| 读取 team 和 project 信息 | ✅ | ✅ | 基础上下文 |
| 读取 issue/task 详情 | ✅ | ✅ | 核心功能 |
| 搜索 issue/task | ✅ | ✅ | 核心功能 |
| 读取 comment | ✅ | ✅ | 了解讨论上下文 |
| 创建 comment | ❌ | ✅ | AI 补充分析结果 |
| 创建/修改 task | ❌ | ❌ | 需要更严格的流程 |
| 修改 task 状态 | ❌ | ❌ | 由人工操作 |
| 删除 task | ❌ | ❌ | 永远不允许 |

和 GitHub MCP 的配合

Linear/Jira MCP 和 GitHub MCP 的配合是高价值组合：

需求到代码的完整链路：
  Linear task → 理解需求
  → GitHub search_code → 定位实现位置
  → 代码实现
  → GitHub create_pull_request → 提交修改
  → Linear comment → 更新 task 状态（人工确认后）

信息闭环：
  人工不再需要在 Linear 和 GitHub 之间手动同步信息。
  AI 可以从 Linear 获取需求，从 GitHub 获取代码上下文，
  完成实现后自动在 Linear 中补充进展说明。

场景四：设计系统（Figma）

工作流

Figma MCP 的核心价值是"设计到代码的对齐"。前端开发者经常需要在 Figma 和代码之间切换，确认组件规范、间距、颜色值、字体大小等。

典型任务链：
  "实现这个组件"（附带 Figma 链接）
  → MCP: 获取 Figma 节点结构
  → MCP: 提取设计 token（颜色、间距、字体）
  → MCP: 获取组件变体信息
  → AI: 生成符合设计规范的代码

权限矩阵

Figma MCP 权限分级：

| 操作 | Trial | Stable | 说明 |
|------|-------|--------|------|
| 读取文件结构和页面列表 | ✅ | ✅ | 基础导航 |
| 读取节点属性（尺寸、颜色、字体） | ✅ | ✅ | 核心功能 |
| 读取组件和变体定义 | ✅ | ✅ | 组件规范 |
| 读取样式（设计 token） | ✅ | ✅ | 颜色、间距系统 |
| 导出图片 | ❌ | ✅ | 截图对比 |
| 修改设计文件 | ❌ | ❌ | 永远不允许 |
| 发布组件库 | ❌ | ❌ | 永远不允许 |

Token 消耗特征

Figma MCP 的 Token 消耗模型：

节点信息获取：
  单个组件节点：~200-500 tokens
  完整页面节点树：~5000-20000 tokens（取决于复杂度）
  设计 token（颜色 + 间距 + 字体）：~1000-5000 tokens

关键风险：
  Figma 文件的节点树可能非常深。
  一个中等复杂度的页面可能有数百个节点。
  如果 MCP server 返回完整的节点树，
  单次调用就可能消耗 10000+ tokens。

  → Figma MCP server 必须支持"按需获取"：
    不返回完整节点树，只返回指定组件的属性。

场景五：文档系统（Notion / Confluence）

工作流

文档 MCP 的核心价值是"让 AI 访问团队的决策记录和技术方案"。当开发者问"我们的 API 认证方案是什么"或"这个模块的设计文档在哪"时，AI 可以直接从文档系统搜索。

典型任务链：
  "理解我们的认证方案设计"
  → MCP: Notion 搜索"认证方案"
  → MCP: 获取匹配的页面内容
  → AI: 总结设计要点 → 结合代码实现给出分析

权限矩阵

Notion MCP 权限分级：

| 操作 | Trial | Stable | 说明 |
|------|-------|--------|------|
| 搜索页面和数据库 | ✅ | ✅ | 核心功能 |
| 读取页面内容 | ✅ | ✅ | 核心功能 |
| 读取数据库条目 | ✅ | ✅ | 查询结构化数据 |
| 创建 comment | ❌ | ✅ | AI 补充分析 |
| 创建/修改页面 | ❌ | ❌ | 由人工操作 |
| 删除页面 | ❌ | ❌ | 永远不允许 |

关键限制：Notion MCP 的 integration 只能访问
被显式授权的页面。没有授权的页面不可见。
这提供了天然的权限边界。

MCP 引入顺序决策树

你的团队最常遇到哪种信息搬运瓶颈？

A. "线上报错了，我要去 Sentry 看，再去代码里找"
   → 第一个接监控 MCP（Sentry/Datadog）

B. "我要理解数据模型才能写查询，但 schema 文档过时了"
   → 第一个接数据库 MCP（schema + 只读查询）

C. "需求在 Linear 里，但我要手动复制给 AI 才能开始工作"
   → 第一个接项目管理 MCP（Linear/Jira）

D. "设计稿和代码经常对不上，改了设计不知道代码在哪改"
   → 第一个接设计系统 MCP（Figma）

E. "技术方案散落在各处文档里，AI 不知道上下文"
   → 第一个接文档 MCP（Notion/Confluence）

如果多个场景同时存在，优先级：A > B > C > D > E
原因：错误分析的时间压力最大，数据模型的理解频率最高。

Token 消耗和延迟对比

各场景的资源消耗特征（单次典型使用）：

| 场景 | MCP 调用次数 | 输入 token | 输出 token | 总 token | API 延迟 |
|------|------------|-----------|-----------|---------|---------|
| 监控分析 | 2-4 | 2000-5000 | 1000-2000 | 4000-9000 | 1-3s |
| Schema 探索 | 2-5 | 500-3000 | 500-1500 | 1500-5000 | 0.5-2s |
| 数据查询 | 1-3 | 500-3000 | 500-1500 | 1500-5000 | 1-5s |
| 项目管理 | 1-3 | 500-2000 | 500-1500 | 1500-4000 | 0.5-2s |
| 设计系统 | 1-3 | 1000-5000 | 1000-2000 | 3000-8000 | 1-3s |
| 文档搜索 | 1-2 | 1000-5000 | 500-1500 | 2000-7000 | 1-3s |

关键观察：
  - 监控分析的 token 消耗最高（因为 stack trace 和 context 数据量大）
  - Schema 探索的 token 消耗最低（schema 信息相对紧凑）
  - 设计系统的 token 消耗波动最大（取决于返回的节点树深度）
  - 所有场景都应该有输出大小限制，防止意外的大响应撑爆上下文

失败案例：Figma MCP 输出过大消耗 40% 上下文窗口

经过

一个前端团队接入了 Figma MCP，配置为 Trial 权限（只读）。开发者让 Claude Code "分析这个页面的设计规范"。Figma MCP server 默认返回了整个页面的完整节点树，包括每个图层的位置、尺寸、样式、子节点等。

这个页面有 8 个组件，每个组件平均 15 个图层，每个图层的属性信息约 50 tokens。加上嵌套结构、变体定义和样式引用，单次 MCP 返回了约 12000 tokens 的数据。

开发者紧接着又问了一个关于颜色系统的问题。Figma MCP 返回了全局的 design token 列表，包含 120 个颜色值、40 个间距值、30 个字体样式定义——又约 8000 tokens。

两次 MCP 调用共返回 20000 tokens 的设计数据，占用了 Claude Code 200K 上下文窗口的 10%。开发者继续在同一个会话中做其他任务时，发现 AI 的响应速度明显变慢，且开始遗忘早期的对话内容——因为设计系统数据占据了大量上下文，挤压了其他信息的空间。

在更极端的案例中，一个开发者请求了整个设计文件的分析。Figma 文件包含 20 个页面、500+ 组件，MCP 返回了约 80000 tokens 的数据，消耗了 40% 的上下文窗口。后续对话的质量急剧下降。

根因

没有输出大小限制。 Figma MCP server 没有配置单次返回的最大节点数或 token 数。
默认返回完整数据。 MCP server 的默认行为是返回请求范围内的所有数据，不做截断或摘要。
没有按需获取机制。 开发者只需要几个组件的属性，但 server 返回了整个页面的数据。
设计系统数据是"大体积低密度"信息。 大量数据中只有少部分对当前任务有用，但 AI 无法在获取前判断哪些有用。

修复

1. 配置 Figma MCP server 的输出限制：
   - 单次返回最大节点数：50
   - 单次返回最大 token 数：5000
   - 超过限制时返回摘要 + "需要更多细节时请求特定组件"

2. 改变交互模式：
   - 不要请求"分析整个页面"
   - 请求"获取 [组件名] 的属性"
   - 按组件粒度获取，而不是按页面粒度

3. 在 Skill 中固化最佳实践：
   创建一个 design-to-code Skill，明确步骤：
   Step 1: 获取组件列表（只返回名称和 ID，约 200 tokens）
   Step 2: 根据任务选择需要的组件
   Step 3: 只获取选中组件的属性
   Step 4: 如需 design token，单独请求且限定范围

修复后的交互对比：

修复前：
  用户："分析这个页面的设计规范"
  MCP 返回：整个页面节点树，12000 tokens
  有效信息占比：~20%

修复后：
  用户："分析这个页面的设计规范"
  Skill Step 1: 获取组件列表 → 200 tokens
  Skill Step 2: AI 识别需要的组件
  Skill Step 3: 获取 3 个相关组件属性 → 1500 tokens
  总计：1700 tokens，有效信息占比：~80%
  Token 节省：86%

场景六：内部 API 文档（OpenAPI / Swagger）

工作流

后端团队维护的 API 文档经常和实际实现不同步。开发者问"这个接口返回什么格式"时，要么去读代码，要么去过时的 Swagger UI。API 文档 MCP 的核心价值是"让 AI 直接读取最新的接口契约"。

典型任务链：
  "调用 user-service 的获取用户列表接口需要什么参数？"
  → MCP: 从 OpenAPI spec 搜索 /users 端点
  → MCP: 获取请求参数、响应格式、认证要求
  → AI: 生成符合规范的客户端调用代码

权限矩阵

OpenAPI MCP 权限分级：

| 操作 | Trial | Stable | 说明 |
|------|-------|--------|------|
| 读取 API 规范列表 | ✅ | ✅ | 查看所有注册的 spec |
| 读取端点详情 | ✅ | ✅ | 参数、响应、示例 |
| 搜索端点 | ✅ | ✅ | 按关键词/路径搜索 |
| 读取 schema 定义 | ✅ | ✅ | 数据模型详情 |
| 调用 API | ❌ | ❌ | 永远不允许（用专用工具） |
| 修改 API 规范 | ❌ | ❌ | 永远不允许 |

关键限制：
  - 只读取 spec 文件，不执行任何 API 调用
  - spec 来源应该是 CI 构建产物，不是手动维护的文件
  - 确保 spec 文件不包含敏感的认证信息

真实配置

{
  "mcpServers": {
    "api-docs": {
      "command": "node",
      "args": ["./mcp-servers/openapi-reader/index.js"],
      "env": {
        "SPEC_ROOT": "${API_SPEC_ROOT}",
        "MAX_ENDPOINTS": "500",
        "MAX_SCHEMA_DEPTH": "5"
      }
    }
  }
}

Token 消耗特征

API 文档 MCP 的 Token 消耗模型：

单端点查询（高频）：
  MCP 调用次数：1-2 次
  输入 token：200-800
  - 端点元信息：~100 tokens
  - 参数列表：~100-500 tokens（取决于参数数量）
  - 响应 schema：~100-300 tokens
  总计：~400-1600 tokens/次

多端点对比（中频）：
  MCP 调用次数：3-6 次
  输入 token：1000-3000
  总计：~1500-4500 tokens/次

关键风险：
  大型 API 可能有数百个端点。
  如果不做端点数量限制，一次搜索可能返回过多结果。
  MAX_ENDPOINTS=500 是合理的上限。
  Schema 深度也需要限制——嵌套过深的 schema 会消耗大量 token。

场景七：日志聚合（ELK / CloudWatch / Loki）

工作流

日志 MCP 的核心价值是"从日志到代码的快速定位"。开发者不需要离开 Claude Code 去打开 Kibana 或 CloudWatch 控制台。特别是在处理线上问题时，秒级的响应速度很重要。

典型任务链：
  "查找过去 1 小时 payment-service 的 ERROR 级别日志"
  → MCP: 查询 CloudWatch / Loki 的 ERROR 日志
  → MCP: 获取结构化的日志条目（时间戳、级别、消息、上下文）
  → MCP: GitHub 搜索相关代码
  → AI: 分析日志模式 → 定位可能的错误源头

权限矩阵

日志 MCP 权限分级：

| 操作 | Trial | Stable | 说明 |
|------|-------|--------|------|
| 查询日志（只读） | ✅ | ✅ | 核心功能 |
| 搜索日志（关键词） | ✅ | ✅ | 核心功能 |
| 获取日志上下文（前后行） | ✅ | ✅ | 排查辅助 |
| 聚合查询（统计） | ✅ | ✅ | 频率分析 |
| 删除日志 | ❌ | ❌ | 永远不允许 |
| 修改日志配置 | ❌ | ❌ | 永远不允许 |
| 修改 alert 规则 | ❌ | ❌ | 永远不允许 |

强制约束：
  - 查询时间范围上限：24 小时（防止全量扫描）
  - 返回条数上限：100 条
  - 禁止查询包含 PII 字段的日志（需要脱敏处理）
  - 连接目标：只读日志流，不接写入端点

真实配置

{
  "mcpServers": {
    "cloudwatch-logs": {
      "command": "node",
      "args": ["./mcp-servers/cloudwatch-logs/index.js"],
      "env": {
        "AWS_REGION": "us-east-1",
        "LOG_GROUP_PREFIX": "/ecs/",
        "MAX_QUERY_RANGE_HOURS": "24",
        "MAX_RESULTS": "100"
      }
    }
  }
}

和监控 MCP 的配合

日志 MCP 和 Sentry MCP 的配合能构建完整的"从报警到根因"链路：

完整排查链路：
  Sentry 报警 → 获取 error ID 和 stack trace
  → 日志 MCP → 查询同一时间窗口的相关日志
  → GitHub MCP → 搜索相关代码变更
  → AI 综合分析 → 给出根因假设和修复方案

信息互补：
  Sentry 提供：结构化错误信息、stack trace、影响范围
  日志提供：错误前后的上下文、请求链路、系统状态
  GitHub 提供：代码变更历史、相关 PR

场景选择决策矩阵

综合七个场景的完整对比：

场景            价值评分  风险评分  推荐顺序  适合团队类型
────────────────────────────────────────────────────────
监控(Sentry)      5        1        第一     全部
数据库(schema)     6        2        第二     后端/全栈
项目管理(Linear)   4        0        第三     全部
设计系统(Figma)    3        0        第四     前端
文档(Notion)       3        0        第五     全部
API 文档(Swagger)  4        1        第六     后端/全栈
日志(CloudWatch)   5        2        第七     后端/SRE

补充说明：
  - 后端团队：监控 > 数据库 > API 文档 > 日志 > 项目管理
  - 前端团队：监控 > 设计系统 > 项目管理 > 文档
  - 全栈团队：监控 > 数据库 > 项目管理 > API 文档
  - SRE 团队：监控 > 日志 > 数据库 > 项目管理

选择原则不变：痛点驱动，不是技术驱动。

MCP 引入的 Token 消耗预算

多 MCP 并行运行时的上下文预算分配：

200K 上下文窗口中的典型分配：

基础消耗（固定）：
  系统提示词 + CLAUDE.md + rules：~10,000 tokens
  工具定义（每个 MCP 约 500-2000 tokens）：3 个 MCP = ~3,000-6,000 tokens
  对话历史（活跃会话）：~5,000-20,000 tokens

可用于 MCP 数据的空间：~100,000-150,000 tokens

多 MCP 并行时的预算分配策略：
  - 主 MCP（任务相关）：60% 的可用空间
  - 辅助 MCP（上下文补充）：30% 的可用空间
  - 保留缓冲：10%（防止突发数据撑爆窗口）

实际操作：
  如果监控 MCP 返回了 15,000 tokens 的错误数据，
  数据库 MCP 应该限制返回的 schema 信息量，
  确保总和不超过 100,000 tokens 的软上限。

  超过软上限时，Claude Code 会触发上下文压缩（PreCompact），
  但压缩可能导致早期 MCP 返回的数据被丢弃。

交叉参考

17 MCP 心智模型：MCP 协议架构和工具定义模型的系统性介绍
18 GitHub MCP：第一个 MCP 的接入指南，权限分级策略
20 MCP + Skill：如何用 Skill 控制每个 MCP 场景的工作流和输出范围
21 MCP 风险：包括大输出攻击在内的安全威胁分析

0 条

登录后可以参与评论和讨论。

💬

还没有评论

欢迎留下第一条评论，帮助这篇内容更快形成讨论。