Skill 里能连数据库/调 API，是否可以取代 MCP？
结论先说
技术上可以，但不能取代 MCP。 Skill 里塞连接代码是「土办法」，MCP 才是标准化、平台托管、安全可复用的正规方式。
一、Skill 直接调 API/连数据库的三大硬伤
1. 密钥和认证是个大问题
Skill 里写 requests.get(url, headers={"Authorization": "Bearer xxx"}) 完全能跑，但密钥怎么办？
- 硬编码到脚本里 → 一旦分享 Skill，密钥就泄露
- 让用户每次手动传入 → 体验差，还会污染对话记录
MCP 的做法：密钥由平台托管，Skill 代码本身永远看不到、碰不到真实凭证，Claude 只是「被允许」调用。
2. 静态说明书 vs 动态自描述
- Skill：Claude 只能靠 Skill 文档里写死的说明知道接口参数和返回。API 更新了、加了新功能，文档不同步就用不上。
- MCP：服务端实时告诉 Claude「我现在有哪些工具、参数长什么样」，动态双向通信，不需要人工同步文档。
3. 网络沙箱是硬墙
Claude 执行环境的网络访问是白名单机制。你的 API 域名不在白名单里，Skill 里的代码直接被拦截（x-deny-reason）。
MCP 走的是平台专门开的通道，不受沙箱限制。
4. 复用性差
Skill 里写的连接代码只属于这个 Skill，别的场景用不了。MCP 连接一次是账号级别的，所有场景通用，不用重复造轮子。
二、「我加了网关统一鉴权，是不是就够了？」
网关 + userid 换 token 这套很成熟，能解决密钥硬编码，但对比 MCP 还有几层问题：
1. 只解决了「认证」，没解决「标准化」
网关方案是你自己的私有协议——只有你知道怎么调、token 怎么传。换个网关实现、改个字段，所有 Skill 代码都得跟着改。
MCP 是协议层标准化：不管后端什么语言、什么实现，Claude 都用同一种方式发现工具、调用工具。
2. userid 和 token 谁来触发？
- Skill 里用固定 userid/密钥换 token → 那个固定凭证还是得存某处，本质没变，只是换层皮
- 用户当场 OAuth 授权 → 这本来就是 MCP 的标准做法（用户登录 → 平台托管 token → 自动带上），你等于在每个 Skill 里重造 MCP
3. 网络沙箱依然是硬限制
网关鉴权做得再好，域名不在白名单里就是连不上，与鉴权设计无关。
三、什么时候用哪种？
| 场景 | 建议方式 |
|---|---|
| 公开、无需认证、不敏感的接口（查天气、单位换算） | Skill 里直接写代码，没问题 |
| 需要认证、涉及私人数据（邮箱、日历、公司系统、CRM、数据库） | 用 MCP，别在 Skill 里硬塞 |
| 需要动态发现工具、跨对话/跨场景复用 | 用 MCP |
| 一次性、临时性、只在这个 Skill 里用的调用 | Skill 内脚本可以 |
一句话终极总结
Skill 里塞连接代码，像是自己焊根电线偷偷接到邻居家电表——能用，但违规、不安全、随时会断。
MCP 则是正经找电力公司拉了一条有合同、有电表、随时可查用量的线路——标准化、平台托管、安全且可复用。
能用，但不是一回事。