浏览 MCP与Skills教程与资源
MCP、Skills、工具和提示词有什么区别：从一次调用看清职责
同样是让 AI 完成工作，MCP 解决能力怎样接入，Skill 组织什么时候用、按什么步骤用。把连接、工具、上下文和工作方法分开，才知道该装什么、故障该查哪里。
写了一份详细提示词，为什么 AI 仍然读不到仓库？
假设你希望 AI 每周整理一次发布摘要：找到最近一次发布、读取变更、筛出影响现有用户的项目，再按统一格式输出。这里至少有两个独立问题：它能不能读取仓库，以及它知道该怎样筛选和组织结果。告诉它‘去查仓库’不会凭空建立连接；接上仓库也不会自动获得团队认可的写作方法。
MCP 可以把读取仓库的能力接进应用；Skill 可以保存‘先核对版本范围、再按用户影响分类、没有证据就标待确认’的方法。如果应用原生工具已经能读仓库，Skill 完全可以复用那些工具，不必再装一个 MCP Server。只做一次且输入已贴在对话里的摘要，一条明确提示词就可能足够。
一次读取经过哪些角色，凭证又在哪一侧？
下面是一张教学关系图，示例中的仓库服务和工具名不对应某个已部署产品。Codex、Claude Code、Cursor 这类应用通常承担 Host（宿主）职责；宿主内部的 MCP Client 与具体 Server 建立连接。口语中把整个应用叫客户端可以，但排错时需要区分应用决策、协议连接和服务执行。
整理某次发布说明
用户：总结 v1.2 → v1.3 对现有用户的影响 ↓ 任务 + 可选 Skill（筛选规则、步骤、输出格式） Host：组织模型上下文、工具选择和用户审批 ↓ 内部 MCP Client 建立连接、发现工具、发送调用 MCP Server：提供 read_release_note 等能力 ↓ 使用它持有的仓库凭证或用户授权 仓库服务：按账号权限返回发布记录 ↑ 原始记录 → MCP 结果 → Host → 有来源的摘要
客户端使用的登录账号、MCP Server 使用的账号和上游仓库权限不一定相同。查不到私有仓库时，先找出真正向仓库发请求的身份。
磁盘上的 README，不会因为被读取就自动变成 MCP Resource
| 对象 | 协议里怎样出现 | 本例的区别 |
|---|---|---|
| Tool（工具） | Server 用 tools/list 暴露名称、说明和输入结构；Client 用 tools/call 传参调用。 | read_release_note(version) 是一种动作。返回值可以是文本，也可能是错误；‘read’这个名字本身不是权限控制。 |
| Resource（资源） | Server 把内容按 URI 作为可读取资源暴露，Client 通过资源接口读取。 | release://product/v1.3 可以是教学示例 URI。同一份说明也可只由 Tool 返回；真实文件存在不代表资源接口存在。 |
| Prompt（MCP 提示模板） | Server 通过协议提供可选提示模板与参数。 | 提供‘比较两次发布’模板，不等于安装一个 Skill，也不等于连接自动具备仓库写权限。 |
Server 不必同时实现三类能力。某个资源型 Server 没有工具，并不能据此认定连接失败；还要核对客户端是否支持其实际能力。
按缺少的东西选择，不按‘哪个更新’选择
| 你现在遇到的问题 | 合适的补充 | 为什么 |
|---|---|---|
| 资料已经在对话里，只做一次整理 | 提示词：目标、范围、输出示例 | 没有新的数据入口或复用需求，增加安装会徒增维护。 |
| 每次都要反复说明同一流程，输入输出可稳定判断 | Skill：触发说明、处理步骤、参考材料 | 它把可复用方法保存在可按需加载的工件里；运行仍依赖现有工具和权限。 |
| 需要查询实时系统，而宿主目前没有访问入口 | 该系统的 MCP Server，或宿主已有的官方连接器 | 先补真实数据和动作能力；不能用一份 SKILL.md 替代认证及接口实现。 |
| 所有项目操作都要遵守仓库约定 | 宿主支持的项目规则文件 | 始终适用的约定通常应随项目加载；把它藏在偶尔触发的 Skill 中可能漏用。 |
| 需要跨系统的稳定流程 | Skill + 已验证的工具/MCP | 分别测试流程是否正确、每个工具是否可用，故障才不会混在一起。 |
连接正常、调用成功、答案正确是三件事
工具能列出来，读取发布说明却返回 403
工具发现证明 Server 描述了能力，通常还不能证明上游账号有目标仓库权限。应保留调用对象和错误来源，检查发请求的身份、仓库可见性和授权范围。此时重写 Skill 没有解决权限问题。
发布说明读到了，却把 v1.2 当作最新版本
连接层可能完全正常。检查查询范围、返回记录是否包含草稿/预发布、Skill 是否要求按日期与版本核对，以及模型是否在得到原文后仍作了错误推断。需要修改的是查询和判断过程。
摘要格式正确，却没有任何工具调用记录
它可能只根据对话或旧知识作答。让它为每一条变更附原始发布链接、版本范围和证据；‘答案看起来专业’无法证明 MCP 曾执行。反过来，即使 MCP 已调用，也要检查返回内容是否支持结论。
API Key、Skill 文件和 MCP 配置各自不能证明什么
拿到 API Key 只说明你获得了一种凭证；仍需要服务地址、协议、可用操作和权限。普通 REST API 也不会因填进 mcp.json 就变成 MCP：对端必须实现客户端期待的初始化与能力调用流程，或者经过真正的适配器。
Skill 可以附带脚本，因此也可能触发执行代码；不能因为入口是 Markdown 就认定没有副作用。MCP 同样不天然代表高风险：一个仅查公开文档的 Server 和一个能发布生产版本的 Server，权限完全不同。判断应落到具体代码、工具、输入、外部账号和审批方式。
当你能够说清‘缺能力、缺数据、缺方法还是缺权限’，再选择下一篇：缺连接就读对应客户端安装；已有连接但结果不对，就查工具参数与返回证据；想复用稳定做法，再进入 Skill 创建。
资料与核对范围
资料核对日：2026-10-10。以下来源支持协议与配置说明；文中的命令、练习和预期结果不代表本站已在所有客户端和系统完成实测。