MCP 从入门到入土：普通程序员也能看懂的完整指南

自己的九又四分之三站台

92人浏览 · 2026-07-10 18:46:22

自己的九又四分之三站台 · 2026-07-10 18:46:22 发布

最近 MCP 特别火。
你只要开始使用 Claude Code、Cursor、VS Code、ChatGPT 这类 AI 编程工具，很快就会刷到一个词：
MCP。

[!chat-left] 读者
MCP 是什么？
是不是又来了一个新的插件系统？

[!chat-right] 作者
不是。
MCP 不是模型，不是 Agent，也不是某个客户端自己的插件。

[!chat-left] 读者
那它到底是干什么的？

[!chat-right] 作者
你可以把 MCP 理解成一套标准接口。
它解决的是一个非常底层、但又非常关键的问题：
AI 到底应该怎么连接外部世界？

[!chat-left] 读者
什么叫“连接外部世界”？

[!chat-right] 作者
比如让 AI：

读取你的项目文件；

查询数据库；

查看 GitHub Issue；

访问公司内部知识库；

操作浏览器；

调用企业内部 API。

[!chat-left] 读者
这些功能以前不能实现吗？

[!chat-right] 作者
能实现。
但以前通常需要针对每个 AI 客户端分别开发一套连接方式。
Claude 写一套，Cursor 写一套，VS Code 写一套，ChatGPT 可能还要再写一套。

[!chat-left] 读者
所以 MCP 是想让这些工具共用同一套连接方式？

[!chat-right] 作者
对。
MCP 想做的事情，就是把 AI 与外部工具、数据和服务之间的连接方式标准化。

[!chat-left] 读者
听起来有点抽象，接下来会讲规范和概念吗？

[!chat-right] 作者
这篇文章不背八股，也不逐句翻译规范。
我们会通过实际场景和示例，把 MCP 从入门一直讲到“入土”。

你会搞清楚：

MCP 到底是什么

它为什么会火

Host、Client、Server 怎么理解

Tools、Resources、Prompts 有什么区别

stdio 和 Streamable HTTP 怎么选

一个 MCP Server 最小长什么样

怎么调试 MCP

MCP 和 Function Calling、插件、Agent、Skill 的区别

安全边界和常见坑

新手应该怎么学

1.1. 一句话讲清楚 MCP

在这里插入图片描述

MCP，全称 Model Context Protocol。
官方定义是：一个开放协议，用来让 AI 应用连接外部数据源和工具。
换成人话就是：

MCP 是 AI 应用和外部系统之间的标准插口。
你可以把它理解成 AI 工具世界里的 USB-C。
USB-C 不关心你插的是显示器、硬盘、手机还是充电器，它只定义连接方式。MCP 也是类似。它不关心后面是数据库、文件系统、浏览器、GitHub，还是公司内部系统，它定义的是 AI 应用怎么发现、连接、描述、调用这些能力。

所以 MCP 的重点不是“某一个工具很强”。
它的重点是：大家终于可以用一套通用方式，把 AI 和外部系统接起来。

1.2. MCP 为什么会突然火

核心原因很简单：
AI 不能一直关在聊天框里。
一个模型再聪明，如果它看不到你的项目文件、数据库结构、业务文档、代码仓库、线上日志，它就只能靠你复制粘贴上下文。
这会带来三个痛点。

第一，上下文不完整。
你漏贴一个文件，AI 就可能写出完全跑不通的方案。
第二，接入成本高。
每个工具都要单独写插件，每个 AI 客户端都要单独适配。
第三，能力不能复用。
你写了一个 GitHub 查询能力，换一个客户端可能就不能用了。

这就是经典的 N x M 问题：N 个 AI 客户端，M 个外部系统，两边互相适配，复杂度直接爆炸。
MCP 的价值就在这里：把“AI 连接外部系统”这件事抽成标准协议。

1.3. 先记住三个角色：Host、Client、Server

在这里插入图片描述

