14 · MCP 集成

让 Cursor 的 AI Agent 长出”手”——连接 GitHub、数据库、Figma、Kubernetes，不只是在代码里改来改去。

01 什么是 MCP

MCP 全称 Model Context Protocol，是由 Anthropic 提出并开源的模型上下文协议。它的设计目标是：给 AI 模型一个标准化的方式去连接外部工具和数据源。

在 Cursor 的语境下，MCP 就是”Agent 的外接工具接口”。没有 MCP 的 Agent，只能在你的项目文件里读写代码、在终端里跑命令。有了 MCP，Agent 可以：

• 查询 GitHub Issue 和 PR
• 读取数据库 schema 并执行查询
• 从 Figma 获取设计稿信息
• 操作 Kubernetes 集群
• 发送 Slack 消息
• 搜索公司内部文档

关键是——这些能力不是 Cursor 内置的，而是通过一套标准协议让第三方提供。Cursor 本身不做这些集成，它只提供”插口”，任何人或组织都可以写一个 MCP Server 来扩展 Agent 的能力。

MCP vs 传统插件

如果你用过 VS Code 或 Cursor 的插件，可以把 MCP 理解成**“Agent 的插件机制”**——它不改变编辑器的 UI，而是给 AI Agent 增加了额外的能力。

02 MCP 的工作原理

架构概览

MCP 采用 客户端-服务器架构：

┌─────────────────┐
│  Cursor Agent   │  ← MCP 客户端（内置在 Cursor 中）
│  (MCP Client)   │
└────────┬────────┘
         │ JSON-RPC 协议（stdin/stdout 或 SSE）
         │
┌────────┴────────┐
│  MCP Server     │  ← 你配置的独立进程
│  (GitHub API)   │
└────────┬────────┘
         │ HTTP API
         │
┌────────┴────────┐
│   GitHub 服务器  │  ← 外部服务
└─────────────────┘

流程如下：

1. Cursor 启动时，读取 .cursor/mcp.json 配置文件
2. 根据配置启动对应的 MCP Server 进程（每个 server 是一个子进程）
3. Agent 在执行任务时，检测到需要外部工具，通过 MCP 协议调用 server
4. Server 通过 JSON-RPC 接收请求，调用实际的外部 API
5. 结果通过同一协议返回给 Agent
6. Agent 将结果整合到上下文中，继续执行任务

心智模型

MCP 就像 Agent 的”外接大脑皮层”。Agent 本身只懂代码和文本，MCP Server 是它连接真实世界的神经接口——查 Issue、读数据、发消息、操作集群，这些能力通过 MCP 协议被”接入”Agent 的思考回路。

支持的传输方式

Cursor 目前主要支持 stdio 方式——你在 mcp.json 中指定一个命令，Cursor 启动该命令作为子进程，通过 stdin/stdout 与它通信。

03 配置 .cursor/mcp.json

配置文件位置

MCP 的配置文件在项目根目录下的 .cursor/mcp.json：

你的项目/
├── .cursor/
│   ├── mcp.json          ← MCP 配置
│   ├── rules/            ← Cursor Rules
│   └── ...
├── src/
├── package.json
└── ...

如果 .cursor 目录不存在，手动创建即可。

基本结构

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-github"
      ],
      "env": {
        "GITHUB_TOKEN": "ghp_xxxxxxxxxxxxxxxx"
      }
    }
  }
}

每个 MCP Server 的配置包含三个字段：

配置多个 Server

你可以同时配置多个 MCP Server：

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "ghp_xxxxxxxxxxxxxxxx"
      }
    },
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": {
        "SLACK_BOT_TOKEN": "xoxb-xxxxxxxxxxxx",
        "SLACK_TEAM_ID": "T01234567"
      }
    },
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/you/projects"
      ]
    }
  }
}

验证配置是否生效

配置好 mcp.json 后，重启 Cursor。然后：

