MCP 是什么、什么时候才该上
- 一句话说清 MCP 是什么：给 Agent 连外部系统的标准接口
- 搞懂 MCP 工具定义常驻吃 token 的代价，知道为什么不能见 server 就接
- 用决策清单判断一个需求该上 MCP、还是 Skills / CLI 就够
- 避开「一上来接五个 server 吃光上下文」「为查 git 状态上 MCP」这类坑
MCP（Model Context Protocol）是一套让 Agent 连接外部系统的标准接口。 你起一个 MCP server——连数据库的、连 GitHub 的、连你内部 API 的——Agent 通过它就能读写那个系统。听起来很强，于是很多人第一反应是「那我把能接的全接上」。结果上下文还没干活就被吃掉一大半，又慢又贵，模型还频频选错工具。
问题不在 MCP 本身，在没搞清它什么时候才该上。这一节我们把这件事讲透：MCP 解决什么、它的代价在哪、以及最关键的——什么需求值得为它常驻一个 server，什么需求 Skills 或 CLI 就够了。
这篇适合谁：听过 MCP、甚至接过几个 server，但拿不准「这个需求到底该不该上 MCP」的人。读完你会有一份决策清单，不再见 server 就接。
先看一个场景：两件事，只有一件该上 MCP
你想让 Agent 帮你干两件活：
- 甲：查一下当前 git 仓库有没有未提交的改动。
- 乙：把本周公司 Jira 上所有任务的状态拉出来，汇总成周报。
凭直觉，这俩好像都「要访问外部东西」，都该上 MCP？错。
- 甲根本不用 MCP——Agent 直接跑一句
git status就拿到了。这是个命令行就能办的本地活，为它起一个 MCP server 纯属浪费。 - 乙才是 MCP 的主场——Jira 是个真·外部系统，需要鉴权、要跨会话反复读写，让 Agent 临时跑命令够不着，这时候常驻一个连 Jira 的 MCP server 才划算。
同样是「访问外部东西」，一个用 CLI 顺手解决，一个才值得上 MCP。 分不清这条线，就会乱接一通。下面把这条线讲清楚。
原理：MCP 给访问，Skills 教用法，CLI 办本地
要判断该不该上 MCP，先把它和另外两个选项的分工摆清楚。这是一句你要记牢的口诀：MCP 给访问，Skills 教用法。
- MCP（给连接/访问）：解决「Agent 够不着某个外部系统」。它把数据库、Jira、CRM、私有 API 这类它本来访问不了的东西接进来。（Skills 和 MCP 的根本区别，给 Agent 加能力的两条路 那节讲得更全。）
- Skills（教方法）：解决「Agent 够得着、但不知道按什么规范/流程做」。写周报的格式、审 PR 的清单、回客诉的话术——都是教方法，跟接不接系统无关。
- CLI / 命令行：解决「本地、临时、跑个命令就拿到」的活。查 git 状态、读个文件、跑个测试——Agent 直接执行命令即可，不需要任何常驻接口。
三者各司其职。很多「看起来要上 MCP」的需求，拆开一看其实是后两者的活——这是省 token、保上下文清爽的关键。
代价：MCP 的工具定义是常驻的，会吃 token
为什么不能见 server 就接？因为 MCP 的工具定义是常驻上下文的。
你接一个 MCP server，它暴露的所有工具的名字、参数、说明，会一直挂在上下文里，不管你这一轮用不用得上。一套典型的五个 server 开场，光工具定义就可能吃掉好几万 token（具体数字随 server 而定，以各 server 实际定义为准）。这份成本是全程付的——哪怕这五个 server 你整轮一个都没用上。
这跟 Skills 完全是两个量级：Skill 没命中时，常驻的只是一张约百 token 的「目录卡片」；MCP 一接上，整套工具定义就赖在上下文里不走。所以「接一个 server」≠「免费多个能力」，它是有持续代价的承诺。
更糟的连锁反应：工具一多，模型选工具的准确率反而下降——几十个名字相近的工具摆面前，它容易挑错。上下文被占、速度变慢、选择变差，这就是「一上来接五个 server」的真实下场。
增量一：该不该上 MCP 决策清单
下次想接一个 MCP server，先拿这几个问题过一遍，全是「是」才上：
- 它是真·外部系统吗？（数据库、Jira、CRM、私有 API，而不是本地文件/git 这种命令行能办的）
- Agent 真的够不着吗？（不能靠跑个命令、或把数据临时喂进来就解决）
- 需要跨会话、反复读写吗？（不是一次性看一眼，而是会持续地、动态地用）
- 需要鉴权/长连接吗？（够不着的根因往往是它要登录态、要持续连接）
- 它带来的能力，值回那份常驻 token 吗？（接进来全程占着上下文，划算吗）
只要有一条是「否」，先别上 MCP，回头看看是不是 Skills 或 CLI 的活。
增量二：MCP vs Skills vs CLI 三选一
把一个需求扔进这张表，对号入座：
| 你的需求长这样 | 选它 | 为什么 |
|---|---|---|
| 够不着的外部系统，要鉴权、跨会话反复读写 | MCP | 只有常驻连接能办，值这份 token |
| 够得着，但不知道按什么规范/流程做 | Skills | 教方法，纯文本、几乎不占 token |
| 本地、临时、跑个命令就拿到 | CLI | 直接执行，零常驻成本 |
| 数据只要喂进来一次就够用 | 临时喂数据 + Skills | 不必为一次性访问常驻一个 server |
| 既够不着数据、又不会按规范做 | MCP + Skills 组合 | MCP 拉数据 + Skills 教格式，互补 |
记住表尾那行：MCP 和 Skills 经常是组合拳，不是二选一。 写周报那个例子，正解就是 MCP 把 Jira 数据接进来、Skills 教它按模板排版。
顺带一提，关于 MCP 协议本身的技术细节（消息格式、server/client 怎么通信），有独立的概念文专门讲，这里不展开，你只需先把「什么时候该上」判断对。
避坑表
| 坑 | 后果 | 怎么破 |
|---|---|---|
| 一上来接五个 server | 上下文被工具定义吃光，又慢又贵 | 按决策清单逐个审，只留真·绕不开的 |
| 为查 git 状态/读文件上 MCP | 杀鸡用牛刀，白付常驻成本 | 这类本地活交给 CLI，跑命令就行 |
| 把「教方法」的活当「接系统」硬接 | 该用 Skills 的活上了 MCP，又重又贵 | 流程/规范/清单类一律走 Skills |
| 不知道工具定义常驻 | 算不清成本，盲目堆 server | 接一个就多一份全程 token，按需上 |
| 一次性数据也常驻一个 server | 为「万一要用」付全程成本 | 一次性的数据临时喂进来，别常驻 |
| 接太多导致模型选错工具 | 准确率下降，调用乱套 | 砍到最少几个，名字别相近 |
动手挑战
- 把你最近想让 Agent 干的五件「要访问点什么」的活，逐个用决策清单过一遍，分成三堆：该上 MCP 的、Skills 够的、CLI 办的。多半你会发现真该上 MCP 的没几件。
- 找一个你已经接了 MCP server 的 Agent，数数它实际用上的工具占暴露工具的几成。如果常年只用一两个，考虑把这个 server 拆细，或干脆换成「临时喂数据」。
- 挑一件你以为「要上 MCP」的活（比如查本地某个状态），试着只用 CLI 让 Agent 跑命令办成它——亲手验证一次「不是什么活都该上 MCP」。
小结 · 你现在掌握了什么
- 你能一句话说清 MCP 是什么：给 Agent 连外部系统的标准接口，口诀是「MCP 给访问，Skills 教用法」。
- 你懂了 MCP 的代价——工具定义常驻吃 token，一套五 server 开场就吃掉好几万（具体以各 server 实际定义为准），所以见 server 就接是大忌。
- 你有了该不该上 MCP 的决策清单和 MCP / Skills / CLI 三选一判断：够不着的外部系统才上 MCP，够得着不会做走 Skills，本地临时活交 CLI，且 MCP 常和 Skills 组合。
- 你避开了最常见的两个坑：一上来接五个 server 吃光上下文、为查 git 状态这种本地活上 MCP。
下一步：Skills 和 MCP 这两条扩展路你已经都摸清了。想把整套 Agent 能力串起来看，回到 AI Agent 智能体阶梯 走完本级，或对照 三支柱路线图 看全局位置；对 Agent 本身还不熟的，先补 AI Agent 是什么。
👉 看看 AI 数字员工落地指南，或了解 数字员工搭建实战课。需要为企业落地方案，欢迎找我们聊 企业服务。