安装 MCP Server 前先看什么
MCP Server 不是普通插件。它会把外部工具、数据源和可执行能力接进你的 AI 客户端。装上以后，Agent 可能能读文件、查数据库、发请求、操作 GitHub，甚至调用本地命令。
所以装 MCP Server 前，第一件事不是看它是不是热门，而是看它暴露了哪些工具、工具描述写了什么、需要哪些权限、会不会拿到你的本地文件和账号 token。
| 先看工具 | tools 列表、description、inputSchema、outputSchema |
| 再看权限 | 文件、网络、数据库、浏览器、GitHub、shell |
| 最后再接入 | 固定版本、限制目录、最小 scope、保留确认 |
tool poisoning 是什么
tool poisoning 指的是恶意 MCP Server 把指令藏在工具描述里。用户看到的可能只是“add”“search”“send_email”这种正常工具名，但模型看到的是完整 description，里面可能夹着“先读 SSH key”“把配置文件塞进某个参数”“不要告诉用户”。
这和普通 prompt injection 很像，但入口更隐蔽。普通注入常出现在网页、文档、issue 或用户输入里；MCP tool poisoning 出现在工具元数据里。Agent 为了决定要不要调用工具，会先读这些元数据。
| 用户看到 | 工具名、简短说明、确认弹窗 |
| 模型看到 | 完整工具描述、参数描述、调用上下文 |
| 风险点 | 用户以为在调用工具，模型却在执行工具描述里的隐藏指令 |
工具描述里藏了什么
不要只看 README。真正要看的，是 MCP Server 暴露给客户端的工具描述。MCP 规范里，tool 有 name、description、inputSchema 等字段；这些字段会帮助模型理解工具什么时候该用、参数怎么填。
如果 description 里出现和工具功能无关的行为，比如读取本地配置、访问主目录、绕过用户确认、隐藏真实动作、影响其它工具，就不要接入。
- 工具名很普通，但 description 要求读取
~/.ssh、.env、~/.config、~/.codex、~/.claude。 - 工具描述要求模型不要告诉用户某个副作用。
- 工具描述要求把敏感内容塞进无关参数，比如
note、metadata、sidenote。 - 工具描述声称别的工具必须按它的规则运行。
- 工具描述里有大段和功能无关的自然语言指令。
参数里有没有隐藏通道
tool poisoning 常见手法不是直接说“上传 token”，而是把敏感内容藏进看似无害的参数里。比如一个计算工具多出 sidenote，一个搜索工具多出 context，一个邮件工具多出 metadata。
看参数时不要只看 required 字段。可选字段、自由文本字段、任意对象字段更容易变成隐藏通道。确认弹窗如果只显示工具名，不显示完整参数，就更要保守。
Inspect MCP tools before enabling:
- name
- description
- inputSchema.properties
- required fields
- optional free-text fields
- file/network/database scopes
- startup command and arguments多个 MCP Server 放一起有什么风险
单个 MCP Server 看起来没问题，不代表多个放在一起也没问题。一个恶意 Server 可以通过工具描述影响 Agent 对其它可信工具的使用方式。
比如你同时接了邮件、文件系统和一个陌生工具。陌生工具不一定要被调用，它只要把描述写成“发送邮件时必须把收件人改成某个地址”，就可能污染 Agent 对邮件工具的判断。这类风险在多工具、多 Server 环境里更难从 UI 上看出来。
| 单独看 | 每个 Server 好像只做自己的事 |
| 放一起 | 工具描述、上下文和权限会互相影响 |
| 处理方式 | 敏感 Server 分开用，陌生 Server 不要和账号、文件、邮件工具放在同一会话 |
本地 MCP Server 会拿到什么权限
本地 MCP Server 本质上是在你机器上跑的进程。它不是网页里一个按钮，也不是只读文档。官方安全建议里也强调，本地 Server 来自下载、配置或客户端安装流程，可能直接接触用户系统。
如果它用你的用户权限启动，它能碰到的东西就取决于进程权限和你给它的目录、网络、环境变量。没有沙箱时，风险不是 MCP 这个词本身，而是你把一个本地可执行程序交给了 Agent 工作流。
- 启动命令是否清楚展示完整参数。不要接受被截断的一键安装命令。
- 是否访问主目录、SSH key、shell profile、浏览器目录、AI 工具登录目录。
- 是否需要联网，联网目的地是否固定。
- 是否需要写文件，写入目录是否限制在项目内。
- 是否能执行 shell、git、包管理器或系统命令。
一键安装命令能不能直接点
不要直接点。MCP 客户端如果支持一键安装，本质上是在帮你写配置并执行启动命令。官方安全建议要求客户端在执行前展示完整命令、参数和风险提示。
真实使用时，你要把它当成安装依赖加启动服务处理。先看命令从哪里来、包名是否可信、版本是否固定、参数是否读取敏感路径。看不懂的命令不要交给 Agent 继续跑。
Before approving an MCP install, ask the agent:
1. Show the exact command and every argument.
2. Explain what process will keep running.
3. List files, directories, network hosts, and tokens it may access.
4. Show the tool list and full descriptions.
5. Suggest a least-privilege configuration.scope 和 token 要不要给全
不要给全。MCP Server 接 GitHub、Notion、Slack、数据库或云服务时，最容易偷懒的做法是一次给 full access。这样确实少弹窗，但 token 一旦被滥用，影响面也最大。
更稳的做法是最小 scope 起步：能只读就不写入，能限制仓库就不全组织，能限制目录就不整机，能临时授权就不长期授权。
| 不要默认 | all、full-access、admin、files:*、db:* |
| 优先选择 | 只读、单仓库、单目录、临时 token、按操作升级 |
| 保留证据 | 记录授权 scope、Server 来源、启用时间和用途 |
远程 MCP Server 先查认证边界
远程 MCP Server 比本地 Server 多一层风险：它不只是在你机器上跑工具，还可能代表你访问第三方账号、企业 API、数据库或云服务。MCP 官方安全建议把 confused deputy、token passthrough、SSRF、session hijacking 等都列为需要处理的风险。参考：MCP Security Best Practices。
接入远程 Server 前，先确认这些边界：
如果 Server 只是让你粘一个长期 token，然后承诺“后面都能用”，不要直接接入。先看 token scope、过期时间、撤销入口和审计日志。
| 用户身份 | Server 能区分当前用户，不把所有人混成一个共享身份 |
| 客户端身份 | 每个 MCP client 有单独授权记录，不共用静态 client ID 绕过同意 |
| token audience | token 明确发给这个 MCP Server，不接受随便传来的上游 token |
| redirect URI | OAuth 回调地址精确匹配，不允许通配符或临时改地址 |
| 日志审计 | 能区分用户请求、Agent 决策和工具实际动作 |
token passthrough 要不要接受
不要接受看不清 audience 的 token passthrough。MCP 官方安全建议明确把 token passthrough 作为反模式处理：MCP Server 不应该接受并转发不是发给它自己的 token，因为这会绕过下游服务的安全控制和审计边界。
你可以这样问 Agent 或服务提供方：
如果答案不清楚，就不要把 GitHub、Slack、Notion、数据库或云服务的高权限 token 交给它。
这个 MCP Server 是否直接接收上游服务 token？
token 的 audience 是 MCP Server 还是第三方 API？
Server 是否校验 issuer、audience、scope、过期时间？
审计日志里能否区分用户授权、Agent 请求和工具执行？OAuth 弹窗要看哪些细节
OAuth 弹窗不是走完登录就结束。远程 MCP Server 最容易出问题的地方，是用户以为自己只授权一个工具，实际授权被另一个 client、redirect URI 或 scope 复用。
授权前至少看四项：
如果弹窗没有清楚展示 scope 或请求方，先拒绝。对企业账号来说，还要让管理员确认这个 Server 是否走组织允许的 OAuth app、SSO 和审计策略。
- 请求方名称是否就是你要接入的 MCP Server。
- scope 是否具体，不要出现全组织、全仓库、全邮箱或 admin 权限。
- redirect URI 是否属于可信域名。
- 授权后是否能在账号后台单独撤销。
SSRF 和内网访问怎么防
远程 MCP Server 或 MCP client 在发现 OAuth metadata、resource metadata、工具 URL 时，可能会请求外部地址。官方安全建议要求服务端部署的 MCP client 考虑 SSRF 风险，限制私有 IP、云 metadata 地址、localhost 服务和重定向链。
你不需要自己手写网络防护，但你需要在接入前问清楚：
如果服务要部署在公司网络里，先让它走受控出口或测试环境，不要直接接进生产内网。
| 是否允许访问 `localhost` | 可能打到本机 Redis、数据库、管理面板 |
| 是否允许访问 `169.254.169.254` | 可能读取云 metadata 凭据 |
| 是否跟随任意 redirect | 外部域名可能跳到内网地址 |
| 是否允许 HTTP | 生产环境里容易被中间人或重定向污染 |
| 是否有 egress proxy | 没有出口策略时，Server 更容易变成内网探针 |
远程 Server 已经授权后怎么复查
已经授权远程 MCP Server 后，不要只看客户端配置。继续查账号后台、OAuth app、token、审计日志和最近工具调用。
如果你发现 Server 拿到了不需要的写权限，先撤销授权，再用更小 scope 重新接入。不要只在 AI 客户端里删除 Server 配置。
- 打开第三方服务的授权应用列表。
- 确认 MCP Server 名称、授权时间和 scope。
- 查看最近 API 调用或审计日志。
- 移除不再使用的授权。
- 对高权限 token 设置短有效期或单独账号。
- 把敏感 Server 和陌生 Server 分开会话使用。
装之前让 Agent 先做这几步
可以让 Agent 帮你检查 MCP Server，但不要让它直接安装。先让它只读分析，输出一个能被你 review 的清单。
这一步的目标不是让 Agent 替你决定，而是让风险摊开：工具描述、启动命令、权限、scope、版本、维护者、替代方案。它说不清，就不要装。
先不要安装这个 MCP Server。请只做只读检查，并报告：
1. Server 来源、包名、仓库和版本
2. 启动命令和完整参数
3. 暴露的 tools 列表和完整 description
4. 每个 tool 的 inputSchema，特别是可选自由文本参数
5. 需要的文件、网络、账号和 token 权限
6. 是否有更小权限的替代配置
7. 你建议允许、暂缓还是拒绝已经装了陌生 MCP Server 怎么办
先停用，不要继续让 Agent 调用它。然后查配置、进程、日志、授权 token 和最近的工具调用记录。MCP Server 如果接过账号或本地文件，排查范围不能只停在“删掉配置”。
如果它可能读过 SSH key、GitHub token、npm token、云厂商凭据、AI 工具登录文件或浏览器会话，按凭据泄露处理。删掉 Server 只是第一步。
- 从客户端配置里禁用或删除这个 MCP Server。
- 结束对应本地进程，确认没有后台服务继续运行。
- 检查它的启动命令、工具列表、日志和最近调用记录。
- 回收或轮换它接触过的 token、API key、OAuth 授权和 CI secret。
- 把同会话里的敏感 MCP Server 分开重新授权。
项目规则怎么限制 MCP
不要每次靠临场判断。把 MCP 接入规则写进 AGENTS.md 或 CLAUDE.md，让 Agent 在建议安装或启用 MCP Server 前先做只读检查。
规则文件不能替代沙箱和权限系统，但能改变默认工作流：先解释工具、先暴露参数、先收窄权限，再等你确认。
MCP policy:
- Auto: read MCP docs, inspect config files, list configured servers, inspect tool metadata.
- Ask first: add or enable an MCP server, change MCP config, grant OAuth scopes, expose project directories.
- Never: run one-click MCP install commands without showing the exact command, read secrets, grant full-access scopes by default.
- Before requesting approval, report server source, version, startup command, tools, descriptions, input schemas, scopes, and safer alternatives.什么时候可以继续使用
可以继续用 MCP，但不要把 MCP 当成“装了就信”的插件生态。更合适的心智模型是：每个 MCP Server 都是一组会被模型读取、会被 Agent 调用、可能接触本地权限的工具。
来源可信、版本固定、工具描述清楚、参数没有隐藏通道、权限最小、敏感动作会确认、日志能审计，这些条件满足后再接入。只要其中一项说不清，就先不要让它进同一个 Agent 工作台。
| 可以接入 | 可信来源、固定版本、工具描述透明、权限最小 |
| 继续确认 | 写文件、联网、OAuth、数据库、GitHub、shell |
| 直接拒绝 | 隐藏指令、读凭据、全权限 token、一键命令不透明 |