1. 打开 Chat 面板（Cmd+L）
2. 切到 Agent 模式
3. 输入类似”在我的 GitHub 仓库里有哪些 open issues？”
4. 如果配置正确，Agent 会调用 GitHub MCP Server 来获取数据，而不是瞎猜

你可以在 Chat 面板中看到 Agent 的工具调用日志——它会显示 “Calling MCP tool: github_list_issues” 之类的信息。

常见问题

问：配置了 MCP Server 但 Agent 报错说找不到工具？ 检查 server 命令是否能独立运行。在终端手动执行同样的命令，看是否有报错。常见原因包括：命令拼写错误、环境变量未设置、npx 包名不对。

问：MCP Server 启动失败怎么办？ 查看 Cursor 的开发者工具（Help → Toggle Developer Tools）→ Console 面板，会输出 MCP Server 的启动日志和错误信息。

04 连接外部工具

GitHub

GitHub MCP Server 是使用最广泛的 MCP 工具之一。它让 Agent 能够直接与 GitHub API 交互。

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "ghp_xxxxxxxxxxxxxxxx"
      }
    }
  }
}

你可以让 Agent 做什么：

• “列出这个仓库最近一周的 open issues”
• “帮我查看 PR #42 的 diff，并总结改动”
• “在这个 Issue 下回复，告诉作者我们正在修复”
• “搜索代码库中所有使用 deprecatedApi 的地方”
• “创建一条新的 Issue，标题为 重构用户模块，内容为详细的迁移计划”

Token 获取方式：

1. 访问 GitHub Settings → Developer settings → Personal access tokens → Fine-grained tokens
2. 选择仓库范围（repo 权限）
3. 生成 token 后复制，填入 GITHUB_TOKEN 环境变量

Slack

{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": {
        "SLACK_BOT_TOKEN": "xoxb-xxxxxxxxxxxx",
        "SLACK_TEAM_ID": "T01234567"
      }
    }
  }
}

你可以让 Agent 做什么：

• “在 #engineering 频道发一条消息：‘后端 API 已部署到 staging 环境’”
• “搜索 Slack 历史中关于 ‘数据库迁移’ 的讨论”
• “查看 #dev-alerts 频道最近的 10 条消息”
• “给我 #general 频道中所有未读的 @提及”

数据库（PostgreSQL / SQLite / MySQL）

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "postgresql://user:pass@localhost:5432/mydb"
      }
    }
  }
}

你可以让 Agent 做什么：

• “查询 users 表最近注册的 10 个用户”
• “显示 orders 表的 schema”
• “帮我写一条 SQL 查询：统计本月的订单总数和总收入”
• “检查 products 表中是否有空值的字段”

安全提醒： 数据库连接应使用只读账户而非管理员账户。除非你明确需要 Agent 执行写操作。

Figma

{
  "mcpServers": {
    "figma": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-figma"],
      "env": {
        "FIGMA_ACCESS_TOKEN": "figd_xxxxxxxxxxxxxxxx"
      }
    }
  }
}

你可以让 Agent 做什么：

• “获取设计文件中 ‘登录页’ 的组件信息”
• “这个按钮在 Figma 中的尺寸和颜色是什么？”
• “对比设计稿与当前代码实现，列出颜色差异”
• “从 Figma 设计稿中提取 CSS 变量”

Kubernetes

{
  "mcpServers": {
    "kubernetes": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-kubernetes"],
      "env": {
        "KUBECONFIG": "/path/to/kubeconfig"
      }
    }
  }
}

你可以让 Agent 做什么：

• “列出 staging 命名空间中所有异常的 Pod”
• “查看 api-server 部署最近 30 分钟的日志”
• “检查 production 命名空间中的资源使用情况”
• “给我这个 Deployment 的完整 YAML 配置”

更多 MCP Server

这些 server 只是冰山一角。MCP 生态在飞速增长，社区贡献了成百上千的 server，覆盖从 Notion、Jira、Linear 到 Stripe、Cloudflare 等各种服务。