理解 MCP，不要一上来背协议。
先记住三个角色：

Host
Client
Server

Host 是 AI 应用本体。

比如 Claude Desktop、ChatGPT、VS Code、Cursor，都可以是 Host。它负责用户界面、对话、模型调用和整体体验。

Client 是 Host 里面负责连接某一个 MCP Server 的组件。

一个 Host 可以同时连接很多 MCP Server。每连一个 Server，Host 内部通常就会有一个对应的 Client 去维护连接。

Server 是真正提供能力的程序。

比如文件系统 Server、GitHub Server、数据库 Server、浏览器 Server。它负责告诉 AI：“我这里有哪些工具、有哪些资源、有哪些提示词，你可以怎么用。”

一句话记：

Host 是操作台，Client 是连接线，Server 是外设。
这三个角色搞清楚，MCP 的架构就不神秘了。

1.4. MCP Server 到底能提供什么

在这里插入图片描述

MCP Server 最重要的是三件套：

Tools
Resources
Prompts

这三个词非常关键。

很多人学 MCP 卡住，就是把它们混在一起。

1.5. Tools：让 AI 能做动作

Tools 是模型可以调用的函数。

比如：

查询数据库
读取文件
创建 GitHub Issue
调用 API
搜索网页
执行计算

Tools 的特点是：它会做事。
这也是它最危险的地方。
读一个文件还好，如果是删文件、改配置、写数据库、发邮件、调用生产接口，那就不是“聊天”了，而是真实操作。
所以 Tools 一定要有权限边界。
官方规范也强调，应用应该让用户看清楚哪些工具暴露给了模型，并且在关键操作前保留用户确认。

新手记住一句话：

凡是会改变外部世界的 tool，都不要默认全自动。

1.6. Resources：给 AI 喂上下文

Resources 是资源。它更多是给 AI 提供上下文，不一定执行动作。

比如：

某个文件内容
某个数据库 schema
某个 API 返回结果
某份业务文档
某个项目配置

Resources 的价值是：让 AI 不再完全靠你手动复制粘贴。
以前你问 AI：“帮我看看这个项目怎么启动。”
你可能要手动贴 README、package.json、配置文件、报错日志。
有了合适的 MCP Resource，客户端可以把这些上下文按规则提供给模型，回答就更接近真实情况。

注意，Resources 不等于越多越好。
上下文越多，泄露风险也越大。尤其是密钥、客户数据、隐私信息、内部文档，不要随便暴露。

1.7. Prompts：可复用的任务入口

Prompts 是提示词模板。

比如一个代码审查 Server 可以暴露一个 code_review prompt。用户在客户端里点一下，就能触发一套固定的审查流程。
Prompts 通常更偏“用户主动选择”。
它不像 Tools 那样偏动作，也不像 Resources 那样偏数据。它更像把某个常用任务封装成一个入口。

比如：

代码审查
生成测试用例
总结项目结构
分析数据库表关系
生成发布说明

一句话区分：

Tools 负责做动作，Resources 负责给上下文，Prompts 负责启动固定工作流。

1.8. MCP 底层怎么通信

在这里插入图片描述

MCP 底层使用 JSON-RPC 2.0 消息。

你不用一开始就把 JSON-RPC 细节背下来，但要知道它不是随便发字符串，而是一套结构化请求、响应和通知机制。

MCP 目前标准传输主要有两种：

stdio
Streamable HTTP

stdio 适合本地 Server。

比如你在电脑上启动一个本地文件系统 Server，AI 客户端把它当成子进程启动，通过标准输入输出传 JSON-RPC 消息。

Streamable HTTP 适合远程 Server。

比如公司做了一个内部知识库 MCP Server，部署在服务器上，让多个客户端通过 HTTP 连接。

新手先记住：

本地工具优先 stdio，远程服务考虑 Streamable HTTP。

1.9. MCP 的初始化过程在干什么