05 Yolo 模式与自动审批

什么是 Yolo 模式

在 Cursor 的 Agent 设置中，有一个名为 Yolo Mode 的选项。开启后，Agent 不再等待你逐个确认操作——它会自动执行所有操作，包括：

• 修改文件
• 执行终端命令
• 调用 MCP 工具
• 安装依赖
• 删除文件

默认情况下，Agent 每执行一个操作前都会弹出一个确认对话框，你需要手动点击”Allow”或按快捷键确认。开启 Yolo Mode 相当于一次性批准所有操作。

在哪里开启

在 Cursor 设置中搜索 “Yolo” 或 “Auto Approve”：

Settings → Features → Agent → Yolo Mode

或在命令面板中搜索 Cursor: Toggle Yolo Mode。

Yolo 模式 + MCP = 强大但也危险

当 Yolo Mode 和 MCP Server 结合使用时，Agent 不仅能自动改代码，还能自动：

• 向 Slack 频道发消息
• 在 GitHub 上创建 Issue 和 PR
• 对数据库执行 SQL 语句
• 在 Kubernetes 集群上操作资源

这就是最大的双刃剑。

什么时候用 Yolo

最佳实践：阶梯式授权

不要简单地在”全手动确认”和”全自动执行”之间二选一。更实用的方案是阶梯式授权：

一级（低风险）：文件修改、代码搜索、终端读取命令 → 自动执行
二级（中风险）：文件删除、npm install、Git 操作 → 需要确认
三级（高风险）：数据库写入、K8s 操作、生产环境部署 → 需要确认 + 日志记录

Cursor 目前没有内置这种精细的权限分级机制，但你可以通过以下方式实现类似效果：

1. 在日常开发中用 Yolo Mode
2. 在涉及 MCP Server 的生产操作前手动关闭 Yolo
3. 或者：配置只读的 MCP Server（如数据库只用只读账户），从源头避免风险

06 上下文膨胀问题与缓解

什么是上下文膨胀

MCP 有一个非常现实的副作用：每次工具调用返回的数据都会进入 Agent 的上下文窗口。

考虑这个场景：

Agent: "查一下 GitHub 上这个仓库的所有 open issues"
  → MCP Server 返回 30 个 Issue，每个包含标题、描述、标签、评论摘要
  → 总文本量：约 15,000 tokens

Agent: "把其中与 bug 相关的 Issue 列出来"
  → 需要重新读取前面的 15,000 tokens + 之前已有的项目上下文
  → 上下文使用量激增

Agent: "把列出来的 Issue 信息更新到项目文档中"
  → 又一轮 MCP 调用 + 文件修改
  → 上下文继续膨胀

如果 Agent 的上下文窗口是 200K tokens，一次大型 MCP 调用可能消耗掉 30%-50% 的窗口。这意味着 Agent 可能在后续步骤中”忘记”前面的指令或项目上下文。

心智模型

上下文窗口就像一个办公桌。MCP 工具每次返回的数据都在桌上堆一摞文件。堆得太多，最早放上去的（你的核心需求、项目上下文）就可能被挤到桌子底下——Agent 不是故意忽略，它是真的”看不到”了。

缓解策略

策略 1：精确的提示词

不要笼统地问，而是精确地限定范围：

❌ "列出所有 open issues"
✅ "列出所有标签为 'bug' 且优先级为 'high' 的 open issues，只返回标题和链接"

❌ "查询 users 表"
✅ "查询 users 表，只返回 id, name, email 三列，限制 5 条"

越精确的提示词，MCP Server 返回的数据越少，上下文越干净。

策略 2：分步执行，而非一次完成

把大任务拆成小的、独立的步骤，每一步完成后手动清理上下文后再继续：

第 1 步："查询 users 表中最近 7 天注册的用户数量"
  → 确认结果 → 关闭这个对话

第 2 步：打开新对话
  "基于前面的结果，生成一个用户增长报告"
  → 把上一步的结果粘贴进来

这相当于手动管理上下文窗口，虽然麻烦，但质量有保障。

策略 3：利用 Rules 约束

在 .cursor/rules/ 中添加规则，限制 MCP 工具的返回值大小：

---
description: MCP tool usage rules
globs: *
---
When using MCP tools, always request minimal data:
- Limit list results to 10 items unless explicitly told otherwise
- Only request fields that are immediately needed
- Avoid fetching full descriptions when titles suffice
- Prefer filter-based queries over full-data retrieval

策略 4：关注 Token 消耗

Cursor 的计费是基于 token 的（Pro 套餐有固定额度）。每次 MCP 工具调用返回的大量数据都在消耗你的 token 配额。这不只是上下文窗口的问题，也是钱的问题。

策略 5：利用 Memory MCP Server

Memory MCP Server  可以将关键信息持久化到知识图谱中，而不是每次都在上下文中携带。Agent 可以在需要时查询记忆，而不需要把所有历史数据塞进当前上下文。

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    }
  }
}

这适合需要跨对话、跨任务保持上下文的场景（如大型项目重构）。

07 社区 MCP 服务器生态

官方 Server 仓库

Anthropic 官方维护了一个 MCP Server 集合仓库：github.com/modelcontextprotocol/servers 。这是最可靠的起点——所有官方 server 都经过验证，文档完善，示例丰富。

截至本文撰写时，官方仓库包含约 20 个 server，覆盖最常用的工具和平台。

社区生态

MCP 的社区生态正在快速扩张。以下是一些值得关注的社区 MCP Server 来源：

在这些平台上，你可以找到连接各类服务的 MCP Server：

• 项目管理：Jira、Linear、Notion、Trello、Asana
• 云服务：AWS、Cloudflare、Vercel、Supabase、DigitalOcean
• 监控：Sentry、Datadog、Grafana、PagerDuty
• AI 平台：Hugging Face、OpenAI、Replicate
• 设计：Figma、Penpot
• 通讯：Slack、Discord、Telegram
• 数据库：PostgreSQL、MySQL、SQLite、MongoDB、Redis
• DevOps：Kubernetes、Docker、Terraform、GitHub Actions

如何评估一个 MCP Server

在选择社区 MCP Server 时，建议从以下几个维度评估：

实战案例：搭建一个工作流

假设你在开发一个 Web 应用，可以配置以下 MCP Server 来覆盖完整的工作流：

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "..." }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": { "DATABASE_URL": "..." }
    },
    "sentry": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sentry"],
      "env": { "SENTRY_TOKEN": "..." }
    },
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": {
        "SLACK_BOT_TOKEN": "...",
        "SLACK_TEAM_ID": "..."
      }
    }
  }
}

然后你可以对 Agent 说一句话：

“查一下 Sentry 中最新报的那个数据库连接错误，在 GitHub 上创建一个 bug 修复 issue，查 PostgreSQL 看是不是表结构变了，然后在 Slack #dev 频道通知团队。”

这一个指令背后，Agent 自动协调了四个 MCP Server——这就是 MCP 生态的力量。

08 安全考虑

最大的风险：Agent 代表你执行操作

配置 MCP Server 时，本质上是把你各类服务的 API Token 给了 Cursor 的 Agent。Agent 在得到你授权（或 Yolo 模式下自动）的情况下，可以代表你执行任何操作。

这意味着：

• GitHub Token 如果拥有 write 权限，Agent 可以创建 Issue、回复评论、甚至 push 代码
• 数据库连接 如果拥有写权限，Agent 可以执行 DELETE、DROP TABLE 等破坏性操作
• Slack Token 如果权限范围过大，Agent 可以读取私密频道、发送消息、删除历史
• K8s Token 如果权限过高，Agent 可以删除命名空间、调整生产环境配置

攻击面分析