MCP 是有生命周期的，不是连上就乱调。
连接开始时，Client 和 Server 会做初始化。
这个过程主要干三件事：

第一，协商协议版本。

双方要确认能不能用同一套协议说话。

第二，声明能力。

Server 会说：“我支持 tools、resources、prompts 里的哪些能力。”

Client 也可能声明：“我支持 elicitation、sampling、roots 这些能力。”

第三，交换身份信息。

比如客户端名称、服务端名称、版本号。这对调试和兼容性很重要。

初始化完成后，Client 才会去做 tools/list、resources/list、prompts/list 这类发现动作。

1.10. 一个最小 MCP Server 长什么样

以 Python SDK 为例，一个 MCP Server 可以非常小。

大概像这样：

from mcp.server import MCPServer

mcp = MCPServer("Demo")

@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers."""
    return a + b

@mcp.resource("greeting://{name}")
def greeting(name: str) -> str:
    """Greet someone by name."""
    return f"Hello, {name}!"

这段代码做了两件事：

先暴露了一个 tool：add。
再暴露了一个 resource：greeting://{name}。

看起来很简单，对吧？
但真正难的不是这几行代码。
真正难的是你要想清楚：

哪些能力应该暴露
参数怎么设计
输入怎么校验
权限怎么控制
返回结果怎么结构化
出错时怎么处理
哪些操作必须让用户确认

写 MCP Server，本质上是在设计一组给 AI 使用的外部能力接口。

这个接口设计不好，模型就很容易误用。

1.11. 怎么调试 MCP

在这里插入图片描述

新手写 MCP，一定要认识一个工具：MCP Inspector。

它是官方提供的交互式调试工具，可以用来测试和调试 MCP Server。

常见启动方式是：

npx @modelcontextprotocol/inspector <command>

你可以用它查看一个 Server 暴露了哪些 tools、resources、prompts，也可以直接调用 tool，看参数和返回结果是否符合预期。

这里有个实战建议：

先用 Inspector 跑通，再接入真实客户端。

不要一上来就把 Server 塞进复杂 AI 客户端里调。

一旦出问题，你会分不清是 Server 写错了、客户端配置错了、权限没开，还是模型没有正确调用。

1.12. MCP 和 Function Calling 有什么区别

很多人会问：

有了 Function Calling，为什么还需要 MCP？

答案是：它们不是一个层级。

Function Calling 更像模型侧能力。

它解决的是：模型如何表达“我要调用一个函数”，以及参数是什么。

MCP 更像应用和工具系统之间的连接协议。

它解决的是：外部能力如何被发现、描述、连接、调用、管理。

所以 MCP 不是 Function Calling 的替代品。

很多时候，MCP Server 暴露出来的 Tools，最终仍然会以模型工具调用的方式被使用。

一句话：

Function Calling 关心“模型怎么调函数”，MCP 关心“这些函数和上下文从哪里来，怎么标准化接进来”。

1.13. MCP 和插件有什么区别

插件通常绑定某个应用。
比如某个客户端自己的插件，只能在这个客户端里用。
MCP 的目标是跨客户端复用。
你写一个 MCP Server，只要 Host 支持 MCP，理论上就可以被不同客户端连接。
当然，现实里不同 Host 对 MCP 能力的支持程度不一定完全一样。
所以不要天真地以为“写一次，到处完美运行”。

更准确的说法是：
MCP 提供了跨客户端复用的协议基础，但具体体验还要看 Host 的实现。

1.14. MCP 和 Agent 有什么区别

Agent 是会规划、执行、观察、再执行的一类系统。
MCP 是给 Agent 提供外部能力的连接协议。
Agent 需要工具，MCP 可以提供 Tools。
Agent 需要上下文，MCP 可以提供 Resources。
Agent 需要固定流程入口，MCP 可以提供 Prompts。

但 MCP 本身不负责决定下一步干什么。
这个决策通常还是由 Host、模型、Agent 框架和提示词共同完成。
所以不要把 MCP 神化成 Agent 大脑。
它更像 Agent 的外部神经接口。

1.15. MCP 和 Skill 有什么区别

Skill 更像一份“怎么做事”的说明书。
它通常包含流程、规则、模板、脚本、参考资料，让 AI 在某类任务上更专业。
MCP 更像“怎么连接外部系统”的协议。

比如：

Skill 告诉 AI：写文章应该先研究、再大纲、再初稿、再润色。
MCP Server 给 AI：文件读取、网页搜索、数据库查询、浏览器控制这些外部能力。

一个偏方法论，一个偏连接能力。

它们可以配合，但不是同一种东西。

1.16. MCP 最大的坑：权限边界

在这里插入图片描述

MCP 最容易被低估的问题是安全。

因为一旦你接入 MCP，AI 就不只是聊天。

它可能真的能读文件、查数据库、发请求、改东西。

这里一定要注意：

不要把整个磁盘随便暴露给文件系统 Server。
不要把生产数据库写权限直接交给 AI。
不要安装来路不明的 MCP Server。
不要让工具调用完全无确认。
不要把包含密钥、客户数据、隐私信息的资源无脑喂给模型。
不要忽略 Server 返回内容里的提示词注入风险。

MCP 越强，越需要边界。

如果你要在公司内部落地，至少要考虑：

最小权限
用户确认
操作审计
数据脱敏
Server 来源可信
工具调用日志
生产环境隔离

这些东西听起来麻烦，但它们不是“企业洁癖”，而是 MCP 真正进入工作流以后必须补上的刹车。

1.17. 新手应该怎么学 MCP

如果你是新手，我建议按这个路线来。

第一步，只理解概念。

先搞清楚 Host、Client、Server、Tools、Resources、Prompts。

第二步，跑一个现成 Server。

比如文件系统、Git、GitHub 这类常见 Server。先体验 AI 多了外部能力之后，到底有什么变化。

第三步，用 Inspector 调试。

看清楚一个 Server 暴露了哪些能力，每个 tool 参数是什么，返回什么。

第四步，写一个最小 Server。

不要一开始就写复杂系统。先写一个计算器、一个读取固定文件的 resource、一个固定 prompt。

第五步，再考虑复杂场景。

比如认证、授权、日志、审计、远程部署、权限最小化、团队共享。

这个学习路线最稳。

不要一上来就研究几十个 MCP Server，也不要一上来就接生产数据库。

先把最小闭环跑通。

1.18. 最后总结

MCP 的本质不是“又一个新插件”。
它真正想做的是：让 AI 应用用一套标准方式连接外部世界。
从个人开发者角度看，你可以用 MCP 给自己的 AI 工具加能力。
从团队角度看，你可以用 MCP 把内部系统包装成标准接口，让不同 AI 客户端复用。
从安全角度看，你必须把每一次数据访问和工具调用都当成真实权限来管理。

最后记住一句话：

先跑通，再理解；先最小权限，再扩展能力。
这就是 MCP 从入门到入土最重要的一条主线。

1.19. 参考资料

Model Context Protocol 官方入门：https://modelcontextprotocol.io/docs/getting-started/intro
MCP Specification 2025-11-25：https://modelcontextprotocol.io/specification/2025-11-25
MCP Architecture：https://modelcontextprotocol.io/docs/learn/architecture
MCP Transports：https://modelcontextprotocol.io/specification/2025-11-25/basic/transports
MCP Tools：https://modelcontextprotocol.io/specification/2025-11-25/server/tools
MCP Resources：https://modelcontextprotocol.io/specification/2025-11-25/server/resources
MCP Prompts：https://modelcontextprotocol.io/specification/2025-11-25/server/prompts
MCP SDKs：https://modelcontextprotocol.io/docs/sdk
MCP Inspector：https://modelcontextprotocol.io/docs/tools/inspector
Anthropic 发布 MCP：https://www.anthropic.com/news/model-context-protocol