MCP 的引入扩展了攻击面：

传统攻击面：Cursor 编辑器进程本身
                  ↓
MCP 扩展后的攻击面：
          Cursor 编辑器进程
                  ↓
          MCP Server 子进程
                  ↓
          外部服务 API（GitHub、DB、K8s...）

如果：

1. 有人获得了你机器的访问权限
2. 你的 mcp.json 中直接存储了 API Token
3. 或者一个恶意的 MCP Server 窃取了环境变量

攻击者就能通过你配置的 MCP Server 接口访问所有外部服务。

安全最佳实践

原则 1：最小权限

每个 MCP Server 使用的 Token 或凭证，只赋予完成任务所需的最小权限：

❌ GitHub Token 权限：整个组织所有仓库的读写
✅ GitHub Token 权限：仅当前仓库的 Issues 读取

对于数据库，创建一个只读账户专供 MCP 使用：

CREATE USER cursor_mcp WITH PASSWORD 'secure_password';
GRANT CONNECT ON DATABASE mydb TO cursor_mcp;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO cursor_mcp;

原则 2：Token 不要明文提交

mcp.json 中的 env 字段包含敏感信息。确保：

• 将 .cursor/mcp.json 加入 .gitignore
• 不要提交包含 Token 的 mcp.json 到仓库
• 在团队中，考虑用环境变量替代硬编码

更好的方案是使用 shell 环境变量引用：

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

不过需要注意，Cursor 目前对 ${VAR} 语法支持有限，最安全的方式是在 shell profile 中设置环境变量，然后在 mcp.json 中引用。

原则 3：审计与日志

定期检查 MCP Server 的操作记录。Cursor 的聊天历史中包含了所有的 MCP 工具调用，你可以通过：

• 回顾 Chat 历史确认 Agent 做了哪些外部操作
• 查看对应服务的 API 调用日志（GitHub Audit Log、Slack Activity Log、数据库查询日志）
• 注意任何异常频繁的 API 调用或非预期的操作模式

原则 4：MCP Server 本身的安全

• 只使用开源、可审计的 MCP Server
• 优先使用 Anthropic 官方维护的 server，或社区广泛使用并经过安全审计的 server
• 避免使用来源不明的 mcp-server——它运行在你的机器上，有网络访问权限
• 定期更新 server 版本，修复已知安全漏洞

原则 5：隔离环境

如果你的项目涉及高敏感度的生产环境（如 K8s 集群、生产数据库），考虑：

• 在专用开发机上运行 Cursor，不连接生产环境
• 或：不为生产环境配置 MCP Server，只在必要时手动操作
• 或：使用专门的 MCP Server 配置，连接 staging/沙箱环境而非生产环境

回顾检查清单

每次配置一个新的 MCP Server，运行以下检查清单：

□ 这个 Token 的权限范围是否最小？（能否缩小？）
□ 这个 MCP Server 的代码是否开源可审计？
□ Token 是否以安全方式存储？（不在明文仓库中）
□ 如果使用 Yolo Mode，是否有不可逆的风险？
□ 是否有只读模式可用？（数据库查询、GitHub 只读 Token）
□ 生产环境和开发环境是否隔离？
□ 是否有日志或审计手段追踪 MCP 操作？

09 小结

关键心智模型

MCP 让 Agent 从”只能改代码”进化到”能连接世界”。每一台 MCP Server 都是 Agent 多长出的一只手。但手越多，越需要你（开发者）把控方向和安全边界。

一句话总结

MCP 的本质是把 Agent 的能力边界从”文件系统+终端”扩展到了”整个互联网服务”——配置得当，Agent 能自动完成从查 Bug、建 Issue、查数据库到发通知的全流程；配置不当，一次 Prompt 就能造成不可逆的生产事故。能力越大，责任越大。

下一篇：15 Composer 高级技巧 —— 解锁 Agent 的完全体形态，掌握多文件协作的终极工作流。